A personal essay about refusing AI code assistance reached 555 Hacker News points and 565 comments within roughly 21 hours of publication, according to MrKeyoor's September 12 brief. It was the only Hacker News candidate in the brief to clear 500 points. Joel Auterson announced no model or product in the essay. He described a smaller, harder-to-measure loss: when a prompt can produce the little utilities developers once made for pleasure and peer recognition, speed can eat into the reasons they wrote them. The scale and intensity of the Hacker News discussion turned that personal account into a live argument about what programming is for.
Auterson, a software developer who works in games and runs a small indie studio, does not dispute that large language models can generate capable code. He writes that he feels pressure to keep up as colleagues adopt them. His objection is direct and subjective: he does not enjoy programming with a code assistant, does not feel ownership of its output, and takes no pride in that output. His post makes no claim that every developer should follow him. It records one developer deciding that productivity is the wrong objective for his personal work.
The opt-out behind the numbers
The essay is unusually concrete about what feels threatened. Auterson likes making small shell scripts and helpers. He points to an interactive Git branch switcher that he still uses every day, recalling the satisfaction of building it and hearing that colleagues liked it. A model can now reproduce that class of tool from a short request. The utility remains, while the learning process and the recognition attached to making it can shrink. Auterson's account treats those social rewards as part of the work rather than an embarrassing extra.
That distinction is easy to miss in workplace debates, where code is usually judged by delivery time, correctness, maintenance cost, and business value. A hobby project can optimize for a different result. Writing a parser or command-line helper by hand may be inefficient as product development and effective as study. Auterson has spent years building his own C++ game engine, Growl, while freely acknowledging that Unity, Godot, or Unreal would be faster routes to shipping a game. He says the slower path is deliberate because he enjoys it and learns through it.
A friend's camera app gives the essay its practical counterexample. Auterson says Shad's iOS app Uncamera uses raw sensor output and lookup tables to create a film-like result, and that Shad develops it without generative AI for similar reasons of enjoyment and fulfilment. That example helped Auterson choose to keep making software in the way he likes. The app's quality and process are presented through Auterson's own experience, so they should be read as testimony from the essay, rather than an independent product assessment.
Adoption rose while confidence fell
The discomfort arrives after AI coding tools have already entered ordinary development work. In Stack Overflow's 2025 Developer Survey, 84% of respondents said they used or planned to use AI tools in development, up from 76% the prior year. Among professional developers, 51% reported daily use. Positive sentiment moved the other way, falling from more than 70% in 2023 and 2024 to 60% in 2025. These survey results do not measure code shipped. They describe the same tense combination found in Auterson's essay: wide use alongside cooling enthusiasm.
Confidence was weaker than adoption. The same survey found that 46% of respondents distrusted the accuracy of AI output, compared with 33% who trusted it; 3% said they highly trusted it. The most common frustration, selected by 66%, was receiving a solution that was almost right. Another 45% said debugging generated code took more time. At the same time, 52% agreed that AI tools or agents had improved their productivity. A developer can save time on some tasks, spend more time checking others, and still dislike the altered work.
The Hacker News thread contains that whole spread of reactions. One commenter described using AI to build a private app for managing Toastmasters clubs because the finished tool mattered more to them than the method. Another said that writing hobby code by hand had begun to feel inefficient once an agent could inspect the working tree and continue the task. Other commenters defended manual programming as a craft, challenged the essay's three choices, or argued that experienced people get better results because they can define and review problems. These are community accounts, not verified productivity findings. Their disagreement explains the 565-comment response better than a simple pro-AI or anti-AI label would.
Productivity data do not settle the craft question
Controlled evidence has also resisted a clean answer. METR's first experiment assigned 246 real tasks from mature open-source projects to 16 experienced contributors, either allowing or disallowing early-2025 AI tools. The developers expected AI to reduce completion time by 24%. METR measured a 19% increase instead. The researchers limited that finding to experienced contributors working in repositories they knew well; it did not establish that AI slows most programming. METR's February 2026 update restates the result and explains why repeating the experiment became harder.
The follow-up involved 57 developers, 143 repositories, and more than 800 tasks. Its raw estimates pointed toward an 18% speedup for returning participants and 4% for newly recruited developers, with confidence intervals that included zero. METR called the new signal unreliable. Developers who valued AI most were less willing to accept tasks that prohibited it, and 30% to 50% said they withheld some tasks because they did not want to risk doing them without AI. Parallel agents also made time accounting difficult because a developer could work elsewhere while an agent ran. METR is changing the study design rather than publishing the raw estimate as a firm productivity result.
That measurement problem has a human consequence. Once developers choose different tasks because an agent is available, elapsed time on a fixed issue captures only part of the effect. METR also heard that people changed the amount of testing, documentation, or subjective code quality they produced under the two conditions. The researchers therefore warn that time differences may fail to represent value differences. Their update concerns paid and open-source work, while Auterson is describing motivation. Both sources point to an objective that has become harder to define before anyone tries to maximize it.
Teams need room for more than one objective
A blanket AI mandate would flatten distinctions that developers already make. Stack Overflow found that 76% of respondents did not plan to use AI for deployment and monitoring, while 69% said the same about project planning. Current users were more comfortable applying it to search and learning; many planned to use it for documentation and testing. The survey's task-by-task results support policies built around use cases and review burden. They give no reason to treat maximum AI use as a useful performance target by itself.
Personal and open-source projects have even more room to choose their objective. A prompt-generated branch switcher may solve someone's immediate problem. Building one by hand can teach a developer about process control and Git's interface. Auterson's daily use of his own tool shows that personal software can be useful long after its educational purpose is met. AI expands who can obtain a custom utility. It does not erase the separate value a maker may place on understanding every line.
The practical choice can also change from task to task. A developer may ask an assistant to draft repetitive tests and still write a renderer alone. Another may care only about the running product. The Stack Overflow data already show mixed adoption by activity, and the Hacker News replies show mixed motives within the same profession. Auterson's contribution is permission to name enjoyment and authorship when choosing a workflow, even when those factors never appear in a velocity chart.
The next useful evidence will come from METR's redesigned experiments and the next broad developer survey. Watch whether measured speedups survive task selection and parallel-agent work, and whether distrust and debugging costs decline. Employers' policies will show whether AI availability becomes compulsory use. METR has said it will test new experimental formats because the old randomization now changes who participates and which tasks they submit. Until those results arrive, 555 points and 565 comments establish strong developer interest in the question. They do not decide how anyone should write code.