← Anti-Patterns · Headliner
Prompt & Pray
Vague prompts. Accepted output. Hoping the architecture is sane.
What it is
The team has a vague goal, types it into the chat, gets back something that compiles, and ships it. The architecture wasn’t designed — it was negotiated with a token predictor.
How it happens
Time pressure plus AI confidence. The prompt is two sentences. The output is three hundred lines. It runs, the tests are green (because the AI also wrote the tests), and the PR description is “Implements X.” Nobody asked the harder question first: what does “X” actually mean in this codebase?
Warning signs
- “It works” is the only justification given for the design.
- PRs include code patterns the author can’t explain.
- The same problem is solved differently in different places — sometimes within the same PR.
- The change introduces real structure (a module, an API, a job, a data shape) and the only written record of intent is the chat history.
- “Why did you do it this way?” → “That’s what the AI did.”
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 generic, designed for the median codebase, not yours. Six months in, you’re maintaining a codebase that nobody actually designed, and the only person who could explain it has moved on to the next prompt.
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 if it’s three paragraphs in a scratch doc. 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 your brief before any code is generated catches more “wait, that’s not what I meant” than any amount of post-hoc review.
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. One or two paragraphs: 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 prove understanding. Not “Implements X.” The actual decisions, the alternatives considered, the tradeoffs made. AI can draft this too — but the author has to be able to defend every claim in it. The PR description is the audit trail. If the author can’t explain a choice, it goes back, no matter how clean the diff looks.
- Reviews that ask “why this approach,” not “does it work.” The compile-and-tests-green bar has collapsed in the AI era — anything passes that. What can’t pass is “explain the design decision behind this section.” When the answer is “that’s what the AI did,” that’s the signal to send it back.
The shift is: the brief, the PR description, and the review aren’t bureaucratic overhead — they are the engineering work. Code generation is the cheap part now. Everything around it is where the judgment lives.