Intent & Execution - The Bottleneck Moved Upstream

Writing code has become substantially faster and cheaper. Defining exactly what that code should achieve, however, remains as difficult as it has always been.

Every major shift changes where the constraint sits

Over the last 25 years, I've watched each major shift in software engineering address a different constraint in how we build and operate software. Waterfall attempted to enforce predictability in requirements. Agile recognized that learning happens through iteration and shortened the feedback loop between building and user response. DevOps automated the operational overhead of deployment, turning releases from infrequent crises into routine background processes. What I've found interesting across those transitions is that solving one constraint rarely eliminates the constraint; it usually exposes another one somewhere else in the lifecycle.

AI is now altering the economics of implementation. Work that previously required weeks of dedicated engineering can increasingly be drafted, tested, and assembled in hours. Modern agentic workflows are taking on planning, scaffolding, and iterative error correction.

When implementation stops being the primary constraint, the real bottleneck moves upstream: deciding what should actually be built, defining the governing constraints, and validating that the output genuinely solves the underlying problem.

The scarce resource changed

For most of my career, engineering capacity has been the scarce resource. Organizations always had more reasonable ideas than developers available to build them. A lot of the management machinery we've built around software, from roadmaps and prioritization to business cases and sprint planning, exists because engineering capacity has always been expensive and constrained.

That dynamic changes when implementation becomes abundant. Lowering the cost of execution means ideas that were previously shelved for lack of engineering bandwidth can now be tried immediately. The primary operational question is rarely whether an engineering team can build a feature, but whether the problem has been understood clearly enough to warrant building it at all.

Anyone who has spent time building software knows that requirements are never as fixed as they look at the beginning of a project. Software will always evolve through real-world use. But as execution cycles compress, ambiguity in intent produces wrong answers much faster.

Capability isn’t accountability

AI can analyze requirements, propose system architectures, and generate test suites, but it cannot own the outcome. A system can generate clean, performant code that passes every unit test while entirely missing the business intent. A passing test suite only proves that the implementation matches the prompt, not that the prompt addressed the right problem. Technical execution can be automated; accountability for the result cannot.

Judgment moved up the stack

None of this suggests that deep technical discipline is obsolete. Code is still what runs in production. When a system fails under load or suffers a security compromise, the operational reality of the codebase is what matters. In many respects, validation, systems thinking, and architectural rigor become more critical as the volume of generated code increases.

What is changing, in my view, is where experienced engineering judgment creates the most value. The technical precision historically required at the level of syntax is now equally required earlier in the process: in framing problems, establishing boundaries, and critically evaluating whether what was generated actually meets the standard.

Many engineering organizations can readily demonstrate how much faster they can ship today compared to two years ago. Fewer can demonstrate that they have improved the discipline with which they decide what to ship in the first place. As implementation continues to accelerate, the clarity of the direction given to that engine is what determines the outcome.