Shipped fast with Lovable, Cursor or Claude Code? Find out what breaks first, what to fix this week, and what a reviewer should hand back.
Change the record ID in the URL of a live AI-built product while signed in as an ordinary test account, and there is a real chance the database hands back somebody else's data without complaint. Escape.tech ran that class of check across 5,600 publicly reachable applications built on Lovable, Base44, Create.xyz, Vibe Studio and Bolt.new, and found 175 cases of exposed personal information, including medical records and bank details.
A security review of an AI built app comes down to five places where failures cluster, which are database access rules, exposed secrets, authorisation checks, input validation, and unreviewed dependencies. Rotating your keys and switching on row level security costs an afternoon and removes two of the most common causes, after which the work worth paying for is a review of authentication and authorisation.
The trend is moving in the wrong direction while adoption accelerates, and Georgia Tech researchers tracking vulnerabilities attributable to AI coding tools recorded more of them in March 2026 alone than in the whole of 2025, reaching 74 confirmed cases and estimating the true count runs five to ten times higher.
The failure behind those numbers is structural rather than the result of carelessness, because models learn their patterns from enormous quantities of code, insecure examples included, without inheriting the defensive instinct experienced engineers build over years. They optimise for output that runs and looks correct, not for output that holds up against somebody actively trying to break it.
Independent measurements land in the same place. Veracode's 2026 report tested more than one hundred models and found that roughly 44% of code generation tasks introduced a vulnerability from the OWASP Top 10, leaving an average security pass rate of 56% against a syntax pass rate close to 100%. That security figure has barely moved from the 55% recorded in the first edition, and coding-specific models did not outperform general-purpose ones.
The obvious defects disappeared while the dangerous ones grew, which is what makes this hard to spot. Apiiro, in research published in September 2025 across large enterprise codebases, found syntax errors dropped 76%, and logic bugs fell 60%, while privilege escalation paths rose 322% and architectural design flaws rose 153%. Those figures come from mature engineering teams rather than solo-built products, so the direction matters more than the exact multiples.
What did not get cheaper is the judgement, because writing the code stopped being the expensive part while deciding whether it can be trusted became the whole cost. That is a shift in where expertise sits rather than a reduction in how much of it you need.
Shipping something rough to find out whether anyone wants it remains sound practice, and testing demand before building is still the cheapest lesson available to an early company. The mistake is never the speed; it is treating the moment real users arrive as a change of category.
Most of the damage clusters in a small number of places, and several of them you can check yourself in an afternoon without reading a line of code. The 2025 Escape.tech scan referenced above also counted more than 2,000 vulnerabilities and over 400 exposed secrets across those 5,600 applications, and found that most were reachable without any authentication at all, which is why several of the checks below need neither an account nor access to the code.
The dependency row is a newer problem than it looks, because roughly 20% of AI-generated code samples reference packages that do not exist, and those invented names repeat predictably across similar prompts. Slopsquatting is the name for the resulting attack, where somebody registers a package name that models reliably invent, then waits for a developer to install it.
Order matters here, because several of these steps are wasted effort if you do them before the ones above. Work down the list rather than picking the items that look most interesting.
The categories worth escalating to a person are narrow and well established: authentication flows, authorisation logic, cryptography, input validation, and any code standing between a user and sensitive data. AI assistance performs acceptably on boilerplate, tests, and refactoring. It performs poorly on those five, and those five are where a breach comes from.
Nobody has published defensible market pricing for this work, and the ranges circulating online trace back to vendor marketing pages rather than research, so treat any single figure you are quoted as that vendor's rate card rather than a market rate. What you can do is understand the drivers, because they move the price far more than the choice of reviewer does.
Six factors set the number, beginning with the size of the surface, meaning how many routes and tables exist rather than how many lines of code. Custom authentication roughly doubles the work, and the absence of any tests adds more. Sensitive records pull compliance into scope, and the price shifts again on whether you want findings only, findings plus fixes, or a repair.
Treat those durations as planning guidance for your own budgeting rather than as quoted prices. The genuinely expensive version is none of the above, it is the one bought after an incident, when the technical work is identical but you are also handling disclosure, affected members, and whatever your terms promised them.
A conversation followed by a reassuring verdict is not a review, so specify the output before the work starts and you will be able to tell afterwards whether you received what you paid for.
One further request gets forgotten almost universally, which is a written record of which parts of the codebase were AI-generated and with which tool, stored alongside the findings. If a platform level flaw is disclosed six months from now, that record tells you within an hour whether you are affected, rather than within a week.
The skill you need is narrower than the word developer suggests, because you are looking for somebody who has worked specifically on authentication, authorisation, and data access boundaries, and who is comfortable reading a codebase they did not write. A capable generalist will find the obvious problems and miss the architectural ones with complete confidence, and the architectural ones are precisely what the research shows increased most.
Automated scanners are worth running and will earn their keep on exposed secrets and known vulnerable packages, since Escape.tech found most of what it caught was sitting in the open with no authentication required. What a scanner cannot tell you is whether a signed in member can reach something they should not, because that judgement depends on knowing what your product is supposed to do.
A review has no feature attached to it and no revenue standing behind it, which is precisely why it slides down the list until an incident promotes it. Work in that category is what BEXHUB tends to unlock, because a member funds it with BEX earned from work already delivered, which turns a deferred job into one that happens this month.
The same logic reaches well beyond security, because what a small company defers is almost always somebody's judgement rather than somebody's typing. The practical mechanics of building an early team without payroll behind you come down to finding a way to fund exactly this kind of one-off, high-skill, low-volume work.