Skip to content
Lesson 5 of 12

Prompting for Speed — From Slow to 5.7x

8 min read

The Anatomy of a High-Velocity Prompt

A prompt is not just a question -- it is a specification. The quality of your prompt directly determines how many iteration cycles you need. A vague prompt requires 5-6 rounds of refinement. A precise prompt gets it right in 1-2. At the 5.7x level, most prompts produce usable output on the first pass.

Every high-velocity prompt contains four elements:

Outcome   — What the final result should be
Constraints — Technical boundaries and requirements
Context   — Project-specific patterns to follow
Format    — How the output should be structured

Here is the difference in practice:

Slow prompt (missing all four elements):
"Add a login page"

Fast prompt (all four elements present):
"Create a login page at /login with email and password fields.
Use the existing AuthForm component pattern from /signup.
Validate with zod: email must be valid format, password min 8 chars.
On success, redirect to /dashboard. On failure, show inline error
messages below each field. Use server actions for form submission.
Follow the same Tailwind styling as the signup page."

The slow prompt will require multiple follow-up messages: "use zod for validation," "follow the signup page pattern," "add error handling," "use server actions." Each follow-up costs time and context. The fast prompt front-loads all decisions and gets a complete implementation in one pass.

Specificity Eliminates Back-and-Forth

The number one cause of slow AI interactions is ambiguity. Every ambiguous element in your prompt forces AI to make a guess, and guesses require corrections. Here are the most common ambiguity patterns and how to fix them:

Ambiguous technology choices:

Slow: "Add authentication"
Fast: "Add authentication with NextAuth.js using the Credentials provider,
       storing sessions in the database with Prisma adapter"

Ambiguous styling:

Slow: "Make it look good"
Fast: "Use the same card component pattern as the dashboard, with rounded-xl
       border border-slate-200 dark:border-slate-700 p-6 shadow-sm"

Ambiguous behavior:

Slow: "Handle errors"
Fast: "Catch all errors in a try-catch. Log the full error to console.
       Return a user-friendly message to the UI. For 401 errors, redirect
       to /login. For 429 errors, show a rate limit message with retry time."

Ambiguous scope:

Slow: "Update the API"
Fast: "Add a PATCH endpoint to /api/users/[id] that accepts partial updates
       for name, email, and avatar fields only. Validate input with zod.
       Return the updated user object. Add a test for each field update."

Each specificity you add eliminates one potential iteration cycle. Five specific details in a prompt can save five rounds of corrections.

The Plan-Then-Execute Pattern

For complex features, split work into two phases: planning and execution. This catches architectural issues before any code is written.

# Phase 1: Plan
claude "/plan Add a notification system with:
       - Database table for notifications (user_id, type, message, read, created_at)
       - API endpoints: GET /api/notifications, PATCH /api/notifications/[id]/read
       - Real-time updates with Server-Sent Events
       - Bell icon in navbar with unread count badge
       - Dropdown panel showing recent notifications
       - Mark as read on click, mark all as read button"

Review the plan carefully. Does the file structure make sense? Are the database choices appropriate? Is the SSE approach right for your infrastructure? Make adjustments:

# Phase 1b: Adjust the plan
"Good plan, but use WebSocket instead of SSE since we already have a
 WS connection for the chat feature. Also put the notification dropdown
 in the existing HeaderActions component instead of creating a new one."

# Phase 2: Execute
"Execute the approved plan. Create all files, run the migration,
 and make sure existing tests still pass."

This two-phase approach adds 2-3 minutes for the planning step but frequently saves 15-20 minutes of rework that would happen if AI made wrong architectural assumptions during direct execution.

Batch Prompting: Multiple Changes in One Message

One of the biggest time sinks is making one small request at a time. Each message has overhead: AI reads context, generates a response, you review, you send the next message. Batch related changes into single prompts:

# Slow: 5 separate messages
"Add a loading spinner to the dashboard"
"Change the primary color to indigo-600"
"Add aria-labels to all navigation links"
"Fix the mobile menu z-index"
"Add a skip-to-content link for accessibility"

# Fast: 1 batched message
"Make these 5 changes to the UI:
1. Add a loading spinner to the dashboard page (use the Spinner component)
2. Change primary color from blue-600 to indigo-600 across all components
3. Add descriptive aria-labels to all navigation links in Navbar.tsx
4. Fix mobile menu z-index — set it to z-50 so it renders above content
5. Add a skip-to-content link as the first focusable element in the layout"

The batched version completes in one AI execution cycle instead of five. For a set of independent changes, this alone can be a 3-4x speedup on that task.

When to batch:

  • Changes that are independent of each other
  • Small to medium changes that do not require deep architectural decisions
  • Bug fixes from an issue list
  • Style or accessibility improvements

When NOT to batch:

  • Changes that depend on each other (do them sequentially)
  • Large features that need individual review
  • Changes where you need to verify each one before proceeding

The Anti-Pattern: Micro-Prompting

Micro-prompting is the habit of making one tiny request at a time:

# The micro-prompting anti-pattern
"Add a new file called utils.ts"
"Add a function called formatDate to utils.ts"
"Make formatDate accept a Date parameter"
"Make formatDate return a string in YYYY-MM-DD format"
"Export formatDate"
"Import formatDate in the Dashboard component"
"Use formatDate for the created_at display"

This is seven messages for what should be one:

# The 5.7x approach
"Create a formatDate utility function in src/lib/utils.ts that takes a
 Date and returns YYYY-MM-DD format. Export it and use it in the
 Dashboard component for the created_at display."

Micro-prompting happens when developers are still in a "writing code" mindset, dictating line by line. The 5.7x mindset thinks at the feature level and trusts AI to handle the implementation details.

Prompt Templates for Common Tasks

Build a library of prompt templates for tasks you do frequently. Here are templates that work well:

New Feature Template

"Add [feature] to [location].
Requirements: [list specific requirements]
Follow the same pattern as [existing similar feature].
Include: [component/route/test/migration as needed].
Use [specific libraries or approaches]."

Bug Fix Template

"Fix: [describe the bug and how to reproduce].
Expected behavior: [what should happen].
The issue is likely in [file or area].
After fixing, verify by [test or manual check]."

Refactoring Template

"Refactor [target] to [new approach].
Motivation: [why the change is needed].
Keep the same public API / behavior.
Update all call sites.
Run tests after to verify nothing broke."

Content Creation Template

"Create [content type] for [topic].
Structure: [outline or sections].
Tone: [describe desired tone].
Length: [approximate word count].
Format: [MDX/markdown/etc] with [frontmatter fields].
Include: [code examples, diagrams, etc]."

Speed Metrics

To put numbers on the impact of good prompting:

| Prompting Style | Avg. Messages per Feature | Time per Feature | |-----------------|--------------------------|------------------| | Micro-prompting | 12-20 messages | 45-60 minutes | | Basic prompting | 5-8 messages | 20-30 minutes | | Specific prompting | 2-3 messages | 8-15 minutes | | Template prompting | 1-2 messages | 5-10 minutes |

The difference between micro-prompting and template prompting is 4-6x speed improvement on individual tasks. Across a full day of development, this compounds into the overall 5.7x multiplier.

Building the Habit

Prompting well is a skill that improves with practice. Start with these habits:

  1. Pause before prompting. Take 30 seconds to think about what you really need before typing. Those 30 seconds save 10 minutes of iteration.
  2. Include the pattern reference. Almost every change follows an existing pattern in your codebase. Name it explicitly.
  3. State the boundary conditions. What should happen on error? On empty state? On edge cases?
  4. Batch related changes. Before sending a message, ask: "Is there anything else I need in the same area?"
  5. Save templates that work. When a prompt produces great first-pass results, save it as a template for future use.

The goal is not to write long prompts. It is to write precise prompts. A 3-line prompt with all four elements (outcome, constraints, context, format) beats a 20-line vague description every time.