Most prompt advice is folklore. People share what worked once, on one model, on one task, and call it a pattern. Over 2025 and into 2026 we ran twenty-four candidate patterns against paired sessions on the Codritium rubric. Some moved scores. Some didn't. A few made things worse. This post extracts the practical part: which framings hold up, when to use them, and how to combine them without canceling their effect.
Why this matters
Every team we audit has internal prompt rituals. Some are load-bearing. Most aren't. The cost of the wrong ritual isn't just wasted tokens — it's a shared belief that an output is high quality because the right incantation preceded it. That shows up downstream as confident merges of regressed code. The point of an A/B benchmark isn't to crown the best pattern. It's to take the question "does this thing do anything" out of the realm of taste.
What makes a pattern actually work?
A pattern earns its place when it changes the shape of what the model produces, not the vibe of it. The patterns that moved our rubric all did one of three things: forced an explicit plan before code, constrained the search space with a worked example, or seeded a rejection criterion the model had to test against.
We sorted the twenty-four candidates into six categories. The split below shows how the population was distributed — not how well each category performed. Performance comes later.
The interesting result: category alone predicts almost nothing. Within Persona, "Senior staff engineer at a payments company" showed no effect; within the same category, "Reviewer who will reject any change that touches three or more files" moved defensibility by 7.2 points. Specificity beats archetype.
The forest plot below shows the top eight patterns by effect size on the composite rubric. The reference line is zero — a confidence interval that crosses it means we can't distinguish the pattern from doing nothing.
Which patterns are folklore — they sound good but show no effect?
Three popular framings showed no measurable effect once we controlled for task type. The first is the senior-engineer persona by itself. Telling a model to "act as a staff engineer" without a downstream constraint doesn't change its output. The second is tone-only constraints — "be concise," "be rigorous," "be careful." These move surface style and nothing else. The third is what we call confidence priming — phrases like "you are an expert" or "this is critical." Effect size: indistinguishable from zero.
The honest read here is that persona without specificity is decorative. A model doesn't become more cautious because it's told to be cautious. It becomes more cautious because it's told what to reject and how to know.
When does a pattern's effect flip negative?
This is where the benchmark stops being a leaderboard and starts being a manual. Two patterns flipped sign across contexts. Anti-example prompts — "do not solve it with a global mutex, do not use a busy loop" — moved correctness positively on greenfield problems and negatively on legacy refactors. The reason looks straightforward in the replays: in legacy code, the anti-examples were often shaped like the code that was already there, and the model started rewriting working code to avoid resembling the forbidden shape.
The other sign-flip was Decomposition without checkpoints. Asking the model to break a problem into steps without then evaluating each step produced more verbose, less defensible outputs. Decomposition only works when paired with a stop-and-verify loop.
| Pattern | Category | Defensibility effect | When to use | When NOT to use |
|---|---|---|---|---|
| Plan-then-code | Decomposition | +8.4 pts | Multi-file changes, design-shaped problems | Trivial one-liners — overhead dominates |
| Decomposition w/ checkpoints | Decomposition | +7.9 pts | Long-horizon refactors and migrations | Without an actual stop-and-verify loop |
| Worked-example seeding | Example-driven | +6.2 pts | Unfamiliar APIs, internal frameworks | When your example encodes a bad pattern |
| Rejection-criteria first | Reflection | +5.7 pts | Code reviews, security-sensitive changes | Exploratory prototyping — slows you down |
| Anti-pattern list | Anti-example | +4.4 pts (greenfield) / −2.1 pts (legacy) | Greenfield code, new modules | Refactors of code that resembles the anti-pattern |
| Senior-engineer persona | Persona | ~0 pts | If you enjoy typing | As your only framing — it isn't doing anything |
How do you stack patterns without canceling them?
Stacking is where engineers most often hurt themselves. Two patterns combined typically add. Three is the inflection point. Four or more degrades correctness measurably — the model spends its attention satisfying the prompt instead of solving the problem.
The combinations that held up share a property: each pattern does a different job. Plan-then-code structures the answer; Worked-example seeding constrains the style; Rejection-criteria first creates a test the answer must pass. None of those conflict. By contrast, stacking two Persona patterns and a tone constraint adds zero new information — they're all pulling on the same lever.
A safe rule, based on the replays: stack at most one pattern per category, and never combine two from Persona. If you need more structure than three patterns can carry, you don't have a prompt problem — you have a problem-decomposition problem.
The full A/B benchmark across 24 patterns, 8,640 paired sessions, and the v2.6 rubric.
From Codritium Research
The Prompt Pattern Library, 2026
Twenty-four prompt patterns, A/B-tested against the rubric. Which framings move correctness, regression, and defensibility — and which don't. Effect sizes with confidence intervals, paired results, and adoption rates.
Common questions
Are these patterns model-specific?
Effect sizes shifted by 10–25% across frontier models in our 2026 cohort, but the rank order was stable. Plan-then-code and Decomposition-with-checkpoints were top-two on every model tested. Senior-engineer persona showed no effect on any of them.
What if my AI tool doesn't support a feature like custom system prompts?
Every winning pattern in this study was implemented as plain text in a single message. None required system prompts, tool schemas, or vendor-specific features. If you can paste a paragraph, you can run them.
How long does adoption take?
In our internal team studies, engineers reached steady-state usage within two weeks. The hard part isn't learning the patterns — it's unlearning the folklore ones, especially Persona-only framings, which feel productive because they're easy.
Should I use the same patterns in interviews?
Rejection-criteria first and Plan-then-code translate directly. Anti-example lists do not — most live interviews don't give you enough context for the anti-examples to be specific enough to matter. Use them in take-homes, skip them live.
Do these patterns generalize across languages?
Yes, with one caveat: Worked-example seeding had a larger effect in statically typed languages than in dynamically typed ones, where the model already had less ambiguity to resolve. The other top patterns were language-independent within our sample.
Where to go next
- The Prompt Pattern Library 2026 — full method and per-pattern detail
- Where AI Pair Programming Fails — the failure modes these patterns are designed to prevent
- The Defensibility Rubric 2026 — the scoring instrument used in this benchmark