AI Can't Hold Your Codebase in Its Head

The most common disappointment with AI-assisted development sounds like this: it wrote something that worked, and it was still wrong.

That isn't a defect in the tool. It's a structural property of how these systems see a project — and understanding it is what separates teams that get real leverage from teams that quietly accumulate debt while feeling productive.

Locally correct, globally wrong

Ask for a component and you'll get a good one. What it won't know:

• The project already has a component doing 80% of this, three folders away, under a different name.
• The pattern it chose was deliberately abandoned six months ago, for reasons living in a PR nobody linked.
• The utility it wrote duplicates one in a shared package.
• The state it introduced belongs in a store the rest of the app already uses.

Every one of those is invisible from inside the file. They're properties of the system, and the model is only looking at the neighbourhood you showed it.

The result: code that passes review if you're reading the diff, and fails review if you're reading the codebase. Those are different activities. The second one is the job.

Why more context doesn't fix it

Bigger windows and repo indexing help, but they don't solve it, because a codebase isn't just a volume of text. It's a set of decisions, most of them unwritten — which duplication was accepted deliberately, which module is being deprecated, which abstraction exists for one stakeholder's requirement.

None of that is recoverable by reading the code, because it isn't in the code. A model with perfect recall of every file still can't tell which of three competing patterns you're standardizing on. It's the same reason a strong new hire is unproductive for a month despite being able to read every file on day one.

What review becomes

When a machine writes the feature, the local reasoning is fine almost every time — and reviewers who haven't adjusted approve too quickly, because the code looks good. The questions that earn their keep:

• Does this already exist? Duplication is the most common defect, and it's invisible unless you know the codebase.
• Is this our pattern — not just a reasonable one?
• What does this touch that isn't in the diff? The model optimized locally; the blast radius is global.
• Is it the right size? Generated code trends verbose — thirty lines and three options where five lines would do.
• Could I change it in six months?

The uncomfortable staffing truth

AI is most dangerous in the hands of whoever knows the codebase least — exactly the person most tempted to lean on it. A senior engineer using it heavily is a force multiplier. A junior using it heavily, unsupervised, produces code that passes CI while slowly making the system incoherent.

The answer isn't restricting the tool by seniority; that drives it underground. It's being honest that review is now where the engineering happens, and staffing it accordingly. Someone has to keep an eye on what the machine is doing and correct it. That isn't temporary — it's the shape of the work.

The reframe

Treat generated code like a pull request from a brilliant contractor who started this morning: strong fundamentals, fast, and no idea what your team decided last spring or why.

You wouldn't merge their first PR unread. You also wouldn't refuse to hire them.