Provenance & accountability

”The AI wrote that part”

A bug ships in AI-generated code. In the postmortem, the engineer explains: “the AI wrote that part.” It’s true. It’s also the worst thing they could say.

Predict, before reading on: why does that land so badly, and what’s the version that doesn’t? The sentence tries to move responsibility to the tool — and everyone in the room hears it do that. The accountable version starts with “I approved it,” and goes somewhere useful from there.

Approval is ownership

The principle is one line: accepting AI output is authoring it, for every purpose that matters — correctness, review, blame, audit. The tool’s involvement changes how the code was produced, not who is responsible for it. This is why “the AI wrote it” fails everywhere it’s tried: in a postmortem it reads as deflection, in code review it doesn’t survive a follow-up question, in an audit it isn’t an acceptable answer.

Read positively, the principle is liberating. You don’t have to limit your use of AI to defend your work — you have to be able to stand behind the result. That reframes the entire guide: the loop isn’t bureaucratic caution, it’s what lets you delegate aggressively and still own the output with a straight face. The interview signal is simple and rare: take ownership of AI-assisted work without hedging. A candidate who says “I built this; here’s how I know it’s right” beats one who says “well, the AI generated most of it” every time — same code, opposite signal.

Provenance: the audit trail for AI code

Provenance is what makes ownership real rather than asserted — the evidence that you actually checked what you’re standing behind. It has two levels:

• For your own work, provenance is the loop. Your ability to explain the code, say what you reviewed it against, and show how you verified it is your provenance. You don’t need a label saying “AI made this”; you need to be able to defend it. Comprehension (Ch 5) and verification (Ch 6) are precisely the record that lets you stand behind AI-written code as your own. A chat log of your prompts is not provenance; your demonstrable understanding is.
• For teams and regulated systems, provenance becomes explicit. What was AI-generated, what it was tested against, who reviewed and approved it — recorded, because the accountability is shared and has to survive the people involved. The PR description, the gate’s pass record, and the review sign-off are the artifacts. “The model decided” is not an audit answer; the record is.

Predict the accountable response in each case:

The pattern: own the approval, show what it was checked against, name the gap honestly, fix the process — never reach for the tool as the responsible party.

When accountability is hardest

The principle is easy to state and hard exactly where it matters:

• Code you approved but didn’t write — the default of AI-assisted work. Approval is ownership, so the comprehension and verification have to be real, not rubber-stamped.
• An agent’s multi-file change — you governed by seams and gate (Ch 9), so your provenance is the scoping, the checkpoints, and what each was verified against — not a claim to have read every line.
• A regulated, high-stakes system — provenance must be documented, because accountability is external and audited; the record is the deliverable.
• A bug whose origin is “the model” — the hardest temptation, and the cleanest test: the accountable move is to own it, show what you checked, name what you missed, and fix the process.

This is also the institutional cure for the automation-bias anti-pattern from Chapter 8. Automation bias is trusting the tool over your own check; provenance is the discipline that makes trust accountable — you can rely on the AI as much as you can stand behind, and no more. The two chapters are the same idea from opposite ends: one names the failure, the other builds the practice that prevents it.

How this is graded

Communication is this chapter’s weighted dimension — accountability is largely a matter of how you own the work out loud:

• Communication (weighted) — you take clear ownership and articulate your provenance, with no “the AI did it” hedging and no false claim to have read what you sampled.
• Evaluation Rigor — your provenance is concrete (what it was checked against), not a vibe; the gate is part of the record.
• Technical Correctness — you can actually explain and defend the code, which is the substance beneath the ownership.
• Trade-off Awareness — you’re honest about where you delegated versus deeply reviewed, and you gate the delegated parts harder.

Industry variation

• Startups — even without formal process, the loop is your provenance; “I can explain and defend all of it” is the bar, and it’s on you.
• Big tech — provenance lives in PR descriptions and review records; ownership in a large team means your name on the approval means something.
• Regulated (fintech, health) — documented provenance is mandatory; the generation, testing, and approval chain is an audit artifact, and “the AI decided” fails compliance.
• Frontier labs — accountability for AI-assisted research: reproducibility and method provenance, so a result built with AI help can still be trusted and rebuilt.

Stretch: put the whole skill in one room

You now have all of it — the loop, communication, the anti-patterns, scale, and accountability. The last question is whether you can do it together, under time pressure, with someone watching: clarify and preregister, prompt and read and verify, narrate throughout, and own the result. Before the capstone: which stage do you most expect to drop when the clock is running and you’re being observed?

Next: Chapter 12 — Interview craft & transfer, the capstone, where the whole loop runs at once in a mock AI-assisted round and you grade yourself against the rubric.