AI writes code. It is terrible at decisions

Let me be clear about something upfront: AI is genuinely good at writing code. Not perfect, but genuinely capable. It can produce working implementations faster than any human, in more languages than any individual developer knows.

That’s not the problem.

The problem is that writing code and making engineering decisions are two completely different activities, and AI only does one of them.

Code is the easy part

Here’s a thing that experienced engineers know but rarely say out loud: the hard part of software engineering was never typing the code. It was figuring out what to build, how to structure it, and - most importantly - what not to build.

Every codebase is the product of thousands of small decisions:

Do we use a library for this, or write it ourselves?
Should this be one service or two?
Is this abstraction worth the complexity it adds?
Should we handle this edge case now, or is it premature?
What’s the right boundary between these modules?

These decisions aren’t about syntax or algorithms. They’re about trade-offs, context, and judgment. They require understanding what the code does today and what it will need to do in six months, against requirements that do not exist yet.

AI doesn’t make these decisions. It just generates whatever you ask for. And that distinction has consequences that compound over time.

Prompts are not architecture

When you build with AI, the architecture of your codebase is shaped by the sequence of prompts you gave. Not by deliberate design. Not by a clear understanding of domain boundaries. Just by the order you happened to think of things.

Monday you asked for user authentication. Tuesday you asked for a settings page. Wednesday you asked for an API integration. Each prompt produced working code. But nobody asked: “How should these three things relate to each other? What are the boundaries? What data do they share and how?”

The AI didn’t ask either. It just built three things, each internally coherent, with no shared understanding between them.

Six months later, someone needs to change how user sessions work and discovers that the auth system, the settings page, and the API integration all handle sessions differently. Nobody decided how the three of them should relate, so each went its own way.

The decision vacuum

This is what we see in every AI-generated codebase we audit: not bad code, but a vacuum of decision-making.

No architectural decision records. No explanation for why one pattern was used over another. No consistency in how similar problems are solved. Just a series of working implementations, each produced in isolation, glued together by whatever the AI suggested at the time.

The code compiles. The tests pass (if they exist). The product works. But the codebase doesn’t reflect any engineering philosophy. There’s no “we do it this way because…” - there’s only “the AI generated it this way.”

This matters because software lives longer than the prompts that created it. The codebase needs to be maintained by people who weren’t there when the prompts were written. If those people can’t understand why the code is structured a certain way, they can’t safely change it.

You don’t notice until you do

The insidious thing about decision-free code is that it works fine initially. AI produces code that runs. Users don’t care about your architecture. Revenue doesn’t depend on clean abstractions.

But the cost compounds quietly:

Each new feature takes a little longer because there’s more to work around
Each bug is a little harder to find because the codebase doesn’t have a consistent model
Each new team member takes a little longer to onboard because there’s nothing coherent to learn
Each refactor is a little scarier because nobody knows the blast radius

And then one day, the compound interest comes due. Someone needs to make a significant change, and they realize the codebase has no center of gravity. There’s no clear architecture to extend, only ad-hoc patterns to navigate. If that moment sounds familiar, the five signs your codebase is becoming a liability is the list of symptoms to check yourself against.

What this means in practice

We’re not arguing against using AI. We use it too. It’s a tool, and a powerful one.

But using AI without engineering judgment is like using a CNC machine without a blueprint. You’ll produce parts - lots of them, fast. But whether those parts fit together into something coherent depends on decisions the machine can’t make.

If you’re building with AI, someone still needs to be the architect. Someone needs to make the decisions that the AI can’t:

What’s the module structure?
What patterns do we follow consistently?
Where do we draw boundaries between concerns?
What do we deliberately choose not to build?
How do we ensure new code matches existing conventions?

These don’t have to be massive upfront decisions. They can be lightweight. But they have to exist. A codebase without decisions is just a pile of files that happens to run. Finding out whether anyone was the architect is the first thing an audit looks for, and how we audit an AI-generated codebase sets out the whole process.

The uncomfortable truth

Here’s what nobody in the “AI will replace developers” conversation wants to hear: AI made the writing part of code cheaper, but it made the thinking part more valuable.

When code is cheap to produce, the bottleneck shifts to judgment. What to build, how to structure it, when to refactor, what to throw away - these are the decisions that determine whether your codebase is an asset or a liability two years from now.

AI can’t make those calls. Training does not remove that limitation, because the tool generates what you ask for. The asking is the engineering.

If your codebase was built without enough asking, we can help sort it out. That’s literally all we do.

If you would rather check it yourself first, the AI codebase health checklist is twelve checks you can run this afternoon. No email required.