The AI Wrote Code I Do Not Understand. Now What?

There is a specific moment that catches people. Something breaks, you open the repo to look, and you realize you cannot tell whether what you are reading is fine, dangerous, or nonsense. You approved every one of those changes. You have no idea what most of them do.

Andrej Karpathy named this in February 2025 when he coined vibe coding — building by describing outcomes and accepting whatever comes back. It works remarkably well right up until you need to change something specific, at which point the gap between "I have an app" and "I understand my app" becomes the only thing that matters.

Here is the useful reframe: you do not need to understand all of it. Professional engineers who inherit codebases do not understand all of it either. They understand a specific 20%, know how to navigate the rest on demand, and are honest about which is which. That is a learnable skill and it takes a weekend, not a bootcamp.

What you actually need to understand

Sort your codebase into three tiers and spend your attention accordingly.

Tier 1 — must understand, no exceptions. Where user data lives and what shape it is in. How a request goes from a click to the database and back. Where authentication happens and how permissions are decided. Where secrets are stored. How the app gets deployed. That is five things, and they fit on one page.

Tier 2 — should be able to find. The specific feature files, the API routes, the components on each screen. You do not need these memorized. You need to be able to locate the right file in under two minutes when something breaks.

Tier 3 — safe to leave alone. Generated types, UI library internals, config boilerplate, lock files. Nobody reads these. Not understanding them costs you nothing.

Most founders feel overwhelmed because they are treating a 200-file repo as one undifferentiated wall. Ninety percent of it is Tier 3.

Map it in an afternoon

Work in this order. It takes three to five hours and the output is a document you will use every week.

1. Start with the database, not the code

The schema is the honest description of what your product is. Open your database — Supabase's table editor, Prisma's schema file, whatever you have — and write down each table, what it holds, and how it links to the others.

Do this first because the schema is small, stable, and explains the code. Once you know there is an organizations table and every other table has an organization_id, half the queries in your app suddenly make sense. And if a table is missing that column, you have just found a tenant isolation bug before it found you.

Flag anything odd: tables with no foreign keys, duplicate-looking tables from a half-finished refactor, columns named 'temp' or 'data' holding JSON blobs. Those are where problems concentrate. Database schema for an AI-built app covers what good looks like.

2. Trace one request end to end

Pick the single most important action in your product — creating the thing your app exists to create — and follow it all the way through. Click, network request, route handler, validation, database write, response, UI update.

Write each hop down with its file path. This one exercise teaches you the app's architecture better than reading fifty files, because every other feature follows roughly the same path. Do it twice, for a read and a write, and you have the shape of the whole system.

3. Find the four things that matter for safety

With a plain text search across the repo, locate:

• Every place a secret could be. Search for 'API_KEY', 'SECRET', 'sk-', 'Bearer'. Anything in frontend code is public — visible to any user who opens devtools. GitGuardian counted 28.65 million new hardcoded secrets in public GitHub commits during 2025, with AI-assisted commits leaking at roughly double the baseline rate, so treat this as likely rather than possible. Secret scanning covers doing it properly, including git history.
• Where auth is checked. If the only check is a conditional that hides a button, your API is open. This is the most common serious flaw in generated apps.
• Where money is handled. Any Stripe or payment code deserves a slow read regardless of your comfort level.
• What talks to the outside world. Every external API call is a dependency, a cost, and a failure mode.

4. Ask the AI to explain its own work — carefully

Point an agent at a file and ask what it does, what calls it, and what breaks if it changes. This is genuinely one of the best uses of these tools: explanation is much more reliable than generation, because it is a summarization task rather than a creative one.

Two guardrails. Ask about code that is in front of you, so you can sanity-check the answer against reality. And ask "what would break if I deleted this?" rather than "is this correct?" — models are agreeable about correctness and much more concrete about dependencies.

5. Write it down

Fifteen files, three paragraphs each, is not the goal. The goal is one page: what the tables are, how a request flows, where auth lives, where secrets live, how to deploy, and a list of things you know are wrong. That page is worth more than any amount of reading you do without writing, and it is the seed of real handover documentation.

Two ways to close the gap

These are not exclusive, and the strongest combination is both: pay for an audit, read the report against the code, and use it as a guided tour of your own app. You learn faster from a document that says "this file does X and here is why it is wrong" than from staring at the file cold. An AI code audit is scoped for exactly this, and if the answer is that a lot is wrong, stabilizing the app is the follow-on.

Stop the gap from widening

Understanding what you have is only useful if tomorrow's code does not undo it. Four habits, all cheap:

1. Read every diff before accepting it. Not the agent's summary — the actual changes. You will not understand every line at first. You will notice when a file you never mentioned got rewritten, and that is the skill that matters.
2. Commit in small pieces with real messages. "Add invoice export" beats "updates". Future you is trying to answer when something broke, and a clean history answers it in minutes.
3. Ask for an explanation with every change. "Explain what you changed and why, in three sentences" costs nothing and compounds fast.
4. Refuse code you cannot follow at all. If you cannot form even a rough mental model of a change, ask for a simpler version. There is almost always one, and complexity you do not understand is complexity you cannot debug at 2 a.m.

Nobody understands every line of a codebase they own. The professionals just have a map, a habit of reading diffs, and a short list of things they know are unfinished. You can have all three by Sunday.

Frequently asked questions

Do I need to learn to code properly? Not to run this app, but reading is worth learning even if writing is not. A weekend of JavaScript and SQL fundamentals will roughly double what you get out of every diff and every AI explanation. Aim for literacy, not fluency.

Is it dangerous to ship code I do not understand? It depends entirely on what it touches. Cosmetic and layout code, no. Auth, payments, and anything handling personal data, yes — those failures are invisible from the outside and expensive when discovered. Understand Tier 1 or hire someone who does before you take real users.

Should I have the AI rewrite it so it is simpler? Generally no. A full rewrite gives you a new codebase you also do not understand, minus the workarounds that were quietly holding things together. Targeted simplification of one confusing area at a time works much better — see refactoring AI-generated code.

---

If you own an app you cannot read and it is now carrying real users, the fastest way to fix that is a map rather than a course. SprintX audits AI-generated codebases and walks founders through their own product — what it does, what is dangerous, and what to fix first. Send us your repo and we will explain it back to you in plain English.