The Playbook and the Contract
The author of Atlassian's AI SDLC playbook answers Impatient Programming. He concedes the missing verification step and pushes back on green merges and unmeasured spend.
Answering IMP
On October 1 I published Atlassian's AI SDLC transformation playbook. Since then I've read Impatient Programming, Obie Fernandez's method for teams that build with coding agents. Its article has a name for what my planning section describes: Confluslop. AI-written plans that nobody reads get turned into Jira tickets, and the tickets get turned into code.
The critique lands, and I'd like to answer it properly.
The two were written for different readers. IMP is for a team that picks a method and adopts it whole. The playbook is for engineering leaders steering large organizations through a change in how they build software. Even so, they landed on a lot of the same ground.
Where IMP and the playbook agree
The playbook's starting claim is that coding agents moved the bottleneck. Writing code got cheap, so the slow parts are now the work on either side of it. IMP starts from the same place and says it shorter: typing is nearly free.
Several IMP rules read like chapters of the playbook.
- Rule 6 wants every Claude Code session feeding a shared knowledge graph. That's the whole idea behind the Teamwork Graph, down to the part where what agents learn flows back in for everyone.
- Rule 10 and rule 25 hand maintenance to agents. We do that with agent loops in Jira that pick up well-defined work and open pull requests.
- Rule 18 has a non-programmer CEO building prototypes. We want designers and PMs shipping UI fixes on their own.
Both put rigor in machines, too. IMP says a name can't drain rigor that a build enforces. I'd put it as standards defined once and applied by agents on every change.
Side by side
| Topic | The playbook | IMP |
|---|---|---|
| Specs | AI drafts requirements and PRDs from org context, people refine them, Jira turns them into work items | The Contract: invariants in the source code, executable, mutation-tested, complete enough to regenerate from |
| Review | AI goes first, and people keep the final call | Green merges itself, and blast radius sets how far you push that today |
| Tests | One passing mention | Contract first, then a kill matrix, and every test earns its place |
| Complexity | KTLO backlog for agents to work down later | Exhale in the same PR |
| Measurement | DX surveys and telemetry, cost, ROI, cycle time | A fix is a production defect, everything else is refine: |
| Cadence | Not covered | No iterations, a Friday showcase, a forecast from the top of the hill |
| Regeneration | Not covered | A fire drill, run now and then |
| Source of truth | Jira, Confluence and the Teamwork Graph | The Contract, versioned with the code |
| Who it's for | Leaders running a transformation one workflow at a time | Teams that pick a method and say "this is how we work now" |
| Evidence | 44% more accurate agents on 48% fewer tokens, cycle time from 11.5 to 6.7 days, 51% of potential vulnerabilities fixed by agents | Seven regeneration experiments on Agora, a Contract that out-killed the old test suite, one production bug found |
Where IMP has a point
The playbook's planning flow goes like this. Agents gather context from across the org and draft the requirements, people refine them in Jira, and the finished plan becomes tracked work items. I described the people in that loop as applying judgment. I never said how they check the plan against the code agents write from it.
That gap is real. A long AI-drafted spec that nobody reads closely produces tickets that nobody questions. Then agents build exactly what the tickets say. IMP calls that waterfall for the TikTok generation, and I can't argue with the shape of it.
Testing got one passing mention in the playbook. IMP builds its whole method around it. Before an agent starts big work, you write down the invariants the result must hold (rule 20). Then you make them executable and prune any test that a mutation run shows catches nothing new (rule 26).
Editor's note, October 7, 2026: Rule 20 has changed since Matthew wrote this. It now says the agent writes each obligation into the Contract during the inhale, while you work out the feature together, and that making sure the Contract is complete is part of the exhale.
The playbook's own comparison table already points this way. Its AI-native column says specs should live as versioned files in the repo. The Contract is a stricter version of that idea, one a machine runs on every change. I'd add it to the planning section as the step that closes the loop.
Where I'd push back
Rule 27 says green merges itself, and the long-term goal is no human code review at all. Blast radius decides how close a team gets today. I like that blast radius is the dial. I'd keep a person on the final call longer than the rule does.
My reason is scale. Picture an organization with thousands of engineers and hundreds of services, where one change touches dependencies its author has never seen. That organization needs to know who approved what, and why. The playbook asks for agent loops that are scoped, aware of standards, and recorded in a system of record. The record is how a leader answers an auditor, or a customer, after something goes wrong.
IMP is quiet on agent permissions, too. We enforce them where the data lives, so an agent can act only on what the person running it is allowed to see. A team at a fintech that hands maintenance to autonomous agents will get asked about this. I'd love to see a rule for it.
Measuring it
Rule 9 counts a fix only when it repairs a defect live in production. Everything else gets labeled refinement. I'd adopt that tomorrow. Small agent PRs make a dashboard lie, and a label is a cheap way to stop it.
The same rule says spend isn't measured, because AI is practically free once it's set up. That line would end the conversation with most of the CFOs I know. Token bills are real at enterprise scale. The leaders I wrote for have to show what the money bought, so the playbook puts measurement first, before adoption grows.
The same reasoning reaches our own headline number. Issue cycle time dropped from 11.5 days to 6.7, and cycle time drops whenever issues get smaller. That number deserves the scrutiny rule 9 gives to bug counts.
One more thing IMP could borrow. We pair the telemetry with what developers tell us about the work. IMP's heart value puts people first, and asking them regularly would give that value a practice.
Editor's note, October 7, 2026: Rule 9 has changed since Matthew wrote this. It now says that on flat-rate plans the bill is fixed, so the thing to watch is how close you run to the plan limits. For teams paying per token, his point stands.
The graph and the Contract
IMP keeps the source of truth in the repo, as the Contract. In the playbook it lives in a system of record that connects code to work, people and decisions.
I think a team needs both, and they fit together. An agent that starts in the wrong place wastes tokens and the developer's patience, which is the problem a context graph solves. Once it's pointed at the right code, it still needs to know which promises that code makes, and an executable Contract is the clearest way I've seen to hand it those.
So here's the change I'd make to the playbook. Planning ends when the invariants are written and a machine can run them. Until then, the tickets wait.