We solved coding. Now what?
For a long time, building software followed a path that felt direct and continuous, even if it was not always easy. A developer could understand a problem, think through a solution, write the code, test it, deploy it, and then keep an eye on it once it was live, all without too much distance between those steps. The work stayed close enough to one person, or at least a small group, that context did not get lost along the way.
As systems grew, that way of working stopped being realistic, and we started to build structure around the difficulty of writing code. Product, design, QA, and management helped reduce the cognitive load on developers, and for a long time that trade-off made sense because coding was slow, expensive, and risky. But every layer we added also introduced handoffs, delays, and small gaps in understanding. Over time, those gaps began to matter more than anyone expected.
Because coding was the hardest part, it made sense to shape this whole process around protecting it. It was not elegant, but it fit the constraints of that time. That is, until AI showed up.
Now we can see it
AI did not make software simple, but it made code fast enough that everything around it became impossible to ignore. Turning an idea into working code used to take time, and that delay quietly absorbed a lot of friction that existed in the system. That made it easy to blame implementation and move on without looking too closely at what was really happening.
Now that coding can happen almost instantly, that buffer is gone, and the rest of the system is suddenly exposed. Unclear requirements stop being a small annoyance and become the thing that blocks progress. Slow decisions become the bottleneck that they always were.
AI did not create these problems. It made them visible, which is also why many ideas from extreme programming still feel relevant today. Tight feedback loops, fast validation, and keeping decisions close to execution were never really about speed alone, they were about keeping understanding and building connected. That matters even more now that we are faced with this new reality: the code itself is no longer the bottleneck.
Speed meets chaos
AI acts like an amplifier, which sounds great until you realize that it does not care what it is amplifying. In a healthy environment, faster implementation means faster learning, because teams can explore ideas, test assumptions, and validate decisions with much less friction than before, creating a strong sense of momentum.
In a messy environment, though, that same speed pushes everything in the wrong direction much faster. Teams can generate more code, explore more directions, and ship more changes, but without clarity and alignment, that just means more unfinished thinking entering the system and more complexity being created in less time. It becomes a very efficient way to make things worse.
That is where things start to feel strange, because it becomes easy to confuse motion with progress. More features, more prototypes, more pull requests, more deployments, all of it looks productive at first, but over time the cracks start to show in weak testing, shallow reviews, security gaps, and decisions that were never thought through properly. The speed feels great right until it starts to leak in ways that are hard to ignore.
And this is not only an engineering issue, because every part of the system becomes faster at the same time. Product can introduce more ideas, design can explore more variations, and engineering can implement more paths, but if the structure still depends on fragmented ownership and long handoffs, then all that extra speed just hits the same limits harder.
At some point, it becomes clear what is really slowing things down.
Now we have to face it
The real shift is not that software became easy, but that code stopped being a convincing excuse for why things move slowly. The complexity did not disappear, it simply moved to other parts of the system, where it is harder to ignore and harder to justify.
That complexity now shows up in decisions, in alignment, in how teams are structured, and in the growing gap between how fast we can build and how slowly we still move when it comes to understanding what should be built in the first place. Keeping the same organizational model and just adding AI on top of it starts to feel uncomfortable, because it produces more code without necessarily producing more clarity.
In some teams, that leads to more rework, in others it leads to more waste that looks like progress, and in the worst cases it leads to shipping confusion at scale. The system becomes faster, but not better, and that difference starts to matter more over time.
So, what is the next step? My guess is that the next step in software development is not another round of optimizing how we write code, but a deeper look at how we organize the work around it. It means questioning how many handoffs we really need, how fragmented ownership should be, and how much value comes from people who can carry context from the problem all the way to the solution.
At the end of the day, if coding got faster while everything else stayed in its tracks, our real problem cannot lie anywhere but in bridging those gaps. And maybe, there is an even deeper layer to all of this: it might be the time to go back to the fundamental questions of the problems we are solving and why certain pieces of software even justify their existence. But that, I will leave for another time.