What happened during the holiday period of 2025-2026 will be studied in history books.
As we all had some breathing space and time to think, we are realizing an entirely new practice for building software is emerging in front of us, and there’s no way back. Software leaders around the world are shocked (shocked!) about the capabilities of coding agents + frontier models. From anonymous startup CTOs and Anthropic education leaders, to popular AI company founders and preeminent thought leaders. Hell, even software contrarians! All of them are now, and only now, converging on the same conclusion: software engineering has changed forever, and for the better, thanks to AI.
We've seen amazing things, but the Claude Code + Claude Opus 4.5 kill combo takes the cake. I am grateful we can see this unfolding live before our own eyes. What a time to be alive and love computers!
The disappearing middle of software work
Amongst all the content posted online during this holiday season, this post from Linear's CEO made me think the most. Karri contends that as AI agents thin out the work of translating intent into code, the real craft of software shifts upstream, away from writing code and toward forming clear intent, context, and constraints that make execution meaningful.
And I absolutely agree with this. I have written about the Theory of Constraints (ToC) in software before .... and this is textbook ToC behavior.
Let me explain.
Engineers move with the constraint
There is a growing narrative around AI-assisted software development that goes something like this:
"Now that agents can produce large amounts of working code, the bottleneck has moved to the right. Code review the new constraints of the system. Look at all those PRs piling up!"
I don’t think this interpretation holds up when you look at it through the Theory of Constraints. In fact, I think it misunderstands where the real leverage in the system now lives.
Theory of Constraints, as formulated by Eliyahu M. Goldratt in his seminal book The Goal, starts from a simple but unforgiving premise: at any given time, a system has exactly one dominant constraint. Improving anything else may reduce local pain, but it will not improve overall throughput. When that constraint is elevated, it does not disappear. It moves. And when it moves, the work that matters moves with it.
This has already happened several times in the history of software. And it's happening again.
This has already happened before
Taking a very reductionist perspective to explain my point, software delivery could be seen as this high-level process:
Intent > Code > Check > Release
- Early on, software delivery was constrained by infrastructure. Provisioning machines, managing environments, deploying binaries, and keeping systems alive absorbed enormous amounts of effort. That was where progress slowed. When tooling, automation, and cloud platforms elevated that constraint (i.e., DevOps), engineers didn’t keep focusing on hardware. They moved. They shifted their attention to deployment pipelines, automation, observability, and system reliability. Not because it was trendy, but because that’s where leverage had gone.
- Later, the dominant constraint lived in the implementation itself. Turning intent into running software required deep familiarity with a codebase, manual wiring, and a lot of careful, hands-on work. The “middle” of the process (this is, between idea and shipped product) absorbed most of the time, attention, and craft of engineering teams. So engineers moved there, too. Writing code became synonymous with doing software work because that’s where the system was constrained.
Agentic coding changes this software delivery pipeline again. Not by removing work, but by elevating the implementation constraint. Now, large parts of the translation from intent to code are becoming cheaper and faster. The middle of the process thins out, and sometimes, it almost disappears. From a Theory of Constraints perspective, this has a very clear implication: the system constraint is moving!
Where it moves is where many people get confused.
Code review and testing are under pressure now, as more output flows through the system with less direct human involvement in writing it. Queues form. Friction appears at the end of the pipeline. That pressure is real, but pressure is not the same thing as a constraint. Theory of Constraints predicts exactly this pattern whenever a constraint is elevated: downstream stages experience stress before the system adapts.
If code review were truly the dominant constraint, then increasing review capacity would increase meaningful throughput. In practice, it doesn’t. You can review faster, test faster, and release faster, and still consistently build the wrong things at speed. When speeding up a step does not improve outcomes, it is not the system’s limiting factor. That's not the constraint, my friend!
The real constraint has moved upstream.
What agentic coding changes
Today, what limits software throughput is no longer our ability to write or review code, but to engineer clear intent. The bottleneck now lives in problem definition, context gathering, goal formation, and constraint articulation. Agents act directly on this input and do not absorb ambiguity, resolve tradeoffs implicitly, or “figure things out” while implementing. Whatever shape the intent has, they execute against it faithfully.
This is why the work that used to feel secondary (i.e., clarifying goals, shaping context, deciding what actually matters) is now the limiting factor of the entire system. And this is also why engineers will move again with the constraint to this step of the software delivery value chain.
They always do.
The emerging software engineering practice
Software engineers don’t hold on to legacy work; we know that. They move toward leverage. When infrastructure was the constraint, engineers became operationally fluent and started learning new technology (e.g., Cloud). When deployment was the constraint, they automated it (e.g., DevOps). When implementation was the constraint, they mastered code. Now that implementation is being elevated, engineers will shift their craft once more, not away from responsibility, but toward a different kind of responsibility.
The emerging craft of engineering is not primarily about writing code. It is about creating the conditions under which good solutions can emerge. That means having a good product mind, forming high-quality intent, assembling the right context, defining goals that matter, breaking work into coherent tasks, and encoding constraints and tradeoffs clearly enough that coding agents can act on them without distorting the outcome.
This is not a downgrade of engineering. It is engineering moving with the constraint, exactly as it always has.
The real mistake would be to keep optimizing the old bottleneck (i.e., code writing and review) after the system has already shifted. Theory of Constraints is clear on this point, even when it’s uncomfortable: progress comes from aligning effort with the constraint, not from defending familiar work.
Right now, the constraint is intent. And that is where engineers will do their most important work next.