We have spent an extraordinary amount of energy making AI better at writing code. We have spent far less redesigning engineering for a world where writing code is no longer the constraint.
That imbalance is starting to matter, and it will matter to the P&L before it matters to the codebase.
Claude Code, Codex, Copilot and the wider generation of coding agents are rapidly increasing how much software one engineer can create and change. The industry’s response has been predictable: better models, bigger context windows, better harnesses, more elaborate instructions. All of that helps. But it is optimizing the wrong side of the equation.
The rate at which we can generate change is beginning to exceed the rate at which humans can reliably understand and govern it.
If your organization can produce five times as much software, but architecture review, code review, security review and regression analysis remain predominantly human activities, you have not removed the bottleneck. You have moved it, and made it more expensive.
The next phase of AI Engineering cannot be about better code generation. It has to be about making software development significantly more deterministic.
Not deterministic models. Deterministic engineering.
The unit of control has to change
Most software organizations still govern change through the pull request. An engineer changes some code. Another engineer reads the diff. Tests run. Static analysis runs. Someone decides whether it looks reasonable.
That model worked when humans were also the constraint on how much code could be produced. AI breaks the assumption. An agent can touch fifty files as easily as five. Multiple agents can work in parallel. Refactoring across hundreds of classes is becoming cheap. The cost curve of software modification is collapsing.
The cost curve of human comprehension is not.
So the unit of engineering control needs to move from the code diff to the system invariant. Instead of repeatedly asking a human “does this still follow our architecture?”, the system should already know. Instead of asking whether this service may depend on that one, the build should know. Instead of hoping the agent remembers that one domain cannot reach into another’s persistence layer, the repository should make that dependency illegal. Instead of relying on a senior engineer to notice customer data flowing into the wrong component, the platform should flag the data flow automatically.
None of this is a new idea. What is new is how necessary it becomes when machines generate a meaningful share of the change.
We have been here before
One of the most reliable patterns in software engineering is that practices begin as human conventions and end as executable constraints.
- Formatting moved from style guides to formatters.
- Type expectations moved into compilers.
- Security rules moved into static analysis.
- Infrastructure expectations moved into policy-as-code.
- API compatibility moved into contract testing.
- Build reproducibility moved into hermetic build systems.
Architecture is next. The idea of architectural fitness functions has existed for years. Neal Ford, Rebecca Parsons and others at Thoughtworks described them as mechanisms for continuously evaluating whether a system’s architectural characteristics remain intact as it changes; in effect, automated architectural governance.
AI turns that from a good idea into a prerequisite. If software is going to change at machine speed, architecture cannot remain something communicated through slide decks, wiki pages and the institutional memory of senior engineers.
Architecture needs an execution model.
The tooling already exists in pieces. dependency-cruiser lets JavaScript and TypeScript teams declare which dependencies are forbidden, allowed or required, and fails the build when the dependency graph violates them. Nx extends the idea across large workspaces, tagging projects by scope or type and enforcing which categories may depend on which. Java has ArchUnit. .NET has ArchUnitNET and NetArchTest, the latter of which describes its goal as a self-testing architecture.
That phrase is the whole point. A self-testing architecture is what an engineering environment built for agents looks like.
The problem with AI is not that it writes bad code
The more interesting risk is that AI writes locally correct code that is globally wrong.
The method works. The tests pass. The API returns the right response. But the agent introduced a dependency that should not exist. It duplicated functionality another domain owns. It bypassed an abstraction. It built a second implementation of a pattern the enterprise already standardized. It solved today’s task while making tomorrow’s system harder to evolve.
Humans do this too. The difference is volume. When the marginal cost of one more implementation approaches zero, architectural entropy compounds much faster than any review process can absorb.
This is why more unit-test coverage will not save you. Unit tests ask, “Does this code behave correctly?” AI Engineering needs systems that also ask, “Is this code allowed to exist in this form?”
That is a different category of verification, and most organizations have almost none of it.
Determinism has to come in layers
Dependency constraints are one layer. A serious engineering control plane needs several, and the good news is that each layer already has mature tooling.
- Structure. Dependency direction, module boundaries and cycles, enforced by dependency-cruiser, Nx, ArchUnit or NetArchTest.
- Semantics. Code patterns, source-to-sink data flows and custom correctness rules, queried with CodeQL.
- Interfaces. Consumer–provider contracts that cannot be broken silently, made executable with Pact.
- Policy. Infrastructure, configuration and CI/CD rules as code, evaluated by Open Policy Agent and Conftest.
- Reproducibility. The same declared inputs produce the same build, guaranteed by Bazel’s hermetic model.
- Remediation. Repeatable, policy-driven refactoring and migration through OpenRewrite recipes.
CodeQL is worth a specific mention because it treats code as data. Organizations can write custom queries for patterns specific to their own applications, and its path queries reason about how information actually flows rather than searching for strings in files. That is the difference between “we told the agent not to log customer data” and “the build proves no restricted data reaches a logging sink.”
OpenRewrite matters for a different reason: it makes remediation deterministic too. Its recipes operate over semantic representations of source code, so a migration or policy fix runs the same way across every repository it touches.
Put those layers together and something bigger starts to emerge.
The coding harness becomes a verification harness
Today an “AI coding harness” means the environment around the model: repository instructions, tools, memory, context retrieval, skills, subagents, MCP servers, planning. All of it improves the model’s ability to create the change.
The next generation of harnesses will focus just as heavily on proving the change is acceptable.
I expect every material agent-generated change to eventually ship with something resembling a proof package. Not a mathematical proof in most cases, but a machine-verifiable body of evidence:
- Which components changed, with the dependency graph before and after
- Confirmation that no prohibited architectural boundary was crossed
- Which public contracts changed and which consumers are affected
- New data flows, with no restricted source-to-sink paths introduced
- The fitness functions and security policies that executed
- The affected test surface and the reproducible build artifact
- The approved exceptions
That fundamentally changes code review. The reviewer stops reconstructing all of this by hand from a 2,000-line diff and instead evaluates intent and exceptions.
Code review becomes exception review
This may be the largest organizational implication of agentic development. Human review today compensates for an enormous amount of undocumented engineering knowledge. A senior engineer looks at a pull request and says: “We don’t call that service from here.” “That library doesn’t belong in this layer.” “We already have an abstraction for this.” “That data can’t leave this boundary.”
Those comments are organizational knowledge, and the organization pays for that knowledge again every time someone reviews another pull request. AI makes that economically irrational. If a review comment recurs and can be expressed mechanically, it should become a rule.
Write the judgment once. Execute it forever.
That changes what senior engineers are for. Their leverage comes less from personally reviewing every implementation and more from converting architectural judgment into mechanisms that shape thousands of future implementations. That is a profound shift in what engineering leadership means, and it should change how you hire, promote and measure your most senior technical people.
ADRs need an execution target
This exposes a weakness in how we practice architecture today. We write Architecture Decision Records. We document that two services should communicate asynchronously, that one domain owns a given entity, which technologies are approved, where the security zones sit. Then we rely on humans to remember.
An ADR should increasingly have two outputs: the explanation of the decision, and the executable constraints that enforce it. Some decisions compile into dependency-cruiser rules. Others into ArchUnitNET tests, CodeQL queries, OPA policies, contract tests or infrastructure policies.
The ADR stops being historical documentation. It becomes source code for the engineering control plane.
The missing product is an architecture compiler
The weakness in today’s ecosystem is fragmentation. Each layer has its own rule model: dependency-cruiser has one, ArchUnit another, CodeQL another, OPA uses Rego, Pact has contracts, infrastructure and security scanners have their own.
The logical evolution is a higher-level, machine-readable model of engineering intent. Call it an architecture compiler. You describe the organization and the system once: these are the domains and the teams that own them; these dependency directions are legal; these data classifications exist and these systems may process them; these APIs are public; these libraries are approved; these components must stay independently deployable; these operations require human authorization.
The compiler then generates or coordinates the enforcement. One architectural rule might become a dependency rule, a CodeQL query, an OPA policy and a runtime observability check.
Architecture becomes something much closer to a type system for the enterprise. The model can generate almost anything it wants. Invalid architectures do not compile.
A new engineering metric
For years we have measured test coverage. AI Engineering suggests a more useful question: what percentage of our architectural decisions are executable? Not documented. Not communicated. Not in the developer portal. Executable.
That number may be a better indicator of readiness for autonomous coding agents than how many developers have installed an AI tool. An organization with sophisticated agents and weak architectural enforcement will simply create technical debt faster. An organization with strong executable architecture can safely give agents far more autonomy.
Where this is going
I do not think we make AI Engineering deterministic by eliminating the probabilistic nature of the model. That misses the point. The model should explore: find a better algorithm, refactor, let several agents propose competing implementations. But surround that creativity with an increasingly deterministic envelope. The model decides how to solve the problem. The engineering system decides what counts as a valid solution.
From the executive chair, here is how I expect the next few years to play out.
The envelope expands, in a predictable order. It starts with formatting, typing, tests and dependency rules. It grows into architecture, then security and privacy, then API and data contracts, then operational characteristics: cost, performance, resilience, observability, regulatory controls. Most of what your architecture review board discusses today becomes continuously executable. The goal is not more governance. It is governance at near-zero marginal cost.
The loop closes. Today a failed fitness function says no. The next generation says why. The agent reads the violation, understands the rule, replans and tries again. The deterministic system becomes the critic in the agent’s learning loop. Extend that into production and something compounding happens: an incident reveals a bad pattern, the fix becomes a CodeQL query or an OpenRewrite recipe, and neither a human nor an agent can reintroduce that class of failure again. Incidents become rules. Architecture decisions become tests. Review comments become policies. Migration knowledge becomes recipes.
Autonomy gets rationed by enforcement, not by trust. Boards and CISOs will start asking how much unsupervised change the organization allows agents to make. The honest answer will be a function of how much of your architecture is executable. Teams with strong envelopes will run agents on long-horizon tasks overnight. Teams without them will stay stuck at autocomplete with extra steps, and they will not understand why their competitors are moving faster.
The competitive advantage is not the model. Models will keep improving and the frontier will keep moving, but most organizations will have access to broadly similar coding intelligence. The hard-to-replicate asset is the deterministic engineering system around it: the accumulated rules, the dependency graph, the domain contracts, the refactoring recipes, the production learnings, the thousands of pieces of institutional knowledge converted from something a senior engineer knows into something the platform executes. Unlike the model, that harness is specific to your business, and it appreciates with every incident you survive.
Engineering leadership changes shape. The senior engineer’s job shifts from reviewing implementations to authoring constraints. The architect’s job shifts from producing diagrams to producing executable intent. The technology executive’s job shifts from managing headcount that writes code to managing a control plane that governs change. Organizations that keep measuring engineering by lines produced or tickets closed will misallocate their best people for years.
How to start preparing
None of this requires waiting for an architecture compiler to exist. The pieces are available today, and the organizational work matters more than the tooling. Here is where I would start.
- Measure your executable-architecture ratio. Take your last twenty ADRs, standards and architecture-board decisions. For each one, ask: if an agent violated this tomorrow, would anything automated notice? Most organizations discover the answer is under 10%. That number is your baseline and your roadmap.
- Mine your code reviews. Pull six months of review comments and cluster them. Any comment that appears more than a handful of times and can be expressed mechanically is a rule waiting to be written. This is the cheapest, highest-yield source of constraints you have, and it converts your senior engineers’ judgment into platform capability.
- Start with dependency direction. Structural rules are the easiest layer to make executable and the one agents violate most often. Pick your stack’s tool (dependency-cruiser or Nx, ArchUnit, ArchUnitNET or NetArchTest) and encode your domain boundaries in one flagship repository. Run it in warn mode for a month, then fail the build.
- Give every new ADR an execution target. Change the template. An ADR without a corresponding test, query, policy or contract needs an explicit justification for why it cannot be enforced. Do not retrofit everything; just stop creating unenforced decisions.
- Turn the next incident into an invariant. After your next material production incident, add one step to the postmortem: what rule, query or recipe would have caught this? Ship it. Make this a standing expectation, not a one-off.
- Wire the feedback into the harness. Make sure fitness-function failures produce readable explanations, then feed them back to the agent instead of just to the human. This is the first step toward the closed loop, and it costs very little.
- Redefine senior roles. Add “constraints authored” and “decisions made executable” to how you evaluate principal engineers and architects. Reward the person who wrote the rule that prevented a hundred review comments over the person who wrote the hundred comments.
- Tie agent autonomy to enforcement coverage. Set an explicit policy: repositories with strong executable architecture get more agent latitude; repositories without it do not. This gives teams a reason to invest and gives your risk and security functions a defensible model.
Do the first three this quarter. The rest follows naturally once the organization sees review load drop and agent throughput rise in the flagship repository.
AI Engineering needs to grow up
The first generation of AI Engineering has been concerned with one question: how much code can the model produce?
The next generation has to answer a harder one: how much change can the organization safely absorb?
Those are very different problems. As the cost of producing code keeps falling, architecture, verification and control become proportionally more valuable. Human review cannot be the scaling mechanism. Documentation cannot be the enforcement mechanism. Prompt instructions cannot be the architecture.
The organizations that reach autonomous software development will be the ones that systematically convert engineering judgment into executable constraints. The model can stay probabilistic. The process around it cannot.
We stop building ever more elaborate ways of telling AI how we would like software built. We build engineering environments where the important properties of good software are machine-verifiable facts.
At that point we are no longer hoping the agent understood our architecture. The architecture is enforcing itself.
