Most workflow guides skip the part where the codebase fights back. The setup that wins on a clean repo collapses two weeks into a real codebase, when the model is suggesting helpers that no longer exist and the engineer is accepting them at 11pm. This tutorial gives you the seven steps in order, the rules that keep them working under load, and the measurement loop that tells you the setup is paying off.
What you'll have at the end
By the time you finish this tutorial you will have three named prompt patterns saved in your tool, a written autonomy floor that tells you which actions you will never let the model take unattended, a replay-capture rule that fires on every non-trivial change, a weekly review slot on your calendar, and a single dashboard tile showing rejection rate trending over time. The setup takes about three hours up front and roughly twenty minutes a week to maintain. The output is a workflow that holds up when the codebase fights back.
Before you start
You need three things: an AI coding tool with autonomy settings you can configure (cursor-class or claude-class is fine); commit access to a real codebase you are responsible for, not a scratch repo; and a way to capture the replay — Codritium's replay primitive, an org-supplied alternative, or at minimum a Markdown file you append to per session. You also need fifteen minutes of read time on the rubric before you start, because the calibration step in month two assumes you've seen it.
The seven steps
The seven steps go in order. Each step's output is the next step's input. Doing them out of order leaves you with a setup that looks complete and fails silently.
How to
Pick your three pattern primitives
Choose exactly three reusable prompt patterns and name them. Three is the sweet spot — fewer leaves gaps, more becomes unmaintained. Good defaults: a 'plan-before-code' pattern that produces a short plan you can argue with, a 'unit-test-first' pattern that drafts tests before the implementation, and an 'explain-this-diff' pattern that walks a reviewer through the change. Save them in your tool's prompt library with the same names you will use in code review.
Configure the AI tool's autonomy floor
Write down the actions the model will never take unattended in your repo. The floor — what is forbidden — matters more than the ceiling. Typical floor items: no destructive file operations, no migrations without human sign-off, no production config changes, no secrets in chat. Configure these in the tool's settings or via a pre-commit gate. If the tool can't enforce the floor, you do not have a floor.
Define your replay capture rule
Decide when you capture a replay. The rule should be 'every non-trivial change' — and trivial is defined narrowly. A typo fix is trivial. A retry budget change is not. The rule must be automatic; if it depends on you remembering, it will not survive the first late evening. If you're on Codritium, replay capture is on by default; if not, append a structured note to a session log file with the prompts and the decisions.
Establish the rejection-tracking habit
Track AI-rejection rate weekly, not per session. The unit is a rejection event: an accepted AI suggestion that a reviewer later rejected or revised. Count them in your weekly review and divide by the suggestions you accepted that week. The number is more useful as a trend than as a value; aim for stability, not a target.
Set the regression test gate
Wire up a pre-merge test gate that runs the full test suite plus a focused subset relevant to AI-touched files. Block merge on regression. This step is the second line of defence behind your autonomy floor; the floor catches what should not happen, the gate catches what happened anyway. If you don't have full test coverage, scope the gate to the files the AI touched in this PR.
Schedule weekly review
Put a 20-minute slot on your calendar — same day, same time — to review the week's rejection rate, regression rate, and one replay you flagged for re-reading. The slot has to recur or it will not happen. Bring the numbers to the review, not to the chat afterwards. A reviewer disagreeing with you is the cheapest form of calibration available.
Calibrate against the rubric monthly
Once a month, score one of your own replays against the published rubric. The scoring takes 30 minutes. The point is not to know your score — it is to notice the dimensions where you are drifting. Defensibility and replay clarity drift first; correctness and spec fidelity drift last. Adjust your three prompt patterns based on which dimension drifted, not based on which one feels off.
Why this workflow holds up under a real codebase
The workflow is opinionated about one thing: feedback-loop length. Every step shortens a loop. Patterns shorten the loop between an intent and a usable prompt. The autonomy floor shortens the loop between a bad suggestion and an enforcement action. Replay capture shortens the loop between a decision and the artefact a reviewer will need to evaluate it. Rejection tracking shortens the loop between an in-the-room judgment and the downstream consequence. Monthly calibration shortens the loop between drift and correction. A workflow that depends on a long memory or a long retro is a workflow that collapses the first time a real bug hits production at 3am. The pipeline below shows the stages the workflow rides on top of — the Codritium scoring pipeline that grades the artefacts the workflow produces.
You will not run a panel review every week. You will run the first three stages — session, solve, defend — every week, and the rest opportunistically when you submit work for review or hire-loop practice. The point of using the same vocabulary your reviewer uses is that you do not have to translate when the time comes.
How to adapt it to your team
The seven steps were written for a single engineer. Teams change two things. First, prompt patterns become shared assets — usually three patterns per team, not three per engineer. Second, calibration becomes someone's job. On a team of three, that is a rotating role; on a team of fifteen, it is a named owner who runs the monthly rubric session for everyone. The autonomy floor is the only step that scales linearly with people — you need it just as much when you're alone as when you're on a team of thirty, because the engineer accepting the suggestion is one person at a time, regardless of org chart. The chart below shows roughly how long each step takes per week at different team sizes.
| Team size | Pattern ownership | Autonomy floor | Calibration owner |
|---|---|---|---|
| 1 (solo) | Three personal patterns. | Personal floor in tool settings. | Yourself, monthly. |
| 2–5 | Three shared patterns + one personal each. | Shared floor in repo settings; personal overrides. | Rotating monthly owner. |
| 6–15 | Three to five shared patterns, versioned. | Org floor enforced via pre-commit and CI. | Named owner; 60-minute monthly session. |
| 16+ | Patterns owned by a platform sub-team. | Org floor + per-team overlays. | Calibration squad; quarterly publish of drift report. |
The full catalogue of prompt patterns we use to seed the three-pattern step, with per-pattern hit rates from the 2026 benchmark.
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
Does this work for solo developers?
Yes — and arguably better. Solo developers see the rejection-rate signal faster because there is no team noise. The only adaptation is the calibration step: you are your own calibration owner, and 30 minutes a month is enough.
How long until I see the gain?
The autonomy floor and the test gate pay back inside two weeks. Replay capture and rejection tracking start to pay back at week four to six, when you have enough sessions to see the trend. The monthly calibration starts to pay back at month two.
What if my tool doesn't support feature X?
Most of the steps survive a tool change. The two exceptions are the autonomy floor — you need a tool with configurable autonomy or an external pre-commit gate — and the replay capture, which needs at least a structured log file. Everything else is process, not tooling.
Can I skip step 6?
No. The weekly review is the only step where the numbers turn into decisions. Skipping it means you are collecting data without acting on it, which produces a workflow that looks measured but is not. If you can only keep three steps, keep 2, 6, and 7.
How do I measure if it's working?
Two numbers, weekly: rejection rate and regression rate. Plot both for eight weeks. If rejection rate is stable or declining and regression rate is flat or down, the workflow is paying off. If rejection rate is rising and regression is rising with it, something in the autonomy floor or the patterns needs revision.
Does this make me slower?
Yes, by about twenty minutes a week, plus the monthly calibration. The trade is a lower rejection rate and a lower regression rate, both of which compound across the quarter. The math holds up at month two; before that the overhead looks larger than it is.
Where to go next
- Read the patterns we recommend: AI pair programming patterns that work
- Read the pattern benchmark: Prompt pattern library, 2026
- Practice in the Codritium challenge catalog
- Background reading: Vibe coding to production workflow