AI Wrote the Bug. You Shipped It.

The pager fires at 2:14 AM. A null reference in the checkout path. Stripe is rejecting half the transactions. The on-call engineer pulls up the failing PR.

The PR has a name on it. The commit has a user ID. Slack says the developer "shipped the AI-generated payment refactor at 6:47 PM."

What it does not say is "the AI generated this." It does not name a model. It does not implicate a vendor. The post-mortem template has one slot for owner, and it is filled in.

Twelve hours later, in the post-mortem room, no one is going to ask which model produced the code. They are going to ask what the developer did to verify it. The question of authorship is not interesting. The question of accountability is.

This is the question the next decade of software engineering is going to keep asking. Vibe coding pretends it has an answer that lets the human off the hook. It does not. Vibe engineering — done well — gives the same answer the craftsmanship movement gave fifteen years ago, applied to a medium it could not have anticipated but completely prepared for.

The bar for ownership did not move. The work of meeting it did.

What Ownership Used to Mean

Sandro Mancuso, in The Software Craftsman, treated ownership as the central virtue. Not as workplace ethics — as a property of the craft itself. You wrote it, you tested it, you refactored it, you defended it. Bob Martin's Clean Coder described professionalism the same way: refusing to ship what you would not sign your name to.

For about fifteen years, the craftsmanship movement made this argument to a software industry that mostly treated it as nice-to-have. TDD, refactoring, pairing, ownership of the work — these were the things some senior engineers cared about and management benignly tolerated.

The argument worked, partly, because typing was the work. When you typed every character of a function, ownership was almost automatic. You knew what was there because you put it there. Tests were an extension of "I made this." Refactoring was "I keep making this better." Reviewing your colleagues' code was "I help them make theirs."

The craftsmanship argument was right then, but it was easy to deflect. You could be a sloppy typist and still ship product. The industry rewarded velocity; the craftsman rewarded discipline; and most of the time the velocity people won.

That trade is gone now. Not because craftsmanship won. Because typing stopped being the work.

What Vibe Coding Pretends Ownership Means

Vibe coding's first sentence to itself is: "I didn't write that. The AI did." It is a small sentence and it does enormous work. It reframes the developer from author to operator. It makes the model the author and the human the dispatcher. Ownership, in this framing, transfers along with authorship — the way it would if you handed a spec to a contractor.

Three excuses follow naturally from this premise.

"I just accepted the suggestion." The developer hit Tab. The diff arrived already-written. They were a witness, not a participant.

"The tests passed." Whatever the AI generated must be right, because the green checkmark appeared. The signal was the green CI badge, not the developer's understanding.

"The PR looked clean." It compiled. The diff was readable. The variable names were sensible. None of these are correctness — they are surface plausibility — but the human read them as proof.

Each excuse is, in effect, an attempt to transfer the ownership of the merge to the system that generated the code. None of them survive contact with a real post-mortem. The PR has the developer's name. The merge has their user ID. The Slack thread that approved the design has their initials. The model is not on the call. It does not have a manager. It does not get a one-on-one. It does not write the post-mortem.

What actually happens when ownership is "transferred" to an AI is not transfer. It is abandonment. The work was done by a system that does not remember it, by a process that has no continuity, by an author that does not exist. The accountability does not move with the authorship; it just stops being held.

That is a worse position than not using AI at all. The developer who hand-types every line is, at minimum, the author of the bug. The developer who vibe-codes their way to a 600-line PR they didn't read is the only person who could have caught it — and didn't.

What Vibe Engineering Actually Requires

Simon Willison drew the distinction last year: vibe coding is throwaway prompting; vibe engineering is the discipline of running AI agents at production quality. The distinction matters because the failure mode of treating them as the same is the ownership confusion above.

Vibe engineering's reframe is small but consequential. You delegate the typing. You retain the understanding, the design intent, and the accountability. Three things, all non-negotiable. The first is workable. The other two are the craft.

This is not a new philosophical position. It is the craftsmanship position translated cleanly to a medium where the keystrokes are not where the work happens anymore. Mancuso's "I made this" becomes "I designed this and I verified what was made for me." Martin's "would I sign my name to this" becomes "I am signing my name to this — would I defend it tomorrow morning?"

The keystrokes were never the deliverable. The understanding was. The design was. The accountability was. What changed under AI is that the keystrokes can be subtracted from the loop without the rest moving. Whether the rest stays attached to the human is the choice that defines vibe engineering.

If it stays attached, the practice is craftsmanship. If it doesn't, the practice is one of the failure modes catalogued in our piece on vibe coding for production-grade systems — the cardboard muffins, the litterbugs, the half-assing problem, the decorative tests. All of them are different shapes of the same thing: ownership that wasn't held.

Figure 1: As typing automates, ownership concentrates — it doesn't diffuse.

Five Things You Do on Monday Morning

The reframe only matters if it has Monday-morning shape. Five practices, none of them new, all of them more important now than they were when craftsmen first wrote them down.

Read every line of the diff before you merge. Not skim. Not "the structure looks right." Read. Most vibe-coding bugs that ship to production are visible to a careful reader of the diff. They are not subtle. They are the parameter that's accepted but not used. The condition that's inverted. The validation that returns true on the empty case. The test that asserts the function was called and not what it returned. AI tools are getting better; they are not yet at the point where reading the output is optional.

Be able to answer "why this and not the alternative" for every non-trivial choice. The model picked a hash map; you have to know why a hash map and not a sorted set. It picked optimistic locking; you have to know why optimistic and not pessimistic. If the answer is "because the AI suggested it," you are not the author of that decision — you are the witness to it. Authorship of the decision is part of what you owe the merge.

Write or co-write the test that catches the bug if AI got it wrong. AI-generated tests, by default, encode what the code does, not what it should do. They are reverse-engineered from the implementation. They go green for the same reason the code is green. The test that you write, against the spec, is the one piece of the PR that asks an independent question. It is also the artifact that, in the post-mortem, shows you held ownership of the verification step.

Defend the design in review without using "the AI suggested it." That sentence is the tell. If a reviewer asks why a function takes seven arguments and your only answer is the AI's recommendation, you are not defending a design — you are quoting one. The defense has to come from the same place every craftsman's defense came from: the constraints, the alternatives, the tradeoff you chose and why. If you cannot get there, you do not own the choice yet.

Refuse the merge you cannot defend. This is the hardest one. The 600-line AI diff that "looks fine" is the modern shape of the same temptation craftsmen always faced — to ship what you do not fully understand because you are tired and the deadline is tomorrow. The craftsman's answer was always: not on my name. The vibe engineer's answer is the same. The temptation got bigger. The answer didn't change.

Figure 2: The ownership checklist — five practices that keep the human attached to AI-authored code.

The Accountability Gradient

There is a useful way to think about what AI changes and what it doesn't.

On a spectrum from I typed every character to I prompted, I shipped, the typing burden goes from carrying the work to carrying almost none of it. Almost everything that used to be the developer's keystrokes is now the model's. Most discussion of AI in engineering treats this as the entire story.

It isn't. The other axis — the accountability burden — runs the opposite direction. As keystrokes fall away, understanding has to fill the gap. Design intent has to fill the gap. Verification has to fill the gap. The total weight on the human does not shrink; it concentrates. You stop being the typist and become, more than ever, the architect, the reviewer, the verifier, the defender.

The craftsman's old practices rotate without disappearing. TDD becomes more important, not less, because it is the only honest signal that the AI's plausible output corresponds to the spec. Refactoring becomes more important, because the model amplifies whatever pattern is already present in the codebase. Pairing — with another human or with the AI — becomes the place craft is taught, because juniors no longer learn it by reading senior keystrokes.

This is what the craftsmanship movement was preparing the industry for, fifteen years before it knew that was what it was preparing for. The argument was: the work that makes software trustworthy is not the work of typing it. It is the work of understanding it. The industry could deflect that argument as long as typing was where the time went. It cannot deflect it anymore.

The Bottom Line

The pager fires at 2:14 AM. The on-call engineer pulls up the PR. There is a name on it. The post-mortem will name the same name.

Nobody in that room asks who typed the code. They ask what the developer did to verify it.

The craftsmanship movement was answering that question fifteen years before AI raised it. Vibe engineering is the same answer, in a new room. You delegate the typing. You do not delegate the rest.

The bar didn't move. The work of meeting it did.