Let me tell you about the project that landed in my inbox last month.
A founder had built an impressive booking platform using AI assistance. Real users. Real revenue. Three months of growth. Then one morning, the database stopped responding. Bookings were double-counted. Customer payments went to the wrong accounts. Three days of manual reconciliation followed.
The cause? A race condition that only appeared under load. The AI-generated code worked perfectly in testing. It catastrophically failed when two customers tried to book the same slot simultaneously.
This isn't an indictment of AI-assisted development. I use it daily. But there's a pattern to how AI-built applications fail, and understanding that pattern is the difference between a successful launch and an expensive rewrite.
The seven ways AI-built apps break
1. The happy path problem
AI optimises for the scenario you describe. Ask it to build a checkout flow, and you'll get code that handles a customer buying a product successfully. What you won't get—unless you specifically ask—is handling for:
- •Network timeouts mid-transaction
- •Users clicking the buy button twice
- •Payment succeeding but webhook failing
- •Partial inventory when only some items are in stock
- •Currency conversion edge cases
- •Tax calculation failures
Real applications spend more code handling failure cases than success cases. AI doesn't naturally think this way because you're prompting for what should happen, not what could go wrong.
How to prevent it: Before accepting any AI-generated code, ask "What happens if this fails?" for every external call, user input, and state change. Then ask the AI to handle those cases explicitly.
2. Security as an afterthought
AI will give you authentication that works. It will not automatically give you authentication that's secure. I've seen AI-generated code with:
- •Passwords stored in plain text (or weak hashing)
- •JWT tokens that never expire
- •SQL queries built by string concatenation
- •API endpoints with no authorisation checks
- •Sensitive data logged to console
- •CORS configured to allow everything
The AI isn't malicious. It's just optimising for "runs without errors" rather than "resistant to attacks."
How to prevent it: Treat security as a separate review pass. After the functionality works, explicitly prompt for security review: "Review this code for security vulnerabilities, especially authentication, authorisation, injection attacks, and data exposure." Better yet, use established auth libraries rather than rolling your own.
3. The state management tangle
This is the silent killer. Your app works fine with one user doing one thing at a time. Then:
- •Two users edit the same record
- •A user opens multiple tabs
- •A background job runs while a user is mid-action
- •The browser refreshes during a multi-step process
AI-generated code often holds state in ways that seem sensible in isolation but create conflicts at scale. I've seen applications where the same data was being tracked in three different places, all getting out of sync.
How to prevent it: Establish clear patterns for state management early. Where does the truth live? How do different parts of the system learn about changes? These architectural questions need human judgment, not AI-generated solutions.
4. Database design that doesn't scale
AI will create database tables that store your data. It won't necessarily create tables that:
- •Query efficiently when you have 100,000 records
- •Handle relationships without data integrity issues
- •Support the features you'll want to add later
- •Avoid N+1 query problems
I recently saw a project where the AI had created a structure where displaying a list of 50 items required 250 database queries. Worked fine in development. Unusable in production.
How to prevent it: Database design is where human experience pays off most. Even if AI helps with implementation, have someone experienced review your schema and query patterns. Adding indexes later is easy. Restructuring your data model is not.
5. Error handling that hides problems
There's a particular pattern I see constantly in AI-generated code:
try {
await doSomething();
} catch (error) {
console.log(error);
}The error is caught, logged (maybe), and then... nothing. The application continues as if everything is fine. The user sees no feedback. The system is now in an inconsistent state.
AI writes this because it technically handles the error—the app doesn't crash. But hiding errors is worse than crashing. At least crashes are visible.
How to prevent it: Search your codebase for empty or log-only catch blocks. Every error should result in one of: retry the operation, notify the user, alert an admin, or explicitly decide it's safe to ignore (with a comment explaining why).
6. No testing, no confidence
AI rarely generates tests unless you specifically ask. This means:
- •You can't refactor safely
- •You can't verify bugs are fixed
- •You can't upgrade dependencies with confidence
- •You can't onboard other developers easily
The irony is that AI is excellent at writing tests. It just won't do it unprompted because tests aren't part of "build me a feature."
How to prevent it: Make testing part of your prompt pattern. "Build this feature AND write tests for it." For critical paths (auth, payments, core business logic), insist on test coverage before considering the feature done.
7. Integration assumptions that break
AI builds integrations based on documentation and common patterns. But third-party services have quirks that only experience reveals:
- •Rate limits that aren't in the docs
- •Webhook delivery that isn't guaranteed
- •API responses that change format based on account type
- •Sandbox behaviour that differs from production
I've seen payment integrations that worked perfectly in test mode and failed on the first real transaction because the production API returned a slightly different response structure.
How to prevent it: For critical integrations (payments, auth, shipping), invest in real-world testing before launch. Use production credentials with small test amounts. Read the API's changelog and known issues. Join their developer community to learn what others have hit.
The pattern behind all these failures
Notice what these all have in common: they're failures of anticipation.
AI is reactive. It builds what you ask for. It doesn't volunteer "but what about...?" Human developers, especially experienced ones, naturally think about edge cases, failure modes, and future requirements. We've been burned before. We carry scar tissue from past projects.
This anticipatory thinking is the actual skill in software development. Writing the code has always been the easy part. Knowing what code to write—and what problems to prevent before they happen—is the hard part.
AI hasn't automated that judgment. It's just made the code-writing part faster.
A practical checklist
Before shipping any AI-assisted feature, verify:
Functionality
- •Does it work for the success case?
- •Does it handle failure cases gracefully?
- •Does it work when users do unexpected things?
Security
- •Is authentication/authorisation properly implemented?
- •Are inputs validated and sanitized?
- •Is sensitive data protected?
Data
- •Are database operations atomic where needed?
- •Will queries perform at scale?
- •Is data integrity maintained?
Reliability
- •What happens if external services fail?
- •Are errors visible and actionable?
- •Is there appropriate logging?
Maintainability
- •Is there test coverage for critical paths?
- •Is the code understandable?
- •Are patterns consistent?
The real question
AI-assisted development is genuinely powerful. The question isn't whether to use it—I do, extensively. The question is whether you have the experience to evaluate what it produces.
If you do, AI is a multiplier. You build faster while maintaining quality.
If you don't, AI lets you build things you can't properly assess. That's when projects hit walls, require rescues, or fail in production.
The most valuable skill in this environment is knowing what questions to ask—both of the AI and of the code it produces. That skill comes from experience building systems that work under real-world conditions.
If you're building something that matters, make sure someone on your team has that experience. Whether that's you, a technical co-founder, or an advisor who reviews before you ship.
The code is the easy part now. The judgment is what you're paying for.