100 commits a week: When AI Speed Gets in the Way of Understanding the Code

The creator of Claude Code described his workflow: parallel AI sessions, a master plan instead of manual prompting, and human intervention only for review. The result: 50–100 code changes per week. Those numbers sound like any team lead’s dream. But behind them lies a problem that’s hard to spot on a dashboard: your brain hasn’t kept pace with Nvidia.

This isn’t a criticism of AI tools. Automating routine tasks—writing hundreds of unit tests, boilerplate code, and refactoring—is an excellent use of the technology. The problem begins when you automate not the routine, but the thinking itself. When an agent produces a solution faster than you can process it, you end up with working code and a gap in your understanding. This is cognitive debt: it accumulates silently, and the interest it accrues is architectural decisions that you will be unable to either explain or defend.

The author of the original article describes this using the metaphor of “cognitive friction.” The idea isn’t new, but in the context of AI coding, it takes on concrete meaning. Information only turns into knowledge when there’s a pause between receiving it and taking the next action. If you immediately switched to the next task, no reflection took place. If an agent submitted a patch and you merged it right away—you didn’t understand the code; you just approved it.

The practical takeaway isn’t to do away with agents. It’s to consciously build in friction where it matters. Rewrite a note in your own words instead of copying it from a chat. Figure out why the agent chose this particular approach before accepting a PR. Pause and ask yourself, “Would I have done it this way?”—not out of paranoia, but because without this step, knowledge isn’t retained.

The Zettelkasten method, which the author mentions, works exactly like this: you read, rewrite in your own words, and connect it to previous notes. Each step slows you down, but it’s precisely that slowing down that transforms information into understanding. Mechanically highlighting text on a Kindle or copying an answer from ChatGPT is an imitation of learning, not actual learning.

The author goes further and suggests studying Sanskrit and classical poetry as a way to train concentration. It’s an interesting idea, but for an engineer, the practical approach is simpler: if you can’t explain an agent’s solution to a colleague without looking at the code, you don’t understand it. And at some point, this debt will come back to haunt you—during a code review, in a product meeting, or in an architectural debate.

The speed at which you generate answers isn’t a measure of intelligence. The true measure is your willingness to stop and think when everything around you is screaming, “Commit faster!”

Source: Hacker News - Newest: “AI” “LLM”