The review checklist

Reading code is the general skill. This is the specific one: six questions that catch the mistakes with a price tag.

Run all six on anything touching data, users, money or the internet. Run the first two on everything.

1. Are there secrets in the code?

Search the changed files for anything that looks like a key, a token, a password or a connection string. Long random strings, things starting with sk-, anything after the word password.

const apiKey = "sk-a1b2c3d4e5f6";

That line is a leak waiting for a destination. Private repositories become public. Folders get shared. Backups get uploaded. And in version control, a secret committed once stays in the history even after you delete the line.

What right looks like: the key lives in an environment variable — a value your operating system or hosting platform holds outside the code — and the code reads it by name.

const apiKey = process.env.READLIST_API_KEY;

Ask directly:

Are there any secrets, keys or passwords written into these files?
Move anything like that into environment variables.

2. Does anything delete or overwrite?

Look for the words: delete, remove, drop, clear, truncate, overwrite, reset, rm, -f.

Then ask two questions about each one:

• What exactly does it delete? One record, or everything matching something?
• Can it be undone? Is there a backup, a snapshot, an undo?

The dangerous shape is a delete with a broad filter, or an overwrite of a file that had content in it. “Clean up old entries” is a description that has destroyed a lot of data.

Show me every place in this change that deletes or overwrites data.
For each one, tell me what it removes and whether it is recoverable.

3. Does it cost money, and how often?

Two parts, and the second is where the surprises live.

Does it call anything paid? An AI model, an email service, a maps or SMS provider, cloud storage.

How often does it run? Once per click is fine. Once per page load starts to matter. Once per item in a list, inside a loop, on every visit, is how a working feature produces a bill.

Also worth asking: is there a limit? A retry loop with no cap will keep retrying. A polling job with no interval will poll as fast as it can.

Does this call any paid service? How many times per user action?
Is there anything here that could loop or retry without a limit?

4. Who can see this, and who can change it?

The question that catches security problems without needing security knowledge.

For each new thing — a page, an address, a piece of data — ask: who can reach it?

The answers that need a second look:

• “Anyone with the link” for something private.
• “Anyone who changes the number in the URL” — the classic way to read someone else’s data.
• “Anyone who can upload” with no limit on file type or size.
• “Anyone who types into this box”, where the text goes straight into a database query or straight back onto the page.

Who can reach this, and what happens if someone changes the values
in the URL to another user's? Where does user-typed text end up?

5. What did it add that I did not have before?

New dependencies. Every package you take on is code you now ship, update and trust.

Sometimes entirely justified — nobody should write their own date library. Sometimes it is a whole package for something that was four lines.

What new dependencies did this add, and what does each one do?
Which of them could we do without?

Also check for a name you cannot verify. Package names that are near-misses of popular ones are a known attack, and an agent picking up a plausible-looking name from training is a real way to end up with one.

6. What did it touch that I did not ask about?

Look at the file list one more time.

A change to fix a button that also edits the storage code, the styling and a configuration file is three unexplained decisions. Each is probably fine. Together they mean you can no longer say what version one of your project actually is.

Why did file X change? I only asked about the delete button.

Ask, do not assume malice, and do not assume competence. Sometimes the answer is a genuinely necessary fix. Sometimes it is “I noticed it could be cleaner”, which is exactly what you want to catch.

Two of them, on a real change

Six questions is a lot to hold. The two you will actually run every time are the cheap ones, so practise those.

Here is a change to review. You asked for one thing — email me my saved links once a week — and the agent says it is done. The terminal is already sitting in the project folder.

Question 6 first: what did it touch? ls prints the names of the files in the folder you are in — the whole file list, in one command. You asked for one feature; count what is there and decide which of those files you expected.

Then question 1: any secrets? grep prints the lines of a file that contain the text you give it, which makes it the fastest secret check there is:

grep -i key send-digest.js

The -i means ignore capitalisation. It matters here, because almost nobody names a variable exactly key — it will be apiKey, API_KEY, secretKey, and a plain search for key finds none of them.

Read the lines that come back rather than glancing at them. One of them hands a long random string to a name, in a file that is about to be shared, backed up or committed. That is question 1 catching exactly what it exists to catch, in about ten seconds.

When you have finished, run cat send-digest.js and read the whole file. There is a second thing in it worth a question: one line prints your entire reading list to the console every time the digest runs. Harmless on your own machine, and not something you want left in the moment anyone else can read those logs.

The short version

Print this, or keep it in your notes file:

1. Secrets in the code?
2. Anything deleted or overwritten? Recoverable?
3. Anything paid? How often does it run?
4. Who can reach it, and change it?
5. What was added — dependencies, files?
6. What changed that I did not ask about?

Two minutes. It is the difference between vibe coding as a party trick and vibe coding as something you can trust with real work.