Limitations of AI Coding Tools

How well does AI write code? According to medalist judges, AI’s code is not so great. But there were a few surprises buried in this paper. This is the most critical and comprehensive analysis of AI coding agents so far. I expected Claude 3.7 to be near the top, but OpenAI’s o4 and Gemini 2.5 Pro scored significantly higher. Both can solve most coding problems that the judges ranked as ‘Easy’, and the solutions cost pennies to generate. OpenAI’s o4-mini-high delivered solutions that only required human interventions 17% of the time for $0.11. Compare that to the cost of a software engineer implementing the solution, and the benefits are obvious. It generated complete implementations for medium problems 53% of the time, also at a significant cost savings. However, its reliability drops to 0 for hard problems. Researchers found that AI coding assistants are exceptionally useful if they are given access to the right tools and focused on simple or medium difficulty problems. With tools and multiple attempts, solution accuracy doubled for some LLMs, and they were able to solve a small number of hard problems. However, programming skills and software engineers are still required. AI coding tool users must be able to identify flawed implementations and know how to fix them. Even with tools and multiple attempts, AI coding assistants still fumble problems at all difficulty levels. Code reviews and validation continue to be critical parts of the workflow, so the hype of vibe-coding and AI replacing software engineers is still just a myth. At the same time, the software engineering workflow is changing dramatically. Multiple researchers have attempted to determine how much code is written by AI vs. people, but accurate classification methods are proving elusive. At the same time, research like this makes the trend undeniable. $0.11 per implementation represents a cost savings that businesses won’t pass up. The future of software engineering is AI augmented. An increasing amount of code will be written by AI and validated by people. Most code required to implement a feature falls into the medium or easy category. AI coding assistants can’t do the most valuable work, but their impact on the time it takes to deliver a feature will be bigger than the benchmarks indicate. Now that we’re seeing research into the root causes of implementation failure, like this paper, expect AI coding tools to accelerate their capabilities development rate in the next two years. For everyone in a technical role, it’s time to think about how to adapt and best position yourself for the next 5-10 years.

I talk to over 40 engineering leaders a month. And here’s what we’re finding: AI coding tools are exhilarating—but unsustainable without structure. Everyone loves the speed. You can spin up a prototype in a day, generate full functions in seconds, and skip the boilerplate. It feels like you’re coding at 10x. But then comes the hard part: What happens when that AI-generated code hits production? Who’s responsible when it introduces a security flaw? Can anyone actually maintain it three months from now? This is the reality of vibe coding—writing code in the moment, fast and loose, trusting that AI will "just figure it out." And while it works beautifully for MVPs and early explorations, it breaks down hard at scale. The cracks show up quickly: -> Architecture gets messy. AI tools don’t necessarily think across larger code bases —they can generate in isolated chunks if the context just isn't there. -> PRs become noise. Reviewing AI-generated changes takes longer than writing them from scratch. -> Security risks slip through. Hardcoded secrets, poor access control, and logic bugs go unnoticed. -> Teams lose trust. No one wants to deploy code they can’t understand or trace. So what’s the path forward? We don’t slow down AI—we build guardrails around it. -> Code review isn’t optional. AI can assist, but someone—or something—needs to catch what it misses. -> Traceability matters. Every AI suggestion should tie back to version control, so nothing gets lost in the fog. -> Security needs to be first-class. AI-generated code must be checked for vulnerabilities before it ships. -> Maintainability is the long game. AI should help refactor, not just generate more mess. At Optimal AI, we’re solving for this with Optibot—an AI agent that reviews, refactors, and protects your codebase while you move fast. Because vibe coding feels great—until you’re drowning in tech debt. How’s your team making sure AI-generated code doesn’t come back to bite you?

TL;DR: Vibe-coding is a horrible idea. It adds unnecessary complexity, it doesn’t always follow instructions, and sometimes it just does incredibly stupid things. An equally horrible idea is throwing out the baby with the bathwater: assuming that AI assisted coding is a dead end. In skilled hands, it can lead to significant boosts in productivity and even code quality. Kind of like the way a chainsaw is both a marvel of modern productivity and can still be responsible for thousands of injuries every year. Chainsaws are an amazing technology. In the hands of someone skilled, a chainsaw allows you to chop wood 5 times as fast as an axe. In untrained hands, however, it is responsible for around 30,000 injuries a year in the US alone. I see vibe-coding as essentially wielding a chainsaw blindfolded: you are trusting the chainsaw to do sane things, when chainsaws have several known failure modes. The most serious is what’s known as “kickback”: when all of a sudden the chainsaw jerks and if you’re not careful, can hit you in the face or chest. Even basic understanding of kickback and how to avoid it makes a huge difference to the safety of chainsaws. For that reason, it’s important to understand what the failure modes of the current generation of AI-assisted coding are. I’ve now completed 5 medium-size projects using Claude Code and Cursor, and here are the failure modes I’ve discovered so far: 10–20% “random acts of stupidity” I have seen AI-assisted coding tools do insanely dumb things that really have you wondering what is going on in those billions of parameters. They seem to happen 10 to 20% of the time. I mean really stupid things, all of these are real: - I point it and ask it to fix a bit of code, and instead of fixing it, it “mocks” it out. - In change 1, it fixes the issue. In change 2 — immediately after change 1 — it undoes the fix. - Randomly change constants. Especially if one constant is older. One particularly sore point is changing constants defining the version of an LLM to use. I’m usually using the latest version, and because it was trained before the latest version, it assumes the new version is a bug and “fixes” it. The solution is simple: review every line of code that an AI coding assistant generates. No exceptions. Every time I have tried to do things in “vibe-code” style it has ended in disaster and took me several times longer than if I had reviewed the code all myself. This is akin to saying “don’t chainsaw while blindfolded, drunk or not paying attention.” Continue here: https://lnkd.in/g9Xx9Z_D