Skip to content
Smitster Data
← All resources

Agentic code review that engineers actually trust

Past a certain size, human review becomes the bottleneck in a dbt estate. Here's the pattern I use for AI review that cites its sources, takes pushback seriously, and costs little enough to run on every pull request.

#ai#mcp#engineering#architecture

The problem

Past a few thousand dbt models and a few dozen contributors, human code review becomes the constraint on delivery. Reviewer bandwidth doesn’t scale with the rate of change, and when timelines tighten, the quality gate is the first thing to quietly give way. Everyone knows this. The usual response is to lower the review standard and not say so out loud.

AI review is the obvious answer and it mostly disappoints, because most implementations are a prompt wrapped around a diff. That produces confident, unsourced comments that engineers learn to dismiss within a fortnight. Once a reviewer is ignored, it is worse than no reviewer at all — it adds noise and a false sense of coverage.

What makes it work

The model is the easy part. The framework around it is where these systems earn or lose trust.

Cite the rule, every time. Every comment should point at a specific entry in a maintained knowledge base. This is the single decision that separates a tool engineers respect from a black box they route around. It also makes the system auditable — you can ask why a comment was made and get an answer.

Let developers argue back. A reviewer that can’t be challenged isn’t a reviewer, it’s a gate. When a developer pushes back, the agent should re-check the objection against the rule it originally cited, verify whether the work is genuinely complete, and then either stand down or hold its ground with reasoning. Holding its ground matters as much as standing down.

Budget the context window deliberately. I use Python’s tokenizer to pack as much relevant rule and diff context into the window as the budget allows. Naive truncation is why AI reviews miss the obvious thing three files over.

Deduplicate across passes. Nothing kills adoption faster than the same finding reappearing on every push. Track what has already been raised and stay quiet about it.

Put real logic underneath. Rule enforcement, context assembly and review orchestration belong in code you control, not in a prompt. The model is one component in the system, not the system.

On cost

This only works if it runs on every pull request, and that means per-review cost has to be near-negligible. The right choice is the cheapest model that clears the capability bar — for this kind of structured, rule-grounded review, a small model like GPT-5-mini via Copilot CLI is more than sufficient. Reaching for a frontier model here buys you very little and prices you out of running it everywhere, which is the only place the value is.

Why it matters

Most “AI for data platforms” conversations stop at a chatbot bolted onto a warehouse. The more durable pattern is agents that participate in the actual engineering workflow — citing the rule behind every comment, taking pushback seriously, and running cheaply enough to sit on every change — without lowering the bar a human reviewer would hold.

Get started

Want this kind of read on your own platform?

These write-ups come out of real engagements. Send me a few lines about your stack and I'll reply with the same kind of read.

Request a Consultation