What's Next For Software
The software development industry is moving faster than ever before. To some degree that’s a tautology: software, like the universe, is constantly expanding and constantly accelerating. But AI has created an angle-change.
One of the founders of Cursor tweeted that Cursor writes about a billion lines of code a day while the world produces only a few billion in total. Alone this is staggering, but I suspect that his second metric is already out of date. Between v0, bolt and Lovable to Windsurf, Claude Code and Copilot to the internal tools at Meta and Google, Cursor is just one of many new tools contributing to a LoC (lines of code) explosion.
https://x.com/amanrsanger/status/1916968123535880684
When things are moving this fast, it’s hard to really know what you can grab hold of. So what types of assumptions about the future might be able to ground us? Where is the terra firma?
One frame we can start with is simple inputs and outputs for business outcomes. And I think we can say two things relatively confidently:
AI generated software as an input is on an exponential growth path and will soon represent almost all code running in production outside of some legacy or particularly sensitive systems (or maybe not)
From a business outcome perspective, there will be humans that are ultimately responsible for this code.
These statements shouldn’t be controversial, but they do have a wide array of implications.
All code is AI code
The very first and simplest implication of essentially all code being generated by AI is that the ratio of LoC to engineer and, more concretely, number of features or services in a given system per engineer is going to increase commensurately. Uh oh! Engineers aren’t good at maintaining the software already!
This will compound with the fact that the engineers will understand the code much much less than before. To be honest, the bond that kept engineers close to the code was already tenuous. As the bottleneck for most projects and as natural optimizers, engineers often take shortcuts and commit code they don’t fully understand (pour one out for copying and pasting from Stack Overflow). Most teams know the pain of having one of the core authors of the codebase leave. Now that’s just our steady state.
Consequently, we should expect a large number of tools, equal to the size and impact of code generation tools to emerge on the maintenance side. Importantly, this side is much more difficult. While code generation is almost perversely suited for LLMs (isn’t it kind of amazing we’re still just editing text files?), modeling and understanding of broad architecture, collecting institutional knowledge, and understanding of business and user intent are still areas where AI has deficiencies. While these tools will lag code gen, they’ve already started popping up (but haven’t yet found the PMF of things like Cursor). They will address all aspects of maintenance, from code organization, to unit testing to acceptance testing to debugging to incident response and more.
The buck stops with people
On the other end of the spectrum, while engineers won’t be as responsible for producing code, they will be ultimately responsible for what that code does. A VP or CEO can blame an AI all they want when the system is down, but if the AI can’t solve the problem, it can’t solve the problem. And I don’t expect firing the AI will be very cathartic.
It’s hard to imagine a future where humans aren’t the last line of defense for maintenance, debugging, incident response, etc. Paired with the above—that they’re vastly outnumbered by the quantity of services and features and more divorced from the code that’s running than ever before—being that last line of defense is a tall order.
We should expect a rough few years of software incidents as we navigate this new paradigm, with some being extremely painful. On the other hand, in response to that, we should also expect many incidents to be prevented or mitigated automatically and much faster by AI! In fact, this is almost a requirement for this new paradigm to find a functioning equilibrium at all.
Designing tools for automation and human legibility
To oversimplify, I think you can imagine maintenance tools as a market counterbalance to code generation tools and they’ll emerge along three layers:
The AI layer: fully automated defense and prevention. This is the most obvious and we’re seeing it already: review Pull Requests, write unit tests, AI SRE / incident response etc.
The human layer: Tools to help people debug and triage better than ever before. These will look different than the past generation of tools, because the past generation of tools were built on different premises and assumptions. New tools will need to do more work to connect engineers to the code and the state of the application. They cannot assume that the engineer is deeply familiar with either.
The glue in between these two. Tools will use AI to create much more legibility for humans. This is already happening at the code understanding layer (generated docs, etc), but will grow to include the full lifecycle: Augmented bug reports, better, accurate and semantic logging, and more. So far, the focus has been on increasing legibility for AI. This will need to shift back to humans as the maintenance burden grows.
One throughline of all of these tools is that the successful ones will not only create counterbalances for code generation by providing better maintenance, but they’ll also counterbalance cognitive load for an engineer. We’ll be asking each engineer to understand more overall than ever before while also asking them to context switch into things they understand less than ever before. Introducing new workflows, complicated documentation, setup or config will cap the growth of all tools but the very very best. The winners will respect the workload and priority of the engineer and use AI to reduce the cognitive overhead, friction of setup and adoption.
Given the acceleration of the last few years, it’s hard to predict at any level of granularity what software will look like five years from now, but I do think we can say a thing or two for sure: AI will be writing most of the code and all of our oncall shifts are about to get a lot busier.