Rhys Brett-Bowen Coding in the age of AI

Appendix — the techniques, tested

These are the moves I actually reach for, pulled from my own session logs — not a tips list, a tested one. A few kinds of receipt sit behind them, and I’ve marked which is which: some were put through a quick with-vs-without A/B (I give the n); most were earned in the making of this essay (marked from the build); and one comes from a separate coding project. Either way the evidence is directional — small n, often one judge, scenarios I built myself — so read that limit once, here, and take the verdicts as a starting map, not settled science. Each comes with a Try: — the actual words I’d type, not a template to fill in. I’ve kept the failures. A technique that backfired is a more useful entry than one nobody checked, which is this whole essay pointed at its own toolkit.

Start here — the 60-second version

Two halves to this, and only one belongs in the machine.

The machine’s half — freeze in the small checklist. Put the following rules somewhere your agent always reads. They do not make the model smarter; they make it less likely to skip the checks you would have wanted it to run.

## Decision quality
On a non-trivial or hard-to-reverse decision, a user correction, or a repeated
failed fix, apply these checks before committing:

1. Verify what exists. Before proposing a new abstraction, file, dependency,
   or approach, confirm the existing system cannot already do it.
2. Name assumptions with confidence: high / medium / low. Flag any low-confidence
   assumption that would change the answer if wrong.
3. Trace consequences in practice: rollout, maintenance, consumer impact, and
   what breaks at 3 a.m.

Lead with a recommendation. If uncertain, recommend the option safest to be
wrong about and say why. For genuinely irreversible decisions with missing
context, "pause — here are the options; don't choose yet" is itself a
recommendation.

## Decisions
Authoritative decisions live in the source — the spec, this file, the code — not in chat.
When something changes, update the source and mark it "SUPERSEDES: <old>". Re-read the
source before acting; a change mentioned only in conversation is a suggestion, not a decision.

## Review
For review that matters, get a second opinion from a DIFFERENT model — not more personas in
this session. Same-model agreement is weak signal; what's useful is where two models disagree.
It's evidence you weigh, not a verdict you hand off.

## Summaries
Treat any summary — a subagent's report, a test digest, your own recap — as a claim, not a
fact. Before acting on its key detail, check it against the raw. Fluency is not correctness.

## Long sessions
When a thread has run long, prefer a fresh session seeded from the source-of-truth file over
carrying full history. Re-ground from the artifact, not the conversation's memory of it.

## Scoping — order, not whether
For work you want done anyway, the only question is sequence; the axis is coupling, and the cost to
price is the human's downstream cost (which doesn't parallelize), not your effort. Do independent,
obviously-mechanical work now, in parallel — it's cheap, and deferred it's the stuff you lose (you
misjudge quick work as unimportant, so your "skip it" read is the unreliable part). Leave work coupled
to a still-unsettled hard call — doing it now is rework when the call lands; let the hard path incubate,
and absent a real deadline don't rush it. Review the settled state once. The context-switch tax
isn't loop length — it's leaving with a full head, several half-resolved forks to keep warm; so the
cheap place to stop is a clean seam, forks closed and the next task standing on its own. A
heuristic, not a law: it only has to beat the default, and genuine urgency still jumps the queue.

Your half — nobody installs this. Three moves carry most of it. Brief for a conversation, not compliance — put your real thinking in (not a one-line wish), and get the machine questioning it rather than just executing. Rough idea or finished plan, the move is the same: make sure something pushes back before it’s built, because it won’t always come for free. Treat everything it hands back as a claim, not a fact, and check the load-bearing parts against the raw: fluency isn’t correctness. And keep asking whether you’re still solving the right problem, not just whether the output looks good — that’s the one call that never delegates.

The one that licenses the rest

The ones that earned it

These overlap and double back in practice — a kit, not a sequence.

The ones that only sometimes help

The ones still unproven — interesting, not earned

The one I had to test five times

Step back, look upstream, change the problem — a checklist nudge that helps only where the default would skip the step.

The first tests said it failed. The next said it worked. Both were too tidy, which should always make you nervous. The problem was the test: I kept handing the model the code that already revealed the root cause. Once it can see the N+1 query, “look upstream” adds nothing — and tips into over-engineering.

The move is for a different moment — before you show the code, when you’re about to prescribe the fix yourself: “my endpoint’s slow, add a cache,” and the model can’t see the root either.

Tested there — four band-aid requests, five reps each, blind cross-family judge — the nudge made the model question the band-aid 20 of 20 times. But the plain model already does it 12 of 20; it won’t blindly build a famous anti-pattern. The nudge’s real value is the cases it flips, and they cluster on the dangerous, less-obvious one: a flaky-charge retry. Unprompted, all five reps wrote the retry loop; prompted, all five blocked on idempotency first. On a charge call, that’s the difference between a double-charge bug and not.

Try: “before you build that, what’s the actual root?” — but only before the code’s in front of the model. Once it can see the root itself, the nudge is on probation.

(Five designs to pin it down; final = 4 scenarios × 5 reps, blind cross-family COMPLY/QUESTION classification, matched by my own read 40/40. The mechanism is this essay’s own: a checklist item that fires the step you’d otherwise skip. Full notes in the research.)

The ones you’ve already seen

If you’ve read a “prompt like a pro” post, you’ve met the carousel: RAIN, CLAR, FLOW, PIVO, SEED, CRAFT — a new acronym a month, plus spin-offs (CRAFTe, CREATE). Line them up and it’s the same handful of pieces re-lettered — the labor goes into the initials, not the idea. None of the pieces are new: it’s retrieval, few-shot, a persona, and an output spec with the serial numbers filed off.

But before sorting them, notice what they’re all for: the transmissive use — getting the model to do a task you could have specified yourself. The constructive use — brainstorming, reaching a thought you couldn’t alone — runs on a different rule: give it the problem, the constraints, the uncertainty, but don’t hand it a finished answer disguised as a spec, or it just polishes the idea you walked in with (see Don’t lead, and the transmissive/constructive split the essay opens with). Everything below is for the transmissive mode; here’s what each piece actually changes.

Change what you get back:

Change how it’s delivered, not whether it’s right:

Helps you give the model a clear task:

Theater:

So the honest version of the whole carousel is short: give it the context it lacks, show an example when the shape isn’t obvious, name a real opinionated persona if perspective matters, and say what shape you want back. The rest is you briefing yourself, and even done perfectly, it’s the floor. What moves the needle sits upstream of the prompt — the thinking you put in, the pushback you invite before it builds, the answer you reject. The catch: a cleanly stated task is what convinces you it’s the right task. Use the checklist if it helps — just don’t mistake it for the brief.

No Try: here — this one maps the pieces, it isn’t a move.

The honest size of all this

The failures are kept on purpose. The upstream-redirect nudge is the one I trusted least, so I tested it — and then four more times, because each result was either tidy-and-suspicious or measured in the wrong condition. The fifth test finally put it where the move is actually used — a band-aid request with the code unseen — and the hit reproduced: it reliably catches the band-aid the model would otherwise just build, most valuably the dangerous one. Five rounds to earn one honest, qualified verdict. That sequence — tidy, suspicious, reversed, reversed again, finally tested right — is this essay’s whole argument happening to its own appendix. An untested technique that sounds good is the fluent-but-unchecked thing the essay warns against; so is a tested one whose tidy number you don’t interrogate. That’s why even the embarrassing results stay in — and why the clean ones get the asterisk too. The clean result was never the prize; the honest one is.