In the last post I argued that intent drift is the gap between what a diff compiles to and what a ticket asked for. This post is about how codingassist.bot closes that gap with six independent reasoning planes.
The problem with a master prompt
When you ask a single LLM "is this PR good?", you get a single LLM's opinion — and worse, you get a different opinion every time you ask. We took a different shape: six independent planes, each scoped to one question, each emitting a typed signal. There is no master prompt.
One PR, six signals
Take a PR that adds an email-update flow. Here's what each plane sees:
| Plane | Question | Signal |
|---|---|---|
| Intent | Does the diff satisfy the ticket's ACs? | warn — AC1 unbound at high confidence |
| Contract | Does it preserve public APIs? | info — new helper, no breaking signature change |
| Semantic | What call sites does this touch? | info — 3 call sites, all in email/ |
| Tests | Coverage delta? | warn — new branch on line 35 not covered |
| Security | New trust-boundary crossings? | info — none |
| Perf | Worst-case complexity? | info — O(1) DB call added |
Two warns, four infos. The orchestrator rolls these up into T3 — Reviewable, with the trace pointing at AC1 and the uncovered branch.
Why determinism matters
Every plane runs at temperature: 0 with a seeded sample. The output schema is validated; non-conformant outputs are rejected and re-asked at a higher token budget. The ReviewContext is content-addressed. Identical inputs produce the same verdict, every time.
The whole chain — context bundle, six signals, orchestrated verdict — is signed and stored. When compliance asks why we approved change X, we open the trace and move on.
What's next
In future posts I'll go deeper on each plane. For now, if you want the architecture in detail, read The 3-stage pipeline — that page's diagram is worth a thousand of mine.