AI made the first draft free. I treated that as the win. The bill arrived later, not in dollars, in the parts of the system nobody on the team ful...
For further actions, you may consider blocking this person and/or reporting abuse
Dean's framing and Sal's example point at the same root: the specification that existed implicitly in the act of writing never got written down. The code encoded an answer to a question nobody stated. When that assumption drifts from reality, whoever fixes it has to reconstruct the original reasoning from behavior rather than from intent.
The part that compounds it for AI-generated code specifically: the model is very good at producing plausible-looking answers to unasked questions. A human writing code from scratch tends to encounter the edge case in the act of typing. The model doesn't encounter it at all unless the prompt forced it to. So the implicit knowledge gap is structural, not accidental.
Genuinely appreciate the kind words. The structural fix you're describing is the right one — asking the agent to state invariants and failure contracts before editing shifts the implicit reasoning back into the visible layer where it can actually be reviewed. The question becomes "does this stated contract match what we actually need" rather than "does this code look right," which is a much more productive thing to review. Looking forward to reading more from you.
The reason the bill lands in month three rather than week one is the lag between borrowing cognitive margin and having to repay it.
When you write an implementation by hand, the physical act of structuring the logic forces you to build an internal mental model of the edge cases. You spend thirty minutes typing, but you walk away with a resident mental cache of how the components fail. When an assistant generates the draft in twenty seconds, that synthesis phase disappears. The code compiles and the tests pass, but the author never built the cache.
In financial terms, generating code without deep synthesis is borrowing against future triage capacity. The upfront velocity is real, but you are shorting maintenance variance. Month one looks artificially cheap because the code has not faced runtime state drift yet. When a subtle regression finally hits in month three, the on-call engineer has to construct that mental model from scratch under production pressure. The twenty minutes saved on boilerplate turns into three hours of forensic reconstruction.
Dean, "borrowing against future triage capacity" is the cleanest framing of this I've seen — better than my accounting metaphor. Borrowing is the right verb because the velocity is real; you're just short a liability that doesn't show up until runtime state drifts. One wrinkle I'd add: the debt isn't uniform. Cosmetic generation debt gets repaid in review. Structural debt — invariants, failure modes, the assumptions nobody wrote down — gets repaid under production pressure, and only if it breaks. That's what stays invisible until month three. Appreciate you shar
That “cheap half of the lifecycle” framing captures the failure mode well: generation is measured inside the PR, while ownership cost appears later in retries, edge-case debugging, and the next engineer’s time.
A metric I’d add is recovery cost: time from the first failing observation to a verified fix, plus the reruns or rollback steps required. It exposes why passing tests can still be expensive when the spec or failure contract is missing. I also like the change from “does this look clean?” to “what does this assume, and how does it fail?” Asking the agent to state invariants and failure cases before implementation gives review something stronger than code cosmetics to inspect.
One practical way to make “ownership cost” measurable is to treat each agent task as a lifecycle record, not a model call: task ID, repo and commit, spec version, attempts and retries, tool calls, review findings, rollback or recovery work, and time-to-merge plus time-to-first-fix. Then split failures into missed requirements, integration errors, regressions, and environment or tooling failures. That makes a cheap first draft comparable to the downstream work it created.
I also like the plain-English contract idea in the thread. Before editing, have the agent state the invariants, forbidden side effects, acceptance checks, and recovery path. If it cannot explain how the change fails and is unwound, it is not ready to own a long-lived codebase.
Yes, and for me it showed up in the second-order thing you named: the reasoning that used to happen while writing has to happen somewhere else. Where I moved it is a plain-English model of the system, written before the code. Who may write which value, what counts as true, what the agents are not allowed to do. When the code failed, I went back to the English and found the sentence I never wrote. Cheap to write. Not free to skip. Your cost-per-task number is the other half of it. I run my agents on the same rule: the smallest spend that gets a claim a person will actually sign off on.
Sal, "the sentence I never wrote" is the whole bug in one line. The code didn't misbehave so much as it quietly answered a question the spec never asked. I like that you put the reasoning into plain English before the code instead of reconstructing it after — that's the difference between a spec and a postmortem. And your rule — the smallest spend that earns a claim a human will actually sign off on — is a sharper cost-per-task metric than mine. Cheaper isn't the goal; defensible is. Thanks for reading.
Recovery cost needs a baseline. Compare AI heavy and human heavy changes by defect density review time and restore time.