Scope cutting with coding agents

Day 26: Scope Cutting When Code Is Free: Cut What Nobody Can Own

We once deleted a feature that worked. CI was green, the customer wanted it, and an agent had built it in an afternoon. What nobody in the room could tell me was what it would do to the customer's data on a bad day. That's the real cost of agent-built code. Writing it is close to free. Your team still has to read it, debug it at 2am, and explain it to whoever joins next. If you only cut scope by build cost, you'll ship more than your team understands, and incidents come out of that gap.

1. The deletion

This is the case that made the lesson concrete for me. A customer asked for automatic sync with a third-party system they already used. One of our engineers briefed an agent after lunch, and by the end of the day we had a working integration with retries, field mapping, a status panel and tests. CI was green. The demo worked.

In review I asked one question: 'What happens when the upstream returns a partial payload?' Nobody in the room could answer, and that included the engineer who wrote the brief. The code did handle it. There was a branch that merged partial records into existing data. But no human could tell me if that merge was correct, what it would do to the customer's records, or how we'd find out it had gone wrong.

So we deleted it. The feature worked, the customer wanted it, and it had cost almost nothing to build. We deleted it because nobody could own it.

2. The old reason for cutting scope

Most of us learned scope cutting as a capacity problem. You've heard all of these, probably this month:

• ▹'We can't fit it in this sprint.'
• ▹'That's three engineer-weeks. Is it worth it?'
• ▹'Let's do the MVP and add the rest later.'

Every one of them assumes the expensive part is writing the code, so cutting scope means not paying for it. For a long time that was close enough to true. Writing code was slow, which meant that by the time something shipped, the person who wrote it understood it. You got comprehension for free with authorship.

3. What agents changed

Agents broke that link. Code now shows up faster than anyone can absorb it, and the person who 'built' a feature may never have read most of it. The cost is still there. It just shows up later, somewhere else:

• ▹Review load. Reviewers get more diff than they can really read, so they skim, and skimmed code is unowned code.
• ▹On-call surprises. Often the first person to properly understand a code path is whoever gets paged when it breaks.
• ▹Context debt, which is code that runs but that nobody can explain. You can plan to pay down ordinary tech debt. You can't plan to pay this down, because nobody knows what's in it.

This connects to two earlier days. On cost of delay, we said speed matters because value decays. That's still true, but shipping faster doesn't help if nobody can support what you shipped. On outcomes over output: agents make output almost unlimited, so the gap between output and outcomes is now wider than it has ever been.

4. Today's lesson in one line

Cut what nobody can own. Your budget is human comprehension, not lines of code. Scope cutting used to ask 'what can we afford to build?' The question now is 'what can we afford to understand and keep running?'

Comprehension is the scarce resource, so you guard it at two points:

5. Cut #1: before the agent writes anything

Left alone, agents grow scope. They're trained to be helpful and thorough, and they have no way of knowing which kinds of thoroughness your team can actually support. Hand one a vague phrase like 'handle edge cases' and you can easily get back 400 lines covering cases nobody asked for: retries with backoff, config flags, fallback modes, a migration helper. Each one is reasonable on its own. Together they add up to more than anyone can own.

The research on multi-agent systems says the same thing. In my PhD work, and in failure taxonomies like the MAST study (Cemri et al., 'Why Do Multi-Agent LLM Systems Fail?', 2025), a large share of failures trace back to specification and system design. Agents disobey the task specification or their role, or the task drifts away from the original goal. A loosely bounded task doesn't stay small. It drifts, and in my experience it nearly always drifts toward doing more.

The fix is to write the non-goals down, explicitly, in the brief. Here's the brief from the sync feature, before and after:

# BEFORE
Build a sync integration with <VendorX> so customer records stay
up to date. Handle edge cases and errors robustly. Make it
configurable.

# AFTER
## Goal
One-way, manual-trigger import of contact records from <VendorX>
into our Contacts table, for a single workspace.

## Done means
- User clicks 'Import now', records are created or updated by email.
- Any upstream error or incomplete payload: abort the whole import,
  write nothing, show the raw error to the user.

## NOT (do not build these, even if they look easy)
- Do NOT support bulk import across workspaces.
- Do NOT merge partial records. Reject incomplete payloads.
- Do NOT add scheduled/automatic sync.
- Do NOT add config options or feature flags.
- Do NOT refactor the auth module or any shared code.

## If you think a NOT item is required
Stop and explain why. Do not implement it.

• ▹'Done means' spells out the failure behaviour. A human can reason about 'abort and write nothing'. Nobody can reason about 'handle it robustly'.
• ▹The NOT section goes after the things agents usually add on their own: generalisation, configuration, and 'helpful' refactors of shared code.
• ▹The escape hatch matters most. 'Stop and explain' means scope can't grow silently. A human gets to decide.

6. Cut #2: after the agent finishes, the ownership test

Even a good brief leaks. So at PhoenixDX we now ask three questions in review, before anyone comments on code style or test coverage:

• ▹Can a named human explain how this fails? I mean a name, not 'the team'. That person should be able to walk through the main failure modes without opening the agent transcript.
• ▹Will someone still want to debug this in 18 months? Picture the engineer who joins next year with no context, on the day it breaks.
• ▹Would we build it if a human had to write it? If the honest answer is 'no, not worth a week', it isn't worth owning forever just because it took an afternoon.

If any answer is no, the code gets cut, or shrunk to the part someone can explain. That holds even when it already works. Emotionally this is the hard bit, because deleting working code feels wasteful. But you've already paid to write it and that money is gone. What you're deciding now is whether to keep paying for it.

Where teams get this wrong:

• ▹Asking the agent to explain the code and counting that as 'a human can explain it'. An agent explaining its own code is not ownership.
• ▹Naming an owner who has never read the hard paths. That's assignment, not ownership.
• ▹Using the test to block everything. The point is to shrink to what someone can own. Rejecting by default misses it.
• ▹Saving it for big features. Context debt piles up quietly in the small stuff, like the helper or config flag the agent added along the way.

7. What it cost us

The customer conversation was uncomfortable. They'd seen a demo, or heard one was coming, and now we were offering less. I didn't tell them 'we couldn't build it'. I said: 'We built it, and we couldn't confidently tell you what it would do to your data when your vendor sends incomplete records. We'd rather ship something smaller that we can stand behind.' It went better than I expected. Customers understand 'we won't risk your data'. 'We ran out of time' gets a lot less sympathy.

What we shipped instead was the 'after' brief: a manual, one-way import that aborts the moment anything looks wrong. It was smaller and less impressive. But the engineer who owned it could draw every failure path on a whiteboard. When the upstream did eventually send malformed data, the import stopped, the user saw the error, and nobody had to clean up the data afterwards.

I also got a cut wrong. In a different review we deleted an agent-built CSV export because nobody could explain its encoding handling. It turned out to be simple, just standard library behaviour, and an hour of one person's reading would have been enough to own it. We cut out of caution when we should have spent the hour, and a few weeks later we rebuilt it. Sometimes 'nobody can explain it' really means 'nobody has tried yet'. Before you delete, ask whether a modest amount of reading would make the code ownable. If it would and the feature matters, do the reading. Use the test to support your judgment. It's not a rule to apply mechanically.

8. Your exercise for Day 26

• ▹Pick the last thing an agent built for you that got merged, or nearly did.
• ▹Write the three-line NOT list you should have given it. What did it add that you never asked for?
• ▹Answer the three ownership questions honestly. Question one needs a name.
• ▹Any 'no' is your scope cut. Decide whether to delete it, shrink it, or spend the reading time to make it ownable, and write down which and why.

9. Bridge to Day 27

Once you're cutting for ownership, the next question is who owns what. You'll also need a way to say no to stakeholders when the honest reason is 'we can't understand it' and not 'we can't build it'. That conversation is harder, and it's what Day 27 covers.

Extend your knowledge

• ▹Read 'Why Do Multi-Agent LLM Systems Fail?' (Cemri et al., 2025). Focus on the specification-related failure modes (disobeying the task specification) and on task derailment. Both map directly to why non-goals belong in briefs.
• ▹Re-read Peter Naur's 'Programming as Theory Building' (1985). He argues that a program's real value lives in its programmers' understanding. It's the oldest and clearest case for treating comprehension as the scarce resource.
• ▹Add a 'NOT' section and a 'Done means (including failure behaviour)' section to your team's agent brief template, or to your CLAUDE.md or AGENTS.md. Run with it for two weeks.
• ▹Put the three ownership questions in your PR template so reviewers have to answer them explicitly and can't just assume them.