This question is usually asked as a matter of size. Is my project big enough to need a real developer? Size is close to irrelevant.
A three-hundred-line tool that emails a spreadsheet of customer details to the wrong address has caused a serious problem. A twenty-thousand-line personal archive of your own reading notes, built entirely by describing what you wanted, can fail in every way imaginable and cost you an evening.
What decides it is not how much software there is. It is what happens when it is wrong.
Three questions worth more than a size estimate
What happens if it is wrong? Not "does it work", but what the actual consequence of a failure would be. Money moves incorrectly. Someone sees data they should not. A record is destroyed. A person is told something untrue and acts on it. Nothing much — you notice and fix it.
Who bears the cost? This is the question that most often changes the answer. If the cost of a failure lands on you alone, you can make your own decisions about how much risk to carry. If it lands on customers, colleagues, patients, or anyone who has no way of knowing the software was built this way, you are making a decision on someone else's behalf.
Would you find out? The most underrated of the three. A crash announces itself. A permission check that passes when it should fail, a total that is quietly wrong in one currency, a backup that has silently written nothing for two months — these produce no symptoms at all until something much worse happens. Where a failure would be silent, your own testing is a weaker safeguard than it feels, because you can only check for problems you have thought of.
If the honest answers are "not much", "me", and "immediately", you almost certainly do not need anyone to look at it. Build the thing. That covers a great many genuinely useful pieces of software.
Where the answers tend to point
Some areas produce uncomfortable answers to all three questions often enough to be worth naming directly.
Authentication and access control. Whether someone is who they say they are, and what each person is allowed to see or do. Failures here are usually silent by nature: the software behaves perfectly for everyone testing it, because they all have the permissions they expect.
Personal or sensitive data. Anything that identifies a person, and particularly anything about health, finances, children or protected characteristics. The consequence is borne entirely by someone else, and it cannot be undone by fixing the software afterwards.
Payments. Money is unforgiving of rounding, of retries, of a request that is sent twice because the connection dropped. It also attracts attention from people actively looking for mistakes.
Integrations with systems that matter. When your software writes into a payroll system, an accounts package or a supplier's ordering system, its defects stop being contained. Reading from something important is usually fine; writing to it is where review earns its cost.
Irreversible operations. Deleting, overwriting, merging records, sending. Anything with no undo deserves attention out of proportion to how simple it looks, because the ordinary recovery — fix it and run it again — is not available.
Things people depend on being available. If a morning without the software means a business stops, the questions to ask are about what happens when it fails rather than whether it works.
Regulated or safety-related use. Where there are rules about how software of this kind must be built, tested or recorded, the requirement is not really a technical one, and being careful is not the same as knowing what the rules actually demand. This is the clearest case for asking somebody who works under that regime.
None of these is a prohibition. They are places where the three questions usually resolve towards "yes, have someone look".
What a review actually is
It is worth being concrete, because "get a developer to look at it" sounds larger and more expensive than it usually is.
A review is someone experienced reading the parts that matter and telling you what they find. It is not a rewrite, it is not an audit in the formal sense, and it does not require handing the project over. For most small systems the useful version is a couple of hours spent on the specific areas above, not a line-by-line reading of everything you have built.
Much of the value is recognition rather than analysis. Someone who has maintained software over years has seen these particular failures before and knows where to look first — which is a different skill from writing code, and one AI assistance does not supply, because the assistant is not the party bearing the consequence. That background is the perspective this site is written from, and there is more about it on the about page.
Making the review worth what it costs
What you provide determines what you get back. Arriving with "can you check this is alright" produces a vague answer, because the question is vague.
Bring the behaviour you accepted — what the software is supposed to do, as you wrote it down. Bring the decisions you made along the way, particularly around the risky areas. Bring what you have already checked and what you have not. And be specific about your concern: "this handles customer addresses and I do not know whether one customer could see another's" is a question that can be answered in an hour.
Then ask for prioritised findings rather than a verdict. "What here would actually hurt me, and in what order" is more useful than "is it good", and it leaves you able to act on the top of the list even if you cannot act on all of it.
Be straightforward about how it was built. There is no reason to be defensive — but a reviewer who knows the code was AI-assisted will look in different places, because the characteristic weaknesses differ. Confidently written code that is subtly wrong in an unusual case is a different search than the one they would run over hand-written work.
Two things this does not mean
It does not mean that building software without a professional review is reckless. Most software built by most people is low-consequence, borne by its author, and fails visibly. That is the ordinary case, and it is the situation described in building software without a development background. Insisting on review for all of it would be a way of telling people not to build things, which is both wrong and a waste of what has become possible.
Nor does it mean AI removes the need for expertise once you have someone to check the result. The assistant will produce plausible code in the areas above as readily as anywhere else, and will describe it in the same confident terms — which is exactly the problem, since a claim that something is production ready is not evidence that it is. Your own checking still matters, and testing against what you accepted catches a great deal before anyone else is involved. Review is what you add when the cost of the things you would not think to check is high enough to be worth someone else's attention.
If there is a single thing to take from this, it is to answer the third question honestly. People are generally realistic about what their software does and unrealistic about whether they would notice it failing. A review costs a few hours. Finding out from a customer, months later, that the wrong people could see each other's records costs considerably more than that, and it is not a cost you can pay back.
The broader question of what remains yours to understand, review or no review, is taken up in what you still need to understand when AI writes the code.