The problem
AI agents make software feel cheap.
You can describe a large product, hand it to an agent, and watch it start writing code. That feels powerful, but it also removes the pause where a small team normally has to ask the hard question: is this actually reasonable to build right now?
For a two-person team, that pause matters. The constraint is not imagination. The constraint is bandwidth. There are only so many useful hours in a day, and every feature carries follow-up work: debugging, integration, deployment, polish, support, and the next set of changes that appear once the first version exists.
The danger is that AI makes the first step feel smaller than it is. The code appears quickly, so the project feels cheap. But the commitment is not just the first generated version. The commitment is everything needed to turn that version into something real.
Clarifying is not enough
Most build workflows already have some kind of clarification step. Ask what the user wants. Ask what features matter. Ask what the app should do. That is useful, but it is not sufficient.
Clarifying questions can still inflate scope. If every answer adds another feature, the conversation becomes a better-written version of the same oversized plan.
The useful questions are the ones that expose tradeoffs:
- What can be cut without killing the value?
- Which part is technically uncertain?
- What assumption makes this worth spending scarce time on?
- What would be useful if the team only had two weeks?
- What is the smallest version that would teach something real?
Those questions change the conversation. The goal is no longer to describe the complete vision. The goal is to find the slice that deserves to exist first.
The gate
The pattern I want before implementation is a scope-realism gate.
Not a giant planning process. Not a product requirements document. Just a hard pause before coding starts.
The gate should take the rough idea and force it through a few filters:
Scope — what is actually necessary for the first useful version?
Risk — what part might take much longer than expected?
Value — what business assumption does this build test?
Time — does the proposed slice fit the rough deadline?
The deadline does not need to be perfectly quantified. “Two weeks from now” is enough to change the quality of the conversation. Exact hour accounting can be useful later, but a rough deadline is usually enough to reveal when the idea is too big.
The important part is that the gate does not pretend to make the decision for the team. It should surface the mismatch clearly: this plan is too large for the time, this integration is the risky part, this feature does not support the core value, this milestone would teach something faster.
Then the humans decide whether to cut scope, accept the risk, or keep going anyway.
The pragmatic skill
I am turning this pattern into an open-source skill called pragmatic.
The skill is basically a pre-build reality check. It borrows the useful parts of a clarification workflow, but points the questions at the constraints that small teams actually feel: limited bandwidth, uncertain technical risk, and the need to spend time only where it can teach or compound.
The output is deliberately simple.
First, a pragmatic build brief:
- what to build
- why it is worth doing
- the rough time constraint
- the biggest scope cuts
- the biggest technical risks
- the business-value assumption
- any obvious mismatch
- the smallest useful first milestone
Then, a prompt for an agent to build the agreed slice.
That second part matters. If the conversation ends with only a critique, the next agent can still wander back into the full vision. The handoff needs to carry the cuts forward. The implementation prompt should describe the smaller thing, not the original ambition with a note that “scope should be reasonable.”
Takeaway
idea → clarification → scope realism → implementation
The added pause makes the first build honest: it forces the team to name the smallest useful slice, the risk, the deadline, and the assumption being tested.