# Reading code without knowing how to program: the minimum to review what the AI does

> The minimum to review AI-generated code without knowing how to program: HTML, CSS, JavaScript, what to look for in a change and how to ask the agent.

*Tags: ai, code, review, ux-for-ai*

---


> [!info] Quick Definition
> **Reading code without knowing how to program** means understanding the structure of what the AI generated: which parts make up the page, what each action does and what data it touches. It lets you review a change with judgment even if you never write a line.


## What do you need to understand at minimum?

A web page has three layers, and each answers a different question:

| Layer | Question it answers | How to recognize it |
|---|---|---|
| HTML | What is on the page? | Tags in angle brackets: `<h1>`, `<button>`, `<img>` |
| CSS | What does it look like? | Rules for color, size and spacing, for example `color: red;` |
| JavaScript | What happens when someone acts? | Functions, events such as `click` and values that change |

HTML tags have an opening, content and a closing part, as in `<p>text</p>`. Some have no content or closing tag, such as `<img>`; MDN calls them empty elements. Attributes are settings on a tag, for example `alt`, which describes an image for a screen reader. Tags nest: `<head>` and `<body>` sit inside `<html>`, and `<title>` sits inside `<head>`. The browser shows what is inside `<body>` and the title in the tab ([MDN, HTML basics](https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/HTML_basics)).

JavaScript gives the page behavior. A typical example: a variable stores the list items, a function changes a class on an item, and a `click` event runs the function each time someone clicks ([MDN, JavaScript basics](https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/JavaScript_basics)).

## How do you read a change (diff)?

You will almost always see the AI's work as a **diff**: a list of what changed compared with the previous version. In the standard Git format, lines that start with `+` are new, lines that start with `-` were removed, and lines that start with a space did not change and are there as context ([git diff documentation](https://git-scm.com/docs/git-diff)). On GitHub, the **Files changed** tab of a pull request shows that diff and lets you choose a unified or split view ([GitHub documentation](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)).

To start, ignore the detail and look at the shape. How many files changed? Are there many `-` lines in a file that had no reason to be touched? A small, focused change is easier to review than a huge, scattered one. If the diff is huge, ask the agent to split it into steps. The full flow is in [[branches-and-pull-requests|branches and pull requests]].

## What should you check in an AI change?

You do not need to understand every line. If the context of these changes is still unclear, start with [[what-is-vibe-coding|what is vibe coding]]. Check five things:

1. **Which files changed.** If the request was for a screen and the change touched the database configuration, something does not add up.
2. **What data is stored.** Look for field names such as `email`, `password`, `phone` or `token`.
3. **What each button does.** Find the button's text and the event that triggers it. If it deletes or sends, it must ask for confirmation.
4. **Whether secrets are visible.** Long key-like strings or words such as `api_key` in a file that ships to the browser are a warning sign.
5. **What happens in the rare case.** Empty field, two different users, slow connection.

These checks do not replace a security audit, but they catch the most common mistakes before publishing. For the next level, review [[vibe-coding-security-basics|security basics for vibe coding]], and for secrets, [[environment-variables-and-secrets|environment variables and secrets]].

## How do you ask the agent?

You can ask for an explanation in plain language, and that is a valid request. Useful questions:

- "Which files did you change, and why?"
- "Explain what this button does, step by step."
- "What does this function store, and where?"
- "What happens if the user clicks twice?"
- "How can I check that this works without touching code?"

If the answer is vague or changes every time you ask, do not treat it as proof. Ask for it to be shown in the code or in a test.

The Claude Code best-practices guide points the same way: ask for evidence, meaning the command the agent ran and its output, or a screenshot. A bare "all tests pass" tells you very little. The rule works with any tool: what matters is seeing the result, not believing the summary. If something fails, [[debugging-with-ai|debugging with AI]] explains how to have the agent investigate the problem before fixing it.

## Example

Illustrative example: a designer reviews a change that adds a "Delete account" button to their app. They read the button's name, follow the `click` event to the function and see that the function calls a delete route directly, with no confirmation. They ask the agent to add a confirmation dialog reading "This action cannot be undone" and to test the cancelled click. Before accepting, they search the files for the word `key` and find no visible keys. They wrote no code; they read enough to ask three correct questions.

## How can you practice starting tomorrow?

1. Open the project in an editor and look for three things without understanding anything else: file names, button labels and data words such as `email` or `password`.
2. Choose one button that does something important and follow its path: the button label, the event that triggers it and the function that runs. Write in one sentence what it does.
3. Ask the agent to explain that path in plain language and compare its explanation with what you read. If they do not match, ask again.
4. Repeat the exercise every time a change touches money, personal data or access.

Start with a file you already know well, such as the page's main text. Following one small thing end to end builds more confidence than skimming ten files. A short note with the file you read, the button you followed and the question you asked works as your guide next time.

## Common mistakes

- Accepting a change because the screen looks right, without checking what data it touches.
- Thinking that not understanding the code means you cannot ask about it.
- Trusting the agent's explanation without asking it to show the code.
- Leaving secrets in files that are sent to the browser.
- Reviewing only the happy path, without trying an empty field or a double click.
- Believing that reading code is the same as auditing security.

## Sources

- MDN Web Docs, "HTML basics" (Learn web development): [https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/HTML_basics](https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/HTML_basics)
- MDN Web Docs, "JavaScript basics" (Learn web development): [https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/JavaScript_basics](https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/JavaScript_basics)
- Anthropic, "Best practices for Claude Code" (asking for evidence, not just assertions): [https://code.claude.com/docs/en/best-practices](https://code.claude.com/docs/en/best-practices)
- Git, `git diff` documentation (`+`, `-` and space markers in the unified format): [https://git-scm.com/docs/git-diff](https://git-scm.com/docs/git-diff)
- GitHub Docs, "Reviewing proposed changes in a pull request" (Files changed tab, unified or split view): [https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)


---

Source: https://www.fernandoux.com/en/wiki/ai/reading-code-without-coding/