The assistant does not delete code it does not understand — and the human does not accept generated code they do not understand. “It works, but I don’t know why” is the accumulation of code that never had an author who understood it; a new kind of debt.
The first direction is Chesterton’s original (44): an agent asked to “clean up” a module removes a guard it cannot explain, because nothing in its context says why the guard is there. The second direction is new. Peter Naur argued in “Programming as Theory Building” (1985) that a program is not its text but the theory its programmers hold — why each part is the way it is and how it would change — and that a program whose team has dispersed is effectively dead even if it still runs. Generated code accepted without being understood starts in that state: the text exists, the theory never did. Nobody can say which lines are load-bearing, so nobody can change them safely, and the fence problem reappears one level up: the next person cannot ask the author why.
A concrete case. A generated migration for a Postgres table adds CREATE INDEX CONCURRENTLY, a lock_timeout and a backfill in batches of 10,000. It passes CI. The reviewer who approves it should be able to answer: why concurrently, what happens if the index build fails halfway (it leaves an invalid index that must be dropped), and where the batch size came from. If those answers are unavailable, the change is not ready, however green it is — the next migration on that table will be written by someone who copies the pattern without the reasons.
Limits. “Understand” means being able to predict the code’s behavior and explain its non-obvious choices, not having typed it — the same bar applies to a library you depend on, and nobody reads all of those. The defense scales with stakes: a throwaway script needs less theory than a payment path. The cost lands on review (59) and on the reviewer’s own skill (112).