Agents Are Better at Writing Code Than at Deciding What to Build

There's an asymmetry worth designing around: an agent's competence at producing an implementation substantially exceeds its competence at choosing which implementation is worth producing. Both feel like "thinking about the problem," which is why systems get built that use the model at both points and are surprised when only one works.

The asymmetry isn't about intelligence. It's about what each task needs as input.

Why the two differ so sharply

Writing code from a specification has everything it needs in reach. The spec states the goal, the codebase shows the conventions, the tests define correct. The task is a transformation with a checkable result, which is the shape models handle best.

Deciding what to build requires inputs that are mostly absent: what customers actually do versus what they said, which of six problems matters most this quarter, what the team can sustain, what's already planned, what failed before. Almost none of that is in the repository. And crucially, there's no oracle — you can't check a product decision the way you check a compile.

→ Any task with complete inputs and a mechanical check plays to the strength. Any task with missing inputs and no check plays to the weakness, and produces confident output either way, which is what makes it dangerous rather than merely unhelpful.

What it looks like when the line is crossed

The failures share a shape: an agent given a decision-shaped question produces a decision-shaped answer, fluently, with no signal that the inputs were absent.

• Asked which of three approaches to take, it picks one and justifies it well. The justification is coherent and doesn't reference the constraint that actually decides it, because that constraint wasn't in the context.
• Asked to prioritize a backlog, it produces a reasonable-looking ordering derived from the wording of the tickets rather than from the value of the work.
• Asked to "improve" something open-ended, it improves what's improvable rather than what matters — the data-cleaning failure in a different costume.

⚠️ The output quality is what makes this hard to catch. A weak answer would be obvious. A well-argued answer that omits the deciding factor reads as a good answer to anyone who doesn't already know the deciding factor.

Designing around it

Put the model where inputs are complete and answers are checkable. Implementation, transformation, extraction, generation against a spec.

Keep the decision with whoever holds the context — which is a person, for now, and specifically a person close to the domain.

When you do want the model near a decision, use it to enumerate rather than to choose. "What are the approaches, and what does each trade off?" plays to the strength: it's recall and structuring, not judgment under missing information. The person then chooses, faster, with a better-organized option set.

✅ That reframe is the single most useful move here. The same model that shouldn't pick is genuinely good at laying out the field — and a well-enumerated set of options with honest trade-offs is real work that saves real time.

Make the missing input explicit when asking anyway. Requiring the agent to state what it assumed and what would change its answer surfaces the gap:

recommendation: approach B
assumed:        read volume stays under ~10k/day
would_change_if: writes need to be strongly consistent across regions
not_considered:  team's existing operational experience

That last field is worth more than the recommendation. It's the agent telling you where its answer is unsupported, which converts a decision it shouldn't make into a briefing for the person who should.

💡 The tell that you've crossed the line

Ask: what would make this answer wrong, and is that in the context?

If the deciding factor is something the agent can't see — the roadmap, the customer conversation, the political constraint, the fragility everyone knows about — then you're asking for a decision, not an implementation, and you should expect a fluent answer that may be wrong for reasons the output won't mention.

The takeaway

Implementation has complete inputs and a checkable result; deciding what to build has neither. Route work by that distinction rather than by apparent difficulty. Where you want the model near a decision, ask it to enumerate options and state what it assumed — that plays to the strength and hands the judgment back to whoever holds the context the model doesn't have.