According to Ars Technica, developers using AI coding tools like Anthropic’s Claude and OpenAI’s Codex are reporting a “staggeringly good” leap in capability, especially in the last six months since Claude Opus 4.5. Software engineer Roland Dreier estimates a 10x speed improvement for complex tasks, like building a full-stack application, and says he now rarely types actual code syntax. One anonymous software architect delivered a feature in two weeks that he thought would take a year, while another developer finally automated a years-old chore in a few hours. However, these gains come with serious worries about accumulating “technical debt” through poor AI design choices, a practice former OpenAI researcher Andrej Karpathy calls “vibe coding,” and deep uncertainty about the future of junior developer roles and education.
The productivity explosion is real
Here’s the thing: the hype is finally matching reality, at least for a certain kind of work. The developers Ars talked to aren’t just using AI for fancy autocomplete anymore. They’re handing off entire chunks of work. Telling an agent to debug a failing test and fix it? That’s now a reasonable request. Spinning up a prototype in an hour for a side project? Done. These tools are lowering the activation energy for tasks developers have put off for years, which is a genuine game-changer.
But it’s creating a weird split in how people work. You’ve got folks like Tim Kellogg, who bluntly says manual syntax coding is “over,” and he’s now in the business of directing AI models. He’s rebuilding projects multiple times to refine architecture—something that was previously a massive time sink. On the other hand, you have engineers like Microsoft’s Darren Mart, who only uses AI for tasks he already fully understands, terrified of being led down a “perilous path.” It seems like your comfort level dictates whether you see this as a super-powered assistant or a potential minefield.
The technical debt time bomb
And that fear of minefields is the big, looming worry. “Vibe coding” is a perfect, scary term for it. You’re conversing in English, you get code that works, but you don’t fully grasp the underlying design. That’s how you end up with a mountain of future debt. The data scientist in the article has the right idea, I think: keeping AI on a very short leash, using it only for conversions, debugging with read-only instructions, and standardization.
It’s a classic automation dilemma. The tools are most powerful when you give them free rein, but that’s also when they’re most dangerous. Brian Westby’s “50/50 good/bad” assessment feels painfully accurate. They cut time on well-defined problems, but hallucinations are still a huge issue if you give them too much rope. So the real skill is shifting from writing code to being a supremely vigilant editor and architect. The question is, are we training developers for that?
Legacy code and the corporate reality gap
One area where these tools seem like an unambiguous win is in dealing with ancient, poorly documented systems. Nate Hashem’s point is huge: businesses were never going to budget weeks just to *understand* old code. Now, AI can act as a translator and archaeologist, figuring out intent and identifying dead code. This makes a previously miserable job “a lot more pleasant” and actually feasible.
Hashem also nailed why the AI experience inside big companies is so different from the hype on social media. Executives mandate AI use, but by the time legal is done vetting tools for proprietary data, they often settle for the weaker, bolted-on AI in products like Microsoft Office or Gmail. The average employee is told to use AI but given “crappy AI tools” because the good ones are a logistical nightmare. It’s a massive gap between the cutting-edge agents developers are using and what’s actually deployed at scale in enterprises.
What happens to the developers?
So, what does this mean for jobs? The answers range from bleak to cautiously optimistic. Kellogg says yes, jobs are threatened “massively,” and that the wave will move from writing code to architecture to product management. Dreier worries about juniors who won’t get the grunt-work experience needed to build judgment. David Hagerty puts it in cold, economic terms: why hire a junior when you can get “junior-quality code for less than minimum wage” from a model?
Mart’s personal take hit hardest for me: the job is “abruptly pivoting from creation/construction to supervision.” For someone who loves the craft of building, that’s a fundamental identity shift, not just a workflow change. And yet, others, like the anonymous architect with 30 years of experience, are having more fun than ever. The truth is, we’re in a chaotic transition. The tools work well enough to be disruptive, but not well enough to be trusted. That’s a recipe for massive anxiety, even alongside the real excitement. Basically, buckle up.
