If AI can build my app, do I still need to hire a developer?

This question usually arrives with an apology attached to it, as though asking it is somehow rude. It is not. It is the most reasonable question anyone building a product right now can ask, and the honest answer is more interesting than either of the two answers people expect.

The two expected answers are both wrong. "No, AI can do everything now" is wrong. "Yes, of course, AI code is garbage" is also wrong, and increasingly it is embarrassingly wrong. The real answer requires separating two things that look like the same thing and are not.

Start with what AI has genuinely got good at

I want to be generous here, because the case is strong and dismissing it makes the rest of this post untrustworthy.

These tools now build working software. Not toys — working software, with a database behind it, authentication, payments, a real interface, deployed on a real domain, doing something a person will pay for. Things that took a competent developer several weeks now take an afternoon and a series of sentences. That is not marketing; it is what I see when people send me their apps.

The measured version of this is stark. Independent testing of large numbers of models across a couple of years showed the rate at which generated code was syntactically correct climbing from roughly half to well over ninety percent. The code compiles. It runs. It does the thing.

If your question is "can AI build my app", the answer in 2026 is: probably, and faster than any human alternative, and you should use it.

That is not the question you are actually asking, though. You are asking whether the result is a business.

The one number that has not moved

The same body of testing measured something else at the same time: how often the generated code introduced a security flaw. Across the same two-year window, while syntactic correctness nearly doubled, that number stayed essentially flat — around forty-five percent of tasks produced code with a security weakness in it. In JavaScript specifically it hovered in the low forties. For one particular class of flaw, cross-site scripting, the failure rate was above eighty percent.

Sit with the shape of that for a second, because it is the entire argument.

Getting dramatically better at writing code that works has not made these tools meaningfully better at writing code that is safe. Those two capabilities improved at completely different rates, which tells you they are not the same capability wearing different clothes.

Why the gap is structural, not a temporary lag

The obvious response is that this is a matter of time — the models are improving, security will catch up. I do not think that is right, and the reason is about feedback rather than intelligence.

Code that does not work produces a signal. The page is blank, the button does nothing, an error appears in red. You see it, you paste it back, the model fixes it. That loop is tight, immediate and self-correcting, and it is exactly why the working-code number improved so fast.

Code that is not safe produces no signal whatsoever. A missing authorization check does not error. A database left open to anyone does not throw an exception. A secret sitting in the browser bundle does not slow the page down. The app works perfectly — that is what makes it dangerous. There is nothing for the loop to correct, so the loop does not correct it.

Security is a statement about what should be impossible, and impossibility has no observable presence. You cannot see the absence of a wall.

This is also why "just ask the AI to check the security" does not close the gap. The model will make changes and report success, and it will be sincere, because from inside the loop everything looks fine. The verification is the missing piece, and verification cannot come from the same place as the work.

What the field data shows

Two independent looks at real deployed apps, both from 2026, both worth knowing about.

A security firm scanned in the region of 380,000 publicly reachable AI-built applications and found roughly five thousand leaking data, with about forty percent of those exposing information that could identify actual people. The root cause was not exotic — it was default-public configuration that nobody changed.

A second study looked at a smaller sample of just over a thousand apps in detail. Sixteen percent had a critical-severity issue and twenty-nine percent had a high-severity one. Of the 1,072 apps examined, twenty-six were clean.

Those numbers describe a systemic property, not a set of unlucky individuals. And they are consistent with the mechanism above: nobody involved was careless, they simply had no signal telling them anything was wrong.

I want to be precise about what this does and does not prove, because there is a widely repeated claim in this space — roughly "nine out of ten AI-built apps have security problems" — that traces back to a forum comment and no study at all. The real figures are serious enough without inflating them.

So what is a person actually for?

Here is the honest, bounded list. It is shorter than a developer's job used to be.

The security boundary. Deciding what each kind of user may touch, writing that down as rules the database itself enforces, and then testing it by trying to break it — from a second account, as an attacker would. The model can write these rules. It cannot judge whether they are the right rules, and it will not try to defeat them.

The failure paths. What happens when the payment provider is slow, the upload is 40 MB, the webhook arrives twice, the user closes the tab mid-checkout. Generated code implements the path where everything works, because that is the path you described. Somebody has to imagine the others, and imagining them is a specific skill.

The decisions with money or liability attached. Where data lives, what is retained and for how long, what a customer's security questionnaire will ask, what happens legally if something leaks. These are not coding questions and no amount of prompting produces them.

The ability to say the shape is wrong. This is the one people underrate most. AI will build precisely what you ask for, extremely well, including when what you asked for is the wrong thing. It has no stake in the outcome and it will never tell you that the feature is not the problem. A person with judgement and some skin in the game will.

Notice that none of these is typing. That is the actual change of the last three years: the typing stopped being the scarce resource, and everything that was hiding behind the typing became visible.

What this does not mean

It does not mean hiring someone full-time. For most people reading this, a full-time developer is both unaffordable and unnecessary. The work above is bursty. It concentrates at a few moments and then it is done for a while.

It does not mean stopping. Keep building with AI. It is faster than any alternative and the first ninety percent of the work is legitimately solved. The mistake is not using these tools; it is assuming the last part comes free with the rest.

It does not mean starting over. Almost nothing in the list above requires a rewrite, and the instinct to rebuild from scratch is usually the expensive wrong turn. I have written about when a rescue beats a rebuild in more detail, because the answer surprises people.

The three moments that actually matter

Instead of "do I need a developer", the better question is "when". There are three points where the answer changes, and it is whichever arrives first.

Before your first paying customer. The moment money changes hands, a failure stops being embarrassing and starts being a refund, a dispute or a chargeback. This is also the cheapest moment to look, because there is not much to unwind yet.

Before you store data that belongs to someone else. Your own test data leaking is annoying. A customer's client list, health information or financial records leaking is their problem, caused by you. That threshold is where the downside stops being bounded by your own tolerance.

When you can no longer change it safely. The tell is specific and most people recognise it instantly: you have started avoiding certain parts of the app, because the last time you asked for a change there something unrelated broke. That is not a feeling, it is a measurement, and it is the same wall I described in why AI-built apps get stuck at 80%.

How to tell where you are right now

Six questions. They take a minute and they are more diagnostic than any general advice I could give.

Can you say, without looking, what stops one customer from reading another customer's records? If a user were deleted right now, would anything else break? If your payment provider sent the same webhook twice tonight, what would happen? If your app started erroring for everyone at 3am, how would you find out? When did you last change something and know for certain you had not broken anything else? And if your platform account were closed tomorrow, what exactly do you have?

If most of those have confident answers, you are in better shape than most and you probably do not need anyone right now. If most of them do not, that is not a failure — it is just the list, and it is finite.

If you want a second pair of eyes

The engagement that fits this situation is not a hire. It is a defined look at a working app by someone whose job is to try to break it and then tell you what they found in plain language.

I do a Production-Ready Audit: the access boundary tested from a second account, the failure paths walked, the ceilings on your current plans checked, and a written list of what to fix in priority order with the honest cost of each. From $499, back in five to seven days.

And if you are not sure whether you are even at the point of needing that, send me a description of what your app does and who its users are, and I will tell you which of the three moments above you are standing in. No charge — it is usually a short conversation.

If you have decided you do want help and the question is now how to pick someone, that is its own subject with its own traps. And the full picture of what tends to be missing is in the ten problems every AI-built app has in production.