At 6:56 p.m., we had 12 unanswered design questions and a review tool we had built so another developer would not have to answer them in a ticket comment.
We were preparing a major tab overhaul. The work had a four-tier design brief, 16 open decisions, and a deliberate coding gate: Tier 2 and above stayed blocked until the reviewer signed off. Tier 4 contained the billing and credit logic, so we kept that part frozen until the state machine was settled. A wrong answer there would turn a visual rewrite into a behavior change with money attached.
The review tool was meant to make that gate usable. It put the brief in one place, grouped questions by tier, and gave the reviewer a structured route through the decisions. We posted a ticket comment that pointed straight at it. The intended sequence: read the brief, answer the grouped questions, lock a tier, let implementation advance.
What the first reply looked like
The first response did not look like a failure. The other developer had answered enough questions to settle the major Tier 4 billing calls. They were reviewing the work. They just did it inline in the ticket instead of in the tool.
Our first move was the wrong one. We read it as incomplete sign-off and kept steering them back to the interface. We had built the tool, so we kept offering it. That cost us time against a gate that was holding up everything from Tier 2 up, and it added nothing, because the review had already moved to the ticket, where the discussion was happening.
Once we looked at what was actually unanswered, the tool stopped being the question. Nothing was trapped behind a broken screen, a missing control or a confusing tier layout. The remaining questions covered visual polish, labels, scope, and one contradiction that could not be waved away:
Tier 4
- Does voiding an item unlock credit?
The current brief contains rules that imply both answers.
That was the work. It needed an answer, and a better destination would not have produced one.
Moving the questions to where the reviewer was
We copied the remaining questions into one fresh ticket comment and told the other developer to answer there. The structured tool stayed available, but it stopped being the gate to progress.
The comment kept the shape that mattered. Each unresolved decision was explicit. The contradiction was named. The scope and label questions were separated from the billing rules. Nothing technical disappeared when we dropped the delivery mechanism.
What the tool was still good for
We still think the tool was worth building. It forced the four-tier brief into a durable form and made the dependency visible: no state-machine decision, no Tier 4 implementation. Without it, the first pass would have been a looser conversation, and we would have had less clarity about what remained open.
But an internal tool has to earn its place in the critical path. A reviewer answering in the ticket was still reviewing, through the channel with the least switching cost. Treating the tool as mandatory at that point would have turned a coordination aid into a delay.
So we kept the decision list, the tiers, the gate and the contradiction, and made the interface optional. That evening, the fastest way to use our review tool was to stop asking anyone to use it.
When a review stalls, check where the reviewer is already answering before you rebuild the tool meant to collect the answers. Here that meant the major Tier 4 billing calls were already settled in the ticket, and the rest only needed a single comment to carry them.
AI Skills
Use this lesson with the AI assistant you already use
A structured review tool built specifically to route a colleague through a tiered set of design decisions was quietly bypassed when the colleague answered the critical questions correctly, just inline in the ticket instead, and the right response was to drop the tool as a gate, not fix or defend it.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: A reviewer answering in a ticket comment instead of your purpose-built tool is not resisting review, it is diagnostic information about actual friction
SOURCE: dxdev.com/blog/know-when-to-abandon-your-own-tool
WHAT HAPPENED: A structured review tool was built to route a colleague through a tiered set of design decisions gating a major feature's implementation, grouping questions by tier and giving a clear sequence toward unlocking coding work. The colleague answered most of the critical, money-sensitive questions correctly, just inline in the ticket comment thread rather than in the tool. The options were to keep steering them back into the tool, which would optimize for the artifact rather than the actual decision, or to rebuild the tool until it felt easier than a ticket reply, which was rejected because no error, missing control, or confusing layout had actually stopped the review; the reviewer had simply chosen the channel with the least switching cost. The remaining unanswered questions, including one real contradiction in the brief, were copied into a fresh ticket comment, and the tool was dropped as a required gate while remaining available for anyone who wanted it.
THE RULE: An internal tool has to earn its place in the critical path; when someone routes around it using a channel with lower switching cost, that is diagnostic information about the actual friction, not resistance to be overcome, and the fix is often to preserve the underlying structure, the decision list, the gate, the named contradiction, while dropping the interface requirement, rather than pushing people toward the tool or rebuilding it.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Any mandatory internal tool or interface where people are already accomplishing the same task through an alternate channel, such as a comment or a chat message, with equal or better completeness.
2. Any decision to improve or rebuild a tool's usability in response to low adoption, without first confirming the tool's interface, rather than the underlying task, is actually what people are avoiding.
3. Any process gate that conflates the tool, the delivery mechanism, with the substance, the decision or structure, it was meant to capture, risking that abandoning the tool loses the substance too.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
Lesson: A reviewer answering in a ticket comment instead of your purpose-built tool is not resisting review, it is diagnostic information about actual friction
