Mistakes AI Makes in Production (And How to Stop Each)
The 10 mistakes AI makes in production code — what Claude did wrong, the correct pattern, and the exact instruction that prevents each one from recurring.
The mistakes AI makes in production are predictable and documented: it writes code that works in the demo and fails live. While building my own platform with Claude, I kept a log of every mistake it made that needed correction: 28 recurring lessons, each with the exact instruction that prevents it. Here are the ten that cost the most when they slip through.
The point of this list is not to scare you off AI development. It is the opposite: because the mistakes are predictable, they are preventable — with a sentence in your prompt or a standing rule in your project instructions. You do not need to write the correct code. You need to recognise the incorrect pattern and know what to say.
Why AI makes the same mistakes every time
AI optimises for the happy path — the version of your feature where the data exists, the user is logged in, nothing fails, and only one customer ever uses the app. That version demos beautifully. Production is everything else: sessions expire, two users click at once, data is missing, and customer A must never see customer B's records.
AI does not skip these because it is careless. It skips them because you did not ask — and unlike a senior developer, it does not fill in unstated requirements from experience. These four sabotage behaviours are a related but different list I covered separately; today's ten are about what production-grade code needs that AI omits by default.
The 10 mistakes AI makes in production, the correct pattern, and the instruction
| What Claude did | The correct pattern | How to instruct it |
|---|---|---|
| Created a duplicate service for functionality that already existed | One source of truth per domain — extend the existing service | "Before creating a new file, check for an existing service that does something similar and extend it" |
| Let UI components talk directly to the database | Three layers: components use hooks, hooks use services, only services touch the database | "Never import the database client in components — follow the 3-layer architecture" |
| Used rigid ENUM types for statuses and categories | Lookup tables you can extend without code changes | "No enums — create a lookup table with code, display name, sort order, and active flag" |
| Created foreign keys with no indexes | Every foreign key gets an index; common query combinations get composite indexes | "Every foreign key column must have an index" |
| Built tables without an organisation column | Multi-tenancy from day 1: every business table is scoped to the customer that owns the data | "Every business table gets organization_id, not null, as the second column" |
| Skipped row-level security entirely | RLS enabled on every table, with policies for read, insert, update, and delete | "After creating any table, enable RLS and add all four organisation-scoped policies" |
| Handled only the happy path in components | Four states everywhere: loading, error, empty, and success | "Every data-fetching component must handle loading, error, empty, and success states" |
| Let errors fail silently | Catch, log with context, and surface a retry to the user | "Every async function gets error handling: log it, throw a friendly error, show a retry" |
| Deleted data permanently on request | Soft deletes — mark records deleted, keep the data, allow undo | "Never hard delete business data — set deleted_at and deleted_by, and filter them out in queries" |
| Ran multi-step writes without a transaction | Related writes succeed or fail together, never halfway | "These writes must be atomic — all succeed or all roll back" |
The full set of 28 lessons — including type safety, logging, accessibility, hardcoded IDs, and test coverage — lives inside the AI Product Builder course, each with before-and-after code and the copy-paste prompt.
The bookThe Solopreneur RevolutionLuis Gonçalves on building a solopreneur business with AI while employed.Get the book →The two mistakes that can end your business
Eight of the ten cost you time. Two can cost you the company.
Missing multi-tenancy and missing row-level security are data-breach machines. Without an organisation column on every table, all your customers' data lives in one undivided pile, and only good luck in the application code keeps customer A from seeing customer B's records. Row-level security is the database-level wall that holds even when your code has bugs — and your code will have bugs. AI skips both unless told, because nothing in "build me a project tracker" says other people's companies will live in this database too.
Retrofitting is brutal: adding the organisation column later means migrating every table, backfilling every row, updating every query, and re-testing everything. One sentence in the original prompt, or a week of migration surgery later. Choose the sentence.
Turn corrections into standing rules
Correcting AI mistake-by-mistake is fighting the tide. The compounding move is to write each correction into your project instruction file, so every future session starts with the rules already loaded — I explained the mechanics in the one file that prevents 90% of AI mistakes. A rules block as short as this changes everything downstream:
Follow the 3-layer architecture. Every table gets organization_id, audit columns, and RLS policies. No enums — lookup tables. Index every foreign key. Soft deletes only. Every component handles loading, error, empty, and success. Every async function has error handling.
Ten lines. Written once. Enforced on every prompt you ever run. That is the difference between correcting AI and directing it — which is the real job, as I argued in you are the architect.
12 weeksYour corporate career was never the planApply to the Solopreneur Accelerator.Apply now →Frequently asked questions
If AI makes all these mistakes, is it safe to build with?
Yes — because the mistakes are consistent, not random. A junior developer makes different mistakes every week; AI makes the same ten until you write the rule that stops each one. A documented failure mode with a known one-line prevention is a manageable engineering risk, not a reason to hire a team.
How do I catch these mistakes if I cannot read code fluently?
Review with questions, not line-by-line reading. Ask AI directly after it generates anything: does every table have an organisation column and RLS policies? Are deletes soft? Does this component handle loading, error, and empty states? AI is honest about its own omissions when asked specifically — the table above is effectively your review checklist.
Should I fix these problems in code AI already wrote?
Prioritise by risk. Fix the security pair first — organisation scoping and row-level security — before you take real customers, because retrofitting them only gets harder as data grows. Missing states, logging, and soft deletes can be fixed feature-by-feature as you touch each screen.
Where do the standing rules actually go?
In a project instruction file that your AI tool reads at the start of every session — in Claude's case, a CLAUDE.md file in your project. Every correction you ever make gets promoted into that file, so it is made exactly once. The setup takes minutes and is covered in the CLAUDE.md guide.
How trapped are you, really?
Take the Corporate Suffocation Index, the free solopreneur readiness assessment.