Who Owns the Spec?

A junior engineer asks an AI assistant to draft a spec for a new billing feature. The assistant produces a tidy document: user stories, edge cases, acceptance criteria, a data model. It looks complete. It reads well. The engineer pastes it into the ticket, and a second AI agent picks it up and starts writing code against it. Two days later there’s a pull request. Nobody — not the engineer who requested the spec, not the reviewer who approved the PR — can actually explain why the refund flow rounds the way it does. The code matches the spec. The spec matches the prompt. And no human in the chain ever understood any of it.

This is the AI-to-AI handoff problem, and it is quietly becoming one of the most consequential failure modes in software teams. Not a dramatic outage. A slow accumulation of artifacts that look authoritative but trace back to nothing a person can defend. A spec nobody read becomes code nobody understands, gated by a review nobody really did.

The question that cuts through it is simple and old-fashioned: who owns the spec? Not who generated it — who is accountable for it being right. Because when AI writes the requirements, the requirements still have to be true, and truth needs an owner.

The compounding problem of unverified artifacts

Software has always been a chain of translations. A need becomes a spec, a spec becomes a design, a design becomes code, code becomes a running system. Every link is a chance to lose fidelity. What’s new is that AI can now generate every link in that chain, fast, and each generated artifact can become the input to the next generation — with no human checkpoint in between.

There’s a useful warning from a different corner of AI research. In a 2024 Nature paper, Shumailov and colleagues showed that when generative models are trained recursively on their own output, they suffer model collapse: the tails of the distribution disappear, errors compound across generations, and quality degrades irreversibly. Their now-famous example fed a model text about medieval architecture and watched the ninth generation devolve into a list of jackrabbits. The mechanism is specific to model training, not to your sprint. But the shape of the failure rhymes. Feed AI output back into AI input enough times, with no fresh ground truth injected, and meaning drifts. A spec generated from a vague prompt, implemented by an agent, documented by another model, summarized for a stakeholder by a third — each step is plausible, and the cumulative drift from what anyone actually intended can be enormous.

The dangerous property is that drift is invisible at each step. Every individual artifact passes the sniff test. The spec is well-formatted. The code compiles and the tests pass. The summary is coherent. There is no single moment where something obviously breaks. The breakage is structural: you’ve built a tower of artifacts where each one was validated only against the artifact above it, and none was validated against reality. We’ve written before about how this kind of self-reinforcing churn turns into AI coding doom loops — work that generates more work without converging on anything correct.

The fix is not to ban AI from writing specs. AI is genuinely good at drafting requirements, surfacing edge cases, and structuring acceptance criteria. The fix is to insist that the chain touch ground somewhere. A human has to verify, and verification has to be deliberate, because the one thing AI cannot do is be accountable.

The responsibility gap is not theoretical

Philosophers have a name for what happens when autonomous systems act and no human can be cleanly held responsible: the responsibility gap. Andreas Matthias introduced the term in 2004, arguing that as machines learn and produce behavior their operators can neither fully predict nor control, we reach situations where “nobody has enough control over the machine’s actions to be able to assume responsibility for them.” More recent work has refined this into several distinct gaps — culpability, moral accountability, public accountability, and active responsibility — but the core worry is constant: harm occurs, and the question of who answers for it has no clean answer.

In a philosophy seminar this is abstract. In your codebase it is Tuesday. When a spec is AI-drafted, implemented by an agent, and merged after a rubber-stamp review, and that feature later mishandles a customer’s money, who owns the mistake? The engineer says they were just relaying requirements. The reviewer says the code matched the spec. The spec, of course, says nothing — it’s a document. The responsibility gap is the empty chair at that retrospective.

The antidote is not better tooling. It is assignment. You close a responsibility gap by deciding, in advance and explicitly, that a named human is accountable for each artifact regardless of who or what drafted it. The AI is a tool the owner used. The owner remains the owner. This is the same principle that underlies a credible AI code audit trail: provenance is useful, but provenance without an accountable human is just a record of who pressed the button.

Why humans over-trust machine output

If ownership were just a matter of telling people “you’re responsible, so check the work,” we’d be done. The hard part is that humans are bad at checking work that a machine has already done — predictably, measurably bad.

The phenomenon is called automation bias, and it’s been studied for decades. In their 2010 review, Parasuraman and Manzey synthesized the research on complacency and bias in human use of automation and found a consistent pattern: people treat automated output as a powerful, salient cue, tend toward the “cognitive miser” path of least effort, and diffuse responsibility onto the aid — resulting in incomplete cross-checking of the information actually available to them. Critically, they found this complacency appears in both novice and expert participants and is not overcome by simple practice. Knowing about the bias does not inoculate you against it.

The implication for AI-drafted specs is uncomfortable. The better the AI gets at producing fluent, well-structured, confident-sounding artifacts, the more our automation bias kicks in, and the less likely a human is to genuinely scrutinize them. Fluency is not correctness, but our brains keep treating it like a proxy. A spec that reads like it was written by a careful senior engineer gets the deference we’d give a careful senior engineer — even when it was generated in four seconds from a one-line prompt.

This is not hypothetical hand-wringing. The 2025 randomized controlled trial from METR found that experienced open-source developers, working in repositories they knew well, took 19% longer to complete tasks when allowed to use AI tools — yet believed they had been sped up by 20%. The gap between perceived and actual impact was roughly 40 percentage points. People are not reliable judges of whether AI helped them, which means they are not reliable judges of whether the AI’s output needs more scrutiny. Verification cannot be left to vibes.

Verification is the scarce skill now

For a long time, the scarce skill in software was generation — the ability to produce correct code from a fuzzy idea. AI has made generation abundant and cheap. What it has not made abundant is the judgment to tell whether a generated artifact is actually right, actually complete, and actually what the business needs. That judgment is now the bottleneck, and it’s worth naming it plainly: in an AI-assisted team, verification is the scarce skill.

This reframes what good engineering looks like. The valuable contribution is no longer “I wrote this.” It’s “I understood this, I checked it against reality, and I’ll stand behind it.” That’s a harder, less glamorous skill than typing fast, and it’s the one teams should be hiring for, training, and rewarding. The right metrics capture understanding and outcomes rather than raw output volume — and verification is exactly the kind of work that volume metrics render invisible.

It also reframes the danger of measuring the wrong thing. If you reward people for closing tickets fast, you reward skipping verification, because verification is slow. Goodhart’s Law — when a measure becomes a target, it ceases to be a good measure — applies with a vengeance here. The DORA team’s 2024 research found that a 25% increase in AI adoption was associated with an estimated 1.5% decrease in delivery throughput and a 7.2% reduction in delivery stability, and their diagnosis pointed at fundamentals: bigger batch sizes, weaker adherence to the basics of small changes and robust testing. AI lets you produce more, faster — including more unverified material moving through the system in larger chunks. Speed without verification is not productivity. It’s deferred debugging with interest.

Definition of understood, alongside definition of done

Most teams have a definition of done: tests pass, code reviewed, docs updated, deployed. It’s a checklist that asks “is this complete?” In an AI-assisted workflow you need a companion checklist that asks a different question: “does a human understand this?”

Call it the definition of understood. It’s the bar an artifact has to clear before it can move down the chain, and it’s owned by a named person. A spec is “understood” when its owner can:

• Restate its purpose and the key decisions in their own words, without reading from the document.
• Explain why the non-obvious choices were made — the edge cases, the defaults, the tradeoffs — and what the alternatives were.
• Identify what’s not covered and where the risk lives.
• Answer “what happens if this is wrong?” with something more than a shrug.

The crucial move is that the human summary must be in the human’s own words. Re-reading the AI’s prose back to yourself feels like understanding but isn’t — it’s recognition, not comprehension, and recognition is exactly the failure mode automation bias exploits. Forcing a restatement in your own words is a cheap, brutal test of whether anything actually landed. If you can’t paraphrase the spec, you don’t own it yet, no matter whose name is on the ticket.

This applies up and down the chain, not just to specs. A definition of understood for a pull request means the author can explain what the AI generated and why, not just that the tests are green. This is the same instinct behind treating AI-generated code as a production risk until a human has genuinely vetted it — green tests prove the code does something, not that it does the right thing, and certainly not that anyone could maintain it at 2 a.m. during an incident.

Lightweight ownership rituals that actually work

Heavy process dies on contact with a deadline. The rituals that survive are the ones that add real safety for little ceremony. A few that hold up:

One named owner per artifact

Every spec, every significant design doc, every meaningful PR has exactly one human owner — a name, not a team. “The team owns it” is how the responsibility gap creeps back in, because shared accountability is diffused accountability. The owner didn’t have to write the artifact. They had to understand it and they have to defend it. If the spec is wrong, the owner owns the wrongness. This single move does more to close the gap than any tooling, because it converts an ambient responsibility into a specific one.

Restate-it review gates

Change the question a reviewer answers. Instead of only “is this correct?”, add “can the owner explain this without the document open?” In practice this is a two-minute conversation or a short written summary attached to the artifact. The reviewer’s job is partly to test comprehension, not just correctness — because a correct spec that its owner can’t explain is a liability waiting for the moment the owner is on vacation. This is a small extension of solid AI-aware code review practices: the reviewer is verifying that a human is in the loop, not just that the bytes are acceptable.

A verification budget

Treat verification as work that costs time, and put it in the estimate. If a spec took the AI four seconds to draft, the owner’s job is to spend real minutes understanding and pressure-testing it — and that time should be visible in planning, not squeezed into the gaps. Teams that don’t budget for verification end up not doing it, because automation bias plus deadline pressure is a near-perfect recipe for the rubber stamp.

Comprehension probes in retros

When something goes wrong, ask the chain-of-understanding question explicitly: at which artifact did human comprehension actually stop? Often you’ll find the spec was understood but the implementation wasn’t, or the prompt was clear but the spec quietly drifted from it. Naming where understanding broke is more useful than naming who wrote the bug, because it tells you where to put the next review gate.

None of this requires new software. It requires deciding that understanding is a deliverable. The SPACE framework — Forsgren and colleagues’ multidimensional model of developer productivity — makes the case that productivity is never a single number, and that satisfaction, performance, and the friction of getting work done all matter alongside raw activity. Verification work lives squarely in those harder-to-count dimensions, which is exactly why it’s so easy to neglect and so important to make explicit.

When the spec is right but unowned

It’s worth being honest about a tempting objection: what if the AI’s spec is genuinely good? What if it’s more thorough than what the engineer would have written alone? Often it will be. The point of ownership is not to second-guess the AI’s competence. It’s that competence without accountability is fragile.

A spec nobody owns is fine right up until it’s wrong. And when it’s wrong, an unowned spec has no defense, no rationale anyone can reconstruct, and no person who can quickly say “here’s what we intended, here’s where it diverged, here’s the fix.” You’ve traded the small ongoing cost of understanding for the large, unpredictable cost of a system whose decisions are unexplainable. That’s a bad trade even when the AI is excellent, because excellence isn’t the same as infallibility, and the moments that matter most are precisely the ones where something went wrong.

Ownership is insurance against the responsibility gap, and like insurance, its value shows up exactly when things break. The good news is the premium is cheap: a few minutes of genuine comprehension per artifact, a name on each ticket, a review that tests understanding. The teams that get this right won’t be the ones that use AI the least or the most. They’ll be the ones who never let an artifact travel further down the chain than a human’s understanding of it.

The Takeaway

AI can write your specs, your code, your tests, and your docs. It cannot own any of them. Ownership — understanding an artifact well enough to defend it and signing off with your name attached — is the one thing in the whole pipeline that doesn’t scale automatically, and that’s precisely why it’s the thing that protects you. The danger isn’t that AI produces bad work; it’s that AI produces plausible work fast enough to outrun human comprehension, and our well-documented tendency to over-trust fluent machine output means we’ll wave it through.

So put a name on every spec. Demand a restatement in the owner’s own words. Add “definition of understood” next to your definition of done, and budget the time it takes. When AI drafts the requirements, a human still has to make them true — and the only way to know they’re true is to make sure someone, specifically, understood them. Who owns the spec? Decide that before the code is written, not after the incident.