Shifting structures in a software world dominated by AI. Some first-order reflections (TL;DR at the end):

Reducing software supply chains, the return of software monoliths – When rewriting code and understanding large foreign codebases becomes cheap, the incentive to rely on deep dependency trees collapses. Writing from scratch ¹ or extracting the relevant parts from another library is far easier when you can simply ask a code agent to handle it, rather than spending countless nights diving into an unfamiliar codebase. The reasons to reduce dependencies are compelling: a smaller attack surface for supply chain threats, smaller packaged software, improved performance, and faster boot times. By leveraging the tireless stamina of LLMs, the dream of coding an entire app from bare-metal considerations all the way up is becoming realistic.

End of the Lindy effect – The Lindy effect holds that things which have been around for a long time are there for good reason and will likely continue to persist. It’s related to Chesterton’s fence: before removing something, you should first understand why it exists, which means removal always carries a cost. But in a world where software can be developed from first principles and understood by a tireless agent, this logic weakens. Older codebases can be explored at will; long-standing software can be replaced with far less friction. A codebase can be fully rewritten in a new language. ² Legacy software can be carefully studied and updated in situations where humans would have given up long ago.

The catch: unknown unknowns remain unknown. The true extent of AI’s impact will hinge on whether complete coverage of testing, edge cases, and formal verification is achievable. In an AI-dominated world, formal verification isn’t optional—it’s essential.

The case for strongly typed languages – Historically, programming language adoption has been driven largely by human psychology and social dynamics. A language’s success depended on a mix of factors: individual considerations like being easy to learn and simple to write correctly; community effects like how active and welcoming a community was, which in turn shaped how fast its ecosystem would grow; and fundamental properties like provable correctness, formal verification, and striking the right balance between dynamic and static checks—between the freedom to write anything and the discipline of guarding against edge cases and attacks. As the human factor diminishes, these dynamics will shift. Less dependence on human psychology will favor strongly typed, formally verifiable and/or high performance languages.³ These are often harder for humans to learn, but they’re far better suited to LLMs, which thrive on formal verification and reinforcement learning environments. Expect this to reshape which languages dominate.

Economic restructuring of open source – For decades, open-source communities have been built around humans finding connection through writing, learning, and using code together. In a world where most code is written—and perhaps more importantly, read—by machines, these incentives will start to break down.⁴ Communities of AIs building libraries and codebases together will likely emerge as a replacement, but such communities will lack the fundamentally human motivations that have driven open source until now. If the future of open-source development becomes largely devoid of humans, alignment of AI models won’t just matter—it will be decisive.

The future of new languages – Will AI agents face the same tradeoffs we do when developing or adopting new programming languages? Expressiveness vs. simplicity, safety vs. control, performance vs. abstraction, compile time vs. runtime, explicitness vs. conciseness. It’s unclear that they will. In the long term, the reasons to create a new programming language will likely diverge significantly from the human-driven motivations of the past. There may well be an optimal programming language for LLMs—and there’s no reason to assume it will resemble the ones humans have converged on.

TL; DR:

• Monoliths return – cheap rewriting kills dependency trees; smaller attack surface, better performance, bare-metal becomes realistic
• Lindy effect weakens – legacy code loses its moat, but unknown unknowns persist; formal verification becomes essential
• Strongly typed languages rise – human psychology mattered for adoption; now formal verification and RL environments favor types over ergonomics
• Open source restructures – human connection drove the community; AI-written/read code breaks those incentives; alignment becomes decisive
• New languages diverge – AI may not share our tradeoffs; optimal LLM programming languages may look nothing like what humans converged on

¹ https://x.com/mntruell/status/2012825801381580880?s=46&t=iVWn6Dak9g-Ei-XSbI6BXw… ² https://x.com/anthropicai/status/2019496582698397945?s=46&t=iVWn6Dak9g-Ei-XSbI6BXw… ³ https://wesmckinney.com/blog/agent-ergonomics/… ⁴ https://github.com/tailwindlabs/tailwindcss.com/pull/2388#issuecomment-3717222957…

From Human Ergonomics to Agent Ergonomics – Wes McKinney

Source: https://wesmckinney.com/blog/agent-ergonomics/ I have been building a lot of new software in Go. Except that I’ve never actually written a line of Go in my life.What is going on?

Anyone following myLinkedInorTwitter/Xfeed has seen that I have been down a coding agent rabbit hole in recent months. This has included:

• moneyflow, a TUI accounting system (written in Python)
• roborev, a continuous background code review system (written in Go).roborev has totally transformed my productivity, by the way.
• VibePulse, a mediocre version ofCodexBar(written in Swift)
• agent-session-viewer, a session history viewer and search tool for your coding agent sessions (written in Python)

I have multiple other in-progress projects I’ve been creating on nights and weekends that I either plan to open source in the future or retain just for me. I’m working harder and having more fun building than I have in years.

Python and Agents

Python remains a remarkably effective language. It’s concise, readable, and has one of the strongest ecosystems of libraries of all time.

But agentic engineering is different:

• Fast compile-test cycles matter more than code simplicity and readability. Agents compile-and-test one-to-two orders of magnitude more often than their human counterparts, so any extra friction here is punishing.
• Painless software distribution feels essential. You may create numerous tools to enable your “agentic loop” and self-contained, dependency-free binaries accessible in a coding agent context feel like the right modality.
• Human ergonomics matters less when humans aren’t the primary authors.

In this context, Python has weaknesses: its test cycles are relatively slow and distribution has challenges (thoughuvhelps). Dragging around a Python interpreter has started to feel like the Java Virtual Machine from which we tried so desperately to unburden ourselves.

Thereasonsthat Python has gotten so popular (and why I went down the Python rabbit hole back in 2007 and dedicated many years of my life to popularizing Python for data analysis) are that it is productive and pleasant for humans to write and use. As the hours and days pass by, this benefit feels increasingly moot compared with the evident downsides (performance, memory use, distribution, etc.), especially with an agent doing all the coding for you.

***Put another way, human ergonomics in programming languages matters much less now.***The readability and simplicity benefits of Python help LLMs generate code, too, but viewed through the “annealing” lens of the iterative agentic loop, quicker iterations translate to net improved productivity even factoring in the “overhead” of generating code in a more verbose or more syntactically complex language.

Frictionless Development and Shipping

The winners of this shift to agentic engineering are the languages that have solved the build system, runtime performance, packaging, and distribution problems. Increasingly that looks like Go and Rust:

• Painlessly build static binaries with zero runtime dependencies
• Predictable dependency management and code sharing
• Fast, deterministic builds
• Lean resource footprint, no just-in-time compilation, good runtime performance

From my experience, Go even has a substantial edge over Rust due to its ultrafast compile times for release builds (while Rust release builds can take minutes of linking and optimization). Rust has memory safety without garbage collection and deterministic resource management, while Go trades some of that control for faster compilation and a simpler concurrency model. Some projects may choose one or the other purely based on these characteristics (with Rust’s slower compile-test loops as an acceptable tradeoff).

For now, LLMs have strong Python programming skills because of the massive amounts of training data mined from GitHub and the broader internet, and so it may be that average code quality is better in Python now than it is in Go or Rust, but perhaps after multiple agentic iterations and automated code reviews, it may be good enough.

To be clear, I am not trying to say that Go and Rust are not very ergonomic for humans. These are already popular languages that we all use for critical applications, such as Docker, Kubernetes, Terraform, Deno, or uv. What’s interesting is that agents have made these languages much more accessible beyond their prior core user base of heavy duty systems engineering. Go is a great language to program in for systems work, microservices, and distributed computing, but in general there is more of a learning curve to working in it and in the past building a Go project as a rule of thumb would take longer than building the same project in Python.

What about Data Science and AI?

Python isn’t going anywhere as long as its moat as a language for data work and ML/AI inference and training persists. The ecosystem of NumPy, pandas, PyTorch, and all the other popular projects represents decades of accumulated expertise, institutional knowledge, and muscle memory. While some projects may be reimagined in systems languages intended primarily for agents, the ecosystem inertia (and abundant training data) will continue for a long time.

What has changed is where the durable value actually lives. It is increasingly useful to separate the stack into a few layers:

• The computing, IO, and compiler kernel libraries based on CUDA, compiler frameworks like MLIR or JAX’s XLA, and of course Apache Arrow.
• The database systems and caching layers, ideally connected withADBC’s zero-serialization connectivity.
• The language bindings and orchestration layers that expose those capabilities.
• The application or agent interfaces that sit on top.

When viewed this way, most of the long term value clearly resides in the first two layers (compute and data access), not the last two.

Code review: more machine than man

An obvious downside in shifting away from Python is that I have much less experience reading and judging the quality of Go code or Rust code. This is part of why I builtroborev, not just because agents’ commits are full of bugs and imperfections, but also because I’m definitely less effective manually reviewing languages I never used pre-AI.

Not the End for Python, but the End of an Era

Python will remain essential as an exploratory computing layer for humans and agents to collaborate on data analysis, research, and data visualization. Notebook layers (Jupyter, Marimo, and so forth) and hybrid IDEs (like Positron, where I’ve been contributing in the last couple of years) will increasingly focus on catering to the human-in-the-loop data scientist or ML engineer, even though the “Python part” may become thinner and thinner as the lower layers of the stack are re-engineered for performance and agentic engineering productivity.

Regardless, I’m proud of what we have accomplished in building the Python ecosystem and how it has democratized data science and ML/AI work. I still love the language, but it seems clear that I and much of the industry will be writing less and less of it given the agentic-loop productivity benefits of Go and other modern compiled languages. Where the road leads from here we will soon see.

Thanks to Josh Bloom, Ian Cook, Pete Jarvis, and John Zila for their helpful feedback on this post.