What AI App Builders Can't Do Yet (2026) | Codersarts
An honest read on where Lovable, Bolt, Replit and the rest stop working, based on what actually breaks in the apps people send us.
There is a specific moment that keeps repeating in our inbox. Someone describes an app, watches it appear, clicks through it, and it works. They show it to a friend. They post a screenshot. Then two weeks later they write to us because the same bug has come back four times, or a customer's card was charged twice, or someone who wasn't supposed to see another user's data saw it.
The gap is not where most people think it is. AI builders are good at writing code. That part is settled. What they are still bad at is everything that happens between "it works on my screen" and "strangers are using it and paying for it." That distance is wider than the demo suggests, and almost nothing about the building experience prepares you for it.
Here is what we see failing, in order of how often we see it.
They cannot hold your system in their head
Every AI builder works inside a context window. It sees the files it decides to look at, plus whatever you just said. It does not carry a model of your application the way a developer who built it does.
For a five-screen app this is invisible. For a twenty-screen app with roles, subscriptions and background jobs, it becomes the central problem. You ask for a change to the checkout flow. The model edits checkout. It has no idea that the onboarding flow also writes to that table, that a webhook reads it, and that an admin screen assumes a field is never null. Nothing warns you. The change ships. Three days later the admin screen crashes, and because nobody connects it to a checkout edit, you ask the AI to fix the admin screen, and it patches the symptom.
This is the mechanism behind the single most common complaint we get: the same bug keeps coming back. It comes back because each fix is local and each fix is blind to the last one. You are not accumulating a system. You are accumulating patches that happen to coexist until they don't.
A developer who has held a codebase for six months has something the model structurally lacks, which is memory of intent. They know that field is nullable on purpose, because of a migration in March. The model sees a nullable field and helpfully makes it required.
Longer context windows have not solved this and probably won't on their own. Context is not the same as understanding what was deliberate.
They cannot imagine someone attacking you
Ask an AI builder to add authentication and it will add authentication. Login page, session, protected routes. It looks right because it is right, for the case where everyone behaves.
What it rarely does unprompted is assume bad faith. In the apps we audit, the recurring security failures are boringly consistent:
Row-level security left off, or written so permissively it may as well be off, so any logged-in user can query any other user's records by changing an ID in a request. Service keys shipped into the frontend bundle, where anyone can read them in devtools.
Authorization enforced by hiding a button rather than by checking permission on the server, so the endpoint underneath is wide open. File uploads with no type or size limit. Password reset flows that leak whether an email exists.
None of these are exotic. They are the first things any security review checks. They persist because the model optimizes for the request in front of it, and nobody asks "make sure a malicious user with a browser console cannot read my customers' addresses." You would have to know to ask.
This is the failure with the worst asymmetry. A broken layout costs you a Saturday. A permissive database policy costs you your customers' data and, depending on where you operate, a regulatory problem that outlives the product.
They cannot reason about money moving
Payment integrations generated by AI builders are usually right in the happy path and wrong everywhere else. The subscription creates, the redirect works, the success page shows.
Then real conditions arrive. A webhook fires twice because the provider retries on timeout, and because the handler is not idempotent, the customer is provisioned twice or charged twice. A user closes the tab after paying but before the redirect, so the payment exists at the provider and not in your database. A card fails on renewal and nothing in your app knows, so a churned customer keeps full access for months.
Someone requests a refund and there is no path for it at all, because the demo never needed one.
Test mode hides all of this. Test mode is cooperative. It does not simulate a retry storm or a disputed charge, so the code that would fall over under those conditions never gets exercised until it is real money.
We rebuild payment layers more often than any other single component, and it is rarely because the integration was wrong. It is because the integration was the only thing built. Billing is not an integration. It is a state machine with a dozen states the demo never enters.
They cannot design for data you don't have yet
An app built against fifteen test rows will be built as though fifteen rows is normal. The model has no reason to think otherwise, and it will not volunteer that your approach collapses at scale, because at the moment it writes the code, it doesn't.
So: a list view that loads every record and filters in the browser. Queries with no index on the column you filter by every single time. A loop that makes one database call per item, which is fine at fifteen and catastrophic at fifteen hundred. Images stored without resizing. Reports computed on request instead of precomputed.
The thing about this category is that it fails gradually, which makes it hard to attribute. Nothing crashes on day one. The app is just slightly slower each week, until a customer emails that the dashboard takes nine seconds, and by then the fix is not a fix but a restructuring.
Related, and worse: almost no AI-built app we have seen arrives with a database migration strategy. Schema changes get made by editing and redeploying. That works until you have production data you cannot lose, at which point the absence of migrations stops being an inconvenience and starts being the reason you cannot safely change anything.
They cannot tell you what they don't know
This is the quiet one, and I think it is the most consequential.
A competent contractor will tell you when you are asking for something that won't work. They will say that emailing 5,000 users from a web request will time out and you need a queue. They will say that storing that data means you now have compliance obligations.
They will say your feature needs a background job, a retry policy and a dead-letter queue, and that this is a week, not an afternoon.
AI builders do not do this reliably. They accept the framing of the request and produce something that satisfies it. Ask for a bulk email feature and you will get a loop inside a request handler. It will work for twenty recipients. It will time out at a thousand, and the failure mode is partial: some sent, some not, no record of which.
The model is not lying to you. It is answering the question you asked, in a register of total confidence, without a mechanism for saying "this is the wrong shape of solution."
Experienced developers push back. That pushback is a feature of hiring humans that nobody prices in until it is missing.
They cannot own an incident
Everything above concerns building. This one concerns the fact that software, once live, has a life.
AI-built apps typically arrive with no structured logging, so when something fails you have a screenshot from a user and nothing else. No error tracking, so failures that don't get reported don't get known. No alerting, so you find out about downtime from a customer. No staging environment, so every change is tested in production. No rollback path, so a bad deploy is fixed by deploying again and hoping. No backups you have ever restored from, which means no backups you can trust.
None of this is glamorous and none of it shows up in a demo, which is exactly why it gets skipped. It also happens to be the difference between an outage that lasts eleven minutes and one that lasts a day and a half.
What will close, and what won't
Some of this is a maturity problem and will improve. The tools are already getting better at generating tests, wiring up error tracking, and flagging obvious secret exposure. I expect security defaults in particular to improve fast, because it is embarrassing for the vendors and mostly solvable with better templates and static checks.
Other parts look structural, at least for this generation of tools. Holding a large system's intent over months, arguing with you about your requirements, and taking responsibility when something breaks at 2am are not code-generation problems. They are judgment and accountability problems. A model can be given more context. It cannot yet be given ownership.
So the honest framing is not "AI builders are toys." They are not. They compress the part of software that used to take the longest, and for a genuinely large class of projects (internal tools, prototypes, validation, anything where the blast radius of a bug is one annoyed colleague) they are sufficient on their own. We tell people this regularly.
The framing that holds up is narrower: these tools get you a working product and they do not get you a durable one. The remaining work is unglamorous, mostly invisible from the front end, and disproportionately concentrated in the places where your business is actually exposed, which is money, data and downtime.
That remaining work is smaller than building from scratch. It is not zero, and it is not something the same prompt loop that created the app can resolve, because the failures are in the parts the loop cannot see.
If you are looking at an app that mostly works and wondering which of these apply to you, the fastest way to find out is to check the six things above against your own build, in that order. Start with the database policies. That is where we find something almost every time.
Not sure where your app stands? We read the codebase and send you a written list of what's actually missing — the specific files behind each finding. No obligation to hire anyone.
Comments