How to Read Code You Didn't Write

You opened the folder your AI tool generated, clicked into a file, and saw a wall of brackets, indentation, and words that half make sense. Your first instinct is that you're supposed to understand all of it. You're not. Understanding every line is a developer's job, and it takes years. What you actually need is orientation: enough of a map to know where things live, what talks to what, and where to point when you say "change this."

This post gives you a repeatable method to get that map in about 30 minutes. It has three moves, in order: find the entry points, follow the names, and follow the data. You don't need to learn a programming language to run it. You need to read the way you'd read a building directory, not a novel.

If you want the bigger picture first, this post is one step inside understand the app you built with AI. Come back here when you're staring at actual files and don't know where to look.

Reading to navigate, not to memorize

Here is the mindset shift that makes the rest possible. You are not reading code to learn what every symbol does. You are reading to answer three plain questions:

• Where does this app start?
• What are the big pieces, and roughly what does each one do?
• When a user does one thing, what path does that action travel?

Notice that none of those questions require you to know how a function is written. They require you to recognize labels, follow arrows, and skim. That's navigation. A developer navigates too before they ever "comprehend" anything, because nobody holds a whole app in their head at once.

Two things make this realistic for a non-engineer. First, code is written in mostly readable words. Files and folders have names, functions have names, and in a well-generated project those names are honest. Second, you're allowed to be uncertain. If you can point at a file and say "I think this is the part that sends the email," you have already done the job. You're building a rough map you can hand to your AI tool or a hired developer, not passing an exam.

It also helps to know the three words that keep showing up: the three words: frontend, backend, API. The frontend is what the user sees, the backend is the part that does work behind the scenes, and the API is the messenger between them. Keep those in mind and the folders start sorting themselves.

Move 1: find the entry points (where the app starts)

Every app has a place where it begins. Find that and you have your first landmark.

You don't have to guess blindly. In most AI-generated and no-code-exported projects, the entry point hides in a small number of predictable spots:

• A file or folder named something like index, main, app, or App. That's often where the app boots up.
• A pages or app or routes folder. Each file inside usually maps to a screen or a web address the user can visit. A file named checkout is very likely the checkout page.
• A public or src folder. src (short for "source") is where your actual code usually lives. public is usually static things like images.
• A package.json or similar settings file near the top. You don't need to read it fully, but the "scripts" section often literally names the command that starts the app, which confirms the starting point.

Open one or two of these and just look at the top. You're not reading for logic. You're confirming "yes, this looks like the front door." When you find a pages or routes folder where the filenames match the screens you see in your live app, stop. You've found the map legend. Each screen the user sees has a home here.

Give yourself about 5 minutes for this move. The goal is one sentence: "The app starts around here, and the screens live in that folder."

Move 2: follow the names (files, functions, and folders as signposts)

This is where the codebase stops being a wall and starts being a directory. In AI-generated projects, naming is your biggest advantage, because these tools tend to name things descriptively.

Read folder and file names as a table of contents. A folder called components holds reusable pieces of the interface (a button, a form, a card). A folder called api or server or functions holds the behind-the-scenes work. A folder called lib or utils holds helpers that many parts share. A folder called db, models, schema, or prisma almost always relates to where your data is stored.

Inside a file, do the same thing with function names. You'll see lines that start with words like function, const, async, or export, followed by a name. Ignore the machinery and read the name. sendWelcomeEmail, validateCoupon, getUserOrders, handleSignup. Those names tell you what that block is for, even if the contents look like noise. A good name is a promise the code is trying to keep.

Here's how to use it in practice. Say you want to understand the signup flow. Search the whole project (every code editor has a search-across-files box, usually a magnifying glass) for the word signup or register. The results are a shortlist of exactly the files that touch signing up. You just narrowed a hundred files down to five without reading any code.

A few naming cues worth recognizing:

You see a name like	It probably means
get..., fetch..., load...	reading or retrieving data
create..., add..., save...	writing new data
update..., edit...	changing existing data
delete..., remove...	removing data
handle..., on...	responding to a user action, like a click
validate..., check...	making sure input is allowed

You won't always be right, and that's fine. Names are signposts, not contracts. But nine times out of ten they point you at the right room. Budget about 10 minutes here to sketch the big folders and what you think each does.

If you want a fuller tour of how these pieces fit into a typical project, it helps to walk through an app's anatomy alongside your own.

Move 3: follow the data (trace one action end to end)

This is the move that turns a map into understanding. Pick one real thing a user does and follow it from the button they click to the place the data lands. Just one. Not the whole app.

Let's use "a user submits the contact form." Here's the trail you're trying to walk:

1. Start at the screen. Find the file for the page or component with the form (Move 2 gets you there, search for contact). Look for the button and the text near it. You're hunting for a name attached to what happens on click, something like onSubmit={handleSubmit} or handleContactSubmit.
2. Follow that name. Search the project for handleSubmit or whatever the name was. That function is the next stop. Read its name-level story: it probably gathers the form values and sends them somewhere.
3. Find the "sends somewhere" line. Look for a word like fetch, post, axios, or a path that looks like a web address, for example /api/contact. That's the messenger (the API) carrying the data from the frontend to the backend.
4. Cross to the backend. Search the project for contact again, now looking in the api, server, or functions folder. There's usually a matching file, like api/contact. That's where the app receives the message.
5. Find where it lands. In that backend file, look for names that mean "save" or "send": save, insert, create, db, or sendEmail. That's the destination. Maybe it stores the message in a database. Maybe it emails it to you. Maybe both.

Walk those five stops and you've traced one action from button to database. You now understand a real slice of your app end to end, in a way that no amount of staring at random files would give you. And here's the quiet payoff: almost every other action in your app follows the same shape. Screen, handler, messenger, backend, destination. Trace one and you've learned the pattern for all of them.

Give this move the biggest chunk of your time, around 10 to 15 minutes, because it's where the map connects.

A worked 30-minute example on a simple app

Picture a small app where users save personal to-do items. Here's the whole 30 minutes.

Minutes 0 to 5, entry points. You open the folder, spot a src folder, and inside it a pages folder with index, login, and todos. The screen names match your live app. You write down: "App screens live in src/pages. The main list is todos."

Minutes 5 to 15, follow the names. You see components (buttons and the to-do row), api (three files: login, todos, user), and lib with a file called db. You jot: "api = behind-the-scenes work, lib/db = probably where data is stored." You open the todos page and see a function named handleAddTodo. Good sign.

Minutes 15 to 28, follow the data. You trace "add a to-do." The button calls handleAddTodo. That function collects the text and sends it to /api/todos. You jump to api/todos, find a block that reads the text and calls db.insert. You follow db back to lib/db and see it connects to a hosted database service. Trail complete: type text, click add, it travels to the backend, it gets inserted into the database.

Minutes 28 to 30, name your questions. With that map, you can now ask something precise instead of vague. "In api/todos, is there anything that stops someone from adding a to-do to another user's account?" is a far better question than "is my app secure?" You've turned confusion into a directed question you can hand to your AI tool or a developer.

That last part matters. Reading like this doesn't make you fix things. It makes you able to ask and direct well. When you're ready to actually approve a change, learning to review a diff as a non-engineer is the natural next skill, because it's the same navigation habit applied to what changed.

What to write down so you don't have to reread it

The worst outcome is doing this skim, feeling oriented, and forgetting all of it by next week. So capture it. A map you wrote once beats a codebase you re-skim five times.

Keep a plain document (a note, a doc, anything) with four short sections:

• Where things live. "Screens: src/pages. Behind-the-scenes: api. Data: lib/db connects to [your database]." Three or four lines.
• Traced flows. For each action you follow, write the five stops in one line: "Add to-do: todos page > handleAddTodo > /api/todos > db.insert." Add flows over time as you touch them.
• Guesses to confirm. Things you inferred from names but aren't sure of. "user.js API might handle password resets? Confirm." This keeps you honest about what you actually know.
• Open questions. The precise questions your skim surfaced, like the "can someone add to another user's account?" one above. This becomes your agenda for your AI tool or a hired professional.

Update it whenever you or your AI tool makes a real change. Over a few sessions this note becomes the single most useful document about your app, more useful than the code itself, because it's the code translated into your own words.

In Plain English

What it means: reading code you didn't write is navigation, not comprehension. You run three moves in about 30 minutes: find where the app starts, use file and function names as signposts, and trace one user action from the button all the way to where its data lands.

Who it helps: any non-technical builder who shipped an app with an AI or no-code tool and now stares at a folder of files with no idea where to look.

When to use it: the first time you open your codebase, and again before any change, so you know which room the change belongs in and can direct your AI or a developer to the right spot.

What to do next: run the three moves once on your own app, and write down the four-section map above. The goal is orientation and better questions, not the ability to hand-edit code. Getting oriented is the win, full stop.

Your next step

Keep this method somewhere you'll actually find it again. Save the three moves and the four-section note template in your own notes, and pull them up before your next edit. The toolkit has related checklists. When you're about to ask your AI tool to change something, run the skim first, then use the change-request templates to turn your map and your open questions into a clear, specific request. You'll spend 30 minutes now and save yourself hours of confusion later. For the wider path this fits into, keep Understand what you built close.

---

Kodbe is an independent commercial publication about maintaining and owning software built with AI or no-code tools. It is not affiliated with Kodbe Inc, Kodobe, Kodable, or Kodu.