Anti-patterns: failing while the code looks fine

The candidate who did everything right, fast

A candidate moves fast and looks great: prompts fluently, accepts the output, ships, everything’s green, and they talk confidently the entire time. It reads like a star performance. They get a no.

Predict, before reading on: what did the interviewer see that the candidate didn’t? The speed was ungoverned, the green was happy-path, and the confident talk was narration of a process with no committed standard underneath. Every signal that looked like a virtue was its look-alike anti-pattern — and the follow-up question is what told them apart.

The four anti-patterns

Each has a behavioural tell, and each is a loop stage skipped:

• Copy-paste automation — accepting AI output without comprehending it. Tell: can’t explain a line when asked. Skips: review (Ch 5).
• Prompt theater — iterating prompts until something passes, with no committed theory of what “right” is. Tell: no preregistration; tests written after the code. Skips: preregistration (Ch 3).
• Automation bias — trusting the model over your own contradicting check. Tell: “the AI said so” as a reason. Skips: verification / comprehension (Ch 5–6).
• The velocity trap — optimizing the speed of producing output over the defensibility of what ships. Tell: fast, but can’t be defended under questioning. Skips: the gate (Ch 6).

The unifying diagnosis: an anti-pattern is a loop stage you skipped, dressed up as productivity. That’s also the cure — name the missing stage and put it back.

Contrasting cases

The teaching move is to put each anti-pattern beside the virtue it imitates, because the difference is never the surface behaviour — it’s whether a committed standard and real comprehension sit behind it:

| Looks like… | Virtue (standard + comprehension behind it) | Anti-pattern (costume only) | | --- | --- | --- | | Moving fast | Governed velocity — clarified, preregistered, verified in the time | Velocity trap — “done” means the demo ran | | Iterating on a prompt | Steering toward preregistered invariants | Prompt theater — tuning until handed-down tests pass | | Trusting the output | Justified trust after a check | Automation bias — trust instead of a check | | Accepting clean code | Accepted because you read and verified it | Copy-paste automation — accepted because it looked fine |

Predict which side of the line each case falls on:

In every pair the observable action is identical; only the committed standard behind it differs. That is the whole diagnostic.

Why they’re rewarded short-term

The reason these are hard to resist is that they work — at first. Copy-pasted code runs; the prompt-theater output passes the demo; the trusted model is usually right; the fast feature ships. The cost is deferred to a later moment: the boundary input in production, the follow-up question you can’t answer, the incident with no provenance. By the time the bill arrives, the behaviour has been reinforced many times.

Interviews exist, in part, to compress that timeline. The follow-up question (“what does this do on empty input?”), the un-one-shottable problem, the request to explain a line — each pulls the deferred cost into the room, in minutes instead of months. That’s why these anti-patterns are a favorite probe: they’re invisible on the happy path and obvious one question past it. Resisting them means valuing the deferred cost now — which is exactly the judgment the loop encodes.

How this is graded

• Communication (weighted) — you don’t perform the anti-patterns (false confidence, fluent talk over unread code); your narration tracks genuine judgment, which is the gap interviewers probe.
• Technical Correctness — you resolve contradictions instead of deferring (no automation bias), so what you claim about the code is true.
• Trade-off Awareness — you recognize ungoverned velocity for what it is and can name the deferred cost you’re choosing to pay or avoid.
• Evaluation Rigor — you have a committed standard, which is precisely what turns prompt theater back into steering.

Industry variation

• Startups — the velocity trap is the endemic risk; the senior skill is naming which speed is debt (skip the polish, never skip the gate on the core).
• Big tech — prompt theater fails code review, and automation bias in a scaled system turns one unchecked output into a wide blast radius.
• Regulated (fintech, health) — automation bias plus no provenance is a compliance failure, not just a bug; “the AI decided” is not an acceptable audit answer.
• Frontier labs — copy-paste automation of AI-written research code produces subtle method bugs (a wrong axis, a leaked label) that run cleanly and invalidate results.

Stretch: the anti-patterns compound at scale

Everything here gets worse when the AI works across many files and runs as an agent: ungoverned automation that’s a nuisance in one function becomes a systemic risk across a repo, where you can’t read every line. Before the next chapter: if you can’t review everything an agent produces, what do you govern instead — and where do you put the checkpoints?

Next: Chapter 9 — Agentic workflows, where the loop scales from a single function to multi-file, agent-driven work, and governance becomes a question of checkpoints and gates.