There is a version of the current AI moment that is genuinely exciting, and a version that is quietly alarming. Both are true at the same time.
The exciting version: the time and cost required to produce working code has collapsed. Things that once took weeks can now be produced in hours. The barrier between having an idea and having something functional has dropped to a degree that would have seemed implausible five years ago. For a certain kind of problem — well-understood, cleanly scoped, building on established patterns — this is a significant and real improvement.
The alarming version: the thing that has become easier is producing code. Not designing systems. Not making the structural decisions that determine whether a system will be cheap or expensive to operate, whether it will hold under load, whether it will remain changeable as requirements shift. Those decisions are as hard as they ever were — harder, in some ways, because the pressure to move fast has increased.
What gets reproduced
AI coding tools are trained on existing code. That code is, in aggregate, a record of how problems have been solved historically — including all the shortcuts, accumulated compromises, and structural decisions made under constraint. When those tools reproduce patterns, they reproduce the patterns, including their flaws.
This is not a criticism of the tools. It is a description of what they are. A model trained on how systems have been built cannot, on its own, tell you how a system should be built for your specific problem. It can tell you what a system in that domain typically looks like. Those are different things.
The structural decisions — where data ownership sits, how concurrency is managed, what the actual consistency requirements are — these have to come from someone who understands the specific nature of the problem. That is not something that can be delegated to a tool trained on historical patterns.
The constraint has shifted
For most of the history of software development, the bottleneck was production: writing the code. Good developers were valuable partly because they could produce correct, efficient code faster than their peers.
That bottleneck is dissolving. The constraint is moving upstream — to design, to structural thinking, to the decisions that happen before a line of code is written. The organisations that will do well in the next decade are not the ones that can produce code fastest. They are the ones that can make better structural decisions and use the new tools to implement them quickly.
This requires a different kind of expertise than the one that was valuable when writing code was the hard part.
What this means in practice
I see two patterns in the work I am being asked to do. The first is organisations that have used AI tools to build things quickly, and are now dealing with the consequences: systems that are structurally awkward, expensive to operate, or difficult to change. The second is organisations that want to get ahead of this — to make sure the structural decisions are right before they commit to building.
In both cases, the question is the same: what shape should this system actually be? Not what shape does it typically take in this domain. Not what shape can we produce fastest. What shape fits the actual problem?
That question has always been the important one. It is just becoming more urgent.
Getting ahead of the structural decisions?