Twelve months ago I looked at the bold predictions of tech-CEOs. The most vocal predicted big changes in software development and the wholesale replacement of software engineers with AI. A revolution.
“In three to six months, AI is writing 90 percent of the code.” “Probably in 2025, we … are going to have an AI that can effectively be a sort of midlevel engineer that you have at your company that can write code.”
It didn’t happen. It looked like hype then and a year later it is confirmed as pure hype — from CEOs who needed a better Q2 forecast.
AI writes a great deal of code, quickly, but we haven’t seen the promised revolution. Organisations are not seeing the productivity increases the hype forecast. As I said at the time, “these tools aren’t (yet) replacing engineers, but they are redefining what engineers do”.
For myself, looking back over the last year, I don’t think AI has revolutionised anything in software development. Nothing. I think we’re seeing the same problems, just faster.
The problem with AI
People complain about AI coding a lot, and I think the complaints have converged into five problems:
- Confidently wrong — it is terribly confident, all the time, even when it is wrong or has hallucinated; it can be plausibly wrong about real things, assert without checking, or just fabricate things that aren’t there: invented requirements, made-up facts, fake citations, APIs and libraries that don’t exist (Karpathy; Willison).
- Slop — what it produces works but is poorly designed, bloated, insecure, duplicated, un-maintainable (Stroustrup; GitClear).
- Orthogonal damage — it changes code it was never asked to touch (Karpathy).
- Non-determinism — same prompt, different answer (Fowler; Stroustrup).
- The productivity illusion — it flies through the easy 70% but stalls on the hard last mile, leaving “house of cards code”; so it feels fast and is measurably slower and costlier (Osmani; METR).
The striking thing isn’t the list — it’s who is making these complaints, and that the enthusiasts and the sceptics have arrived at the same place from opposite ends. These are the people building and studying the tools, not cranks on the sidelines.
Andrej Karpathy coined “vibe coding” — the give-in-to-the-vibes style where you “forget that the code even exists” (Karpathy, 2025) — and now says the errors are no longer syntax but “subtle conceptual errors that a slightly sloppy, hasty junior dev might do”: the models “make wrong assumptions on your behalf and just run along with them without checking,” and they “don’t push back when they should” (Karpathy, 2026). The numbers are just as blunt. GitClear’s analysis of 211 million changed lines found copy-pasted code up four-fold, and refactoring collapsing from 25% of changes in 2021 to under 10% in 2024 (GitClear, 2025); and METR’s randomised trial found experienced developers using AI took 19% longer — while believing they’d been sped up by around 20% (Becker et al., 2025).
The rest of the list is the same story from the same calibre of witness: Willison on the fabrications a compiler will never catch (Willison, 2025), Fowler on the “non-deterministic abstraction” you can’t store in git (Fowler, 2025), Osmani’s “house of cards code” (Osmani, 2024), Stroustrup on the bugs, security holes and bloat (OfficeChai, 2026), and Stack Overflow’s survey at scale — 84% using AI, only 29% trusting it, down eleven points in a year (Stack Overflow, 2025; May, 2026).
Enthusiasts and curmudgeons, agreeing — even on the uncomfortable part. Karpathy admits he is “slowly starting to atrophy [his] ability to write code manually” (Karpathy, 2026); Stroustrup fears the same erosion across a generation, that people “lose the ability to detect problems because they are so used to having it done for them” (DevClass, 2025). When even they agree, the mantra “AI changes everything for the better” is running out of credibility.
I’ve seen it all before
Read that list again: Confidently wrong, Slop, Orthogonal damage, Non-determinism, The productivity illusion.
I don’t think the list is about “AI-assisted software development”. I think this is a list of “Software development problems”. Every item is a failure mode we’ve struggled with before AI.
The thing is humans make mistakes. And humans are past masters at overconfidence. You don’t need more than that to explain the problems.
- Confidently wrong — the engineer who proclaims, “I’ve got it”, then confidently builds completely the wrong thing and is surprised when you reject it. It’s the entire reason review and tests exist. And when it’s not overconfidence it’s fallible memory: the requirement you thought you heard the product owner ask for, the misremembered method you were sure was there. It could also be laziness, e.g. the snippet pasted from a stale answer that solves a problem, just not your problem. People fill the gaps with plausible guesses rather than admit they don’t know.
- Slop — Copy-paste programming leading to technical debt, not thinking of the edge cases, or just writing rubbish. I had a junior developer working for me once. Nice guy but software wasn’t his thing. I had to change every line of code he produced. Every single line … before I fired him. Because it was slop. Human produced slop.
- Orthogonal damage — it edits code it was never asked to touch? “While I was in there…” — the drive-by regression every reviewer knows.
- Non-determinism — same prompt, different answer? You think humans are any better? I was “blessed” with five senior developers on a project once; we had to do a major revision to the software and every single one of them suggested a different approach, as in, completely incompatible. But individuals are also non-deterministic: Same developer, same problem, a different solution a year apart. We’ve never had deterministic implementations. When it was humans doing this we just accepted it as human nature, but now we complain about it because it is a computer giving us seemingly random answers and we like our computers to be consistent.
- The productivity illusion — software development is hard and I think all projects stall on the hard last mile. The last 20% was always 80% of the work. “Hey, that is easy, I’ll do it this afternoon!” Should be fast, but measures slow. Again this is just software development reality fighting human optimism. This is so common it has a name: ‘The planning fallacy’.
None of these are new. So why do they feel new?
We took the brakes off
I think two things changed:
- the cost of producing code fell to near zero
- because of that, we, en-masse, decided to trust a “slightly sloppy, hasty junior dev” to do the bulk of our software development
The “slightly sloppy, hasty junior dev” label is from pro-AI Karpathy (2026). Others have similar labels. Willison (2024) says, “I call it my weird intern, because it really does feel like you’ve got this intern who is screamingly fast, and they’ve read all of the documentation for everything, and they’re massively overconfident, and they make mistakes and they don’t realize them.”
I think a lot of us have experienced that now. My initial attempts with AI-assisted development were not inspiring. Well, that isn’t quite true, initially they are terribly exciting, a real “yeehaw!” moment … until something goes wrong. Or, again, more accurately, everything goes wrong. In my first venture into AI land I was using Copilot inside VS Code. It was great for a few hours until, to make the tests run green, Copilot deleted the offending tests. As a TDD and BDD fan, that was quite traumatic for me and I’ve not used Copilot since. I moved onto Claude. Now Claude is a coding giant compared to Copilot. So I thought I’d see what it could do. I let Claude Code run for a week with minimal oversight from me as the lofty product owner. Wow. It felt great. Churning out feature after feature in quick succession. I thought, this is great, maybe the tech bros are right and AI is the future. Then I had a look at what Claude Code had produced and there is only one word for it — slop. It has taken over a month to correct the bad choices the AI had made in that first week. And to really rub salt in the wounds the AI would resist my refactoring because clearly the existing code was the best source of truth. Sigh.
So there we were trusting this weird, screamingly fast but over-confident intern, this slightly sloppy, hasty junior dev, to build our enterprise software. It seems to me that the bloat Stroustrup and GitClear describe is what “cheap” looks like at scale. The software equivalent of hyper-processed food with zero calorific value.
The problems didn’t change. The rate did — because we over-trusted. And once that misplaced trust was exposed, there it was: exactly the same problems, just faster.
Remember: AI doesn’t make you go faster; Brakes Let You Go Faster.
References
Becker, J., Rush, N., Barnes, B., & Rein, D. (2025, July 10). Measuring the impact of early-2025 AI on experienced open-source developer productivity. METR. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
DevClass. (2025, May 9). Interview: Bjarne Stroustrup on 21st-century C++, AI risks, and why the language is hard to replace. https://www.devclass.com/development/2025/05/09/interview-bjarne-stroustrup-on-21st-century-c-ai-risks-and-why-the-language-is-hard-to-replace/1625839
Fowler, M. (2025, June 24). LLMs bring new nature of abstraction. https://martinfowler.com/articles/2025-nature-abstraction.html
GitClear. (2025). AI copilot code quality: 2025 look back at 12 months of data. https://www.gitclear.com/ai_assistant_code_quality_2025_research
Karpathy, A. [@karpathy]. (2025, February 2). There’s a new kind of coding I call “vibe coding”… [Post]. X. https://x.com/karpathy/status/1886192184808149383
Karpathy, A. [@karpathy]. (2026, January 26). [Post on the shortcomings of AI coding agents] [Post]. X. https://x.com/karpathy/status/2015883857489522876
May, E. (2026, February 18). Mind the gap: Closing the AI trust gap for developers. Stack Overflow Blog. https://stackoverflow.blog/2026/02/18/closing-the-developer-ai-trust-gap/
OfficeChai. (2026, May 19). AI still can’t generate code for programming language design: C++ creator Bjarne Stroustrup. https://officechai.com/ai/ai-still-cant-generate-code-for-programming-language-design-c-creator-bjarne-stroustrup/
Osmani, A. (2024, December 4). The 70% problem: Hard truths about AI-assisted coding. https://addyo.substack.com/p/the-70-problem-hard-truths-about
Stack Overflow. (2025). 2025 developer survey: AI. https://survey.stackoverflow.co/2025/ai/
Thomas, S. (2014). Brakes let you go faster. https://itsadeliverything.com/brakes-let-you-go-faster
Thomas, S. (2025). Bold predictions or hype? Tech CEOs on AI’s impact on software development. It’s a Delivery Thing. https://itsadeliverything.com/bold-predictions-or-hype-tech-ceos-on-ais-impact-on-software-development
Willison, S. (2024, September 20). Notes on using LLMs for code. https://simonwillison.net/2024/Sep/20/using-llms-for-code/
Willison, S. (2025, March 2). Hallucinations in code are the least dangerous form of LLM mistakes. https://simonwillison.net/2025/Mar/2/hallucinations-in-code/