Why We Should Feel More Exhausted Than Our Coding Assistants

Published May 28 2026
By Vicki Boykis

What the headline claims

The article argues that developers who rely on agentic code‑generation tools (e.g., Claude‑3.5‑Sonnet, GPT‑4‑Turbo, or open‑source models like LLaMA‑3‑70B‑Chat) end up with a lighter‑looking codebase but a deeper sense of mental fatigue. The author suggests that the proper response is to re‑introduce friction—manual rewrites, peer discussion, and timed problem‑solving—so that the brain does the work that the model would otherwise do for us.

What is actually new?

1. A concrete workflow for “slow‑code” with LLMs

The piece does not merely warn about over‑reliance; it offers a step‑by‑step process that many developers can adopt today:

1. Write the first draft yourself and then ask the model to review it line by line.
2. Ask follow‑up questions about any part you do not understand; let the model surface documentation, related pull requests, or design rationales.
3. Compare two implementation strategies suggested by the model, then critique the alternative yourself.
4. Discuss the model’s suggestion with a teammate before merging.
5. Delay the model’s involvement until after a 20‑minute personal attempt.
6. Read primary sources (books, academic papers) on the underlying algorithms.
7. Re‑implement core data structures from scratch.

These actions are not brand‑new in the sense of a research breakthrough, but they form a coherent, reproducible habit loop that counters the “instant‑answer” UX of current agents.

2. Empirical hints from recent studies

A handful of papers released in the last six months provide data that backs up the anecdotal observations:

• “Cognitive Load in Human‑LLM Interaction” (ICLR 2026) measured a 12 % increase in self‑reported mental effort when developers edited model‑generated code versus writing from scratch, but participants retained 30 % more of the underlying algorithmic concepts after a week.
• OpenAI’s “Code‑Assist Usage Patterns” report (2026) shows that developers who reviewed generated code rather than accepting it outright had a 0.8 % higher bug‑fix rate in subsequent commits.
• Meta’s “Friction‑Enhanced Coding” blog post (https://ai.meta.com/blog/f friction‑coding) describes a pilot where adding a mandatory 10‑minute “thinking window” before invoking the model reduced reliance on the assistant by 22 % without hurting sprint velocity.

These studies do not claim that friction makes you faster; they claim it improves skill retention and error detection—exactly the benefits the author describes.

Limitations and trade‑offs

Short‑term productivity loss

Adding any of the steps above inevitably slows down a single ticket. In a fast‑moving startup, the cost of a 15‑minute delay can be measurable. Teams must decide whether the long‑term knowledge gain outweighs the immediate deadline pressure.

Not a one‑size‑fits‑all solution

The workflow assumes the developer already has a baseline understanding of the language and libraries involved. Junior engineers who lack that foundation may find the friction overwhelming and could benefit more from guided pair‑programming with the model rather than solo critique.

Model limitations remain

Even with careful review, current agents still hallucinate API signatures or suggest outdated library versions. The “review‑then‑accept” loop can catch many of these errors, but it does not eliminate them. Continuous integration checks and type‑checking remain essential.

Scaling the practice

If every developer on a team adopts the friction pattern, the cumulative time spent on manual rewrites could become a bottleneck. Some groups mitigate this by designating “LLM‑review days” where the whole team focuses on reviewing generated patches together, turning the extra time into a shared learning session.

Practical takeaways for developers

1. Start small – pick one of the seven tactics and apply it to a single pull request.
2. Measure your own retention – after a week, try to re‑implement the same feature without assistance and note the gaps.
3. Use tooling – extensions like the GitHub Copilot Labs “Explain” feature can surface explanations that you can then discuss with a colleague.
4. Document the friction – keep a short log of how long you spent on each step; over time you’ll see whether the extra effort translates into fewer bugs or faster onboarding of new team members.
5. Share findings – post a summary in your team’s knowledge base; collective reflection helps calibrate the right amount of friction for your context.

Conclusion

The claim that developers should feel more tired than the model is not a call for needless hardship; it is a reminder that mental work is the currency of long‑term competence. By deliberately slowing down, re‑reading fundamentals, and treating LLMs as assistants rather than authors, we preserve the cognitive pathways that make us adaptable programmers. The trade‑off is clear: short‑term speed for long‑term skill. Teams that can balance the two will likely see fewer regressions, more maintainable code, and developers who remain confident in their own reasoning—not just in the next token the model spits out.

---

Keywords: agentic coding, cognitive load, LLM‑assisted development, skill retention, friction engineering