How to tell if your AI-generated code is any good

You ask the AI a question every founder eventually asks.

"Is this any good?"

You don't quite know what you mean by it. You mean: the code you wrote for me, the thing my customers are about to use, is it built right? The AI looks at the file you opened, looks at the change it just made, and answers in a friendly voice.

"This looks great. The implementation is clean and follows best practices."

It always says that. You've never once asked an AI if its work was any good and had it say no.

That's not a bug. The AI cannot tell you.

What "good" actually means, and why nobody can see it

When a developer asks if code is good, they're not asking if it runs. They're asking something harder. Will it keep working when the next person changes it? Will it break in a way you can fix? Will it survive the things real users do that nobody who built it has thought of yet?

Those questions don't have answers in the file the AI is looking at. The answers live in everything around it. The way the project was put together six months ago. The pieces in other folders that depend on this one. The decision someone made on a Wednesday afternoon to handle a customer who emailed about something weird.

The AI cannot see any of that. It looks at a slice. It tells you the slice looks good.

Here's the part that should give you pause. Veracode tested more than 150 of the latest AI models on 80 coding tasks for its Spring 2026 GenAI Code Security report. Almost half the code came back with security flaws. The number that should land harder: it hasn't budged in two years. The security pass rate has gone from 55 percent to, almost exactly, 55 percent, across every major model release. The developers who use these tools every day are not the ones telling you the output is fine. The people telling you it's fine are the people selling the tools.

Nobody who built these tools thinks the answer to "is this any good?" lives inside the AI. They know it doesn't.

The honest answer to the question, then, is: you cannot fully know. Not from inside your own project. Not by asking the same tool that wrote the code. The only way to know for certain is to put the project in front of a person who can read it, and that person needs the time to read more than a slice.

But there's something else, and it's the part most founders miss.

You can read your experience of the code

You can't read the code. You can read what the code does to you.

Every time you open the project to make a change, the project tells you something about itself. How long it took to do something simple. Where you got stuck. Which parts you avoided. Whether the AI helped or kept making you go in circles. None of that requires reading a line of code. It requires noticing.

Your experience of working with the project is the cheapest, most honest test you have. Real developers know this. They don't read every line of every file before they say "this codebase is in trouble." They notice. They try to make a small change, the code fights them, and they know.

You can do the same thing. You've been doing it without realizing.

Eight signs you can spot without reading code

Here's what to look for. None of these require you to know how code works. They show up in your daily experience, if you slow down enough to notice them.

1. The AI keeps suggesting fixes for things you didn't ask about. You ask for one change. It rewrites three. It tells you it found a few "improvements" along the way. Then something that worked yesterday doesn't work today. The AI is touching code it doesn't understand, hoping it gets it right. Sometimes it does. The other times pile up.

2. The same idea is written three different ways across the project. You go looking for how dates get formatted, or how an email address gets checked, or how money is added up. You find it in three places. Each one slightly different. The AI never noticed the first two when it wrote the third. This is the most common quiet sign of a project the AI has lost the thread on. It looks like nothing. It costs you on every change.

3. Small changes spread to files you didn't expect. You ask the AI to update a button. The AI changes the button, and also the form the button sits in, and also a file you've never opened. Each change "needs to happen for it to work," the AI explains. Maybe. Or maybe the project is so tangled that touching anything touches everything. Real codebases are more like a house and less like a hairball. If everything is connected, nothing has shape.

4. You're afraid to touch certain parts. The login. The payments. The email that goes out when someone signs up. You haven't touched these in weeks. You don't really know why. The AI offers to clean them up. You say no. Some part of you knows: that thing works, and you don't know what it would take to make it work again. Fear of certain files is the project telling you it has secrets you haven't kept track of.

5. The AI introduces a bug into something it just fixed. On Tuesday, the email verification was broken. The AI fixed it. On Friday, you ask for something unrelated, and the email verification is broken again. Not in the same way. The AI has forgotten that this thing was broken once, that the fix mattered, that it is now removing the very change it made. The project has no memory. The AI has no memory. The two of them keep meeting each other for the first time.

6. The app works for you, but breaks in unexpected ways for other people. A friend tries to sign up. They get a screen you've never seen. A customer says the dashboard looks empty, even though for you it loads fine. The AI built the app for the path you tested. The other paths are guesses, and no real person has tried any of them. Real users don't follow the path. That's the whole problem.

7. You can't describe what your app does without listing every screen. Someone asks what your app does. You start naming pages. The dashboard does this. The settings page does that. The onboarding has these four steps. You don't have a one-sentence answer because the app doesn't have a one-sentence shape. The shape grew out from the AI's slice, not down from a clear idea. The shape can be found again, but not from inside the project.

8. You've stopped reading what the AI writes. There's too much of it. Every change comes with a paragraph about why. You skim. You accept. You hope. The first month, you read every line. Now you watch the changes scroll by and you press the button. This is not a sign of laziness. It's a sign that the project has outgrown the way you were building it. The cost of reading is now higher than the cost of being wrong, and you've made the trade quietly.

If three of these sound familiar, the project is in the gray zone. If five do, the project is past the point where the AI can fairly evaluate itself.

What it means if you spot these

It does not mean your code is broken. It does not mean you built the wrong thing. It does not mean you have to start over.

It means your project is past the point where the same tool that wrote it can fairly tell you whether it's any good. That's normal. Every project built quickly hits this point. The AI was the right tool for the first few months, and it has done what the first few months needed. What you need now is something else.

The thing you need is not a long project. It isn't a developer to take the project over. It isn't a contract or a monthly commitment or a new tool to learn. You need someone who can read code to look at your project once, with you, and tell you the shape of what you've built. Where the same idea is written three ways. Which parts are sturdy and which are leaning. Which signs from the list above are pointing to something real, and which are normal growing pains.

After that, you know what you're working with. The next change is not a guess.

This is the same ceiling we wrote about in when vibe coding stops paying off and what "ready for real users" actually means, looked at from a third side. This post is the one before either of those. The one for the founder who is still wondering, before the wondering turns into trouble.

What we do on a session

You share your screen. We open the project together. We don't read every line, because nobody does that, and the goal isn't to grade you. We look at the parts that match the signs above. We name what we see. By the end, you know which of the eight you have, and which of them matter.

It isn't a fix. It's a read. After it, you can keep going with the AI, or you can take a different path, but you'll be able to see where you actually are. Which is more than the AI can tell you. Which is more than you could tell yourself.

You don't need to read the code to know it. You only need to notice what it asks of you.