We have entered the era of the “vibe coder”—a developer who treats the LLM not as a tool, but as an oracle. The workflow is seductive in its simplicity: paste a spec, receive a block of code, verify it passes the tests, and merge. It is a frictionless loop that satisfies the immediate metric of “task completion.” But beneath the surface, we are rapidly accumulating a massive, invisible cognitive debt.
The Erosion of the Mental Model
The core problem isn’t the AI; it’s the posture. Research, including studies from Anthropic and MIT, confirms that the way we engage with these models dictates our long-term utility as engineers. When you rely on an LLM to bridge the gap between problem and solution, you aren’t just saving time; you are outsourcing the very struggle that builds expertise.
The MIT study on essay writing is a grim mirror for software development: brain connectivity scales down in direct proportion to external support. In coding terms, this means that every time you bypass the “messy struggle” of debugging or architectural design, you are effectively atrophy-ing your ability to handle those tasks without a crutch. If you cannot explain the code you just “shipped,” you don’t own the system—the model does. And when the model hallucinates or the framework shifts, you are left with a codebase you don’t understand and a skill set that has quietly degraded.
The Trap of “Task Completion”
Product teams and management are obsessed with cycle times and merged PRs. They don’t care if you learned how the underlying library handles memory management; they care that the feature is live. This creates a dangerous incentive structure. We are rewarded for being fast, not for being sharp.
The danger here is that we are treating AI as a replacement for conceptual problem-solving rather than a pedagogical partner. Features like Socratic questioning—where the tool forces you to write the first five lines or explain your hypothesis—exist, but they are largely ignored by the production-focused crowd. We have relegated these “learning modes” to students, forgetting that the senior engineer working on a complex migration needs them just as much as a junior developer learning the basics.
Reclaiming the Engineering Posture
We don’t have to choose between AI and competence. We have to choose a workflow that forces us to remain the primary architect. This requires a shift in how we interact with the terminal:
- Hypothesize First: Never prompt without first writing down your own theory of the problem. Use the model to validate your logic, not to generate the solution from a vacuum.
- Explain Before Execute: In unfamiliar territory, demand an explanation of tradeoffs and design choices before you ask for a single line of code.
- The “Junior Review” Protocol: Treat AI output with the same skepticism you would a PR from a junior engineer. If you wouldn’t merge it without understanding it, don’t merge it now.
- Manual Re-derivation: Periodically take a complex function generated by an agent and rewrite it from scratch. It is the only way to calibrate how much of your own intuition has been lost to the loop.
The Final Takeaway
The market is already beginning to re-price engineering expertise. There is a growing divide between those who use AI to amplify their existing knowledge and those who use it to mask their lack of it.
If you find yourself ending your day having “closed a lot of issues” but having learned nothing, you are not working—you are merely managing a machine. The tools are ready to make you a better engineer, but they are equally happy to make you a redundant one. The choice of whether you are the pilot or the passenger is yours, and the defaults are not on your side. Ship the code, but make sure you’re the one who actually built it.
Sources
- https://x.com/addyosmani/status/2056078124346228860
- https://en.wikipedia.org/wiki/Anthropic
- https://en.wikipedia.org/wiki/Claude_(language_model)
- https://en.wikipedia.org/wiki/Dario_Amodei