Almost every app I see that was built quickly with AI has no tests at all. Not few. None.
I want to explain what that actually costs, because the usual explanation — "tests catch bugs" — is true, boring, and misses the thing that will actually hurt you.
Tests are not mainly for finding bugs
They are for letting you change the software later.
Right now you know how your app works, because you watched it get built. In three months you will not. And the first time you want to add something, you will face a choice: change the thing and hope, or leave it alone.
Most people leave it alone. Quietly, without ever deciding to. The app stops improving, and the reason gets described as being busy.
An app with no tests is not risky so much as finished. That is the cost. Not a bug — a ceiling.
What does a test actually look like?
Less than you think. It is a small piece of code that runs your real code and checks the answer. "Given a cart with two items, the total is the sum of both." "Given an expired card, the order is not created."
You do not write them for everything. You write them for the things that would cost you money or trust if they went wrong, which in most small apps is a short list: payment, access control, anything that sends a customer an email, anything that changes a number someone else relies on.
Do they actually find anything?
Here is my own number, and it is not a flattering one.
I have an algorithmic trading system I had run for months with zero tests. I wrote 318 for it. They found six real bugs — four of them the same shape, none visible by reading the code, all in paths I had personally reviewed and believed were fine.
Then the suite went green and the system still had no profitable edge, which is a completely separate claim and one the tests had nothing to say about. Both halves of that are the point: tests found things reading could not, and they did not make the thing good.
The trap nobody mentions
A test that cannot fail is worse than no test, because it looks like coverage.
I have shipped these. A safety check that read a printed banner instead of the actual files. An assertion that passed against a build with the feature removed. Every one of them was green, in CI, giving the exact impression of a thing being verified.
So the useful question when you add a test is not "does it pass". It is "what broken version of this would it catch?" — and then go and break it, and watch it fail. If you cannot make it fail, it is decoration.
That one habit is worth more than any coverage target.
Where to start if you have nothing
Pick the single path where a mistake costs you real money. Probably checkout, maybe the thing that sends invoices. Write two tests: one where it works, one where it fails the way you would most hate.
Then break the code on purpose and confirm both fail. Now you have two tests that mean something, and you have learned the only technique that matters.
That is an afternoon. It will not make the app good. It will make it changeable, which is the thing you actually lost.
Run the free website check — not a test suite, but the same question pointed at a public site: what is broken that nothing is telling you about?
If your app is at the stage where you are afraid to change it, tell me what you have got. That fear is a specific, fixable condition and usually a smaller job than it feels like.
