Every codebase has the one function. Ours was `processCheckout`, and over two years of 'just slot it in here, we'll clean it up later' it had swollen to 180 lines: validation, tax calculation, coupon application, inventory reservation, the Stripe charge, the confirmation email, and a receipt record, all in one breathless sequential scroll with no paragraph breaks for the soul. People genuinely scheduled their risky work around not touching it. Testing it meant mocking five external services just to get past the second guard clause, so — predictably, honestly — mostly nobody did, and it sat there at the center of our revenue path with almost no coverage, radiating menace.
The reason it never got refactored is the reason these never do: the function is load-bearing, the blast radius of a mistake is 'we can't take money,' and 'no tests' plus 'critical path' is a combination that makes any sane person back away slowly. So it grew. Functions like this don't get written; they accrete.
The afternoon I finally did it
I used the Break a God Function into Small, Testable Units (No Behavior Change) prompt. I pasted the whole 180-line monster, set language to TypeScript, and in preserve_constraints wrote 'keep the exported processCheckout signature, stay async, no new classes, no new deps' — because the one thing scarier than the function is a refactor that 'improves' its behavior on the way through. I deliberately picked Grok 4.1 Fast Reasoning for this. Splitting a long-but-mechanical function into named helpers is a high-throughput, low-latency job, not a deep-reasoning one — there's no clever insight required, just disciplined extraction — and I wanted it back fast so I could stay in flow. It returned seven helpers — validateCartItems, applyDiscounts, calculateTaxes, reserveInventory, createStripeCharge, sendConfirmationEmail, buildReceiptRecord — and a new `processCheckout` that was 22 lines reading like a numbered checklist of what checkout actually does.
What I did with the output
The genius of the 'zero behavior change' constraint is that it makes the refactor verifiable instead of a leap of faith. I didn't have to trust the model's taste or read all seven helpers like a hawk — I had to trust my existing tests, and crucially, I had a handful of integration tests even though the unit coverage was nothing.
- Ran the existing 23 integration tests against the refactored version — all green, zero changes needed, which is the only real proof that 'no behavior change' actually held rather than was merely promised
- Then wrote focused unit tests per helper; the tax function alone got 11 tests for rounding and locale edge cases I could never isolate before because they were welded into the middle of the monolith
- The 'what changed and why' bullets flagged that two helpers shared a mutable variable — implicit coupling the original wall of code had hidden — which I then cleaned up deliberately, in its own separate commit, so the refactor and the fix stayed reviewable
The honest caveat about 'no behavior change'
I want to be blunt here, because it matters: 'zero behavior change' is the model's stated intent, not a mathematical proof. Grok did an excellent job, but the integration tests are what made it safe — they're the proof, the model is the proposal. On a function with literally no test coverage I would not blindly trust the extraction and merge it; I'd write a few characterization tests first to pin the current behavior, golden-master style, and only then refactor against them. On this one I had just enough of a safety net, so the whole thing — extraction, running tests, writing the new unit tests, the cleanup commit, review — took about two hours instead of the two days I'd have budgeted and then never spent.
There's a quieter benefit I didn't anticipate. Once the helpers existed as named, single-purpose functions, our future feature work stopped piling back onto the monolith. The next coupon-logic change went into applyDiscounts, in isolation, with its own test, instead of getting wedged into line 90-something of a function nobody dared read. The refactor didn't just clean up the past; it changed where new mess was allowed to land, which is how a god function quietly stops growing back.
The real payoff landed the next sprint. A teammate picked up a checkout ticket, opened the file, and told me it was the first time they'd understood how checkout actually worked just by reading the top-level function — no archaeology required. That's the entire point of the exercise. Grab the Break a God Function into Small, Testable Units (No Behavior Change) prompt on Prompt Dock, point it at your own scariest function, and run your existing tests against the result — and if that function is currently bare, lock its behavior down first with a reproduction from my Write a Failing Test That Reproduces This Bug Before I Fix It prompt so your refactor has something to prove itself against.