Your Coding Agent Will Ship the Wrong Feature Perfectly — And Never Once Question It

Agentic tools never made your decisions better. What they did was stop giving bad ones three weeks to hide before anyone noticed. That's the real story behind the speed — not that you ship faster, but that judgment has nowhere left to hide.

The scene: correct code, bad decision

Here's the scene. An engineer prompts an agent: build bulk export for the admin dashboard. Twenty minutes later there's working code — tests green, button renders, CSV downloads. It ships that afternoon. Two weeks later, support tickets start piling up. Turns out nobody wanted bulk export. What they wanted was to stop re-running the same filtered report every single Monday. The code was correct. The feature was wrong. Sit with that distinction for a second — this isn't "we shipped a bug." It's "we shipped the wrong thing, cleanly, on the first try."

The inversion: slowness used to be a forcing function

Before agents, a bad idea usually didn't survive contact with reality — not because anyone was especially disciplined, but because delivery was slow enough to give reality a shot. A feature took three days to build. Somewhere in those three days — standup, a stray Slack thread, a PM glancing sideways at the ticket, a reviewer asking "wait, why are we doing this again" — someone reopened the premise almost by accident. Slowness was a bug in the process. It just happened to double as a safety net. Agents rip the net out without touching the fall. The premise never gets reopened, because there's no gap left for anyone to stumble into it.

The mechanism: agents close the question, they don't reopen it

A coding agent takes "build X" as settled, closed, done — and optimizes execution against it. It will interrogate implementation details relentlessly: edge cases, types, error handling, all of it, because that's the domain it was told to work in. What it won't do is ask "should this exist" or "is X even the right answer to the actual problem." Nobody scoped that as its job. And nobody handed it to a human either, because the human's job just got compressed down to typing the prompt. The agent is a phenomenal executor of a decision and has exactly zero opinion on whether the decision was right. That gap used to get filled by elapsed time. Now it gets filled by nothing — unless you fill it yourself.

A PhoenixDX example: the unasked question

At PhoenixDX, one of our teams agent-built a "retry failed webhook" admin action in under an hour — button, backend call, audit log entry, done, merged the same day. We unwound it a week later. The skipped step wasn't "we should've done more research." It was one specific question nobody asked: what happens to the three downstream systems that already reacted to the original failure? Nobody asked it because there was no natural pause left to ask it in — the build moved too fast to trigger the reflex. The fix wasn't a slower process. It was making that question mandatory before the prompt, not after the merge.

The excuse that's now gone

"We didn't have time to explore alternatives" used to be a legitimate excuse. Throughput was real, and building three options instead of one cost real time. Agents collapsed that cost. Spinning up two competing implementations, or just spending ten minutes writing down the alternative before you build the first one, costs almost nothing now. Which means when a shipped feature turns out to be wrong, it doesn't trace back to capacity anymore. It traces back to an assumption nobody bothered to examine — because examining it was optional, building was fast, and the team defaulted to building.

The tell: write the bet before you write the prompt

Here's the concrete practice for Day 12. Before you type the prompt, write one sentence: the bet this feature is testing, and the result that would make you kill it. Not a spec. Not a ticket. One sentence each.

Bet: Admins will use bulk export to stop manually re-running Monday reports.
Kill condition: If fewer than 20% of admins use it in 2 weeks, remove it and
talk to the 3 support tickets that requested it instead.

Bet: Retrying a failed webhook is safe because downstream systems are idempotent.
Kill condition: If any downstream system double-processes on retry, this ships
behind a manual confirmation step, not a one-click button.

If you can't write that sentence, the honest read isn't "we're moving fast." It's that you're skipping discovery on purpose and using the agent's speed as cover so nobody notices — including you. The agent will build whatever you hand it either way. That one sentence is the only thing standing between velocity and shipping the wrong thing quickly.

Judgment is now the naked metric

Velocity used to be the scoreboard because velocity was scarce. Now it's cheap — which means it quietly stopped being what separates teams that ship well from teams that just ship fast in the wrong direction. What's left exposed, once speed stops being the bottleneck, is judgment: the ability to state a bet, name a kill condition, and know which questions the agent will never think to ask on its own. That's not a soft skill bolted onto engineering anymore. It's the actual skill this course is training. Not better prompting. Better deciding.

Extend your knowledge

• ▹For one week, write the bet-and-kill-condition sentence before every agent prompt you write for a new feature — not for bug fixes, just new capability — and see how many times you can't finish the sentence.
• ▹Look up Teresa Torres's continuous discovery habits framework — it predates agents but describes exactly the discovery muscle that agentic delivery speed now demands you exercise deliberately instead of by accident.
• ▹Look up John Cutler's writing on the 'feature factory' pattern — agentic tools make it trivially easy to become a much faster feature factory if discovery isn't separately enforced.
• ▹Audit your last three agent-built features that shipped without a written premise, and name the specific question that went unasked in each — not 'we should've done research,' the actual question.