The audit: approving the agent's code without turning into a rubber stamp
The agent writes code that passes every automated test and can still be doing the wrong thing. This lesson gives you a five-item audit checklist for whoever approves agent PRs at scale, and the principle that whoever approves is always who answers for it.
An agent opened a PR to fix a pagination bug. Tests passed, lint passed, build passed, all green. The reviewer glanced at the automatic summary, thought it looked reasonable, clicked approve in fifteen seconds. Only later, while investigating a different bug, did someone notice the PR had also changed a default cache value in a configuration file that had nothing to do with pagination. Nobody had noticed, because nobody had read the full diff.
An agent drafts a contract amendment, citing the original clause and the proposed change. The lawyer approves quickly because the text is well written and formatted to the firm's standard, without opening the original contract to compare line by line. Only when the client asks why a confidentiality clause disappeared from the amendment does someone notice the agent rewrote the entire section instead of just inserting the change, and the clause that should have been preserved wasn't there anymore.
An agent prepares the performance review package for twelve people, with score, justification, and raise recommendation, from the cycle's records. The manager approves the whole package in an afternoon, because the formatting is impeccable and the justifications sound plausible. Later, someone contests their score: the justification cited a project they never led, a data point the agent pulled wrong from a different employee with a similar name, and nobody checked before approving the whole package at once.
An agent writes the PRD for a new feature, with success criteria, scope, and an estimated-effort table. The PM approves the document because the structure is tidy and the criteria sound reasonable, without checking the source of each number. Only in the planning meeting does someone ask where the effort estimate came from, and nobody can answer: the agent extrapolated from a "similar" feature that was actually much simpler, and the team commits to a deadline that was already broken at birth.
An agent puts together the commercial proposal for a big client, with discount, term, and adjustment clause, pulling from the history of past proposals. The sales manager approves quickly, because the format is the usual one and the discount looks within policy. Only when the client signs does someone notice the annual adjustment clause had been copied from a contract in a different segment, with a condition the company never practices with this type of client, and now it's signed.
An agent adjusts the routing of a logistics process after identifying a bottleneck, and presents the new flow with the projected SLA metric. The operations manager approves the change because the projected number looks good and the report is well written, without testing the new flow on a small sample first. In the first week in production, the new routing raises cost per delivery by 15%, because the agent had ignored a capacity constraint at one of the distribution centers that wasn't documented in the base it used.
An agent prepares the controls compliance report for the risk committee, marking most items as compliant. The compliance officer approves the whole report because the format follows the usual standard and nothing caught their eye at first glance. In an external audit months later, it's discovered a critical control had been marked compliant based on evidence from a previous cycle, which the agent reused because it "seemed current", and nobody checked the date before approving.
An agent adjusts the signup flow in the Figma prototype after a usability test, and presents the before and after with the projected completion metric. The responsible designer approves the change because the mockup looks like an obvious improvement, without testing again with a real user. Once it ships to production, the change solves the problem that motivated the adjustment, but introduces a new one: the field the agent moved to the top of the screen breaks the tab order for anyone navigating with keyboard only, a problem that only shows up in an accessibility audit, weeks later.
An agent puts together the quarterly competitive positioning report for the board, cross-referencing market data with the internal CRM. The document comes out formatted, with a chart and a cited source, and the executive reviewing it approves in five minutes because "the numbers match what I expected". Only in a follow-up meeting does an analyst notice the market-share chart added up two different segment cuts, inflating the number by eight points, a mistake nobody caught because nobody opened the source spreadsheet before approving the slide that went to the board.
Whoa, let me tell you a scene that's probably already happened on your team. An agent opens a PR, the whole pipeline goes green, the automatic summary looks reasonable, and the approve button is right there, asking for a click. You click. Move to the next one. By the end of the day you've approved twenty PRs and couldn't recount what was in any of them. This lesson is about the exact moment approving stopped being review and turned into a rubber stamp.
The core idea of this lesson. The automatic gates you saw in lesson 6.1 already lock down part of this: green tests, lint, and build guarantee the code does what the checks verify. What they don't guarantee is that the code does the right thing, that it stayed within the requested scope, and that it didn't open a door nobody asked to open. That's why there's a layer above the automatic gate: the judgment of whoever approves. This lesson gives you a five-item checklist for that layer, and a principle with no exception: whoever approves the PR is who answers for what it breaks. The agent signs nothing. You sign.
01"Passed the tests" isn't the same thing as "is correct"
It's worth understanding the difference from the root, because it changes how you look at the pipeline's green. An automated test verifies one specific thing someone wrote before: this function returns this value, this route responds with this code, this screen renders without breaking. It's a closed question, and the test answers yes or no to it.
The problem is an agent can write code that answers yes to every closed question that exists, and still be wrong in a way nobody thought to test. It fixes the requested bug, but also touches a configuration file that had nothing to do with the request. It fixes the error message, but also flips the order of two security checks. The existing test stays green, because it was never designed to catch this kind of deviation. The automatic gate from lesson 6.1 is real and works, it just blocks what someone already knew needed blocking.
02Why approving at scale turns into a rubber stamp
Here lies the risk nobody says out loud. When the volume of agent PRs rises, the reviewer gets tired. The pattern repeats: open, look at the summary, see the green, approve. By the twentieth one of the day, the brain has already decided "this always passed before", and the click to approve becomes reflex, not judgment.
It's exactly the mechanism of the deadly catch that already showed up in this track: speed without review turns into debt and incident. Except here it has a specific face, the rubber stamp's. A rubber stamp is when approval stopped checking something and started only confirming the process was followed. And the worst part is that a rubber stamp feels exactly like real review, from the inside. Nobody realizes it turned into a rubber stamp until the incident shows up.
03The five-item audit checklist
Here's the lesson's core. Five questions, in order, before any agent PR gets approved with your name on it. Think of them as a funnel: each one filters a type of risk, and what survives the five is a PR you can really defend.
The first: does the diff match the intent described in the ticket? Read the original request and read the diff, and check whether one is contained in the other. If the PR does more than the ticket asked for, that extra needs an explanation, not an assumption.
The second: is the blast radius what you'd expect? Look at the list of changed files before looking at the content. A "fix pagination" PR that also touches a cache configuration file is exactly the kind of deviation this item catches.
The third: did the PR touch a secret, permission, credential, or sensitive data? This question alone would have caught the security example from the start of the lesson, where the order of two permission checks was flipped with no test covering it.
The fourth: does the test cover the real case or just the happy path? Ask what would happen if the input were bad, if the system were under load, if the dependency changed behavior. If the answer is "I don't know", the green test proves nothing beyond the easy path.
The fifth, and the most important: can you defend this PR in a meeting, line by line, if questioned? If the answer is "no, the agent did it", the PR isn't ready for approval. Approval with no possible defense is an orphan approval.
Learn more: why item 5 (defense) is the strongest of the five
Items 1 through 4 are objective checks, doable in minutes and almost always catch the obvious deviation. Item 5 is different: it's an honesty test on yourself. If you picture a tough meeting, with your name on the PR and someone asking "why did line 340 change the timeout value", and the only answer that comes to mind is "I don't know, the agent decided", that's the most reliable sign the approval was a rubber stamp. This item works even when you don't know exactly what to look for in the other four, because it doesn't depend on finding the mistake, it depends on you admitting to yourself that you didn't really look. It's the item that survives even when your specific technical knowledge of that piece is limited, because the question isn't "is this correct", it's "do I know enough to say it is".
04The three-tempo ruler: the agent proposes, the gate checks, the person approves
The checklist has a principle behind it, and it's what holds everything up. Think of a three-tempo ruler you never collapse into one.
The agent proposes. It's fast and tireless, and the PR it delivers already comes with a ready, often good, draft. Use that speed freely, it's where the agent shines.
The automatic gate checks. It's what you already saw in lesson 6.1: test, lint, build. It's objective and doesn't accept what didn't pass, and it does this without getting tired, without skipping a line, without a sleepy face on Friday at 6 PM.
And the person approves, for real. That's the step the five-item checklist fills. Approving for real isn't the same as clicking "approve" after seeing the green icon. It's running the five questions and being able to answer each one. Skipping this step is exactly what makes a wrong PR, with a green test, nearly become a production incident.
05Whoever approves answers, always
Close the reasoning with the point that has no middle ground. When a PR breaks something in production, or plants a debt that only shows up months later, the question that matters isn't "who wrote that line". It's "who approved it". And the answer is always a human name.
"The agent did it" doesn't exist as an excuse, the same way it doesn't exist in finance or anywhere else in this track. The agent doesn't go to the post-mortem meeting. The agent doesn't lose the team's trust. The agent isn't who explains to the client why the system was down for forty minutes. Whoever approved that PR is who carries this, because approving is exactly the act of saying "I checked, this can ship".
This isn't distrust of the agent, it's hygiene for whoever operates at scale. The agent hands you back hours of mechanical work. The five-item checklist is the small price that protects that gain: minutes of audit against an incident that costs a night of work, a hard conversation, and a piece of the team's trust. Approving for real is what turns agent speed into speed that's safe to use.
Do it now
Pick a real agent PR you'd approve today just because the tests passed, your your real task or another recent PR from your queue. Run the five-item checklist on it, writing one line of an answer for each:
- Does the diff match the intent described in the ticket or the original request?
- Is the blast radius what you'd expect, or did the PR touch a file or module outside the scope?
- Did the PR touch a secret, permission, credential, or sensitive data?
- Does the test cover the real case (load, bad input, a changing dependency) or just the happy path?
- Can you defend this PR in a meeting, line by line, if questioned tomorrow?
At the end, decide: would you still approve this PR the way it was, or does it need one more look? If the answer changed after the checklist, you just felt the difference between a rubber stamp and an audit.
Practice
1. An agent PR passed all automated tests, lint, and build. What does that guarantee?
2. Why does approving agent PRs at high volume tend to turn into a rubber stamp?
3. An agent PR you approved takes down a service in production. Who answers for it?
For the board
On the green buildit passed the tests is not the same as it is right.
On rubber-stampingthe worst part of rubber-stamping is that from the inside it feels like reviewing.
On who answerswhoever approves answers for what breaks. That is why approval has to be judgement, not a click.
Thanks for the feedback. It helps sharpen the next lesson.