Don't Just Measure Code. Measure Engineering Decisions.

We already write down why engineering decisions get made. That’s what RFCs are for. They capture the problem, tradeoffs, alternatives, and the decisions we expect the team to build on. We also have pretty good ways to tell you where and what engineering work happened. Git can tell you which commit changed a line. CI can tell you which test failed. Session records can tell you the one session that cost $2,633. But we don’t have a good way to answer the question “What happens next?”

Now that agents are generating a lot more engineering work, a lot faster, it’s becoming an important question.

The way most of us experience this is like this: An architecture decision gets made. Someone implements it. Someone else builds on top of the implementation. Another person hits an edge case the decision never considered, and a chunk of work gets thrown away and redone. There’s a migration. Then there’s a production problem during the migration.

Every piece of that work looks like its own task, commit, or agent session, but it all started from the same decision.

That matters when we talk about AI budgets. We can put a budget on an engineer or threshold on a session, but it doesn’t tell the story of why the organization spent the money.

The cost of an engineering decision is the work that decision causes afterward. How many systems did it touch? How many engineers did it pull in? How long did it keep generating work? How much of that work was rework? How much implementation did it amplify relative to the cost of making the decision?

To measure this for our team, I traced one of our architecture decisions through 30 days of session records to put a price on that sentence. The design doc cost $57.05 to write. The work it set in motion cost $4,704.74, spread across 70 sessions, 3 engineers, 8 repos, and 27 days. This post is about the metric behind those numbers and how any team that keeps agent session records can compute it.

An RFC tells you what you expected the decision to do, git tells you what the decision changed, and session records tell you what the decision caused. Blast radius connects them all together. It measures the downstream footprint of a single decision and gives you historical data for engineering decisions in the same way you have historical data for incidents, deployments, and infrastructure. A mediocre decision with nothing depending on it is a cheap fix. A mediocre decision with three engineers, eight repos, and a migration depending on it is load-bearing and blast radius is a way to measure that before you’re committed.

We measured one architecture decision through 474 sessions

In late July, our team decided to restructure tapes around cassettes: pull search, export, and skills out of the core and ship each as a standalone unit, as part of the open-core release of tapes. (If you want to know what a cassette actually is before you watch one cost us money, start with The Anatomy of a Cassette.) The decision trail starts cleanly. On July 23, one engineer reads the RFC (“This is the source of truth for our tapes and cassettes project”). On July 24, another writes DESIGN.md in a $57.05 session. Five sessions, $71.51, and the decision phase is over.

Then it starts to travel. I grouped every downstream session into rings by causal distance, using the session records themselves as evidence. Each ring below is connected to the previous one by verbatim prompt text, session by session.

The chain is legible in the prompts. July 27: “Read @DESIGN.md and implement this.” August 3: three extraction sessions all open by reading the freshly written cassettes.md before pulling their feature out of core. August 12: “the cassettes just were released in public ecr so its time to get our cloud in shape.” Each session picks up an artifact the previous ring produced. That’s a decision propagating through a team, recorded turn by turn.

You can walk the same evidence yourself. The explorer below holds all 474 sessions the decision caused: switch between the rings and the timeline, and tap any dot to see what that session cost and where it sits in the cascade.

The cost curve runs backwards from the session count

Session count is front-loaded: 44 of the 70 human sessions are implementation. Cost is back-loaded: 87% of the money sits in deployment and migration, rings that contain five sessions total. Flip the chart below between the two measures and watch it invert.

One deployment session carried $2,633.11 over 145 turns. That’s 46 times the cost of the design session, and 56% of everything the decision has cost so far. The cassette thread as a whole consumed 20% of our org’s entire 30-day fleet spend.

If you’ve been budgeting agent costs per seat or per session, this is the argument against it.

The rework the session records refused to hide

Following the rings also surfaces what the decision got wrong, priced and dated.

Four days after DESIGN.md, an engineer reviews the new code and writes: “I’m confused about the concept of an ‘alias’… Registration order is load-bearing twice.” The alias subsystem is scrapped the same day, about $42 across 4 sessions. Five days after the design, the TOML manifest format is replaced wholesale with a versioned OpenAPI spec. Two weeks after deploy, ergonomics complaints are still arriving (“I’m not a fan of the CASSETTE_ presumed prefix”).

And on August 14, inside the migration grove, the radius reached production: “I think we need to solve PCC-1203 pretty urgently.” A pathological Postgres query, caught in the logs during cutover. The fix was validated at a measured 1,130× speedup on the live tenant. That session cost $45.92 and would never show up in any accounting keyed to the original project, because by August the project was “done” even though the decision wasn’t.

There were also 404 automated eval sessions grading cassette documentation and rubric compliance, $431.54 and counting. The decision created a permanent measurement workload. When you price a decision, you have to count the automated systems it creates and leaves running, because those have a cost too.

The question git can’t answer: which decision caused the most work this quarter?

Notice what it took to draw those rings. Git gives you the lineage of code. blame, bisect, log --follow: ancestry for every line. Ticket systems give you the lineage of tasks, with dependencies and links between them. Both are genuinely good at what they track, and neither can tell you that a $2,633 deployment session in August exists because of a design doc written in July. The commit graph connects code to code. The ticket graph connects task to task. The decision that created all of them should link them all.

Which engineering decision caused the most work for your team this quarter? Session records are the one artifact that captures those fingerprints at the moment the work happens, and if you keep them, you can follow a decision for as long as it keeps generating work.

Four blast-radius metrics to track with your AI agents

Once the sessions are grouped by decision, four measurements fall out. Here’s each one, with the value our cassette decision produced.

• 1.Reach. How far the decision traveled: repos touched, systems changed, people pulled in, agent sessions depending on it. Ours reached 8 repos, 3 engineers, and 474 sessions, 404 of them robots.
• 2.Duration. How long the decision keeps generating work. Ours ran 27 days from design doc to the last human session, and the automated measurement ring is still counting.
• 3.Rework. How much changed after the decision was made: the scrapped alias subsystem, the manifest format replaced within five days, the $45.92 production fix during cutover. Rework is where the decision’s blind spots get priced.
• 4.Amplification. How much implementation one decision produced, relative to what it cost to make. Ours turned $57.05 of design into $4,704.74 of downstream work: a 65× floor.

Together, those four are the blast radius. None of them requires new instrumentation if you already record agent sessions. They require grouping the records you have by the decision that caused them.

How much future work depends on today’s decision?

The one-time analysis was the easy half. The blast radius metric should be a standing question, because a decision propagates through stable identifiers: repo names, working trees, ticket IDs, branch names.

The loop is simple. Each monthly pull, re-run the tracker and diff the rings. Ring 4 and 5 growth means the migration is still consuming engineers. New names appearing in ring 5 means adoption, and we check whether each new person costs less to onboard than the last (the cutover-kickoff docs should be doing that work). Ring E growth means the measurement tax is compounding. Two flat pulls in a row means the decision is settled, and we stop watching it.

It’s worth noting that signature matching is a floor. I can only count sessions that name the work in a title, a path, or a prompt. A session that touched cassettes without saying so slips through. I take the floor seriously anyway, because a floor of $4,704.74 against a $57 design doc is already a 65× amplification, and the true number is only higher.

Agents make engineering work measurable

None of this measurement was possible for us two years ago, and the reason it’s possible now is that agents leave complete records. The same fleet that amplified a $57 doc into $4,704.74 of work also wrote down every step, which is the only reason I can show you the rings at all.

Agents make it possible to operationalize a decision faster than we can learn whether it was a good one. Our cassette decision went from the initial look at the design doc to production deployment in ten days. The rework evidence (the scrapped subsystem, the replaced manifest format, the urgent production fix) arrived mostly after the expensive rings had already run.

AI has collapsed the cost of execution. It hasn’t collapsed the cost of thinking, and no model roadmap will, because the thinking is the part that decides what all that cheap execution gets aimed at. In our cascade, the $57.05 design session was the cheapest line item on the bill and the only one that determined the shape of everything else. If execution is nearly free and decisions are 65× amplifiers, the leverage has moved upstream, and maybe the friction belongs back where the leverage is: slower, more deliberate decisions, reviewed like the dependencies they are, because everything downstream of them now happens fast.

Measure the thing that creates the work

Over time, blast radius answers a question RFCs can’t: What happened the last time we made a decision like this, and what did it actually cost? The method transfers to any team that records agent sessions: anchor the decision to its origin artifact, write down its identifiers, classify the sessions it caused, and re-run.

If you’re not recording sessions yet, that’s what paper or our open source project, tapes, is for. Pick one decision your team made this quarter. If you had to draw its rings today, could you?