When a feature is split across several agent runs, what stops the fourth reinventing what the first built?

## The problem splitting creates Cutting a feature into units buys earlier evidence and a smaller loss when a unit goes wrong. It also creates something that did not exist before: **boundaries across which the work can disagree with itself.** Each run starts from what it can see. What it can see is the repository — not the reasoning of the run that went before it, which lives in a transcript nobody re-reads, and not the plan in your head. So the question for every decision made in an early unit is narrow and practical: *what did that decision leave behind that a later run will trip over?* ## What the failure looks like Across the reporting migration, unit one puts every date call site behind an internal helper. Three units later, a run adding a period column to the export writes its own small date routine beside it, because that was the shortest path to a passing test. Both are reasonable code. Together they are two date policies in one module, and the year-end rounding differs between them. It is a tidy-looking failure, which is why it survives: - each unit's diff is individually sensible, so unit-by-unit review passes it; - the tests pass, because each piece was tested against itself; - nothing is duplicated textually, so a mechanical check has nothing to flag; - it is only visible across the set, and the set is never looked at as one thing. ## What actually carries a decision across a boundary | what you want to survive | what really carries it | what does not | |---|---|---| | all date work goes through one helper | the helper exists and the old route is gone | a line in the plan | | week boundaries round this way at year end | a test named for the year-end case | a sentence in the previous session | | the export's times are the customer's, not the server's | the helper's parameters make it explicit | a convention people know | | why the rule was chosen | a note recorded with the change | the code, which shows only the what | The right-hand column is the point. Intentions expressed only as text outside the repository do not cross the boundary, because the next run does not read them and a colleague picking the work up on Thursday does not either. ## Three things that actually hold a set of units together 1. **Make the shared thing the first unit's product, and close the alternative.** A helper that later units *may* use is a suggestion. A helper they must use, because the direct route no longer compiles or the old dependency is gone from the module, is a constraint. The second costs a little more to build and is the one that survives contact with four more runs. 2. **Encode decisions as tests, not as prose you re-paste.** A test named for the last week of a year fails when a later unit contradicts it, in the ordinary run of the build. A paragraph carried from session to session degrades every time it is restated, and it never fails anything. 3. **Review the set once, not only the units.** Splitting moves a review cost; it does not remove one. One pass over the finished feature asking *is this one design or four?* catches what unit-by-unit review is structurally unable to see. ## What this does not claim It does not claim these measures guarantee agreement — a later run can still add a second path, and people do it too, for the same reason: it was the shortest way to green. What the measures change is the cost and visibility of the disagreement. A contradicted test fails loudly at the moment it is contradicted; a contradicted intention merges. Nor does it claim splitting is the cause of the disagreement. Two developers, two weeks apart, produce the same duplication for the same reasons. Agent units simply run the sequence faster and more often, so a habit that leaked slowly now leaks at speed. ## The cost side Closing the alternative route is real work: sometimes it means deleting a path that still has callers, or taking the dependency out of a module before you would otherwise have bothered. It is worth it when several units queue behind the seam, and it is over-engineering when the feature is two units long and one person is doing both this afternoon. ## What a good answer sounds like Say plainly that nothing about splitting makes the units agree, then name the carrier: **the code, not the conversation.** Give one concrete example — the helper with no way around it, the test named for the year-end case — and finish with the review pass over the set, because that is the part people leave out. A weak answer promises to "keep context between sessions", which describes the problem rather than a mechanism that fails when it is violated.