AI sped up development but took the work itself away from the programmer

The strongest complaint about AI coding is not that models sometimes err. They really do help ship a non-trivial project faster, but the price may lie elsewhere: the developer stops being the person who builds the system and turns into an operator of a task queue.

That is exactly what the author of Brett Codes describes — an experienced engineer who used coding harnesses such as Claude Code for over a year. At some point he connected Linear to Claude Code and got a working project from start to finish having written almost no code himself. It sounds like perfect automation until you ask: what was left for the engineer to do at that moment?

The answer turned out to be less than inspiring: look at generated code, catch the odd error and check the result. The author writes that he stopped understanding the details of his own system without AI's help, cared less about quality and no longer felt any connection to the program. The work sped up, but learning, growth and the pleasure of solving hard problems went out of it.

What matters here is not the argument over whether "AI writes good code or bad". Even if the code is good enough to pass the tests, the developer can lose the main thing — context and responsibility for the product. And the quality of software, in the author's view, is determined not by the number of features added quickly but by how much people genuinely care about what they create.

The problem was compounded by the chat model gradually becoming a universal adviser for the author: he asked it about books, career, business ideas and health. After an incident involving an unnecessary trip to the emergency department he stopped using AI for such decisions. But stopping with code proved harder: if the tool is there even for trifles, it is easy to hand it almost all the work.

The limits of this conclusion should be stated too. This is one developer's personal experience, not proof that AI coding inevitably harms everyone. The author offers no measurements of productivity or software quality. His medical story shows the danger of uncritical trust in a chatbot but does not license conclusions about every model. Environmental damage, the use of training data and the effect on the labour market are flagged in the text as serious problems but not examined in detail. Besides, giving up AI may jeopardise the author's own job — he does not know himself how the decision will end.

The practical lesson for teams is unwelcome: counting lines of code and closed tickets is not enough. If AI takes away developers' understanding of the system, their review time and their sense of authorship, the gain in speed may be not an improvement but a deferral of costs into the future — onto maintenance, quality and people's motivation.

If you were forced to choose between higher speed with AI and keeping full control of the code, what would you be ready to sacrifice? Source: Hacker News - Newest: ""AI" "LLM""