← Anti-Patterns · Headliner
Prompt & Pray
AI-generated code can run on the first try and still solve the wrong problem.
What it is
Prompt-and-pray coding is shipping AI-generated code from an underspecified request without first deciding its behavior, boundaries, or acceptance criteria. The architecture wasn’t designed — the model filled in the missing decisions.
How it happens
A request such as “add refunds to the API” leaves the important decisions unstated. Can a pending payment be refunded? What response does a second refund request get? The AI fills those gaps with plausible defaults, then writes tests around the behavior it chose. The endpoint runs, the suite is green, and the PR says “Implements refunds.” This is an illustrative example, but the missed question is real: what does this feature have to mean in this system?
The tell is a structural change whose only record of intent is the chat history. The author can show that it works, but cannot say why this data shape, error response, or module boundary fits the product. The next prompt sees those choices as established conventions and repeats them.
Why it’s dangerous
You inherit the AI’s defaults for every architecture decision it made on your behalf. Those defaults aren’t malicious — they’re plausible patterns drawn from the available context, which may miss your product’s rules. A later AI session treats the generated choices as established patterns and spreads them into the next feature. The cost is borne by whoever must reconcile inconsistent behavior after customers and integrations already depend on it. AI can also make the repair cheaper — once a human states the intended boundary and gives it a testable contract.
How to prevent it
Match the rigor of the brief to the stakes of the change. Tweaking a string or fixing a typo? Just say what you want. Introducing real structure — a module, an API, a workflow, a data model — write down the intent first, even in a short note. That brief becomes two things at once: the context you prompt with, and the standard reviewers measure the output against.
AI doesn’t replace the brief — it makes both writing it and using it cheaper. Asking AI to challenge the brief before implementation can surface missing assumptions before they become code.
The serious team fix
Three things, reinforcing each other:
- A brief-first habit for any work with structural consequences. Not for every prompt — for any change that introduces a new module, API, workflow, or data shape. Record what we’re building, for whom, with what data, and how we’ll know it’s correct. Have AI draft it, then have AI poke holes in it. Then prompt with the result.
- PR descriptions that explain decisions. Not “Implements X.” The actual decisions, the alternatives considered, the tradeoffs made. AI can draft this too — but the author should understand the important structural choices. The PR description records that rationale for future maintainers. If a key choice cannot be explained, resolve it before merging.
- Contract checks that outlive the chat. Put the agreed response shapes, authorization rules, and important edge cases into tests or a machine-checked API contract. Have AI generate implementation against that artifact, then let CI catch a later prompt that drifts from it. Reviewers can focus on the remaining design tradeoffs instead of rediscovering the brief.
The shift is: decide what the code must do, then let AI build it against a durable contract. Code generation is the cheap part now. The decisions it cannot infer are the engineering work.