Series: Engineering Judgment, Part 7

I have started to notice a particular kind of discomfort in engineering work.

The output is arriving faster. Code that once required an afternoon can appear in minutes. Design alternatives that might have taken several meetings can be explored before the meeting begins. Tests, migrations, scripts, documentation, and prototypes can all be produced with less friction than before.

This is a real productivity gain. It is too large to dismiss, and I do not want to romanticize slower work simply because it was familiar. Searching documentation, reconstructing boilerplate, or translating an idea into a first implementation consumed attention without necessarily producing better judgment.

The discomfort comes from somewhere else. As output becomes easier to produce, confidence does not become easier to earn. I increasingly encounter work that is complete enough to move forward but difficult to explain all the way down. The code runs. The tests pass. The architecture sounds coherent. Yet one more question about the invariant, the failure path, or the reason this option was chosen can expose how little of the system is actually owned.

AI does not merely accelerate output. It can widen the gap between what a team produces and what it can still explain, verify, and own.

That gap may become one of the defining engineering problems of this period.

Production and Comprehension Move at Different Rates

For most of software history, producing an artifact and understanding it were imperfectly connected. Writing a function required someone to hold part of its causal structure in mind. Designing a component forced a person to make its tradeoffs explicit enough to turn them into code. People still copied code they did not understand and built around weak assumptions, but production created some unavoidable contact with the problem.

AI weakens that coupling.

A team can now increase its generation capacity much faster than its comprehension capacity. Plausible implementations multiply. Documentation becomes abundant. Even tests can be generated alongside the implementation, giving the work the shape of something already examined.

Understanding does not scale in the same way. To understand a change, someone still has to connect it to the system that exists: its historical decisions, hidden invariants, data shape, operational boundaries, and failure behavior. Verification is constrained by evidence. Ownership is constrained by attention and responsibility. These capacities can improve with better tools, including AI, but they do not increase simply because more output is available.

When accepted output grows faster than the team's ability to understand and verify it, the difference accumulates inside the system. I think of that difference as unowned complexity.

Unowned complexity is not merely generated code. It can be written entirely by people. It is any code, configuration, design, test, or operational behavior that the system depends on but the team cannot confidently explain, verify, repair, or remove. AI matters because it can increase the rate at which this condition is created while making the result look unusually complete.

The artifact exists. The ownership does not.

Plausibility Ends at the System Boundary

AI is exceptionally good at producing locally coherent work. Given a problem statement, surrounding code, and a desired form, it can generate an answer that fits the visible frame. The names are appropriate. The structure resembles the codebase. The explanation connects the parts. If the frame changes, a different answer may appear with equal confidence and internal consistency.

That behavior should not be surprising. Generated output is conditioned on the context it receives. It cannot independently establish that the context contains the right problem, the complete constraint set, or the contract the real system must preserve.

Engineering correctness is external to the answer.

A retry loop can be idiomatic and still amplify load during partial failure. A migration can be syntactically correct and still violate an invariant that lives across several historical data states. A permission check can match the visible API while missing an authorization assumption enforced by another service. A test suite can pass because the generated tests reproduce the behavior of the generated implementation rather than challenge the contract that implementation was supposed to satisfy.

Each artifact can look persuasive inside its local frame. The failure appears when the frame meets the system.

This distinction has always existed, but AI changes its frequency and presentation. Weak work once carried visible signs of incompleteness: missing branches, rough explanations, unfinished tests, or awkward code. Generated work can arrive polished before it has earned trust. Completeness of form begins to substitute for completeness of reasoning.

Most experienced engineers will not believe every answer. The subtler danger is that plausible work lowers the friction required to continue. A proposal becomes an implementation, then arrives with tests that make review feel safer. The change merges because every individual step looks reasonable, even though nobody has reconstructed the full argument from problem to outcome.

The Causal Chain Becomes Fragile

A healthy engineering decision has a causal chain:

problem → assumptions → decision → implementation → evidence → outcome

The chain does not have to be documented as a formal process, but it has to exist in the team's understanding. Someone should be able to explain which problem mattered, what had to remain true, why this path was chosen, how the implementation expresses that choice, what evidence supports it, and what production outcome would show that the reasoning was wrong.

AI can accelerate several links in this chain. It can help articulate assumptions, compare decisions, produce implementations, and generate candidate tests. Used carefully, it can make the chain more visible because engineers can spend less time on mechanical translation and more time interrogating the argument.

It can also allow the middle of the chain to appear without the beginning.

A developer asks for a migration and receives one that handles the visible schema change. It runs successfully against representative data. Yet the real requirement was not simply to transform rows; it was to preserve an ordering guarantee while old and new versions of the application were running together. The code proves that a transformation can execute. It does not prove that the system remains correct during the transition.

Or a team asks for recovery logic around a distributed operation. The implementation includes retries, timeouts, and idempotency keys. Unit tests cover the expected branches. During an actual partial failure, however, the retry policy changes contention on a shared dependency and delays the signal the operator needs to distinguish slow progress from duplicated work. The mechanism exists, but the failure model was never owned.

In both cases, adding more generated detail can deepen the illusion. More tests, more comments, and a cleaner abstraction make the artifact easier to accept. They do not restore the missing link between the implementation and the system condition it must survive.

Once that causal chain is lost, repair becomes expensive. Engineers can read what the code does, but they have to rediscover why it exists. They can observe an outcome, but they cannot tell which assumption failed. They can change the implementation, but they do not know which invisible contract the previous version was protecting.

The system continues to move. Its explainability falls behind.

Verification Is Becoming the Constraint

When generation was expensive, implementation effort naturally limited the number of paths a team could pursue. A developer might compare two approaches and build one. Reviewers examined a relatively scarce artifact. The production rate and the verification rate were close enough that ordinary engineering practices could often keep them in contact.

AI changes that economy. A team can generate five plausible approaches in the time it once took to implement one. This sounds like a fivefold increase in optionality. It can also create five times as many assumptions to inspect, failure modes to compare, and attractive details to reject.

The scarce resource moves from producing options to establishing trust.

Verification in this environment means more than checking syntax, running tests, or completing code review. It includes deciding whether the prompt represented the right problem, whether important context was absent, whether the selected approach matches the system's stage, whether the tests assert the correct contract, whether production evidence can distinguish success from plausible failure, and whether somebody is prepared to own the result after the original conversation is gone.

AI can help with parts of this work. It can search for call sites, identify edge cases, generate adversarial tests, compare a proposal with documentation, and explain unfamiliar code. But using AI during verification does not remove the need for an external standard. A second generated opinion is still an opinion produced inside a frame. The team has to decide which evidence connects the frame to reality.

This is why a faster coding loop does not automatically produce a faster engineering loop.

If generation accelerates while verification remains unchanged, review queues grow or standards fall. If teams attempt to preserve speed by accepting plausible work, unowned complexity grows. If they preserve standards through exhaustive human review, the expected productivity gain narrows and reviewers become the bottleneck.

None of these outcomes means AI has failed. They mean the system around AI has not yet learned to convert generation capacity into trusted change at the same rate.

More Output, Less Shared Confidence

It is tempting to describe this as an individual skill problem: some engineers understand what they generate, while others accept results too easily. There is truth in that distinction, but it is incomplete. The same person can use AI as a careful amplifier in one task and as an unexamined answer generator in another. Time pressure, familiarity, risk, and organizational incentives all change the boundary.

The larger issue is that output is visible and comprehension is not.

A merged feature can be counted. A completed migration closes a project. A large refactor creates an impressive diff. The time spent proving that a proposed abstraction should be deleted, reconstructing an invariant, or rejecting a plausible implementation leaves less visible evidence.

Organizations therefore have a structural reason to consume generation gains immediately. More work enters the system because more work can be produced. Verification remains a cost center. Deep understanding is assumed to exist because the artifacts look complete and the delivery metrics are moving.

Over time, shared confidence weakens. One engineer may understand the prompt and generated path, while reviewers see only the artifact. Six months later, the team inherits decisions whose reasoning lived in a private conversation. Documentation may describe the resulting structure without preserving the evidence and rejected alternatives that made it trustworthy.

The organization knows what the repository contains. It knows less about why the system should be believed.

This is a different form of technical debt. Traditional debt often comes from a conscious shortcut: the team knows what it postponed. Unowned complexity can arrive without that awareness. The code is clean, the tests are green, and the explanation is articulate. The debt is the missing ability to connect those artifacts to a causal model of the system.

What Must Remain Owned

I do not think the answer is to reserve all important code for manual writing. Authorship is a weak proxy for understanding. Engineers can misunderstand code they wrote themselves, and they can deeply understand code produced by a tool, a library, or another person.

The stronger boundary is ownership.

Someone has to own the problem definition. If the question is wrong, a high-quality answer only accelerates the wrong direction. Someone has to own the system boundary, including the context that cannot fit into a prompt and the historical constraints that no longer look important until they fail.

Someone has to own the correctness criteria and failure model. Tests can encode those criteria, but they cannot decide which criteria matter. Observability can provide evidence, but it cannot decide what evidence is sufficient. A model can enumerate tradeoffs, but it cannot accept the consequences of choosing one for a system with users and obligations.

The final responsibility also remains human and organizational. When an AI-assisted change causes an incident, "the generated implementation looked correct" is not an engineering explanation. The useful explanation traces the failed assumption, the evidence that was trusted, the review boundary that missed it, and the system changes required to prevent recurrence.

These responsibilities suggest practical boundaries. Use AI aggressively where output is easy to verify, consequences are local, and the surrounding contract is strong. Increase the evidence burden where state, security, recovery, financial correctness, or distributed coordination make errors expensive. Keep changes small enough to reconstruct their causal chain. Record assumptions and rejected alternatives when they matter more than the final syntax.

These practices help, but they are not a complete method. They are ways to preserve ownership while the method is still being invented.

A Transition Without Settled Rules

The uncomfortable truth is that I do not think engineering has a mature answer to this problem yet.

More review is an incomplete response because review capacity does not scale automatically with generation. More tests are incomplete because generated tests can validate the wrong contract with great consistency. Smaller diffs help, but a small change can still alter a global assumption. Restricting AI to low-risk work may protect the system, but it can also prevent teams from learning how to use the tool where its leverage matters most.

Our existing practices were shaped in an environment where producing code was expensive and the person creating an artifact usually encountered much of its reasoning along the way. That environment is changing faster than the practices around it.

This pattern is not unique to AI. Large shifts in production tools create a period in which capability grows before norms, controls, and professional judgment catch up. People use the new tool through habits formed around the old one. Some old disciplines become more important. Others become ceremony. New failure modes appear before the vocabulary needed to describe them.

We are likely in that period now.

The next engineering discipline will have to do more than generate correct-looking artifacts. It will need reliable ways to preserve causal ownership across human and machine work: ways to expose assumptions, connect tests to contracts, distinguish exploration from commitment, retain the reasoning behind accepted changes, and make responsibility legible after the original context has disappeared.

I do not know the final form of those methods. I am increasingly certain that output volume is the wrong measure of whether we are making progress.

AI is making system construction easier. The harder question is whether our capacity to understand and verify those systems can keep pace. If it cannot, the productivity gain does not disappear. It changes form. What we save during production returns later as uncertainty, review load, operational fragility, and recovery work.

The question is no longer only whether AI can help us build the system.

It is whether, after the acceleration, the system still belongs to us in the engineering sense: we can explain it, verify it, repair it, and take responsibility for what it does.