---
title: "I Built the Review Tool, Then Told Everyone to Stop Using It."
canonical: https://dxdev.com/blog/2026-06-26_the-tool-nobody-was-using/
datePublished: 2026-06-26
---
I had twelve unanswered questions and a tool I had built specifically so a colleague wouldn't have to answer them in a ticket comment. They answered most of the important ones in a ticket comment anyway.

## A gate that mattered

We were heading into a major overhaul with real money logic riding on it. The plan had four tiers of decisions, and the riskiest tier stayed frozen until a reviewer signed off, on purpose. A wrong call there wouldn't just look different. It would change what customers were charged.

To make that review usable, I built a tool that laid the plan out by tier and walked a reviewer through the open questions in order. I also pointed straight at it in a ticket comment. The idea was simple: read it, answer the grouped questions, unlock the next tier.

## The answer showed up somewhere else

The colleague reviewing the plan answered the highest-stakes questions correctly, including a real contradiction buried in the brief that could have gone either way. They just did it inline in the ticket, not inside the tool.

That distinction is the whole story. It would have been easy to read this as an incomplete review and keep steering the conversation back to the interface. But nothing about the tool had actually stopped anyone. No error, no missing button, no confusing layout. The review was happening. It was happening in the ticket instead of in the place I'd built for it.

## Three options, and only one that respected the evidence

I could have kept pointing back at the tool. That preserves a tidy record, but it makes progress depend on someone changing a habit that was already working for them.

I could have rebuilt the tool until it felt easier than replying to a comment. That was tempting precisely because I'd built the first version. It also solves a problem that wasn't actually there. Nothing about the interface was the obstacle. The reviewer had simply picked the channel with less friction, and a better interface doesn't fix a channel that was never broken.

So I copied the remaining open questions, including the named contradiction, into a fresh comment and asked for answers there. The structure stayed. The requirement to use my tool didn't.

## What the tool was actually for

The tool wasn't wasted effort. Forcing the plan into four tiers with an explicit gate is what made it possible to notice, quickly, that the real decisions were already being made somewhere else. Without that structure, the review would have been a looser conversation with no clear sense of what was actually still open.

## Where AI fit, and where it stopped

Noticing that the diagnostic signal was the location of the answer, not its content, is a pattern an AI agent can flag reliably: here is where the process says the decision should happen, here is where it's actually happening, and here is what would be lost if you only looked in one place. It can also carry the unresolved structure, the tiers, the named contradiction, into whichever channel is actually in use.

Deciding to drop a mandatory gate on money-sensitive work is not a call to hand to a tool. That decision, and confirming the contradiction was actually resolved correctly rather than just answered somewhere, stayed with a person.

## The lesson

The Build Log companion breaks down the three options I weighed and why two of them lost. The rule that survived: when someone works around a tool you built for them, using a channel that costs them less effort, treat that as a measurement, not a complaint to argue with. Keep whatever the tool was protecting, the decision list, the gate, the named risk, and drop the requirement to use a specific interface if that's the only part nobody actually needs.