What AI coding costs you

Hacker News · Feb 28, 2026 · Collected from RSS

Full Article

Every developer I know uses AI for coding now. The productivity gains are real, but there are costs that don’t show up on any dashboard. Imagine a spectrum. On the far left are humans typing on the keyboard, seeing the code in the IDE. On the far right: AGI. It implements everything on its own. Cheaply, flawlessly, better than any human, and no human overseer is required. Somewhere between those two extremes there’s you, using AI, today. That threshold moves to the right every week as models improve, tools mature, and workflows get refined. Recently I stumbled upon this awesome daxfohl comment on HN: Which is higher risk, using AI too much, or using AI too little? and it made me think about LLMs for coding differently, especially after reading what other devs share on AI adoption in different workplaces. You can be wrong in both directions, but is the desired amount of AI usage at work changing as the models improve? How We Got Here Not long ago the first AI coding tools like Cursor (2023) or Copilot (2022) emerged. They were able to quickly index the codebase using RAG, so they had the local context. They had all the knowledge of the models powering them, so they had an external knowledge of the Internet as well. Googling and browsing StackOverflow wasn’t needed anymore. Cursor gave the users a custom IDE with built in AI powered autocomplete and other baked-in AI tools, like chat, to make the experience coherent. Then came the agent promise. MCPs, autonomous workflows, articles about agents running overnight started to pop up left and right. It was a different use of AI than Cursor. It was no longer an AI-assisted human coding, but a human-assisted AI coding. Many devs tried it and got burned. Agents made tons of small mistakes. The AI-first process required a complete paradigm shift in how devs think about coding, in order to achieve great results. Also, agents often got stuck in loops, hallucinate dependencies, and produced code that looks almost right but isn’t. You needed to learn about a completely new tech, fueled by FOMO. And this new shiny tool never got it 100% right on the first try. Software used to be deterministic. You controlled it with if/else branches, explicit state machines, clear logic. The new reality is controlling the development process with prompts, system instructions, and CLAUDE.md files, and hope the model produces the output you expect. Then Opus 4.5 came out. The workflows everyone were talking about just worked, out of the box (not always, obviously, but more often). Engineers transitioned to Forward Deployed Engineers, becoming responsible for many other things than coding. Sometimes not even coding by hand at all. Recently Spotify’s co-CEO Gustav Söderström said An engineer at Spotify on their morning commute from Slack on their cell phone can tell Claude to fix a bug or add a new feature to the iOS app. And once Claude finishes that work, the engineer then gets a new version of the app, pushed to them on Slack on their phone, so that he can then merge it to production, all before they even arrive at the office.” I hope they at least review the code before merging. The next stage is an (almost) full automation. That’s what many execs want and try to achieve. It’s a capitalistic wet dream, a worker that never sleeps, never gets tired, always wants to work, is infinitely productive. But Geoffrey Hinton predicted in 2016 that deep learning would outperform radiologists at image analysis within five years. Anthropic’s CEO predicted AI would write 90% of code within three to six months of March 2025. None of this happened as predicted. The trajectory is real, but the timeline keeps slipping. Your Brain on AI In 2012, neuroscientist Manfred Spitzer published Digital Dementia, arguing that when we outsource mental tasks to digital devices, the brain pathways responsible for those tasks atrophy. Use it or lose it. Not all of this is proven scientifically, but neuroplasticity research shows the brain strengthens pathways that get used and weakens ones that don’t. The core principle of the book is that the cognitive skills that you stop practicing will decline. Margaret-Anne Storey, a software engineering researcher, recently gave this a more precise name: cognitive debt. Technical debt lives in the code. Cognitive debt lives in developers’ heads. It’s the accumulated loss of understanding that happens when you build fast without comprehending what you built. She grounds it in Peter Naur’s 1985 theory that a program is a theory existing in developers’ minds, capturing what it does, how intentions map to implementation, and how it can evolve. When that theory fragments, the system becomes a black box. Apply this directly to fully agentic coding. If you stop writing code and only review AI output, your ability to reason about code atrophies. Slowly, invisibly, but inevitably. You can’t deeply review what you can no longer deeply understand. This isn’t just theory. A 2026 randomized study by Shen and Tamkin tested this directly: 52 professional developers learning a new async library were split into AI-assisted and unassisted groups. The AI group scored 17% lower on conceptual understanding, debugging, and code reading. The largest gap was in debugging, the exact skill you need to catch what AI gets wrong. One hour of passive AI-assisted work produced measurable skill erosion. The insidious part is that you don’t notice the decline because the tool compensates for it. You feel productive. The PRs are shipping. Mihaly Csikszentmihalyi’s research on flow showed that the state of flow depends on a balance between challenge and skill. Your mind needs to be stretched just enough. Real flow produces growth. Rachel Thomas called what AI-assisted work produces “dark flow”, a term borrowed from gambling research, describing the trance-like state slot machines are designed to induce. You feel absorbed, but the challenge-skill balance is gone because the AI handles the challenge. It feels like the flow state of deep work, but the feedback loop is broken. You’re not getting better, you’re getting dependent. No Code, Only Review There’s this observation that keeps coming up in HN comments: if the AI writes all the code and you only review it, where does the skill to review come from? You can’t have one without the other. You don’t learn to recognize good code by reading about it in a textbook, or a PR. You learn by writing bad code, getting it torn apart, and building intuition through years of practice. This creates what I’d call the review paradox: the more AI writes, the less qualified humans become to review what it wrote. The Shen-Tamkin study puts numbers on this. Developers who fully delegated to AI finished tasks fastest but scored worst on evaluations. The novices who benefit most from AI productivity are exactly the ones who need debugging skills to supervise it, and AI erodes those skills first. Storey’s proposed fix is simple: “require humans to understand each AI-generated change before deployment.” That’s the right answer. It’s also the one that gets skipped first when velocity is the metric. The Seniority Collapse This goes deeper than individual skill decay. We used to have juniors, mids, seniors, staff engineers, architects. It was a pipeline where each level built on years of hands-on struggle. A junior spends years writing code that is rejected during the code review not because they were not careful, but didn’t know better. It’s how you build the judgment that separates someone who can write a function from someone who can architect a system. You can’t become a senior overnight. Unless you use AI, of course. Now, a junior with Claude Code (Opus 4.5+) delivers PRs that look like senior engineer work. And overall that’s a good thing, I think. But does it mean that the senior hat fits everyone now? From day one? But the head underneath hasn’t changed. That junior doesn’t know why that architecture was chosen. From my experience, sometimes CC misses a new DB transaction where it’s needed. Sometimes it creates a lock on a resource, that shouldn’t be locked, due to number of reasons. I can defend my decisions and I enjoy when my code is challenged, when reviewers disagree, and we have a discussion. What will a junior do? Ask Claude. It’s a two-sided collapse. Seniors who stop writing code and only review AI output lose their own depth. Juniors who skip the struggle never build it. Organizations are spending senior time every day on reviews while simultaneously breaking the mechanisms that create it. The pipeline that produced senior engineers, writing bad code, getting bad code reviewed, building intuition through failure, is being bypassed entirely. Nobody’s talking about what happens when that pipeline runs dry. What C-Levels Got Right and Wrong Look at what lands on C-level desks every week. Microsoft’s AI chief Mustafa Suleyman says all white-collar work will be automated within 18 months. Anthropic’s CEO Dario Amodei predicts AI will replace software engineers in 6-12 months and quoted his engineers saying they don’t write any code anymore, just let the model write it and edit the output. Sundar Pichai (CEO, Google) reported 25% of Google’s new code was AI-generated in late 2024. Months later, Google Research reported that number had reached 50% of code characters. If you’re a CTO watching that curve, of course you’re going to push your teams. The problem is that predictions come from people selling AI or trying to prop the stock with AI hype. They have every incentive to accelerate adoption and zero accountability when the timelines slip, which, historically, they always do. And “50% of code characters” at Google, a company that has built its own models, tooling, and infrastructure from scratch, says very little about what your team can achieve with off-the-shelf agents next Monday. AI adoption is not a switch to flip, rather a skill to calibrate. It’s not as simple as mandating sp