// blog/why-veteran-developers-split-on-ai-coding-agents
Why Veteran Developers Split on AI Coding Agents


In early March a developer posted a short note: he is 60 years old, ready to retire, and Claude Code has him "chasing the midnight hour and not getting any sleep." The comparison he reached for was his own youth, when Active Server Pages, COM components, and VB6 felt like the greatest thing in the world. "It kept me up nights trying to absorb it all," he wrote of that first era, and the agent gives him "that same energy and drive."
The replies filled up with people of the same vintage, and they did not agree with each other. Developers with three and four decades of experience, looking at the same tool, reported opposite experiences: one camp says agents gave them their career back, the other says agents took the point of the career away. AI coding agents deliver value for some kinds of work and not others.
Why late-career developers are picking agents up
The most direct reply came from a 50-year-old who had stopped coding entirely, worn down by "the never ending rat race of keeping up with the latest bizarre web stacks, frameworks for everything, node for this, npm for that, Angular, React, Vue, whatever." His verdict on agents: "the ultimate cheat code" and "almost an unfair unlock." He also predicted, with some relish, that "it'll be good to see leetcode die."
He wrote: "I know more than enough about architecture and coding to understand the plumbing and effectively debug, yet I don't have to know or care about implementation details."
Software knowledge decays at wildly different rates. Framework and API knowledge is the most perishable layer; whatever you knew about a frontend stack ten years ago is nearly worthless today. Architecture, debugging instinct, and the sense of what "done" looks like barely decay at all. An agent can read a stack trace, consult documentation, run the code, and iterate through the perishable layer. For someone whose durable skills are intact and whose perishable skills lapsed a decade ago, the trade is asymmetric in his favor. He supplies the judgment; the model handles the churn he refused to keep up with.
Another commenter, a GPU engineer near retirement, described the same division of labor from the still-employed side. He has more prototype ideas than time to build them, and Claude Code functions as "a never tiring eager junior engineer to work out how to make use of frameworks and APIs to deploy my code." The boundary he draws is explicit: the agent "cannot improve the performance of optimized code I've written so far," so he keeps the kernels and delegates the glue. He also noted the pace of change, observing that a year earlier Cursor was flummoxed by simple things Claude Code now navigates with ease.
Why others say it killed the joy
Directly under those comments, a developer in his 60s who is retiring this summer reported the opposite: "Agents have removed most of the satisfaction and fulfilment from designing, building, testing and completing a feature or component." He compared himself to the weavers who watched mechanized looms arrive in the industrial revolution, and called himself a Luddite without apparent irony. He conceded the business case in full: agents "may well make projects viable that weren't previously." His objection is about where the joy comes from, and no capability improvement changes that. Future coders may find fulfilment using agents; his generation will not be among them.
Some excellent engineers will stay out of the agent workflow because they enjoy the work agents take over. A hand-weaver could concede the loom's throughput and still prefer weaving.
The micro versus macro divide
One reply described the disagreement this way: people who enjoy getting bits of code to work and fit together neatly tend to hate AI agents, while people who enjoy building systems that work tend to love them.
The thread sorts almost everyone along that line. The retiree who lost the joy loved the micro; the act of building the feature was the reward, and delegating it removes the reward. The lapsed 50-year-old and the GPU engineer love the macro; the feature was always a means to the system, and delegating it removes an obstacle. The divide predicts agent adoption better than age, stack, or seniority does, which is why the same tool produced a re-ignited passion and a resigned retirement in people with nearly identical resumes.
The manager-versus-hacker objection
A sharper commenter argued that people who want to manage work respond differently to agents than people who want to write code directly. He said the people most enamored with LLMs skew toward "project managers, people managers, principal+ engineers who don't code much anymore." The comment also made a technical point: "the inputs to train LLMs on future languages and frameworks necessarily have to come from the hacker types. Somebody has to get their hands dirty" to "write a high quality corpus of code in the new tech so that LLMs have a basis to work from."
Models are trained on code humans wrote. A new language or framework ships with an empty corpus, so agents are structurally weakest on the newest technology, where micro-loving hackers spend their time. Agent loops can read documentation in context and iterate against a compiler or test suite, which works better than raw next-token recall would suggest. Anyone who has pointed an agent at a framework released last quarter has felt the difference.
What the CUDA fight predicts
The GPU engineer compared coding agents to "the coolest thing I've seen since I saw the first cut of cuda 20 years ago," and expects "the same level of belligerence and resistance to it that I saw deployed against cuda."
Early CUDA advocates presented what he describes as valid claims of 100x to 1,000x speedups on real workloads, and watched them get dismissed as ignoring memory-copy overhead or as comparisons against single-core baselines. The HPC establishment preferred Intel's pitch that existing x86 code would "recompile and run" on Xeon Phi, a promise that fell apart when anyone tried it seriously, though he grants that hand-written assembler could squeeze Fermi-class performance out of Phi. He says he was all but blacklisted for insisting on CUDA, and quotes the line thrown at him: "You lack vision and you probably wouldn't have backed the Apollo program or Lewis and Clark." He says the recompile-and-run crowd gave Nvidia "a decade+ headstart that should never have happened."
People protected sunk costs: decades-old FORTRAN codebases, familiar programming models, and the hope that someone would make the new capability accessible without a rewrite. The deadlock broke when deep learning arrived, because researchers were already working through frameworks such as Lua Torch, Caffe, and Theano, and framework authors had to make a handful of operations fast on GPUs for everyone downstream to benefit without rewriting anything.
Agents will win first where integration cost is lowest: greenfield prototypes, glue code, and lapsed developers with no sunk workflow to defend. They will win last where hand-built expertise runs deepest, where the loudest resistance will come from. The GPU engineer flagged the recurring vocabulary, comparing people who still call LLMs "stochastic parrots and glorified autocomplete" to the CPU luminaries who kept insisting GPUs were bad because they were designed for gaming.
Caveats from the enthusiasts
The endorsements in this thread come with sharp edges attached. The CUDA veteran, the thread's biggest booster, says the agent still hallucinates "on the strangest seemingly obvious things," concedes it cannot touch his optimized code, and is currently writing tooling to make the program's runtime behavior more visible to the model, since the agent fails most often on state it cannot observe.
The developers getting the most out of agents supply durable architectural judgment about what to build and observability so the agent can see what its code is doing. Others are being asked to hand over the part of the job they loved.