AI is writing software at speeds previously considered unthinkable. However, when I look around at the software I use every day (Gmail, Canvas, Mac, apps on my iPhone, Zoom, GitHub, etc.), I don’t see a large increase in the number of new features that were not around a year ago. This despite a very public push from large companies to increase their AI use. To borrow a quote from William Gibson, the (AI enabled) future of software is here, it’s just not very evenly distributed. In this post I will explore that uneven distribution, and argue that it happens for a reason.
To be clear, I am not claiming that there has been no impact from AI. While there is not an observable speedup to the development of features some existing software, there has been a wave of new software being released which is written by AI. Some examples include an Operating System, Developer Tools, the Epic Games launcher, games, a social media app, even Photoshop replacements (although at the time of writing, the quality is spotty). Additionally, there is an entire suite of custom scripts that I now use almost every day that I have written with AI to help me with a wide range of small tasks that wouldn’t have been feasible before AI, everything from throwaway scripts to enter a rubric into Gradescope, to a cyber-physical system to track attendance.
These are my (admittedly anecdotal) observations, but there is research findings that back them up. In this paper from Harvard, researchers look at a large dataset of approximately 300 million work events of 700,000 workers across 700 firms. They find that the adoption of AI agents leads to large and significant increases in lines of code (30%), commits (20%), and PRs (23%). These numbers are consistent with what I hear from talking to people in the industry, as well as in other literature. However, when they look at features deployed to production, they only find small (statistically insignificant) positive effects. How is it the case that so much more code is being written, but the amount of features we see varies so widely in different types of software?
It could be that there is a lag between features being written and features being released to the public. However, given the prevalence of Continuous Deployment, it seems unlikely that most major large companies are sitting on 6 to 9 months’ worth of software features just waiting to deploy them.
Another potential explanation for this is that these larger companies have been trying to push LLM features at the expense of all other features. While we do see “sparkle buttons” everywhere and see some AI-enabled features, for example Zoom’s AI Companion, I am not seeing enough of these features to account for 30% extra features being shipped as compared to the pre-AI velocity.
So what is going on here? What could be an explanation for what we are seeing?
Let’s take a step back and see exactly what claims were made by the AI developers. In early 2026, Dario Amodei made waves when he said there were engineers at Anthropic who don’t write code. They just do “all the things around the code.” He then said “I don’t know. We might be 6 to 12 months away from when the model is doing most, maybe all of what SWEs do end to end.” It is interesting to note that while the predictions of coding being overtaken by AI have become true, it seems that we are not seeing the same gains in software engineering tasks as we see in code writing.
The reason we see differences in the effectiveness of AI building software is not about the code. It is about the software engineering work that must be made for large complex software systems (or what Amodei called “what SWE’s do end to end”). The challenges of coordinating large, complex projects are discussed in the book The Checklist Manifesto. The author, Atul Gawande, starts by discussing the impressive results in the medical field that have come from the introduction of checklists into their process. Specifically, in medicine, there were some pretty eye-popping results from the improvements made by adding a simple, five-step checklist into the process of adding an IV line. This works great for small, well-defined tasks, like inserting an IV, and these are the same types of tasks that AI is great at performing. However, what do we do when there are tasks that are too complex for a checklist to be developed a priori, for example, in the construction of skyscrapers? Gawande investigates this, and what he finds is that there is still the concept of a checklist, but it is not an explicit task list. Instead, it is a document that describes a series of conversations that must happen before the building can move to the next stage. The example he gives is that the electricians have to talk to the drywallers before they close up the walls. This is because there are tasks that are too complex to be described upfront, and experts need to have conversations as the task goes along to ensure the project is still on track and that each step is being done properly.
I argue that building a large software project is on the complex end of this spectrum, more like building a skyscraper than inserting an IV. It is not something that can be reduced to a short checklist. Instead, it is a large, complex project that involves an entire team of experts, who all need to use their expertise in order for the project to be successful.
This isn’t a new idea. In 1986, Fred Brooks wrote an essay called No Silver Bullet, where he argued that no single new technology would give us an order of magnitude improvement in software productivity. His reasoning was that there are two kinds of complexity in software. Accidental complexity comes from our tools: the languages, the compilers, the work of translating an idea into something a machine can actually run. Essential complexity comes from the problem itself: figuring out what the software should do, and making sure all of the pieces fit together. While in the 80s, Brooks argued that most of the big gains against accidental complexity had already happened, in the last few years AI certainly has drastically further reduced it. However, even if we could completely eliminate accidental complexity, there would still be essential complexity. Brooks summarized this by saying the hardest part of building software is “deciding precisely what to build.”
While AI is the biggest leap we have had at solving accidental complexity in my lifetime, solutions still need to deal with essential complexity. Someone still has to decide what the software should do. If you look at some of the biggest successes in AI development, we see a lot of projects run by a single developer or a very small team, (e.g., Omarchy) who can unilaterally make decisions about what the software should do, or projects that can be done in an automated fashion where there is a clear oracle for correctness (e.g., re-implementing old programs such as Halo). These projects shine because of the reduced complexity of making decisions about what to do next. When we look at systems with lower feature velocity, we see large software projects having to decide which features to add to existing products when there are no obvious correct answers, and there are a large group of experts and stakeholders, who all have different goals and different priorities. Getting these groups to work together is similar to the complex conversations Gawande describes between the electricians and the drywallers as a skyscraper is being built. If the coding gets faster but the conversations don’t, then more code without many more features is exactly what we should expect to see. The future (of AI software) is already here — it’s just not very evenly distributed. Why? Because the challenges of building software are not evenly distributed. A single developer can have a singular vision and implement it at a rate unheard of before. AI can churn away creating code when there is a clear oracle. However, when it comes to making complex decisions in a complex environment without clear answers, just being able to write more code doesn’t mean that more features will ship. Essential complexity still exists, and while AI can dramatically speed up the Software part of Software Engineering, there are still Engineering challenges when building software solutions. We shouldn’t pretend that removing accidental complexity will eliminate the essential complexity. However, I for one am excited about a future where software engineers can focus on solving essential problems, and not just typing out code.