What AI coding tools get wrong, and why it isn't their fault

We use AI coding tools every day. They make our senior engineers faster, and they let founders with no engineering team ship real products that real customers pay for. That's a genuine achievement, and we'd never tell anyone to stop.

We also spend a growing share of our time rescuing apps that AI tools built. The same failures show up again and again, whichever tool wrote the code. Once you see why they happen, they stop looking like bad luck and start looking predictable. Predictable problems are fixable.

The core problem: the tool does what you asked

An AI coding assistant is very good at the request in front of it: "add a login page," "make checkout work," "fix this error." What it doesn't do on its own is think about everything you didn't ask for, which is most of what makes software survive contact with real users:

• What happens when two people do this at the same time?
• What happens when the payment provider sends the same message twice?
• Who is allowed to see this record, and where is that enforced?
• What happens to existing data when the structure changes?

An experienced engineer asks those questions without being prompted, because they've been burned before. The tool hasn't been burned. It's optimizing for the thing you can see working in the next five minutes.

That's not a flaw in the tool. It's a gap in the process, and the process is the part a person has to supply.

The patterns we see most

1. Features stacked on features, with no structure underneath

Each prompt adds working code, but nobody decides where things belong, so the app becomes a pile of individually reasonable pieces. We regularly find several slightly different copies of the same function, each fixed a different way. Change one, and the others still carry the old bug.

Why it happens: each session only sees part of the app, and the fastest way to make the current request work is often to write something new rather than find and reuse what already exists.

2. Login that almost works

Sign-in screens appear quickly. The hard part is checking on the server, on every request, who the user is and what they're allowed to do, and that part is often missing or inconsistent. "The button is hidden" is not the same as "the action is forbidden."

Why it happens: the visible part of authentication is easy to demo. The invisible part only fails when someone goes looking.

3. Payments that handle the happy path

The first successful test charge feels like done. Production brings retries, duplicate notifications, refunds, disputes and expired cards. Without verification, duplicate protection and a way to reconcile the payment provider's records with yours, money and data drift apart.

Why it happens: test mode almost never produces the messy cases, so nothing in the loop asks for them.

4. Secrets in the wrong places

API keys end up in browser code, in the repository, or pasted into a chat to "debug faster." It works right up until someone finds them.

Why it happens: putting the key right where it's used is the shortest path to working code.

5. "It's fixed" when it isn't

You describe a bug, the tool changes something, and it announces the fix with total confidence. Sometimes the fix is real. Sometimes it treats a symptom, or quietly breaks something else. After a few rounds of this, the codebase fills up with patches over patches.

Why it happens: without tests that check behavior, neither you nor the tool has an objective way to know whether the bug is gone.

6. Nobody knows how it works

This is the one that turns problems into emergencies. When the only record of why things are built the way they are is a scattered chat history, every change is a gamble, and teams get afraid to deploy.

Why it happens: code got written faster than anyone could understand it, and no one was asked to write down the map.

What actually helps

The fix isn't "stop using AI." It's putting back the parts of the process the tool doesn't supply:

• A person who owns the architecture and decides where things belong before the next feature lands
• Tests around the dangerous parts (sign-in, payments and data writes) so "fixed" means something
• Secrets in a proper secrets store, rotated if they've ever been exposed
• Separate environments for development, staging and production, each with its own data and keys
• A short written map of how the core flows work, so the next change starts from understanding rather than guesswork

With that structure in place, AI tools get better. Clean, well-organized code with tests gives them far better context than a tangle does. That's how we work: AI plus senior judgment, not one or the other.

If your app is already showing these symptoms

You're not alone, and it's not a verdict on you. The AI got you far enough to have customers and a real problem, which is a better place to start from than a blank page.

If your app is failing right now, or you're weighing whether to keep what you have, get senior eyes on it before the next round of patches. AI Slop Surgery starts with a free 30-minute consultation, then a triage: a written diagnosis and a priority list. The full service lives at aislop.surgery.