The Alignment Interview

What you'll learn

• An alignment interview is a structured conversation with an AI agent that stress-tests your project idea before you write code
• The agent plays the role of a skeptical reviewer who identifies edge cases, architectural risks, and missing requirements that would otherwise surface three hours into a build
• A 20-minute interview catches problems that cost hours to fix after implementation starts
• The interview prompt in this lesson works with any capable coding agent: Claude Code, Codex, Cursor, or the API

The problem

You have a project idea. You've thought about it for a week. You know the stack, the features, and the rough shape of the code. You sit down, fire up Claude Code, and start building. Three hours later you hit a wall: the database schema you chose can't handle the query pattern you need, or the auth model doesn't work for the multi-tenant case you forgot about, or the API design you started with can't support the notification system you were planning for week two.

You now have two bad options: refactor three hours of code with the agent (slow, error-prone, and you'll hate it) or ship with the architectural flaw and fix it later (technical debt that compounds every day you wait).

The root cause is not that you're bad at planning. It's that solo builders don't have a team to push back on ideas. When you're the only person in the room, every idea sounds reasonable because there's nobody saying "what happens when the user deletes their account mid-transaction?" or "how does this handle 10,000 users hitting it at once?"

The alignment interview pattern gives you that pushback. It's a structured, agent-driven review of your project plan that surfaces problems before they become code.

Options & when to use each

Option	What it's good for	What it costs you	When to pick it
Build first, fix later	Truly trivial features where the cost of being wrong is near zero	High risk of rewrite for anything with state, auth, or multiple users	Throwaway scripts, one-off data transformations, personal tools you're the only user of
Whiteboard it yourself	Thinking through architecture in your own head	You miss the same things you always miss. You don't know what you don't know, and neither do you	Quick sketches before a build. Useful, but incomplete on its own
Alignment interview with an agent	Catching edge cases, architectural mismatches, and missing requirements before coding starts	20 minutes of your time, a few thousand tokens of API spend	Any project that involves state, auth, multiple users, or a deadline you care about
Full design review with a human team	Mission-critical systems, compliance requirements, multi-team coordination	Hours of meetings, scheduling overhead, requires a team	Enterprise environments where the process already exists

The alignment interview is the cheap option that catches 80% of what a full design review would surface, at 1% of the time cost. It works because the agent reads your plan and asks questions a human reviewer would ask: "what happens when X fails?" "how does this scale past Y?" "what's the fallback for Z?"

Build it

Step 1: Write your project brief

Before the interview, write a one-page markdown document describing what you want to build. Save it as project-brief.md. This is the document the agent will stress-test:

# Project: [Name]

## What it does
[Three to five sentences. What does the user do? What does the system do in response?
Who uses it? Is this a web app, CLI tool, API, mobile app?]

## Core features
1. [Feature one: what the user does and what happens]
2. [Feature two]
3. [Feature three]

## Technical plan
- Stack: [language, framework, database]
- Hosting: [Vercel, Railway, Hetzner VPS, etc.]
- Auth: [none / Clerk / Auth0 / hand-rolled JWT / session-based]
- Storage: [PostgreSQL / SQLite / S3 / none]
- Background jobs: [none / Redis+worker / in-process / Cloud Tasks]

## Known unknowns
- [Anything you're uncertain about: "Not sure if SQLite can handle the write volume"]
- [Questions you have: "Should I use websockets or polling for real-time updates?"]
- [Assumptions you're making: "Assuming max 100 users for the first month"]

## Constraints
- Budget: [$X/month for hosting]
- Timeline: [launch by date / no deadline]
- Team: [solo / 2 people / etc.]
- Must work on: [desktop only / mobile + desktop / CLI only]

A brief that's too vague ("I want to build a SaaS") produces a useless interview. A brief that's too detailed (10 pages of architecture decisions) means you've already done the work the interview would do for you and you're looking for validation, not stress-testing. One page is the target.

Step 2: Run the alignment interview

Hand the brief to your agent with this prompt:

You are a senior engineer and product reviewer. Read project-brief.md.

Your job is to stress-test this project plan. Do not compliment the idea. Do not
suggest features. Your only output is problems: edge cases, architectural risks,
missing requirements, scaling concerns, and operational gaps.

For each problem you find, use this format:

**Problem:** [One sentence description]
**Category:** [Edge case / Architecture / Missing requirement / Scaling / Operations / Security]
**Impact:** [What happens if this isn't addressed. Be specific: "users lose data," not "bad UX"]
**What the brief says now:** [Quote or paraphrase the relevant part of the brief, or note that it's not mentioned at all]
**What to decide before building:** [The specific question the builder needs to answer. Not a solution, only the decision point]

Find at least 10 problems. If you can't find 10, you're not thinking hard enough.
Look at every feature. Look at the gaps between features. Look at the operational
surface: deployments, monitoring, backups, error handling. Look at the unhappy
paths: what happens when things fail.

After listing all problems, group them into: "Must resolve before coding starts,"
"Should resolve in the first week," and "Can defer to post-launch."

This prompt does several things: it defines the agent's role (skeptical reviewer, not cheerleader), it gives a structured output format so results are scannable, it demands a minimum number of problems so the agent digs deep, and it asks for prioritization so you know what to fix first.

Step 3: Run the interview in interactive mode for follow-up questions

The initial interview will produce a list of problems. Some will be actionable immediately ("add rate limiting to the API"). Others will raise questions you need to think about. For those, run a follow-up session:

Read project-brief.md and the interview results in interview-results.md.

For each problem marked "Must resolve before coding starts," walk through the
decision space. What are the tradeoffs? What are two or three reasonable approaches?
What are the second-order effects of each approach? Do not recommend one. Present
the options and let the builder decide.

This second pass converts identified problems into decision frameworks. You walk away knowing not only what's broken but what your options are for fixing it.

Step 4: Build the alignment interview as a reusable custom subagent

If you're starting projects regularly, turn the interview into a custom subagent. Create .claude/agents/alignment-interviewer.md:

---
name: alignment-interviewer
description: Stress-tests project plans before implementation. Use me when someone has a new project idea and wants to find problems before writing code.
tools:
  - Read
  - Glob
model: claude-sonnet-4-20250514
---

# Alignment Interviewer

You are a senior engineer and product reviewer. Your job is to stress-test
project plans. You find problems, not solutions.

## Process
1. Read the project brief (the user will tell you which file)
2. For each feature in the brief, trace through the full lifecycle: creation,
   normal usage, error states, deletion, recovery
3. Identify gaps between features: how do they interact? What state is shared?
4. Examine operational concerns: deployment, monitoring, backups, error handling,
   secrets management
5. Output problems in this format:

**Problem:** [One sentence]
**Category:** [Edge case / Architecture / Missing requirement / Scaling / Operations / Security]
**Impact:** [Specific consequence]
**What the brief says:** [Quote or "not mentioned"]
**Decision needed:** [The question to answer before building]

## Rules
- Find at least 10 problems. Dig if you're under 10.
- Do not compliment the idea. Do not suggest features.
- Do not recommend solutions. Your job is to surface decisions the builder
  needs to make, not to make those decisions for them.
- Prioritize: "Must resolve before coding," "First week," "Post-launch."

Now you can trigger the alignment interview from any Claude Code session by asking the agent to review a project brief. The custom subagent pattern means you write the interview logic once and reuse it.

What goes wrong

Mistake	How you notice it	The fix
Brief is too vague	Agent produces generic problems ("consider scaling") instead of project-specific ones ("your chosen DB can't handle the write pattern described in feature 3")	Fill in the "Technical plan" and "Known unknowns" sections. The agent needs specifics to surface specific problems. If you haven't decided on a database yet, say so, but list the options you're considering
You argue with the agent's findings in your head	You read a problem and think "that won't happen" or "I'll handle that later"	Write down every problem the agent finds, even the ones you dismiss. The ones you dismiss are often the ones that bite you. If you genuinely think a problem is irrelevant, add it to "Can defer" rather than deleting it
Agent produces fewer than 10 problems	Interview output is 3-4 items, all surface-level	The brief is too thin or the prompt didn't push hard enough. Add "Find at least 10 problems" to the prompt. If the agent still can't find 10, your project might genuinely be too small to need this pattern -- and that's fine
You use the interview as a substitute for thinking	You implement whatever the agent says without evaluating the tradeoffs yourself	The interview identifies decisions. You make them. The agent doesn't know your users, your business constraints, or your taste. Its job is to ask the right questions, not to answer them
You run the interview but don't update the brief	You fix three problems and start coding, but the brief still says the old thing. Two weeks later you forget why you changed the data model	After resolving each problem, update the brief. The brief is now your project's source of truth. When you hand it to a coding agent later, it reflects the decisions you made during the interview
Interview finds so many problems you get paralyzed	You have 25 "must resolve" items and you don't know where to start	Pick the three highest-impact problems and resolve those. Ship something small. You can't eliminate all risk before writing code. The goal is to catch the problems that would force a rewrite, not to achieve theoretical perfection

Confirm it worked

Run the alignment interview on a real project idea:

# 1. Write a project brief (Step 1). Don't overthink it. One page, 15 minutes.
# 2. Run the interview prompt (Step 2) with Claude Code:
claude -p "You are a senior engineer and product reviewer. Read project-brief.md.
Your job is to stress-test this project plan. [include full prompt from Step 2]" \
  --allowedTools "Read" \
  --max-turns 5

# 3. Count the problems found. If fewer than 10, the brief needs more detail or
#    the prompt needs to push harder.
# 4. For each "Must resolve" problem, run the follow-up (Step 3) to explore
#    tradeoffs.
# 5. Pick three problems and resolve them. Update project-brief.md with your decisions.

# Success: the interview surfaced at least 3 problems you hadn't thought of.
# Better success: it surfaced a problem that would have forced a rewrite if
#   discovered mid-build.
# Best success: you resolved the problems, updated the brief, and handed the
#   brief to an agent for Spec-Driven Development without hitting a wall.

The alignment interview pays for itself when it catches one architectural mistake before you've written code against it. Everything after that first catch is free insurance.

Next: Autonomous Subagent Workflows -- delegate research, linting, and background work while you focus on architecture.