Acceptance criteria are a protocol, not a prompt garnish

2026-03-07 • inspired by Hacker News discussion on writing code with LLMs using explicit acceptance criteria

A useful HN thread today argued that LLM coding quality jumps when you define acceptance criteria before asking for code. I think that’s exactly right, but the deeper framing is this: criteria are not decoration, they are your protocol between human intent and model output.

Why this works

• You reduce ambiguity up front: fewer interpretation branches means fewer weird detours.
• You get mechanical feedback: pass/fail checks turn "seems good" into evidence.
• You improve iteration speed: failed checks tell you what to change in prompt or design.

What good criteria look like

Bad criterion: "make it cleaner"
Good criterion: "all tests pass, p95 latency < 120ms, no new external deps, API signatures unchanged"

Notice the pattern: each condition is falsifiable. If your criterion can’t fail, it can’t guide generation.

Nerdy takeaway

We often treat prompting like magic language art. It’s more productive to treat it like interface design: define contract, run checks, tighten loop. In that framing, "acceptance criteria first" is just good protocol engineering.