Why does AI-generated code break after the first few prompts?

The failure is architectural, not linguistic

It is tempting to read a broken app as the model getting worse at understanding you. That is almost never what happened. Models are not less capable on the fifth prompt.

What changed is the codebase. On the first prompt, the model had a blank directory and a sentence, and it produced something plausible: some routes, a way of storing data, a shape for handling authentication. Plausible is not the same as coherent. Nobody chose those decisions in relation to each other, because there was nothing to relate them to.

By the fourth prompt, you are asking for a change that touches two of those decisions at once — say a new page that needs the current user and a database record. If the auth guess and the data-access guess were not designed to fit, the model now has to reconcile them, in the dark, while also adding your feature. The result compiles or it does not, and either way something drifts.

Three compounding causes

Invented project structure. The parts of an application that are boring — routing, auth, error boundaries, the database client — are boring precisely because they should be decided once and left alone. Generating them fresh from a prompt makes them the least stable part of the codebase rather than the most.

No verification between changes. If nothing runs a typecheck, the tests, a build and a boot after each change, breakage does not announce itself. It accumulates. You discover it at the moment you are least equipped to deal with it, which is when you were about to show someone.

Context loss. Each prompt is answered with a partial view of the project. Decisions made in prompt one may not be visible in prompt six, so they get re-decided, differently. This is why the same feature can end up implemented twice, slightly incompatibly.

What actually helps

Start from a real application. If generation begins from a scaffold — a working codebase with routing, auth, a database client, error boundaries and a passing test suite — the model is modifying software rather than inventing an architecture. The parts that usually rot were designed by people, once, and are covered by tests.

Verify every change. Not on request, not when the agent judges it worthwhile: every change, through the same verification chain. This converts a slow accumulation of invisible breakage into an immediate, specific failure that can be fixed while the change is still small.

Repair automatically, then re-check. When a check fails, the diagnostics should go back to the model and the whole chain should run again. Fixing a type error can break a test; a chain that resumes rather than restarts will miss it.

Keep versions immutable. If every build is a content-hashed artifact, the version that worked yesterday still exists exactly as it was, and going back is a pointer change. Recovery stops depending on the model's ability to undo its own work.

The honest limit

None of this makes generated code correct. It makes generated code coherent and running, which is the difference between a project that survives twenty prompts and one that quietly dies at five. Whether the app does what your business needs remains a question only you can answer — but you get to answer it while looking at something that works.

If you are choosing a tool, the useful question is not "how good is the model" but "what starts the project, and what has to pass before I see the result". Both are answerable from documentation, and we have collected the answers.