When a drafting model writes most of a suite's cases, where does the team's effort move instead of vanishing?
answer
- Cost relocates, it does not vanish
- Drafting is the smallest lifetime term
- Volume drives review and triage hours
- Count multiplies every recurring term
basics
~20 sAuthoring effort falls; review, triage and repair rise. Cheap drafting increases how many cases a team must read, explain and keep truthful, so the cost moves downstream and is charged against a bigger standing suite.
solid answer
~50 sDrafting is only the first payment on a case. When a model produces cases quickly, the hours saved writing reappear as **review**, because someone must confirm the case asserts the behaviour that matters rather than the behaviour the product happens to have today, and as **triage**, because every case added is a future failure someone must explain. Repair rises too: each case is a standing claim about the product that must be corrected whenever the product legitimately changes. The shape of the cost curve changes, not its total. Drafting is charged once against the cases added; review, triage and repair are charged repeatedly against every case the suite now holds, so cheap supply raises the count and the count drives the recurring bill. A team that measures only authoring hours reports a saving it is not actually banking.
code
pseudocode · 11 lines# where a suite's hours actually accumulate, per release
authoring = new_cases * hours_to_draft # falls sharply
review = new_cases * hours_to_read # falls very little
triage = total_cases * unexplained_rate * hours_to_diagnose
repair = total_cases * change_rate * hours_to_fix
total = authoring + review + triage + repair
# cheap drafting shrinks term one and grows total_cases,
# which is the multiplier on terms three and fourgo deeper
Be ready to say that a case costs something after it is written: someone reads it, someone explains its failures, someone repairs it when the product changes. Knowing a case is a recurring cost rather than a one-time purchase is enough at this level.
An interviewer expects you to name the terms and say how each scales. Drafting is charged once against new cases; review, triage and repair are charged against every case the suite holds, so raising the count raises the recurring bill even when each case got cheaper to write.
Show that you have watched it happen. Describe the interruptions that arrive first, why a passing drafted case is weak evidence of value, and what you changed in how work was intaken and budgeted once you saw the total refuse to fall.
Own the accounting. Decide what your organisation counts as the cost of a suite, insist the recurring terms are booked somewhere visible, and be able to argue that the return on cheap drafting is coverage of previously untested behaviour rather than a smaller bill.
Drafting a case is the first and smallest payment a team makes for it. Every case that lands in a suite opens a stream of obligations that runs for as long as the case stays there: someone reads it before it is trusted, someone explains each of its failures, and someone repairs it whenever the product legitimately changes shape. Cheap drafting attacks exactly one term in that stream, the first one, and while it does so it inflates the multiplier every other term is charged against, because supply that costs little tends to be consumed in quantity. ## The lifetime terms of a single case | Term | Paid when | Scales with | What cheap drafting does to it | | --- | --- | --- | --- | | Drafting | once, at creation | cases added | falls sharply; this is the visible win | | Review | once, at acceptance | cases added | falls little; reading is not cheaper than writing | | Execution | every run | total cases | rises with the count, mostly as machine time | | Triage | on every failure | total cases | rises with the count, entirely as human time | | Repair | on every product change | total cases | rises with the count, entirely as human time | | Retirement | once, at removal | stale cases | deferred, which is part of why it feels free | Only the first term is charged against the cases added this week. The rest are charged against the whole standing base, which is why a suite that grows quickly gets expensive quietly: the bill arrives as a hundred small interruptions rather than as a line item anyone signs. ## Why review does not fall the way drafting does Reading a case somebody else produced means reconstructing an intent nobody wrote down. A drafted case is unusually good at looking finished: consistent naming, a plausible arrangement of preconditions, assertions that pass on the first run. Passing is the weakest possible evidence of value, because a case derived from the product's present behaviour asserts precisely that behaviour, including the parts of it that are wrong, and it keeps passing until somebody corrects the product. The reviewer's task is therefore harder than the author's was. They must decide what the case **ought** to assert, then check what it **does** assert, without ever having held the intent themselves. Teams that assumed review would shrink alongside drafting are usually the ones surprised by the total. ## Why failure work rises faster than anyone budgets for it Triage is charged per failure, not per case, so it scales as the count multiplied by the chance that any one case fails for a reason other than a genuine defect. Take a worked example with numbers chosen here purely for the illustration: 200 cases, each with a one-in-two-hundred chance of an unexplained failure in a given run, produce roughly one such failure per run. Quadruple the suite without changing the behaviour of a single case and the same run produces about four. Each one is a person stopping what they were doing, and none of that time is booked against the drafting that created the cases. Repair behaves the same way. A product change that touches a shared flow invalidates every case that walks through that flow, so four times the cases means four times the repairs for one product decision. Neither term appears in the saving a team reports after its first month of cheap drafting, because neither term has had time to arrive yet. ## What to do with the shift 1. **Price the lifetime, not the keyboard time.** The number worth reporting is hours per case across drafting, review, triage and repair, multiplied by the cases you now own, rather than the hours saved typing them. 2. **Budget acceptance as work.** Review that is unbudgeted becomes sampling by accident, and a suite fills up with cases nobody has actually read. 3. **Record one sentence per case saying what behaviour it protects,** written at the moment it is accepted. That is the cheapest moment to capture intent, and it is what lets a different person diagnose the case's failure a year later. 4. **Bound intake to what the team can absorb,** not to what the drafter can produce. The constraint used to be authoring speed; once that constraint is removed, something deliberate has to take its place. 5. **Expect the payoff in coverage rather than in hours.** The honest argument for machine drafting is usually that behaviours which previously had no case now have one, not that the suite became cheaper to own. ## The shape of the curve, not its total The trade can be a good one. Cheap drafting reaches behaviours a team would never have found time to cover, and it lowers the barrier to covering a neglected area at all. What it does not do is remove maintenance. It relocates it, from work that scales with typing to work that scales with attention, and attention is the scarcer of the two. A team that reports the saving without reporting the relocation has described half of its own cost curve, and it will pay the other half regardless.
- Why can reviewing a drafted case take longer than writing the same case by hand?Writing a case and holding its intent are the same act; reviewing splits them. The reviewer has to decide what the case should assert, then read what it does assert, with no record of why it exists. A drafted case also reads as finished, which suppresses the scepticism an obviously rough draft would attract.
- If authoring hours halve and total upkeep hours do not fall, has the change failed?Not necessarily. The gain may be coverage rather than cost: behaviours that previously had no case now have one, at flat spend. It has failed only if neither the cost per protected behaviour improved nor the set of behaviours covered grew, in which case the team bought volume and nothing else.
- Does the shift differ for a case a person drafted versus one a model drafted?The recurring terms are identical; the review term is not. A hand-written case has a person who once held its intent and can be asked. A machine-drafted case has none until someone writes the intent down at acceptance, so the review has to manufacture what would otherwise have existed for free.
Cheap seedlings do not make a cheap garden. The recurring work is weeding and watering, and it scales with how much you planted, not with what the seeds cost.
saying these in an interview costs you the question
- Claims cheap drafting removes upkeep rather than relocating it
- Reports only the hours saved authoring as the gain
- Treats a drafted case as finished once it passes
- Assumes more cases automatically means more protection
- Says review is quick because the case already runs green