Free to read · no account needed

16 min · code

Ask the model for tests (not just code)

Goal: Get small tests that prove a fix before you trust the patch—so you are not pasting mystery code into production.

Best for: Beginners who get code dumps with no way to check.

Models love to “helpfully” rewrite half your file. Flip the order: tests first, patch second, and only after you approve the tests. Include at least one check you can run by hand without a framework.

Ask the model for tests that fail on the bug first—then for the fix. Tests-after-the-patch often rubber-stamp the patch.

Keep the failing tests even if you discard the model’s first patch. Tests are the asset; the patch is disposable.

Why beginners skip this

Skipping the hard part of “Ask the model for tests (not just code)” feels fine until a live thread pays the bill. Hold: Failing test first; patch second; you run the proof—date a refuse-line this week, or nothing changed Mid-week cost shows up as rework, not as a missing bookmark.

Step 1 — Tests-first ask

Do this step with a real artifact open—not from memory.

Before any fix:
1) Propose 3 tests (input → expected output)
2) Mark which I can run manually without a framework
3) Wait for my OK
Only after I approve tests, suggest the smallest patch.
Do not refactor unrelated code.

Step 2 — Date-parse bug

Example

Filled prompt

Bug: webhook retries double-charge in staging only.
Demand: failing test that reproduces double-post, then minimal patch.
I run the test before merge. No "trust me" patches.

What good output looks like

  • Names files/functions you provided for “Get small tests that prove a fix before you trust ”
  • No secrets in logs; no mystery whole-repo rewrite
  • Explain-before-patch or minimal repro respected
  • Pass/fail: you can restate the change in 3 bullets

Step 3 — You run one test for real

Do not rubber-stamp. Run the manual case. If it fails, paste the failure back—do not ask for a bigger rewrite yet.

Manual test failed: input X expected Y got Z. Adjust the smallest patch only. Do not add new features.
Example

Filled prompt

Review these tests for tautologies (tests that only mirror the new patch lines).
Paste: [tests asserting exact new if-branch text].
Flag which tests prove behavior vs which only echo the patch.

What good output looks like

  • No secrets in logs; no mystery whole-repo rewrite
  • Explain-before-patch or minimal repro respected
  • Pass/fail: you can restate the change in 3 bullets
  • Names files/functions you provided for “Get small tests that prove a fix before you trust ”

Save this card

Card: Failing test first; patch second; you run the proof—date a refuse-line this week, or nothing changed. Keep this beside the tool; read before you start.

1. What I shipped: ___ 2. What I refused: ___ 3. What I will never-do again: ___ (date: Asia/Shanghai)

  • [ ] Tools/writes paused
  • [ ] Refuse-line dated
  • [ ] Artifact path saved
  • [ ] Next link chosen (or stop)

Before you start

Open the failing test, diff, or ticket for “Get small tests that prove a fix before you.” Keep secrets out of the chat. Have the file path you will name. Guide: code-tests-with-the-model. If you only have a blank practice box, stop and fetch the real job first.

  • Goal in one line: ___
  • Allowed tools: ___
  • Forbidden: ___
  • Human approve needed for: ___

How to use this week

This week in code: get one small test that proves a fix before you merge; refuse tests that invent APIs you don’t have on a live artifact—not a blank demo. Write one refuse-line and date the note (Asia/Shanghai). If you only skimmed code-tests-with-the-model, put 25 minutes on the calendar and redo once.

Keep it real

Run this guide’s Practice now on work you will actually ship this week—not a fictional scenario. Dated notes beat perfect theory.

Ship the practice

Close the tab only after Practice now is done on a real artifact.

Do not bookmark-only

Finish Practice now, then tick this guide on your path. Titles unread are not skills.

Close the loop

After Practice now, write one line: what you will refuse next time. That line is the habit.

Example

Filled prompt

Live artifact this week for: Get small tests that prove a fix before you trust the patch—so you are not pasting mystery
Name real files/people. No invented facts; label Unknowns; stop before send/delete.
Return working prompt + one pass/fail check I can mark in a minute.

What good output looks like

  • Explain-before-patch or minimal repro respected
  • Names files/functions you provided for “Get small tests that prove a fix before you trust ”
  • Pass/fail: you can restate the change in 3 bullets
  • No secrets in logs; no mystery whole-repo rewrite

Red flag

Merge without tests; tests calling APIs you do not have; model editing tests to match a bad fix—stop.

Pitfalls

PitfallFix
Accepting code before testsHard rule: tests → OK → patch
Framework-only tests you cannot run yetDemand one manual case
“While we’re here” refactorsBan unrelated edits
Trusting the model’s “all tests pass”You run them
Example

Filled prompt

Temptation: skip the habit for code-tests-with-the-model to “save five minutes.”
Job still: Get small tests that prove a fix before you
Do the smallest correct pass: Done visible · one checkable artifact · Unknowns labeled [?].
Boundaries: draft only; no silent send; no invented metrics.
Return: the artifact + the refuse-line you said aloud.

What good output looks like

  • Names the shortcut you refused (specific to code-tests-with-the-model)
  • Still delivers a checkable artifact for “Get small tests that prove a fix before you”
  • Unknowns labeled; draft-only respected
  • Pass/fail: refuse-line written and dated (code-tests-with-the-model #4)

Practice now

Live card: one real code change under “Ask the model for tests (not just code)”—diff-only + test note (Asia/Shanghai).

Today: paste one real bug + minimal repro. Demand: (1) failing test sketch (2) then minimal patch. Reject a patch with no test. Run or mentally simulate the test.

Today card (copy) — code-tests-with-the-model: 1. Artifact I will produce: ___ 2. Pass/fail check: ___ 3. Refuse-line if tempted to skip verify/send: ___ (date: Asia/Shanghai) 4. One never-do from this guide: ___

  • [ ] Artifact path written
  • [ ] Refuse example would say "yes"
  • [ ] Dated Asia/Shanghai

One sentence takeaway

Failing test first; patch second; you run the proof—date a refuse-line this week, or nothing changed

  • You can point to a dated refuse-line
  • You have one artifact path from tonight
  • You can teach the red flag in one sentence

Next

Explain then change · PR description · Minimal repro · Code path · Coding agent boundaries

Pair with today: open the first Next link (code-explain-then-change) only after you dated a refuse-line for this guide (Asia/Shanghai).

← Back to home · Learn · Tools · Compare · Start