Twelve Working Agreements for Machine-Written Code

The retro was the easy part.

Your team ran the vibe-coding hangover retro. The churn data was on the board, the room agreed the review queue had been quietly rationing itself, and everyone left with the rare post-retro feeling of having decided something. Two sprints later, the agreements live in a summary document nobody opens, and the churn chart hasn't noticed a thing.

That failure mode is well documented: about two-thirds of retrospective action items die without changing anything. Working agreements die faster, because an agreement is a norm, and a norm gets no ticket number and no owner unless you give it one.

This is the rulebook half of the hangover retro. Twelve working agreements for teams shipping machine-written code, built from the same public research that named the problem. The three examples from the original post are here, joined by nine more, all in the same format: a rule the team can state in one sentence, the number that moves when the rule is followed, and the check-in where you look.

What Is a Working Agreement for Machine-Written Code?

A working agreement for machine-written code is a rule a team writes for itself about how AI-generated changes get produced, reviewed, and owned. It differs from a policy in both origin and enforcement: a policy is handed down and audited, while a working agreement is negotiated in a retrospective, verified against the team's own delivery data, and rewritten when that data says it isn't working.

The research case for them is direct. DORA's 2025 report found 90% of developers now use AI at work, with adoption positively linked to throughput and negatively linked to delivery stability. Its AI Capabilities Model identifies what separates teams that AI amplifies from teams it destabilizes, and every capability on the list is organizational: a clear and communicated AI stance, small batches, strong version control practices. A working agreement is the smallest unit of organizational stance — one sentence the whole team has agreed to be held to.

A Rule, a Number, a Check-In

Most working agreements fail structurally, not culturally. They're missing one of three parts.

The rule has to fit in one sentence a teammate can state cold. If it takes a paragraph, it's guidance, and guidance loses to a deadline every time.

The number makes the rule falsifiable. Verification is exactly where intuition misleads: Stack Overflow's 2025 survey of 49,000+ developers found the top frustration with AI tools, cited by 45%, is code that's "almost right, but not quite" — and almost-right code feels fine until production disagrees. Feelings don't arbitrate that. Numbers do.

The check-in gives the number a date and a venue, usually the first five minutes of the next retro. A rule without a number is an opinion. A number without a check-in is wallpaper.

The Twelve

Steal freely. The numbers in the rules (400 lines, 90 days, two tasks) are starting points to tune, not laws.

Review Is Rationing Itself. Ration It on Purpose.

Faros AI's 2026 telemetry across 22,000 developers found median time to first review up 156.6% and PRs merged with no review at all up 31.3%. When review capacity runs out, teams don't decide to skip review — it decides itself, one "looks fine" at a time.

1. "Nothing merges without one human approval, green CI or not." The baseline agreement. Nearly a third more changes now reach production without a single human reading them, and almost-right code is precisely the kind that passes CI. Check: no-review merge count, weekly.

2. "Machine-written PRs over 400 lines get split before review." Small batches are the most load-bearing capability in DORA's model, and batch size is the input a team controls most directly. A reviewer can hold 400 lines honestly; nobody holds 2,000. Check: PR size distribution, next retro.

3. "Changes touching auth, payments, or data migrations get a second reviewer, whoever the author was." Scale verification with blast radius, not with confidence in the tool. The hot paths are wherever your incidents already cluster; name them explicitly in the agreement. Check: two-approval rate on hot-path PRs, next retro.

Ownership Survives the Autocomplete

The module nobody wants to touch has an author who can't explain it. These two agreements keep authorship meaning something.

4. "If you can't explain the diff, you can't merge it." Explanation is the cheapest verification available: it costs ten minutes and catches the class of bug that review skims past. If explaining a change takes longer than regenerating it, that's information about the change. Check: at demo prep, one merged machine-written PR per engineer gets walked through aloud, each sprint.

5. "The PR description records what the human verified, not what the model generated." "Ran the migration locally, tested the rollback, checked the query plan" tells a reviewer where the human attention went. DORA's 2026 ROI report calls the cost of checking machine output the verification tax; this line item makes the tax visible instead of ambient. Check: share of merged PRs with a verification note, next retro.

Churn Is the Honest Speed Metric

Code churn is up 861% in the Faros data. A feature that shipped twice was not fast the first time, whatever the sprint report said.

6. "A rewrite inside 90 days is rework, and rework gets a ticket." The 90-day window comes from the pattern Autonoma calls the 90-day reckoning: month-one speed becoming month-three debt. Rework that never appears in the tracker is a cost the team pays but never counts. Check: rework tickets and churn rate per module, next retro.

7. "Throwaway code is declared throwaway at birth." Spikes and prototypes are a legitimate use of AI speed. Label them when they're created, so the churn stats stay honest and no spike gets promoted to production by everyone forgetting what it was. Check: share of churn coming from labeled spikes, monthly.

Incidents Are Where the Tax Comes Due

Incidents-to-PR ratio: up 242.7%. Bugs per developer since adoption: up 54%. The verification you skip at review time gets performed in production, at the worst possible hourly rate.

8. "Every incident review asks whether the triggering change was machine-written, and we track the ratio." Not for blame — the ratio replaces the loudest anecdote in the room with the team's own number, and it's the number that tells you whether agreements 1 through 5 are working. Check: postmortem template field; ratio reviewed monthly.

9. "A human owns every test's assertion." AI writes plausible tests the way it writes plausible code, and a test that asserts nothing is worse than no test, because it buys confidence without buying verification. Drafting tests is delegable. Deciding what must be true is not. Check: escaped-bug count, next retro.

Don't Flood the Queue

10. "Two agent tasks in flight per person, max." Typing speed used to be a natural work-in-progress limit; agents removed it. One engineer can now open PRs faster than three can review them, and the overflow becomes either review latency or unreviewed merges — the same two numbers already moving the wrong way. A WIP limit on delegation keeps the human verification budget solvent. Check: open PRs per author, weekly.

Agreements About the Agreements

The last two exist because the first ten will otherwise join the two-thirds of action items that die.

11. "Every agreement carries an expiry date." Three sprints is a sensible default. At expiry the team re-votes: keep, rewrite, or retire. An agreement that auto-renews forever is a policy in disguise, and a list full of dead rules teaches the team the list is decoration. Check: the active list and its ages, each retro.

12. "The retro opens with the scorecard." First five minutes, before new topics: each active agreement, its number, and whether it moved. This is the loop shipping and sticking instead of shipping and evaporating. Check: it's the first agenda item, every retro.

Label the Code, Never the Coder

Several of these agreements track whether a change was machine-written. None of them track who leaned on the model, and the distinction carries the whole system. Change-level data describes how the team's process handles a new kind of code. Person-level data becomes a leaderboard, and a leaderboard corrupts every number it displays: the moment engineers suspect the incident ratio feeds a performance review, they stop labeling honestly, and the retro is back to running on vibes.

This is the same argument we've made about measuring AI's impact generally: measure outcomes at the team level, never activity at the person level. The agreements above only work because everyone in the room knows the numbers judge the process, not the people.

How to Adopt These Without Killing Them

Adopt two or three, not twelve. A team holding twelve new rules checks none of them; the menu exists so you can match agreements to your own worst numbers.

• Start from your data, not this post. If churn is flat but incidents are climbing, you want 8 and 9, not 6 and 7. Pull the numbers before the retro and let them pick.
• Vote in the retro. An agreement imposed by a manager is a policy wearing a costume — it gets compliance, not ownership. The team that wrote the rule is the team that defends it under deadline.
• Record the baseline at adoption. "No-review merges: 14 last sprint" turns the first check-in into a comparison instead of a debate. No baseline? Then finding it is the first action item.
• Give each agreement an owner. Not an enforcer — a reporter. One person brings the number to the retro so the scorecard never depends on collective memory.

FAQ

How many working agreements should a team have at once?

Two or three active agreements at a time. Each one needs a number pulled, a check-in held, and an owner reporting, and that attention budget runs out fast. Teams that adopt a long list check none of it; teams that adopt three and retire or replace them at expiry build the habit that makes the next three cheap.

Should pull requests be labeled as AI-generated?

Yes, at the change level — a label or a PR-description note is enough to make churn and incident ratios computable. Never at the person level: per-engineer AI usage tracking corrupts the data it collects, because people game whatever is watched. The useful question is how the process handles machine-written changes, not who produced them.

What if the number doesn't move?

Then the check-in worked. Either the rule wasn't followed, which usually means it was too expensive as written and needs renegotiating, or it was followed and didn't help, which means retire it and spend the attention elsewhere. An agreement that can fail visibly is the only kind that can succeed credibly.

Do these work without sprints?

Yes. The check-ins attach to whatever reflection rhythm the team has — weekly, per release, or event-driven. The cadence matters less than the venue: a recurring moment where the numbers are on the board and the team is allowed to change the rules.

The Bottom Line

The hangover retro's argument was that vibe-coding debt is a process failure, and the retrospective is where process gets renegotiated. This is the other half: what leaves that room has to be falsifiable, or the next retro re-argues it from scratch. The teams getting past the hangover aren't the ones with the strictest AI rules or the loosest. They're the ones writing rules that can lose an argument with the data — and letting them lose.

Steal three. Set the expiry. Open the next retro with the scorecard.

Sources

• Faros AI — "Ten takeaways from the AI Engineering Report 2026: The Acceleration Whiplash" (April 2026)
• DORA — State of AI-assisted Software Development 2025 (September 2025)
• DORA AI Capabilities Model (2025)
• InfoQ — "New DORA Report Claims Strong Engineering Foundations Drive AI Return on Investment" (May 2026)
• Stack Overflow — 2025 Developer Survey results (December 2025)
• Autonoma — "Vibe Coding Technical Debt: The 90-Day Reckoning" (April 2026)

Further Reading

• The Retro for the Vibe-Coding Hangover — the retrospective this rulebook comes out of.
• Why 2/3 of Retrospective Action Items Die (And How to Fix It) — the follow-through mechanics behind agreements 11 and 12.
• Measuring What AI Actually Does to Your Team — the team-level, AI-neutral measurement argument in full.
• Ship and Stick: How to Measure Whether AI Is Actually Working — the outcome standard the scorecard closes on.