Stop asking your AI agent to be careful — give it a checklist

Talk to anyone using an AI coding agent for more than a week and you'll hear some version of this complaint:

"I told it to be careful. It still deleted my migration file."

The agent is not being lazy. It's not ignoring you. The instruction "be careful" is just not actionable. It carries no information the agent can act on. Careful about what? In what direction? Compared to what baseline? The agent has no shared definition of careful, so it does whatever feels reasonable in the moment, which sometimes turns out to be deleting your migration file.

There's a better pattern. It's the pattern senior engineers use when they hand a task to a junior. It's not "be careful." It's a checklist.

What "careful" actually means in your head

When you tell a colleague "be careful with the migration," what you actually mean is something like this:

• Don't drop tables that exist in production.
• Don't rename columns without a backfill plan.
• Don't change types in a way that requires a data conversion.
• If you must do any of the above, propose it first and wait for sign-off.
• Make the migration reversible — every up has a down.
• Test the migration on a copy of production data before applying.

Six items. Each one is concrete. Each one can be checked.

When you say "be careful," you're hoping the colleague reads your mind and arrives at the same six items. With a human you've worked with for years, that often works. With an AI agent — and frankly with most new colleagues — it doesn't.

The fix is to write the checklist down

This is the entire premise behind the Vibe Coder's Guide skills. The skill bundle is, in effect, sixty or seventy concrete checklists across seventeen skill files. The agent reads the relevant checklist before acting. The user doesn't have to remember to say "be careful about X, Y, Z." The checklist already named X, Y, Z.

For example, in the security skill (sub-skill 10), one of the checklists looks roughly like this:

Backend lockdown (only if a separate backend exists):

1. CORS allowlist — never *. Configure CORS to allow exactly the deployed frontend origins.
2. Origin/Referer verification on state-changing requests.
3. Auth tokens scoped to the frontend domain. Cookies SameSite=Strict or Lax, Secure.
4. Don't expose API surface in production. Disable Swagger/OpenAPI docs unless gated.

The agent reads this. The agent then audits the codebase against it. The user gets a report: "Items 1 and 4 are not done. I'll fix them. Item 2 isn't applicable because all your routes are GETs. Item 3 is done correctly."

That's a different conversation than "be careful with security."

How to write a good checklist

Three rules.

One — every item is binary. Either it's done or it isn't. "Make sure performance is good" is not binary. "Lighthouse Performance score is at least 90 on mobile" is binary.

Two — every item is observable. The agent (or anyone) can verify whether the item is true without asking the user. "Make sure the user has a good experience" is not observable. "404 page exists at /404 and renders the site's brand colors" is observable.

Three — order them in the sequence you'd execute. A checklist is a script. The reader does item 1, then item 2, then item 3. If items can be done in any order, fine, but if there's a sequence (e.g., set up the env vars before running the build), the checklist needs to enforce it.

Together, these three rules make a checklist auditable. You can hand it to anyone — agent or junior dev or senior dev or yourself a year later — and they'll do the same thing.

What to do with this today

Pick one task you keep having to redo with your agent. Write down, on paper or in a notes app, the checklist you wish the agent would follow.

Examples I've used:

Before any commit. Run the linter. Run the typechecker. Run the relevant tests. If any fail, do not commit. If all pass, commit with a message that names the file and the change in active voice. Push only after I've reviewed the diff in the terminal.

Before any deploy. Confirm .env.local is in .gitignore. Confirm no secret strings in the diff. Run the production build locally. Confirm the production build doesn't reference localhost. Sync to the prod bucket. Invalidate the CDN. Curl the prod URL and confirm 200.

Before any database migration. Read the existing migrations to see the schema. Propose the migration in plain English first and wait for my approval. Generate the up and down. Test on the local SQLite. Apply to staging. Confirm I see the expected data shape. Apply to production only after I say go.

Each of these takes maybe two minutes to write down. Each one converts a category of mistake your agent makes into a category of mistake your agent never makes again.

The Vibe Coder's Guide is the same idea, scaled up to "everything an MVP needs." Seventeen skills, each a checklist. Run the agent through them and you ship something good. The checklists do the careful for you.

Stop saying "be careful." Write down what careful means. Hand the agent the list.

← All posts