DEV Community: Pluto

Stop asking AI to “write tests for this” — 5 prompt changes that make generated tests catch bugs

Pluto — Wed, 14 Oct 2026 02:40:01 +0000

AI coding tools can write a test file in seconds. Most developers have also noticed the catch: the tests are green, coverage goes up, and a real bug ships straight through them.

That usually isn’t the model being bad at testing. It’s the prompt leaving out everything that makes a test valuable. Here are five changes I now make to every testing prompt — in Cursor, Claude Code, ChatGPT or Copilot Chat — and why each one matters.

1. Give it the intent, not just the code

If the only input is the implementation, the implementation becomes the spec. The model reads what the code does and asserts exactly that — including any bug.

Add one or two sentences of intent, in your own words:

What this code is supposed to do:
prorate() returns the charge for the unused part of a billing period,
rounded half-up to cents. It never returns a negative amount.

Now the model has something to test against. If it notices the code can return a negative amount, it has a reason to flag it instead of pinning it.

2. Ask for a plan before any code

“Write tests” invites volume. Ask for a behaviour inventory and a case table first:

Before writing any code:
1. List every observable behaviour (return values, errors, side effects, branches).
   Mark anything that looks like a bug with [SUSPECT].
2. For each behaviour, list cases: happy path, boundaries (empty, zero, one, max,
   off-by-one), invalid input, error paths.
Show me both. Then write the tests.

A case table takes ten seconds to review. If the boundaries or error paths are missing, you see it immediately — instead of discovering it in 300 lines of generated code.

3. Attach one existing test file

Describing your conventions (“we use Vitest, factories live in tests/factories, we name tests like…”) works poorly. Showing them works well:

Conventions to copy: tests/billing/invoice.test.ts
Match its imports, helpers, file location and naming.

This one line stops most of the “new assertion library, different folder, duplicate fixtures” problems.

4. Write the rules the model would otherwise break

Models take the shortest path to green. State the boundaries explicitly:

Rules:
- Do not change production code to make tests pass. If the code seems wrong, report it.
- Expected values must be hand-computed literals, not the same formula as the code.
- Only stub true boundaries: clock, randomness, network, third-party APIs.
- No fixed sleeps. Freeze time and seed randomness explicitly.

The second rule alone removes a whole class of “mirror tests” — tests that agree with the implementation by construction and can never fail for the reason you care about.

5. Make it justify every test

End with a self-check:

For each test, state in one line the specific bug it would catch.
Delete any test whose answer is "none" or "same as another test".
List behaviours from the case table that still have no test.

Then do the human version: break the code on purpose (flip a < to <=, return early) and see whether anything goes red. If nothing does, the tests are decoration.

Different jobs need different prompts

The five changes above are the skeleton. The process section should change with the job:

Integration/API tests: rank scenarios by risk — contract, validation, auth (including another tenant’s resource), persistence, idempotency, downstream failure — and forbid mocking the database.
E2E: separate checkpoints worth asserting from incidental UI, use role/label locators, and ask for an explicit flake review.
Legacy code: write characterization tests that pin current behaviour, bugs included, before you change anything.
Flaky tests: ask for ranked hypotheses with evidence and a reproduction step. Retries and longer sleeps are not fixes.
Coverage: treat the percentage as one input to a risk-based plan, not the goal.

The shape that works

Every good testing prompt I use has the same five parts:

Part	Purpose
Role	“Senior engineer writing tests a skeptical reviewer will accept”
Context	Target, intent/spec, framework, one example test, what not to touch
Process	Numbered steps, plan before code
Output contract	Exact sections and tables to return
Rules	The shortcuts the model must not take

Try it on a function you know well. If the case table finds an edge case you hadn’t written down, it’s working.

I packaged the eight prompts I use for this — unit, spec-first, integration/API, E2E, characterization, flaky diagnosis, coverage planning and mock boundaries — plus two checklists, a Cursor rule and a PDF guide, as the **AI Test Generation Prompt Pack: https://lirenplr.gumroad.com/l/cuofwr. Everything above works without it.

— Pluto · @Mars_Peakul

Stop asking AI to "review this PR" — use a risk map instead

Pluto — Tue, 13 Oct 2026 14:03:00 +0000

If you paste a pull request into ChatGPT, Claude, Cursor, or Copilot Chat and say “review this,” you usually get:

a summary of what the diff already shows
a handful of style opinions
a generic reminder about “validating inputs”
a friendly “looks good overall”

That is not a review. That is a book report.

After enough of those, people either stop using AI for review or — worse — start treating the essay as approval.

What actually goes wrong

No intent. Without one sentence on why the change exists, the model cannot tell a deliberate behaviour change from a bug.

No priority. Naming nits compete with authz bugs for the same paragraph budget.

No output contract. Free-form prose hides severity. You want Must fix / Should fix / Nit, locations, and a verdict.

Equal time for unequal risk. Renames and payment-path changes should not get the same depth.

A better default loop

Use four steps:

Diff + intent — skim --stat, write one sentence of purpose.
Risk map — ask the model only which areas deserve depth (auth, money, migrations, public API, supply chain, hot paths).
Deep dives — new prompts (or new turns) on those areas: security, tests, API breaks, migrations, etc.
Human verdict — dedupe, drop wrong nits, you own merge.

The important part is splitting map from deep dive. One mega-prompt on a 3k-line PR burns context and produces shallow commentary.

A skeleton that works across tools

You can adapt this in Cursor, Claude Code, ChatGPT, or Copilot Chat:

You are a senior engineer doing a pre-merge review. Do not edit files.

## Context
- Intent: <one sentence>
- Diffstat: <paste>
- Risk notes: <auth? migration? public API?>

## Process
1. Risk map (area → why → files)
2. Correctness vs intent
3. Security (authz, injection, secrets)
4. Tests (new behaviour covered? tests weakened?)
5. Only then maintainability that hides real risk

## Output
### Risk map
### Findings (Must fix / Should fix / Nit, with path:line, why, fix)
### Verdict: Approve | Approve with nits | Request changes
### Open questions

Do not invent issues. If nothing serious, say so.

Keep the output contract. It is doing more work than the adjectives in the role line.

Specialist passes beat one giant checklist

Once you have a risk map, fan out:

Trust boundary → security threat model + Pass/Fail evidence
Behaviour change → behaviour↔test matrix (watch for deleted or loosened tests)
Schema → expand/contract and lock risk
Manifest/lockfile → necessity and install scripts, not only audit noise

You rarely need every pass. Two deep dives on the real risks beat eight shallow ones.

Team norms that keep this healthy

Human owns merge. The model is a junior reviewer, not a gate bot.
Shared severity words. Must fix means blocks merge.
Read-only review chats. Implement fixes in a separate turn so “findings” do not silently become a rewrite.
Authors can paste a risk map into the PR to save reviewers’ discovery time — without requiring them to accept every nit.

Privacy reminder

If your company forbids pasting code into a given tool, these prompts do not override that. Use whatever surface policy allows (including self-hosted options).

Soft close

I’ve been packaging this loop as a small set of copy-paste prompts and checklists (full PR, security, performance, tests, API, migrations, frontend a11y, dependencies) for people who already live in AI coding tools and just want reviews that surface real risk.

If you try the risk-map-first skeleton above on your next non-trivial PR, watch whether the Must-fix list gets shorter and more serious. That feedback loop matters more than any tool brand.

— Pluto · @Mars_Peakul

One AGENTS.md to rule Claude Code, Cursor and Codex

Pluto — Tue, 13 Oct 2026 06:48:38 +0000

If you use more than one AI coding agent, you've probably ended up with three instruction files: a CLAUDE.md for Claude Code, a pile of .cursor/rules for Cursor, and an AGENTS.md for Codex. They start out identical. A month later one still says npm, another says pnpm, and the third forgot that tests live next to the code.

That's how instruction files drift apart. The fix is simple: make AGENTS.md the single source of truth and keep every tool-specific file thin. This post shows the layout, how each tool actually picks up AGENTS.md, and a template you can copy.

The layout

your-repo/
├── AGENTS.md            # canonical: commands, layout, conventions, definition of done
├── CLAUDE.md            # "@AGENTS.md" + Claude-only notes
├── .claude/
│   ├── settings.json    # permissions + hooks
│   ├── agents/          # subagents
│   └── skills/          # procedures that load on demand
├── .cursor/
│   ├── rules/           # .mdc rules, with the core rule pointing at AGENTS.md
│   └── cli.json         # permissions for the `agent` CLI
├── .cursorignore
└── .codex/
    ├── config.toml      # sandbox + approval defaults
    └── agents/          # custom agents

AGENTS.md holds everything every agent needs. The other files hold only what is specific to one tool: its behaviour, permissions and features.

How each tool picks up AGENTS.md

This is the part people get wrong, because the three tools load it differently.

Codex builds an instruction chain once per run. It starts with the global file (~/.codex/AGENTS.override.md or AGENTS.md), then walks every directory from the project root down to your working directory. In each one it checks AGENTS.override.md, then AGENTS.md, then any project_doc_fallback_filenames, and takes at most one file per directory. Files closer to your working directory come later, so they win when instructions conflict. The combined chain has a default size cap of 32 KiB, and Codex stops adding files once it reaches it.

Cursor supports AGENTS.md in the root and in subdirectories. Nested files combine with their parents, and the more specific instructions take precedence.

Claude Code has the catch. It reads AGENTS.md directly only when there's no CLAUDE.md or CLAUDE.local.md in the working directory or above. Once you add a CLAUDE.md, put an import at the top so both load:

# CLAUDE.md
@AGENTS.md

A personal, uncommitted CLAUDE.local.md also counts as "a CLAUDE.md exists". So even if you never create a project CLAUDE.md, adding a local one silently stops Claude reading AGENTS.md. Keep the explicit @AGENTS.md import and that can't happen.

The canonical AGENTS.md

Here's a trimmed version of the template I use. Replace the placeholders with your own stack.

# AGENTS.md

## Project snapshot
- What it is: <one sentence>
- Main language / runtime: <TypeScript 5, Node 22>
- Package manager: <pnpm>. Do not use any other package manager.
- Layout:
  - `apps/web/`: frontend
  - `apps/api/`: HTTP API (handlers in `apps/api/src/handlers/`)
  - `packages/db/`: schema + migrations

## Commands
- Install: `<pnpm install>`
- Unit tests (fast, run often): `<pnpm test>`
- Single test file: `<pnpm test -- path/to/file.test.ts>`
- Lint + types: `<pnpm lint && pnpm typecheck>`
- Build: `<pnpm build>`

## Conventions
- Named exports, no default exports.
- Errors: return `{ code, message }` objects from services; never throw raw strings.
- New code needs tests next to it (`*.test.ts`).

## Working agreement
1. Restate the task in one or two lines and list the files you expect to touch before editing.
2. Make the smallest change that solves the task. No drive-by refactors.
3. If requirements are ambiguous, stop and ask. Do not guess on behaviour.
4. Never commit secrets, tokens, or `.env*` files.
5. Do not run `git push`, `git reset --hard`, `git clean -fd`, force-pushes,
   or destructive DB commands unless explicitly asked.

## Definition of done
- [ ] Lint + types pass
- [ ] Tests pass (and a new test covers the change)
- [ ] Diff is limited to files related to the task
- [ ] Short summary: what changed, why, how it was verified, open risks

## Code Review Rules
- Flag any handler that reads request input without validation.
- Flag SQL built with string concatenation.

Why it's built this way

Commands come first because wrong commands cause most wasted agent turns: npm instead of pnpm, or the wrong test runner. The single-file test command also saves tokens, since the agent stops running the whole suite on every iteration.
The working agreement turns common failure modes, like silent scope creep and guessing, into explicit rules.
The definition of done gives every agent the same exit criteria. Without it you get "Done!" while the tests still fail.
## Code Review Rules is a heading Codex's GitHub code review looks for, so the review guidance comes along for free.

Keep it short. Leave formatting checks to CI, not the rule file. And write instructions the agent can verify: "Run pnpm test before finishing" works better than "test your changes".

The thin files

CLAUDE.md

# CLAUDE.md: project instructions for Claude Code
<!-- Keep this file under ~200 lines. HTML comments are stripped before Claude sees them. -->

@AGENTS.md

## Claude Code specifics
- Use plan mode before touching more than 3 files.
- For searches that would flood the context, delegate to a subagent
  and ask for a summary with file paths.
- Before calling a task done, run the checks in "Definition of done"
  and paste the command output summary.

## Things that went wrong before
- Do not "fix" failing tests by loosening assertions or adding `.skip`.

Two details: imports are relative to CLAUDE.md and can nest up to four hops. Block-level HTML comments are stripped before injection, so notes for humans cost no context. Run /context to confirm which memory files actually loaded.

.cursor/rules/00-core.mdc

Cursor project rules must be .mdc files in .cursor/rules/. A plain .md file there is ignored. The always-on core rule just points to AGENTS.md and adds a few hard limits:

---
description: "Core working agreement for every Agent chat in this repo"
alwaysApply: true
---

- Follow `AGENTS.md` at the repo root for commands, layout and definition of done.
- Before editing, list the files you plan to change. Keep the diff limited to the task.
- Never read, print, or edit `.env*`, `*.pem`, `*.key` or credential files.
- Finish every task with: what changed, how you verified it (exact commands), open risks.

Stack-specific rules go in separate .mdc files that attach by globs, so they only cost tokens when a matching file is in context.

.codex/config.toml

Codex instructions come from AGENTS.md. Behaviour (sandbox, approvals, subagents) lives in config.toml:

approval_policy = "on-request"
sandbox_mode = "workspace-write"
web_search = "cached"

[agents]
max_concurrent_threads_per_session = 4

Codex loads a project's .codex/ layers only when you trust the project.

When the agent "ignores" the rules

If an agent ignores your conventions, the cause is almost always that the rule file is too long, vague or contradictory, or wasn't loaded at all. Check before rewriting anything:

Claude Code: /context and /memory
Codex: /status
Cursor: Customize → Rules

Then shorten the file, make the instructions verifiable, and remove conflicts. One canonical file makes that much easier, because there's only one place to fix.

Wrap-up

AGENTS.md is canonical. CLAUDE.md and .cursor/rules stay thin and point to it.
In CLAUDE.md, always add an explicit @AGENTS.md import.
Put commands first, use verifiable instructions, and give every agent the same definition of done.
Keep tool behaviour (permissions, sandbox, hooks) in each tool's own config, not in the instructions.

Free excerpt: https://lirenplr.gumroad.com/l/zocmzn

This article is adapted from the **AI Coding Agent Workflow Pack: a 37-page guide plus a drop-in template bundle (the full AGENTS.md, CLAUDE.md, all four Cursor rule types, Codex config, 10 copy-paste workflows and a security checklist). Every file name and flag was checked against the official docs in October 2026. Get it on Gumroad ($24). I post tested agent workflows as @Mars_Peakul on X.