The code runs. That is genuinely the hard part and an assistant did it in an afternoon. The question is what else is true about it, because "it runs" and "it is safe to point at the public internet with a payment form on it" are two different claims and only one of them has been demonstrated.
Should I get AI-generated code reviewed?
Before it takes payments, holds anyone's data, or gets a marketing budget pointed at it, yes. AI assistants produce code that works, which is not the same as code that is safe. The findings repeat: secrets committed to the repository, authorisation checked in the interface instead of on the server, and dependencies nobody chose.
None of that is a criticism of the tooling. It is a description of what the tooling optimises for. A model asked to make a feature work produces the shortest path to the feature working, and the shortest path never includes the parts that only matter when somebody is hostile.
What goes wrong in AI-written code?
The same five things, in roughly this order: credentials in the repository, permission checks that live only in the front end, no rate limiting on anything, dependencies added without a decision, and error handling that swallows the failure so nothing ever alerts.
- Secrets in the repository An API key pasted into a config file to get something working, then committed. It stays in the history after it is deleted, and the history is what a scraper reads.
- Authorisation in the interface The admin button is hidden from non-admins and the endpoint behind it will still answer anybody who calls it. Hiding a control is not a permission check.
- No limits on anything No rate limit on login, no size limit on an upload, no cap on a query. Each one is fine until somebody notices, and noticing is automated.
- Dependencies nobody chose Packages pulled in to solve one line of a problem, unmaintained, and now part of your attack surface and your upgrade path.
- Errors that vanish A catch block that logs nothing and returns success. The system appears healthy and is quietly losing work, which is the most expensive failure mode there is.
- Blocking, fix before launch
- Worth fixing, not urgent
Illustrative of the pattern rather than a count from your codebase. The point is the ratio: the blocking findings cluster in a handful of categories that are quick to check and quick to fix, which is why this is worth doing before a launch rather than after an incident.
Growth is a process. Nothing here happens overnight, and anybody promising you overnight results is lying to you.
Get a snapshot from $100What is a vibe-coded app?
An application built mostly by describing what you want to an AI assistant and accepting what it produces, rather than by writing and reviewing each part. It is a legitimate way to build and it ships real products. It also means nobody has read the whole thing, and that is the gap an audit closes.
There is no shame in it and it is not a category of lesser software. Plenty of businesses are running on code nobody senior has read, and that was true long before assistants existed: agencies, contractors and departed junior developers have been leaving unreviewed code behind for thirty years. What is new is the volume, and the speed at which one person can now produce more code than they can personally hold in their head.
What does a code review actually check?
Four things a test suite cannot: whether the data can be reached by somebody who should not reach it, whether the money can be moved in a way you did not intend, whether the system fails loudly enough to notice, and whether anything here becomes unworkable at ten times the size.
Tests confirm that what you specified happens. A review asks what else can happen. Those are genuinely different activities, and a product with excellent test coverage can still have an endpoint that returns every user's email address to anyone who asks for it, because nobody wrote a test for something nobody thought of.
Can I review it myself?
You can do the first half in an afternoon, for nothing, and you should before paying anyone. Search the repository history for keys. Call your three most sensitive endpoints with no credentials and see what comes back. Check whether a failed background job would reach a human.
What is hard to do alone is the part that needs pattern recognition across a lot of code: which query will not survive growth, which abstraction is doing nothing, which dependency is a liability. That is judgement built from having seen the failure before, and it is the actual thing you are buying when you buy a senior pair of eyes rather than a scanner.
Are automated security scanners enough?
They are worth running and they are not enough. A scanner finds known vulnerable dependencies and obvious injection patterns, which is genuinely useful and completely automatable. It cannot tell you that your permission model is wrong, because your permission model is specific to your business and no scanner knows what your business is.
Run them anyway. Most are free, they take minutes, and they clear the floor so a human review can spend its time on the things only a human can see. Anyone who quotes you for a review without having run the free tools first is billing you for the easy half.