What's this about?
The argument: humans refactor because they hit a wall. A function gets tangled enough that no one can hold it in their head, and that pain forces a cleanup. Agents are not bound by human context limits in the same way — an agent can read the tangled function, trace every caller, and make sense of a mess that would have stopped a human cold. So it adds the next branch correctly, and the one after that, working confidently inside code no human on the team fully understands. The wall never arrives, so the cleanup never happens.
Why is "the pain was doing something useful" the interesting claim?
Because comprehension limits functioned as an unplanned quality mechanism. Nobody decided that code should be refactored when it exceeds what a person can hold in working memory; it happened because progress stopped otherwise. Remove the constraint and you remove the forcing function, without removing any of the reasons the code should have been cleaned up — it will still be hard to change safely, still hide bugs, and still be unreviewable. The debt just stops generating a visible signal.
What's the community saying?
- The most-upvoted objection is flat disagreement with the premise: "AI agents don't get lost" — that is not my experience, not at all. They go down rabbit holes and have to be yanked back.
- Sharper still: they very often do not actually read the files, even when told to, because they take any shortcut available.
- The author is in the thread and concedes the point — agents do get lost sometimes; his argument is that they can often make sense of tangled code better than humans when the bounds are not well defined.
- He also volunteers that he wrote the article by giving Opus a long prompt containing the content and then reviewing the output, which one commenter had already guessed.
- The practical countermeasure offered: make them prove their work — "build a script to trace callers", "cite each file and line that calls this function."