When AI-Generated Code Goes Wrong

AI has made it possible for me to build software at a scale I would not have attempted a few years ago.

Across my recent projects, I have now worked through more than 800,000 lines of AI-assisted code. I have built web applications, network monitoring tools, CRM systems, FiveM resources and integrations using Cursor, Claude and Grok.

But there is another side to AI-assisted development that does not get discussed nearly as much.

AI writes code extremely quickly. It also writes broken code extremely quickly.

As my projects have become larger, I have realised that generating the implementation is often no longer the difficult part. The difficult part is working out why something does not work.

Generating Code Is the Easy Part

Modern coding agents are remarkably good at taking a requirement and turning it into an implementation.

Give an agent enough context and it can create database migrations, backend services, React components, API endpoints and tests in minutes.

The problem begins when you are no longer working with a small application. A change that looks completely reasonable in isolation can have consequences somewhere entirely different in the system.

I have had AI-generated changes that fixed the exact problem I described while breaking something else. I have seen models recreate functionality that already existed because they had not understood the wider architecture. I have also seen them confidently use APIs or framework features incorrectly.

One of the most dangerous situations is when the generated code looks right.

There is no syntax error. Nothing obviously ridiculous has been generated. It simply does not behave correctly.

At that point, repeatedly telling an AI "it still does not work" is not a debugging strategy.

You have to fault-find.

The Fix That Creates Another Bug

AI is very good at solving the problem you put directly in front of it. That does not automatically mean it understands the consequences of its solution.

I have had generated fixes work perfectly for the scenario I was testing, only for another feature to stop working. The model had changed shared functionality, modified assumptions elsewhere in the application, or introduced behaviour that conflicted with another part of the system.

That is why I have become increasingly cautious about large AI-generated changes.

Before accepting them, I want to know:

What files changed?
Why did they change?
Was existing functionality already handling part of this?
What else calls this code?
What should I test after changing it?

AI makes it incredibly cheap to generate code. It does not make regressions cheap.

Context Is Everything

Large projects introduce another problem: context.

An application might contain hundreds of files and years of decisions. Even with increasingly large context windows, an AI does not automatically understand all of it.

If it only sees the component currently being changed, it may produce a perfectly sensible solution that is completely wrong for the architecture of the application.

For significant changes, I increasingly use AI to investigate first:

Find the existing implementation.
Trace where the data comes from.
Find everything that depends on it.
Explain the current behaviour.
Identify likely causes.
Propose a solution.
Only then start changing code.

That single change in workflow has made AI-assisted development considerably more reliable for me.

AI Is Also a Powerful Debugging Tool

None of this means I think AI is bad at debugging. Quite the opposite. It is one of the most valuable uses I have found for it.

The difference is in how I use it.

Instead of saying:

"This does not work. Fix it."

I provide logs, errors, expected behaviour, actual behaviour, relevant architecture and what I have already tested.

AI then becomes another tool in the fault-finding process. It can trace unfamiliar code, compare implementations, suggest instrumentation, identify edge cases and explain areas of a codebase I have not touched before.

Human investigation combined with AI's ability to process large amounts of technical information quickly is far more useful to me than simply asking it to generate another version of the code.

Understanding Matters More, Not Less

There is an argument that AI-generated software means developers will not need to understand code anymore. My experience has pushed me towards almost the opposite conclusion.

The easier code becomes to generate, the easier it becomes to create a lot of bad code.

If an AI can generate 5,000 lines while you are making a coffee, somebody still needs to determine whether those 5,000 lines belong in the application.

You need enough understanding to recognise when an approach does not make sense. You need to understand the architecture well enough to know what a change could affect. When something breaks, you need to investigate it systematically rather than continually pressing Generate until the error disappears.

The most valuable skill I am developing is not the ability to make AI write code. That is becoming easier for everyone.

It is technical judgement:

understanding a system
breaking problems down
giving AI useful context
questioning its assumptions
testing its output
recognising when it is looking in the wrong place
taking responsibility for whether the finished product works

AI has changed how quickly I can build. It has not removed the need to understand, investigate and verify what I ship.