← The Infinum AI Harness
Infinum · Engineering · PSDD

Pragmatic Spec
Driven Development.

PSDD — Infinum's 4-step approach for shipping features with AI, from a quick fix to a full system. Same process, different depth.

The core idea behind PSDD: Think of a good architect. They don't swing a hammer until they know what they're building and where the walls go. This workflow is that — applied to AI. You invest a few minutes up front to align the model with your intent, and everything that follows gets faster and more predictable.
Complexity dial — pick your lane
Step
⬤ Small / Low-risk
◆ Purely technical
▲ Large / High-risk
1Understand
Short prompt or bullet points
Technical brief: goal, constraints, success checks, rollout
Full PRD/FRD — goals, constraints, acceptance criteria (or a well-refined task that covers the same ground)
2Design
Agree on approach in chat, keep in context
Agree on approach in chat, keep in context
Written tech spec, reviewed by a fresh agent
3Plan
Short ordered list of what changes where
Ordered list including rollback strategy
Structured plan in Plan mode, reviewed before execution
4Build
Run it, review, commit
Run it, validate parity, canary if needed
Agent execution in Build mode, step-by-step validation
Rule of thumb: High complexity / ambiguity (especially user-facing) → full PRD. Smaller features → a clear description is enough. Purely technical work (refactors, upgrades, migrations) → skip the PRD, write a tight technical brief instead. If your task already has a well-written description with goals, constraints, and acceptance criteria from refinement — use that as your PRD base.
The 4 steps — what you actually do
1
Understand the feature
Remove uncertainty before anything else
Done when: requirements are clear and testable
+

Before writing a single line of code, make sure you and the AI agree on what "done" means. Use the model to challenge assumptions and surface edge cases. The context you capture here directly determines how well the model performs in the next three steps.

Model Top-tier — Claude Opus, Codex stronger reasoning finds better edge cases early
A — Small feature or change

Use when the work is contained, the goal is clear, and the blast radius is small.

→Write a prompt describing the feature: goal, expected behavior, key edge cases. That prompt is your Step 1 output — use it directly to start Step 2.
→Optionally, do a quick back-and-forth with the AI to tighten requirements before moving on.
Example
"Add a 'Save for later' option in the cart. Items should move to a separate list, stay across sessions, easy to move back. Edge cases: out of stock, price changes, not logged in. Ask missing questions, then propose a technical approach."
B — Purely technical change

Use for refactors, upgrades, migrations, performance work. The risk is technical correctness, not unclear requirements — skip the PRD, write a tight technical brief instead (goal, constraints, success checks, rollout/rollback).

Example
"Migrate background jobs from Celery to a managed queue service. Goal: same behavior, improved observability. Constraints: no user-facing changes. Success = parity tests + canary rollout + easy rollback. Talk through the safest approach."
C — Large or complex feature

Use when the feature is ambiguous, cross-cutting, risky, or involves many edge cases. If your task from refinement already covers goals, constraints, and acceptance criteria, use that as your PRD base. Otherwise, use the PRD skill to produce a structured document: goals/non-goals, user stories, functional requirements, acceptance criteria, and constraints. Light on implementation — the "what" and "why", not the "how."

Example
"Let's create a PRD for: Subscriptions / recurring deliveries. Customers can subscribe to products (weekly/monthly), manage skips and cancellations, and see upcoming shipments."
Example
"Let's create a PRD for: Loyalty and rewards program. Customers earn points on purchases, unlock tiers with benefits, and redeem points at checkout. Needs rules for expiration, partial redemption, and integration with promotions."
2
Design the solution
Agree on the technical direction — no code yet
Done when: approach is agreed and risks are addressed
+

The main control lever in the workflow. Before any code runs, get the AI to propose its approach — then steer it or let a good proposal change your mind. Stay in Ask mode only. No code changes happen in this step.

Model Top-tier — Claude Opus, Codex reasoning quality matters most here
→Ask: "How would you build this?" Let the model propose a solution first.
→State hard constraints clearly. Then push back, redirect, or accept better ideas. Iterate in Ask mode.
→Output: for small features, the agreement in chat is enough. For larger ones, write it into a tech spec — then open a fresh chat and have a new agent critique it until feedback is minor.
Open-ended
"Don't make any code changes. How would you approach building this? Consider our existing architecture. Outline main components, data flow, and edge cases."
With constraints
"No code changes. Constraints: must use existing service layer, avoid DB schema changes, keep API backward compatible. Propose an approach and call out trade-offs."
Produce the spec
"Based on our discussion, write a technical specification in markdown. Include enough detail so the feature can be implemented without ambiguity."
Review pass — open a fresh chat
"Review this technical specification and identify gaps, unclear areas, risks, and edge cases. Suggest concrete improvements."
3
Plan
Turn the agreed direction into ordered steps
Done when: plan is reviewed and approved
+

Convert your understanding and agreed design into a concrete implementation plan. AI performs significantly better when work is decomposed into smaller, well-defined tasks. The plan should be reviewable before a single line of code runs — this is your last clear checkpoint.

Model Top-tier — Claude Opus, Codex better plans mean fewer surprises during execution
→Switch to Plan mode in Cursor or Claude Code.
→Provide context: small features stay in the same chat; larger ones include the PRD and tech spec.
→Review before approving. Check sequencing, missing pieces — migrations, edge cases, tests, rollout. Adjust anything that looks off.
From discussion
"Generate an implementation plan based on our discussion. Break it into clear, ordered steps with checkpoints."
From artifacts
"Using the attached PRD and technical specification, generate an implementation plan. Include sequencing, affected areas, and validation steps."
Refine
"Update the plan to include migration steps and rollback strategy. Also add tests for edge cases we discussed."
4
Build
Execute the plan — then review like any other change
Done when: tested and validated against Step 1
+

Now the agent runs. Because you did the work upfront, it stays aligned and you rarely need to re-explain decisions. When something isn't right, corrections are fast and targeted.

Model Cost-efficient — Claude Sonnet, Codex execution-heavy, many tokens, main reasoning is done
→Switch to Build / Agent mode. Approve the plan and let it execute.
→Review the output: focus on business-critical paths and core logic. Skim boilerplate and wiring unless it looks suspicious.
→Iterate: if something needs adjusting, tell the agent what to change. It has full context, so fixes are fast and targeted.
→Run and test. Does it meet the acceptance criteria from Step 1? Paste failing logs back to the agent if needed.
Targeted adjustment
"Refactor the implementation of [component] to follow [pattern]. Keep behavior the same and update tests if needed."
Fix from logs
"Here's the failing test output / exception stack trace: … Identify the root cause and fix it. Add regression coverage if appropriate."
Note on codebase patterns: Agents repeat patterns already present in the codebase — an advantage when patterns are healthy, a problem when they aren't. Consistently messy build results are usually a signal to improve conventions or add the right rules/skills.
Pick your path
Small / Low-risk
Goal is clear, blast radius is small
Steps 1–3 · One prompt
Write a clear description: goal, behavior, constraints, edge cases. That single prompt is your understanding, design, and plan.
Step 4 · Build
Run, review, commit.
You're not skipping steps — the work is just small enough that they compress into one move.
Purely technical
Refactors, upgrades, migrations
Steps 1–2 · One conversation
Write a technical brief (goal, constraints, success checks, rollout/rollback), then agree on approach — same chat, two checkpoints.
Step 3 · Plan
Ordered list + rollback strategy.
Step 4 · Build
Run, validate parity, canary if needed.
Skip the PRD — the risk is technical correctness, not unclear requirements. Brief and design happen together, but think what before how.
Large / High-risk
Ambiguous, cross-cutting, user-facing
Step 1 · Understand
Full PRD: goals, constraints, acceptance criteria. A well-refined task can serve as the base.
Step 2 · Design
Written tech spec, reviewed by a fresh agent.
Step 3 · Plan
Structured plan in Plan mode, reviewed before execution.
Step 4 · Build
Agent execution, step-by-step validation.
Every step is distinct. This is where the full process pays for itself.
⚠ Watch out: context window degradation
!
⚠ Watch out: context window degradation
Every model has a finite window — when it fills up, quality degrades silently
Signs the context is degrading: the agent repeats questions, forgets earlier decisions, or produces output that contradicts the agreed approach.
When to split across chats
Conversation is getting long and quality is dropping
The plan has natural seams — backend vs. frontend, data layer vs. API
A structured artifact exists — starting fresh is low-cost when it carries the context
What to carry into a new chat
Current versions of key artifacts (PRD, tech spec, plan)
Short status summary: what's done, what's in progress, any deviations
Relevant code and error output — leave out unrelated history
Rule of thumb: if the feature can be planned and built in a single session without quality loss, stay in one chat. If the work spans multiple components, plan for multiple sessions from the start and keep your artifacts updated as the source of truth.
Glossary
Terms used in this workflow
PSDD
Pragmatic Spec Driven Development — Infinum's workflow for building with AI, described in this document. Pragmatic because the depth of each step scales to the work.
PRD / FRD
Product/Feature Requirements Doc. Captures goals, constraints, user stories, and acceptance criteria before design or code begins. Can be generated from scratch or based on an existing refined task. The "what" and "why", not the "how".
Tech brief
Lightweight alternative to a PRD for purely technical work. Covers goal, constraints, success checks, and rollout/rollback plan.
Ask mode
The AI explores ideas without making code changes. Use this for Steps 1 and 2.
Plan mode
Generates a structured implementation plan from your context. No code runs — you review and approve first.
Build mode
Also called Agent mode. The AI executes the approved plan step by step, making actual code changes.
Fresh agent
A new chat with no prior context. Useful for spec reviews — catches assumptions the first conversation missed.
Context window
The maximum text a model can "see" at once. When it fills up, earlier context is lost and quality degrades silently.