Iterative Specification: Refining Your Request

intermediate 12 min 📋 Copy-paste ready

Sources not yet verified

specificationiterationpromptingintermediate

Scenario

Context: You need to build a complex feature but you're not sure how to specify it completely upfront

Goal: Learn to use iterative prompting to progressively refine requirements with AI assistance

Anti-pattern: Trying to write one massive prompt that covers everything at once

Tools: ClaudeGitHub Copilot ChatCursor

Conversation

The Problem with Monolithic Prompts

Complex features are hard to specify completely upfront. Iterative specification lets you build understanding together with the AI.

👤 You ✗ Bad example

I need to build a user authentication system with OAuth, password reset, MFA, session management, audit logging, and rate limiting. It should work with React, use JWT tokens, integrate with our existing PostgreSQL database, and follow OWASP security guidelines. Also needs to handle enterprise SSO.

This prompt is too dense - it covers too many concerns at once, making it hard to get coherent, focused assistance.

🤖 AI

That's a comprehensive authentication system! Let me try to address all of these...

[Proceeds with an overwhelming, unfocused response that tries to cover everything superficially]

The AI struggles to prioritize and ends up giving shallow coverage of many topics instead of deep help on any one.

The Iterative Approach

Start with the core problem, get it right, then expand.

👤 You

I'm building a user authentication system. Before we dive into implementation, help me think through the architecture.

Current situation:

React frontend, Node.js backend
PostgreSQL database
No existing auth (greenfield)

Must-haves for MVP:

Email/password login
Session management

Future needs (not MVP):

OAuth providers
MFA
Enterprise SSO

What questions should I answer before we start designing?

Clearly separates MVP from future needs and asks the AI to help think through the problem first.

🤖 AI

Great approach to separate MVP from future features. Here are key questions to answer:

Session Strategy:

JWT tokens vs server-side sessions?
- JWTs are stateless but harder to revoke
- Server sessions require storage but offer more control
Where will tokens be stored client-side?
- HttpOnly cookies (more secure against XSS)
- LocalStorage (vulnerable to XSS but simpler)

Security Baseline:
3. Password requirements?
4. Rate limiting strategy for login attempts?
5. Will you need audit logging from day one?

Future-Proofing:
6. Should we design the user model to accommodate OAuth from the start?

Separating credentials from users table helps later

Want me to elaborate on any of these trade-offs?

The AI provides focused, actionable questions that help shape the design iteratively.

👤 You

Let's go with:

JWT stored in HttpOnly cookies
Separate credentials table for future OAuth
Rate limiting on login endpoint (5 attempts per minute)
Audit logging can wait for v2

Now help me design the database schema for users and credentials.

Makes decisions based on AI's guidance, then requests focused help on the next piece.

🤖 AI

Here's a schema that supports your current needs and future OAuth:

-- Core user identity (provider-agnostic)
CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  email VARCHAR(255) UNIQUE NOT NULL,
  email_verified BOOLEAN DEFAULT FALSE,
  created_at TIMESTAMPTZ DEFAULT NOW(),
  updated_at TIMESTAMPTZ DEFAULT NOW()
);

-- Password credentials (separate for OAuth flexibility)
CREATE TABLE credentials (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID REFERENCES users(id) ON DELETE CASCADE,
  type VARCHAR(50) NOT NULL, -- 'password', 'oauth_google', etc.
  -- For passwords:
  password_hash VARCHAR(255),
  -- For OAuth (future):
  provider_id VARCHAR(255),
  provider_data JSONB,
  
  created_at TIMESTAMPTZ DEFAULT NOW(),
  UNIQUE(user_id, type)
);

-- Refresh tokens for session management
CREATE TABLE refresh_tokens (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID REFERENCES users(id) ON DELETE CASCADE,
  token_hash VARCHAR(255) UNIQUE NOT NULL,
  expires_at TIMESTAMPTZ NOT NULL,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

This lets you add OAuth later by inserting a new credentials row with type='oauth_google' without changing the users table.

Want me to move to the JWT implementation next, or refine this schema first?

Delivers focused, complete help on one piece, then asks what's next - supporting iterative flow.

Key Takeaways

Break complex requests into phases: core first, then expand
Ask the AI to help you think through the problem before jumping to code
Make decisions explicitly, then request the next piece
Separate MVP from future needs in your initial context
Each iteration should produce a complete, usable artifact

Try It Yourself

Prompt Template

I'm building [COMPLEX FEATURE]. Before we dive into implementation, help me think through the architecture.

**Current situation:**
- [Stack/constraints]
- [What exists today]

**Must-haves for MVP:**
- [Core requirements]

**Future needs (not MVP):**
- [Nice-to-haves]

What questions should I answer before we start designing?

Variations to Try

After getting questions: 'Let's go with [decisions]. Now help me design [next piece].'
If stuck: 'What are the trade-offs between [option A] and [option B] for my use case?'
To validate: 'Review this design against [specific requirements]. What am I missing?'

Sources

Tempered AI — Forged Through Practice, Not Hype

? Keyboard shortcuts

Iterative Specification: Refining Your Request

Scenario

Conversation

The Problem with Monolithic Prompts

The Iterative Approach

Key Takeaways

Try It Yourself

Prompt Template

Variations to Try

Related Content

Sources