Slow code, smart code: why AI-assisted developers are taking longer (and that might be fine)

There's a strange contradiction sitting at the heart of the software industry right now. On one hand, AI is reportedly writing close to a third of all new code in the United States, with chief executives at Microsoft, Google and Meta openly talking about machine-generated software as the new normal. On the other, some of the most experienced engineers using these tools are quietly admitting they've gotten slower, not faster.

If you've been told that AI coding assistants are pure productivity rocket fuel, that second part might come as a surprise. But it shouldn't. The story of AI in software development is turning out to be less about velocity and more about a deeper, messier question: what does "better" actually mean when you're writing code?

The productivity paradox no one expected

A recent piece in CIO framed it bluntly: the best engineers in some organisations are getting slower with AI, not quicker. The reason isn't that the tools are bad. It's that senior engineers use AI differently to juniors. They interrogate the output. They reject suggestions. They rewrite. They run the generated code through their own mental compiler before letting it anywhere near production.

That extra cognitive load — reviewing, verifying, refactoring AI-generated suggestions — eats into the raw time savings the marketing decks promise. A junior developer might accept an autocomplete suggestion in two seconds. A staff engineer might spend five minutes asking themselves why the model chose that pattern, whether it handles edge cases, and whether the dependency it just pulled in is even maintained.

The headline numbers are real. According to ZME Science, roughly 30% of code at major US tech companies is now generated by AI tools. But "generated" is doing a lot of heavy lifting in that sentence. Generated isn't the same as merged. Merged isn't the same as shipped. And shipped isn't the same as shipped without later regret.

Skilled hands, sharper tools

Anthropic — the company behind Claude — published research recently that adds a useful wrinkle. As DevClass reported, the study found that more skilled developers tend to extract more value from AI coding tools than less skilled ones. The reason is intuitive once you say it out loud: AI assistants are leverage, and leverage amplifies whatever you bring to it. A senior developer knows what to ask for, what to throw away, and what "good" looks like. A novice may not yet have those filters.

That same Anthropic research surfaced a less comfortable finding, though: heavy reliance on AI appears to be bad for skill development. If you never struggle through writing a recursive function yourself, you may never truly internalise how recursion works. If autocomplete writes your SQL, you may never learn why your query plan is a disaster at scale.

This is the trap that should worry the industry more than any short-term productivity dip. The best engineers using AI today became the best engineers before AI. The pipeline question is: how do the next generation get there if the scaffolding of difficulty has been removed?

Speed was never the right metric

Software engineering has always had a complicated relationship with the idea of "output." Lines of code is a famously terrible measurement — write enough of them and you've just created more bugs and more maintenance burden for someone else. Pull requests per week, tickets closed, story points: every proxy metric the industry has tried eventually collapses under the weight of its own gaming.

AI tools are forcing a long-overdue conversation about what we actually want from developers. If a senior engineer is slower because they're using AI to explore three architectural options before choosing one — instead of just typing out the first one that came to mind — is that worse? If a developer spends an extra hour writing tests because the AI made it cheap to generate them, is that a productivity loss or a quality win?

For Australian tech leaders running engineering teams in Sydney, Melbourne or Brisbane, this matters more than the global hype cycle suggests. Local salaries are high, talent is scarce, and the temptation to measure AI adoption through crude throughput numbers is enormous. But the organisations that win the next decade will likely be the ones that resist that temptation — and instead ask whether their code is more robust, more readable, and easier to change than it was a year ago.

The jobs question that won't go away

Behind all of this hovers the question everyone is too polite to ask in standups: are these tools going to take our jobs?

A roundup by AIMultiple compiled more than 20 expert predictions on AI-driven job loss, and the picture is — predictably — all over the map. Some predict massive displacement in white-collar roles, including software development. Others argue that demand for software is so far from being satisfied that any productivity gain will be absorbed by simply building more things.

The honest answer is probably somewhere uncomfortable in the middle. Routine coding tasks — boilerplate, glue code, simple CRUD endpoints — are clearly compressible. The roles most exposed are those built almost entirely on that kind of work. But "writing code" has never been the whole job of a software engineer. Understanding a business problem, negotiating tradeoffs, designing systems that won't fall over in two years, mentoring others, debugging at 2am when production is on fire — those don't disappear because a language model can suggest the next line.

What may change is the shape of a career. The traditional path of "write a lot of code as a junior, gradually learn to design as a senior" assumes that the early years of grinding through small tasks build the intuitions you need later. If AI removes that grind, the profession has to find new ways to grow people. Apprenticeships, code-reading practices, deliberately tools-off learning sessions — these aren't nostalgic indulgences. They might be how the industry stays healthy.

What "better" looks like

The most useful reframing of this whole debate is to stop treating AI as a speed multiplier and start treating it as a thinking partner. Used well, it can:

Used badly, it produces a tide of plausible-looking code that nobody fully understands, accumulating technical debt at machine speed.

The senior engineers getting slower aren't doing it wrong. They're doing it right. They've recognised that the bottleneck in software has rarely been typing — it's been thinking, deciding, and understanding consequences. AI doesn't remove that bottleneck. If anything, by generating more material faster, it puts more pressure on the human judgement layer at the top.

So if you're a developer feeling vaguely guilty that Copilot or Claude or Cursor hasn't doubled your output, take a breath. The goal was never to write twice as much code. The goal was to write code that works, that lasts, and that the next person can understand. If AI is helping you do that — even slowly — you're winning the only race that matters.

Related on Bleen

Sources