Most rework isn't from bad code — it's from a spec that was technically naive. The outcome was clear, the evidence was solid, but nobody flagged the race condition, the missing migration, or the third-party rate limit until the work was half-built. Engineering review is where that gets caught. Pathmode gives you the spec in a form you can actually review: evidence, outcomes, and verification criteria, not a wall of prose.
The input
A draft IntentSpec the product side has authored — objective, outcomes anchored to evidence, and a first pass at edge cases. It's ready for a second set of eyes, specifically yours.
The flow
1. Read the outcomes against the system you'll build in. Each outcome carries its verification criteria. Ask: can this actually be verified the way it's written? If "the list loads instantly" really means "p95 under 200ms with 10k rows," say so — and add it as the criterion.
2. Add the edge cases only engineering can see. Concurrent edits, empty states, the migration that has to run first, the API that paginates at 100. These become explicit "must handle" requirements the agent can't skip.
3. Name the constraints and the out-of-scope lines. The implicit "we don't support multi-tenant yet" assumptions are invisible to an agent. Write them into the spec so they survive the handoff. Out-of-scope is as load-bearing as in-scope.
4. Check the readiness signals, then send it on. Review the readiness blockers, open questions, and verification checks. Missing evidence is a separate signal: a failure case can be worth handling before anyone reports it. Resolve the product decisions and approve the proposal revision separately before implementation.
The output
A spec that's been pressure-tested from the build side before any agent touches it:
- Verification criteria that are actually checkable — not "works well" but a condition that passes or fails
- Edge cases enumerated, so the agent handles them instead of inventing behavior
- Constraints made explicit, so scope doesn't quietly expand mid-build
- Risk surfaced early, when it costs a comment instead of a sprint
Why this beats reviewing a PR cold
Reviewing the spec is reviewing intent; reviewing the PR is reviewing a guess at intent that's already been coded. The first costs six minutes. The second costs a rewrite. Spec review moves the cheapest correction point — the comment thread — to before the work exists, where it belongs.
Try it yourself
- Open a draft spec the product side handed you
- Add two edge cases and one constraint only you would know
- Tighten one vague verification criterion into a pass/fail condition
- Review the revised proposal and obtain implementation authorization
Related
Bring this workflow to your team.
Keep the evidence, decisions, and follow-up work together in your product.
Start with Pathmode