PAPER
AI Does Not Replace Engineering Judgment
AI is accelerating how code gets written. It is not replacing engineering judgment, and confusing the two is where teams get into trouble.
The difference comes down to one question: who is driving?
AI Is Being Used in Two Very Different Ways
Teams are using AI in fundamentally different ways today, and the gap in outcomes between those approaches is widening.
In the first model, AI generates the system and the human reviews and adjusts. Architecture emerges during implementation rather than before it. Decisions are reactive, made in response to what the AI produced rather than in advance of it. This feels productive at first. Output appears quickly, upfront effort is low, and it is easy to get something running. For small or isolated problems, it is often sufficient.
But that early productivity masks a compounding problem. When architecture is accidental, system boundaries are unclear. As complexity increases, AI output drifts, not because the model degrades, but because the context it is operating in was never coherent to begin with.
Code that appears correct at the unit level fails to cohere at the system level. Scalability problems surface later, rework becomes inevitable, and the team discovers they were not accelerating. They were discovering the system while building it.
In the second model, the human defines architecture first. Constraints and boundaries are established before implementation begins. AI operates within that structure, executing clearly defined intent rather than making structural decisions on its own. This is the model that holds up.
Why the Second Model Scales
When the human drives, architecture is intentional. Service boundaries are explicit. System behavior is deterministic because the rules governing it were defined in advance, not inferred from generated output. AI output stays aligned because it has a coherent structure to align to. Iteration accelerates once design is set, failures are easier to reason about, and rework drops significantly.
The tradeoff is real. This approach is slower upfront. It requires strong engineering fundamentals and forces clarity before implementation begins. There is less immediate visible progress in the early stages. But this is front-loaded cost, not waste. It removes friction at every stage that follows.
What AI Cannot Do
AI does not fail because it writes bad code. It fails because it is asked to make decisions it is not equipped to make. Decisions about lifecycle boundaries, data ownership, coupling between services, failure modes, and long-term scalability are not implementation details. They are architectural commitments, and they require judgment grounded in understanding the system as a whole.
AI will generate something that works in isolation. It will not generate something that is correct in context without being told what "correct" means. The distinction matters enormously in production systems, and it is invisible until it is not.
How This Works in Practice
AI is the implementation layer. It is not the architect, the decision-maker, or the engineer. The engineer defines the system, establishes the constraints, and sets the contracts that govern how components interact. AI executes within those boundaries.
In practice, this means the work before the first line of code matters more than it ever did. Define requirements. Define architecture. Define service boundaries and the event model. Then implement one unit at a time, reviewing and validating output against the structure you established. Now AI is no longer guessing. It is executing clearly defined intent, and the output is coherent because the thinking behind it was coherent first.
The Bottom Line
AI accelerates writing code. It does not replace engineering judgment. The teams that treat it as a force multiplier, executing human-defined architecture with speed, will outperform the teams that treat it as a driver. Speed without direction is not an advantage. It is technical debt at scale.
If AI is driving, you get speed without direction. If you are driving, you get both. The difference is not the tool. It is who is making the decisions.
Continue reading
Papers