Stories as Delegation Contracts¶
User Stories Deliver the Three Pillars¶
The three pillars give you a framework for any prompt. But when you're delegating a feature, not just asking a question, you need a format that packages Scope, Intent, and Structure into a repeatable contract. That's what user stories do.
This isn't a prompting trick. It's how software teams have worked for years. A Product Manager writes a user story. An Engineer uses it as the contract that defines what "done" looks like. The story aligns both sides before anyone starts building. You're applying the exact same pattern here. The only difference is that your delegate is an AI coding assistant instead of a human Engineer.
The format:
As a [type of user],
I want [capability],
so that [outcome].
Notice that the format starts with a person, not a feature, not a technology, not a screen. That's intentional. Good software is built for people, and the best way to build something valuable is to stay connected to who you're building it for and what they actually need. A user story is a small act of empathy: you step into someone else's shoes and describe the world from their perspective. When you do that, whether you're handing the story to a human or to AI, the thing you build is more likely to be something people actually use.
- "As a" = who you're building for, grounding every decision in a real person's needs
- "I want" = what to build (Scope, bounded and specific)
- "So that" = why it matters (Intent, the steering wheel that guides AI's judgment calls)
The "so that" clause is especially important. It's the steering wheel. When AI has to make decisions about implementation details (and it will), the "so that" tells it what outcome to optimize for. Without it, AI guesses. With it, AI makes informed tradeoffs.
Acceptance Criteria: Your Definition of Done¶
A user story tells AI what to build. Acceptance criteria tell both of you when it's done.
The format:
Given [starting condition],
when [action happens],
then [expected result].
These aren't suggestions. They're your verification checklist. After AI delivers, you walk through each criterion: pass or fail. No guessing, no "it looks okay." Either it meets the criteria or it doesn't.
Example:
As an Office of Naval Intelligence (ONI) watch floor analyst,
I want to see which vessels in my area of interest appear
on the OFAC sanctions list (the US Treasury's registry of
sanctioned vessels and their owners)
so that I can prioritize them for investigation before
they leave the region.
Given I'm viewing the vessel traffic display,
when a vessel's MMSI (its unique 9-digit transponder
identifier) matches an OFAC entry,
then that vessel is highlighted with a sanctions flag
showing the vessel name, MMSI, and sanctions program.
Given I've identified a sanctions-matched vessel,
when I click on it,
then I see its current position, speed, heading,
destination, and the full OFAC entry with all known
identifiers.
Notice how the acceptance criteria are specific enough that you could hand them to someone who's never seen the project and they'd know exactly what to check. That's the standard. They're a contract between you and your AI delegate.
Here's the pattern that matters: if you can't write acceptance criteria for it, you're not ready to delegate it. The inability to define "done" is your signal to break the task down further or explore more before implementation.
The Workflow¶
The user story plugs into a four-step workflow you'll use throughout the day:
Explore → Plan → Implement → Verify
- Explore: Before you start building, understand who you're building for. What do your users need? What problems are they trying to solve? What decisions are they making, and what information would help them make better ones? This is the discovery step. You're building enough empathy with your user that you could write a story from their perspective. You can use AI to help: "What does a maritime intelligence analyst need to assess when monitoring vessel traffic for sanctions evasion? What data sources would they cross-reference, and what makes a vessel suspicious enough to investigate?"
- Plan: Write the user story with acceptance criteria. Your story IS your plan
- Implement: Hand the story to AI and let it build
- Verify: Walk through each acceptance criterion, pass or fail
When verification reveals a problem, the cycle repeats: plan the fix, implement, verify again. The acceptance criteria you wrote in Step 2 are the same checklist you use in Step 4. They do double duty as both spec and test.
Write Your First Delegation Contract
Mob Session | ~5 minutes total | Gather around one screen. One person drives, everyone else navigates.
New to mobbing? The whole team gathers around one screen. One person is the "driver" (hands on the keyboard) while everyone else "navigates" (guiding what to do, watching for mistakes, thinking ahead). You'll rotate who drives throughout the day.
Your team is about to build a Dark Vessel Risk Assessment Tool: a system that helps maritime intelligence analysts at the Office of Naval Intelligence (ONI) detect vessels that may be evading sanctions. These analysts work a 24/7 watch floor at the National Maritime Intelligence Center, monitoring vessel traffic across entire ocean regions. Their job is to cross-reference vessel identities against sanctions lists, check behavioral history for patterns of deception, and correlate satellite imagery against transponder data to find vessels that have gone dark. Today, this work requires manually switching between six different systems and data formats. Your tool brings those sources together.
First, practice the Explore step. Ask your AI coding assistant:
I'm building a tool for maritime intelligence analysts
who monitor vessel traffic and detect sanctions evasion.
Their workflow involves cross-referencing AIS transponder
data, OFAC sanctions lists, vessel behavior history, and
satellite imagery.
What are the biggest pain points in this workflow today?
What would make the analyst's job faster and more accurate?
Spend 60 seconds reading the response. Let it inform which capability you focus on and what acceptance criteria you write.
Now write a user story for the ONI analyst with 2-3 acceptance criteria. The analyst has one role but many needs. Pick one capability to focus on:
- Sanctions screening: "As an ONI watch floor analyst, I want to see which vessels match the OFAC sanctions list so that..."
- Behavior analysis: "As an ONI watch floor analyst, I want to see each vessel's history of AIS gaps so that..."
- Dark vessel detection: "As an ONI watch floor analyst, I want to cross-reference satellite detections against AIS positions so that..."
Add 2-3 Given/When/Then acceptance criteria that define when this feature is done.
Discuss: Notice how the "I want" changes the entire shape of the feature. Sanctions screening pulls from the OFAC list and needs a quick visual flag. Behavior analysis pulls from gap event history and needs a timeline view. Dark vessel detection pulls from satellite imagery and needs a map overlay. Same user, same tool, but each capability is a different delegation contract with different data, different UI, and different acceptance criteria.
Key Insight
A user story with acceptance criteria is a delegation contract. The story tells AI what to build and why. The criteria tell both of you when it's done. When you can't write the criteria, that's your signal to break the task down further, not to delegate and hope for the best.