A reviewer pulls up your pull request three weeks after you merged it. They were not in the room when the choice was made. The model that wrote half of it has been deprecated. The Slack thread is gone. The only thing left is the code, the tests, and whatever record you kept of the decision. Defensibility is the property that decides whether that reviewer can trust the work.
Why this matters
A senior engineer is paid to make decisions under uncertainty and to be answerable for them later. AI pairs do not change that contract. They change the shape of the evidence trail. The diff used to encode the decision; now the diff encodes the outcome and the decision lives in a conversation you may not have kept. Hiring panels, code reviewers, and on-call rotations all converge on the same question: can this engineer reconstruct the reasoning? Engineers who can do this stay employable as models get better. Engineers who cannot, end up shipping code they did not understand and cannot maintain.
What does "defensible" actually mean here?
Defensibility is not eloquence. It is not confidence. It is the property of a piece of work that lets a competent reviewer, without you in the room, answer four questions: what problem was being solved, what the alternatives were, why this option was chosen, and how the choice would be revised given new information. A defensible decision survives a reviewer disagreeing with it. An indefensible decision collapses on the first pushback because there was never a reason underneath it, only a generated answer that looked right.
In our scoring v2.6, defensibility is one of six weighted rubric dimensions. The radar below shows how it stacks up against the others when we ask the narrower question: which dimension best predicts a hire decision at the senior bar, averaged across panel reviewers in Q1–Q2 2026.
Correctness sits below defensibility because almost every shortlisted candidate writes code that runs. The discriminating signal lives one layer up: the candidate who can explain why the runnable code is the right code.
Why is this harder in the AI era — not easier?
Three years ago, the diff was the record. You wrote the code, so you remembered the reasoning. In 2026 the diff is the artefact of a conversation, and the conversation is usually thrown away. The engineer reads the suggestion, accepts it, runs it, and moves on. The mental model that used to form while typing now forms while reading — if it forms at all.
This is the trap. AI pairs raise the floor on what gets shipped. They lower the floor on what the engineer can explain. Most engineers do not notice the gap until a senior reviewer asks why the retry budget is three, or why the cache key includes the tenant id, or why the migration is reversible. Those are the moments where a junior engineer says "the AI suggested it" and a senior engineer says "because the upstream timeout is 1.5s and three retries fit inside our 5s SLO with margin."
The fix is not to use AI less. It is to add a step where you reconstruct the reasoning out loud before you ship. We call it a replay review, and the data below shows what eight weeks of it does to defensibility scores.
The cadence matters more than the volume. Engineers who reviewed one decision per week beat engineers who reviewed eight in a single monthly session. The skill is a habit, not a study sprint.
How do you practice defensibility on your own?
You do not need a panel reviewer to practice. You need a structured prompt and a quiet hour. The five questions in the table below are the ones we use in the Hard tier replay session, condensed into a self-review you can run on any merged PR. Pick one PR per week. Answer all five. Compare what a junior engineer would say to what a senior engineer would say.
| Question | Junior answer | Senior answer |
|---|---|---|
| What problem does this code solve? | It fixes the bug in the issue. | It fixes a class of bugs where stale tenant scoping leaks across cached reads. The reported issue is one symptom. |
| What alternatives did you consider? | The AI suggested this approach. | Two. A read-through cache with tenant in the key, and a write-through invalidation. We chose the former because invalidation broke under our replication lag. |
| What would have to change for this to be the wrong choice? | Not sure. | If tenant cardinality grows past 100k the key space gets expensive. We have a metric on cache size that triggers a re-design at 80k. |
| What is the blast radius if this is wrong? | It would have to be reverted. | Cache pollution for the affected tenants until TTL. No data corruption. Revert is one PR, rollback in under fifteen minutes. |
| How would you know it is wrong in production? | Tests would fail. | A cross-tenant read alarm fires on a Prom histogram we added in this PR. Without that alarm, we would not detect this for hours. |
If you can answer all five without consulting the chat history, the work is defensible. If you cannot, the work is not yours yet — it is the model's, and you are the courier.
What does a panel reviewer score, exactly?
Panel reviewers are not grading creativity or speed. They are grading whether the engineer can hold a position under pressure and change it when the evidence is good. The five questions above map almost one-to-one to the panel rubric. The reviewer asks question one. If the answer is shallow, they ask follow-ups until the engineer either deepens the answer or runs out of road. The score is calibrated against inter-rater agreement of 0.81 on the Hard tier, which means two reviewers grading the same replay agree on the defensibility score within one point on a ten-point scale, four times out of five.
The behaviour we score highest is changing a position when the reviewer raises a point the engineer had not considered. A defensible engineer is not a stubborn engineer. The score rewards the update, not the original answer.
The full v2.6 rubric, inter-rater agreement numbers, and the methodology behind defensibility scoring.
From Codritium Research
The Defensibility Rubric, 2026
The public scoring rubric behind every Codritium benchmark and certification: six weighted dimensions, twelve task categories, inter-rater agreement, and a frozen reference quarter.
Common questions
Is defensibility just communication skills?
No. Communication is the surface. Defensibility is the property of the work itself — the reasoning is either present or it is not. A clear speaker with no reasoning underneath fails the rubric. A quiet engineer who can write the reasoning down passes it.
Can you train this in a sprint?
Not durably. Our 16-week cohort data shows engineers who practiced weekly grew by 37 points on average; engineers who practiced in a single dense session grew by 15 and regressed by week 12. The skill is a habit.
Does it matter at junior level?
Yes — for a different reason. Junior engineers are not expected to defend architecture choices, but they are expected to defend why they accepted a model's suggestion. Reviewers at the junior tier score AI-rejection rate and replay clarity heavily.
How do you measure your own defensibility?
Run the five-question self-review on three of your last PRs. If you can answer all five for each PR without checking history or asking the model, your defensibility score is above the median for your level.
What if you're shy?
Defensibility is mostly written. Replay reviews are async by default — engineers annotate the diff, the reviewer reads it, and the conversation happens in markdown. Spoken defence is a separate Hard-tier component and does not dominate the score.
Where to go next
- Read the full rubric: The Defensibility Rubric, 2026
- See where AI pairs introduce the most indefensible code: Where AI pair programming fails
- Practice with a Hard-tier replay challenge in the Codritium challenge catalog