Nobody is arguing anymore that LLMs make developers faster. Every benchmark, every survey, every team report confirms this. You can write more code, ship more features, close more tickets, in less time than at any point in the history of this field.

Nobody is talking about what you give up to get that speed.

All of the public debate is still stuck on "is AI code good or bad". That is the wrong question. The correct question is: what breaks, when, and how do you stop it before it eats your team or your project.

This article pulls together six months of independent research, production post-mortems, and real developer experience to map the failure modes that never show up on pass rate benchmarks.

The quiet shift no one benchmarked

For the last three years every LLM code evaluation has measured exactly one thing: given a self contained problem with a complete test suite, does the generated code pass the tests.

On this metric models have improved steadily. GPT-4o mini passes 72% of SWE-bench verified. DeepSeek hits 78%. The best open models now clear 69%. These are good numbers. They are also almost completely irrelevant to what actually breaks when you use these tools on a real codebase.

None of these benchmarks measure:

• Silent semantic regressions that pass all existing tests
• Knowledge debt accumulated when no one understands the shipped code
• Skill atrophy when generation replaces construction
• Confidence hallucinations where wrong answers are presented as fact
• Language bias that changes output quality based on what language you prompt in

These are not edge cases. These are the default failure modes today. Every team using AI tooling is hitting at least one of them right now. Most have not yet noticed.

What LLMs are actually good at

We have one good controlled experiment of building non trivial software entirely from research papers with LLMs. CoreForge built a full MaxSAT solver using only published papers, ChatGPT and Codex. No existing solver code was used as reference.

The result worked. It passed all fuzz tests. It produced correct answers on every MaxSAT Evaluation instance. It was not as fast as the best hand written solvers, but it worked.

This is the single best demonstration of what LLMs can actually do well. They will reliably translate explicit, complete, written specifications into working code. They will audit existing implementations. They will iterate on known designs.

They will not invent the thing that is not written down. They will not remember the incident from two years ago that made you pin that dependency. They will not notice the edge case that everyone on the team knows but no one ever wrote down.

The CoreForge team concluded exactly this: LLMs are excellent implementation assistants. They do not replace validation, benchmarking, or human context.

The language bias no one warned you about

A new paper from this month documents something almost no one has tested: code generation quality changes dramatically depending on what natural language you write your prompt in.

Researchers tested GPT-4o mini, DeepSeek and Claude across 460 coding tasks, translated exactly between English, Chinese, Hindi, Spanish and Italian. There was no universal best language. English did not consistently win. For Java tasks, Spanish prompts produced 11% higher pass rates than English for Claude. For Python tasks, Hindi prompts outperformed English on DeepSeek by 8%.

Model	Best prompt language	Worst prompt language	Correctness delta
GPT-4o mini	English	Italian	12.7%
DeepSeek	Hindi	English	8.2%
Claude 3 Opus	Spanish	Chinese	11.4%

Generated code also consistently mixes the prompt language into comments, identifier names and string literals, even when explicitly asked to use English. This is not a bug. This is inherent behaviour. No model currently avoids this.

If you are prompting in anything other than English, you are almost certainly getting different output than the benchmarks report. If you have an international team, different developers are getting different quality code from the exact same model for the exact same task. No one is measuring this.

The 27x speedup and the green CI lie

Zachary Lee rebuilt KeyEcho 1.0 almost entirely with AI assistance. He got a 27x speedup on the audio hot path. He removed all sample copies, eliminated the global mutex, predecoded every audio slice once at load time. The agent did almost all of the implementation work.

This is the success story everyone shares. The part almost no one talks about is what almost shipped.

The agent proposed a clean, simple fix for a broken CI build: remove the git pin on the audio dependency and use the crates.io release. CI went green. All tests passed.

Lee rejected it. That pin existed to hold cpal at 0.18, which included the device change notification that made audio follow you when you unplugged headphones. No test covered this behaviour. No comment explained the pin. The agent had no way to know it existed.

Green CI proves the tests pass. It does not prove the tests cover the thing you care about. This is the single most dangerous failure mode of AI generated code. It will very reliably pass every test you wrote. It will very reliably break every thing you did not write a test for.

Code as debt, not asset

Every line of code you generate is a loan. You get the code today. You pay the interest later, when you have to debug it, extend it, or explain it.

This is not a hypothetical. This is the default experience for thousands of developers right now. The debt is invisible until the first bug. It does not show up in velocity metrics. It does not show up in pull request reviews.

Lines generated	Debt owed
10 lines	5 minutes reading
100 lines	1 hour understanding structure
200+ lines across feature	Full debugging session

The loan has negative interest for the first week. It compounds after that.

The only working mitigation anyone has found is brutally simple: before you merge anything generated, ask yourself if you could explain it to another developer right now without looking. If you cannot, the task is not done.

Recognition is not production

There are two separate skills involved in working with code. You can recognise that a piece of code is correct. You can produce that code from scratch.

These are completely different neural pathways. AI makes it extremely easy to only practice the first one.

Many developers have now reported exactly the same experience: they can review AI generated code perfectly. They can spot bugs, critique architecture, argue tradeoffs. Then one day they sit down to write something from scratch and they freeze. They cannot remember the basic syntax. They cannot construct the pattern they recognise instantly.

This is not laziness. This is skill atrophy. The skills you exercise grow. The skills you outsource weaken.

This is not a new problem. Compilers did this to assembly. Stack Overflow did this to standard library APIs. AI is just accelerating the gap by an order of magnitude.

The solution is not to stop using AI. The solution is to be intentional about which skills you keep exercising. Pick one thing every week that you write completely by hand. It does not have to be production code. It just has to be practice.

Local code memory works, if you do it right

Developers are increasingly moving away from cloud coding assistants. The reasons are not ideological. It is unpredictable billing. It is the hard ban on sending company code to third party APIs.

Local code memory servers now work well enough for production use. Recent testing with Ollama and ChromaDB shows that 9B parameter models running locally on consumer hardware can answer codebase questions almost as well as cloud models.

There is one critical difference that almost no one documents. Good local models will tell you when they do not know the answer. Bad local models will confidently make up an answer.

Model	Mean latency	Correct answers	Confident wrong answers
mistral:7b	6.14s	3/5	1/5
ornith:9b	13.39s	4/5	0/5

For an IDE assistant, one confident wrong answer costs more than ten honest gaps.

The other unstated rule: garbage in, garbage out applies more strictly to local models than cloud models. You cannot just scan your codebase into ChromaDB and expect good results. You need to run a docstring enrichment pass first. If you skip this step you will spend weeks blaming the model when the real problem is the garbage vectors you indexed.

The rules that actually stick

No one has found a perfect system. But across all these reports, post mortems and papers, a small set of rules are consistently working for teams right now:

1. Never accept an unrequested dependency version change, even when CI is green.
2. Before merging generated code, you must be able to explain it without looking.
3. Write the why next to every pin, hack and magic number. The agent will not remember.
4. Pick one small thing every week that you write completely by hand.
5. Always prefer a model that says it does not know over one that guesses.
6. Green CI is necessary. It is not sufficient.

None of these are dramatic. None of them will go viral on Twitter. They are just boring rules that stop you from getting burned.

What comes next

We are not going back. No one is going to un-invent this tool. The productivity gains are too large. The pressure to ship is too high.

But we are only just starting to learn the real cost. For thirty years we have optimized software engineering for the cost of writing code. Now writing code is almost free. All of the cost has moved to understanding, maintaining and debugging it.

All of our tools, our processes, our benchmarks, our career ladders were built for a world where writing code was the hard part. That world no longer exists.

We have not yet built the replacement.