DEV Community

Cover image for Stop Writing User Stories for AI. Start Writing Specs.
Jacques Montagne
Jacques Montagne

Posted on

Stop Writing User Stories for AI. Start Writing Specs.

The "2-Pizza Team" is dead. McKinsey just confirmed that Agentic Workflows can increase productivity by "500%".
But there is a catch.

If you feed a Senior AI Agent (Claude 4.5 Sonnet / GPT-5.2) with a standard Agile User Story, you will get garbage.

Why? Because User Stories are "Conversation Starters". They rely on human context, tribal knowledge, and the "Definition of Ready" discussed in a meeting room.
AI was not in that meeting room.

If you want the "Commando Unit" efficiency I talk about on LinkedIn, you need to switch from Story-Driven Development to Spec-Driven Development (SDD).

Here is the protocol I use to migrate Legacy Java apps to AWS Serverless without breaking production.

The Entropy of Human Language

This is a typical Jira ticket:

User Story: As a customer, I want to filter my transaction history so I can see my spending.
Acceptance Criteria: Filter by date and amount.

If you give this to a Junior Dev, they will ask questions.
If you give this to Cursor/Copilot, it will hallucinate assumptions:

  • "I'll use client-side filtering!" (Performance killer)
  • "I'll assume the date format is MM/DD/YYYY!" (Breaks in Europe)

You are not managing risk; you are amplifying it.

The Protocol: Markdown Specifications

In my workflow, the "Senior Architect" does not write production code. The Architect writes the Spec. The AI writes the implementation.

As Werner Vogels said: "The work is yours, not the tool's."

I treat English as a programming language. The Spec must be deterministic.

The Structure

I create a .specs/ folder in my repository. Each feature gets a markdown file.

# SPEC-001: Transaction History Filter (API Level)

## 1. Context
Migrating `LegacyTransactionService.java` to AWS Lambda (Node.js/TypeScript).
Target Database: DynamoDB (Single Table Design).

## 2. Interface Contract (Strict)
**Input:** `GET /transactions`
- `startDate` (ISO8601, Optional)
- `minAmount` (Integer, cents, Optional)

**Output:** JSON Array `Transaction[]`
- Max page size: 50 items.
- Pagination: LastEvaluatedKey.

## 3. Logic & Constraints (The "Meat")
1. **Validation:** If `startDate` is in the future, throw `400 Bad Request`.
2. **Query Pattern:** MUST use DynamoDB `Query` (GSI_Date), NOT `Scan`.
3. **Legacy Parity:** Must replicate the "rounding error" logic from the old COBOL core (see reference: `calc_utils.legacy.js`).

## 4. Edge Cases
- User has 0 transactions -> Return `[]` (HTTP 200), not 404.
- DynamoDB Throttling -> Implement exponential backoff (Use AWS SDK v3 standard retry).
Enter fullscreen mode Exit fullscreen mode

5. The "Vibe Coding" Trap: Why Code Comprehension is King

There is a lot of buzz around "Vibe Coding"—letting the AI handle the syntax while you focus on the flow.
But as Gene Kim and Steve highlight in their work on Vibe Coding, this only works if you have extreme Code Comprehension.

AI suffers from the "Illusion of Competence". It generates code that looks correct, compiles perfectly, but contains subtle logical bugs or security holes.

In this model, you are no longer just a "Writer". You are a Code Auditor.

  • Vibe Coding: Rapidly iterating with AI to build the structure.
  • Code Comprehension: Reading every generated line to ensure it matches the Spec and doesn't introduce hidden technical debt.

You cannot "vibe" your way through a banking migration. You must comprehend the output. If you treat the AI as a "Black Box", you are not engineering—you are gambling.

The Workflow (ROI Analysis)

This looks like "Waterfall", doesn't it?
Good.
Agile was created to manage the cost of change when coding was slow.
Now, coding is instant. The cost has shifted to debugging bad requirements.

Task Old Model (Agile + Human) New Model (Spec-Driven + AI)
Requirements 1h (Jira/Refinement) 2h (Deep Work / Writing Spec)
Coding 8h (Dev + Tests) 5 min (AI Generation)
Auditing / Review 1h (PR Review) 2h (Deep Line-by-Line Audit)
Total 10h ~4h

Conclusion: The "Thinking" Gap

The McKinsey report scares people because it implies we need fewer developers.
It's true. We need fewer coders.
But we need more Engineers who can articulate complex system behaviors in unambiguous text and validate the result.

AI is a multiplier.
Zero times a Million is still Zero.
If your input (User Story) is fluff, your output (Code) will be technical debt.

Stop writing stories. Start writing Specs.


Follow me for more on **Legacy Modernization* and Risk Management in the cloud.*

Top comments (0)