Tech & AI, Explained

workflow-patterns

9 min read

Workflow patterns

Status: 🟩 COMPLETE Last updated: 2026-06-19 Plain-English tagline: The recurring rhythms of productive Claude Code use. The “how I actually work with this thing” patterns that fluent users converge on.

In plain English

Claude Code is open-ended — you can use it any way you want. That flexibility is its strength and a source of confusion for new users. After a few weeks of real use, however, certain rhythms emerge that consistently produce good outcomes. This entry catalogs those rhythms.

None of this is rocket science. Most of it is “what you’d naturally arrive at after enough sessions.” Reading it just gets you there faster.

Why it matters

The difference between a beginner and a fluent operator isn’t model knowledge — it’s workflow habits. Three of the same prompts, executed by people with different workflow habits, produce very different results.

The patterns here are the day-to-day moves that scale: that work across project sizes, task types, and your own focus state. Internalize them and Claude Code becomes a much more powerful collaborator.

Pattern 1: Plan → Build → Verify → Commit

The canonical rhythm. Use it for any task larger than a few minutes.

Plan

Before writing any code, ask Claude to plan the work. “Walk me through your approach before you start.” Use /plan or the Plan subagent.

What good planning surfaces:

  • Files that need to change
  • New files to create
  • Order of operations
  • Trade-offs and alternatives
  • Things you forgot to mention

Approve, redirect, or add constraints. Then go.

Build

Claude executes the plan. Stay engaged enough to interrupt if something looks wrong, but let the agent work without micromanaging every step.

Verify

Most important step. Don’t accept “I think it works.” Claude should:

  • Run npm run build and confirm
  • Run the dev server and use the feature
  • Take a screenshot if it’s a UI change
  • Run any relevant tests

“Verified by running X and observing Y” is the bar for “done.”

Commit

Tight, focused commits. One coherent change per commit. Good commit messages that explain why, not what (the diff shows what). If the commit message could be the title of a PR, it’s good enough.

Pattern 2: Read → Diagnose → Fix → Verify

For bug fixes specifically.

Read

Don’t fix what you haven’t read. Claude should read the affected files, related files, and tests before proposing a fix.

Diagnose

Explain the root cause. “The bug happens because X.” Not “I changed Y and it should fix it.”

If the diagnosis sounds wrong, push back. A wrong diagnosis often produces a fix that “works” but only by accident, leaving the real bug.

Fix

Make the minimal change that addresses the root cause. Resist the temptation to also refactor adjacent code (that’s a separate commit).

Verify

Reproduce the original bug → apply the fix → confirm the bug is gone. Add a test if reasonable.

Pattern 3: Explore → Plan → Build

For new features in unfamiliar code.

Explore

Spawn an Explore subagent to map the relevant parts of the codebase. Don’t pollute the main session with all the file contents.

Plan

With the structure understood, plan the new feature. What files do you change? What new ones do you add? Where do they go?

Build

Execute the plan with focus.

Pattern 4: Spike → Discard → Build Properly

For risky or experimental work.

Spike

“Quick and dirty — just see if this approach works.” Throwaway code. The goal is information.

Discard

Once the spike answers the question, throw it away. Don’t ship the spike code. It’s full of shortcuts.

Build properly

With the lesson from the spike, build the real implementation. Cleaner, tested, properly integrated.

This is one of the most underused patterns. Most developers spike, then try to clean up the spike, which is usually worse than building fresh.

Pattern 5: One task per session

A surprisingly impactful discipline. Each Claude Code session is focused on a single coherent task. Don’t pile up “while you’re at it…” requests.

Why:

  • Context stays clean
  • Memory of what was decided stays clear
  • Easy to commit when done
  • Easy to abandon if it goes wrong
  • Sets a natural cadence

When you finish a task, commit, close the session, open a new one for the next thing. The friction of opening is essentially zero; the cognitive clarity is significant.

Pattern 6: Restate the goal every 10 turns

In long sessions, context drifts. The original task gets diluted by intermediate steps, side investigations, course corrections.

Periodically restate: “to recap, we’re trying to achieve X. Are we still on track?”

This re-anchors both you and the model. Sometimes it surfaces “we got sidetracked”; sometimes it confirms “we’re on track and 80% done.” Either is valuable.

Pattern 7: Interrupt to redirect

You don’t have to wait for Claude to finish a wrong direction. Press Esc (or your interrupt key) the moment you see the model heading the wrong way.

A redirected agent is much cheaper than a misdirected agent. Don’t be polite — interrupt, redirect, continue.

This is one of the most important habits to develop. Beginners watch Claude do the wrong thing for 30 seconds out of politeness. Pros interrupt at second 3.

Pattern 8: Read every diff

Even when you trust Claude, glance at every diff before approving the change. You’ll catch:

  • Unintended side effects
  • Subtle bugs the model missed
  • Style or naming you’d prefer different
  • “Wait, why did it change that file?”

The pattern recognition you build by reading diffs is itself valuable — over time you start to spot common AI patterns and counter them up front in your prompts.

Pattern 9: Save lessons as memory

When something goes wrong (or surprisingly right), capture the lesson:

"Remember that when adding Supabase auth, I always need to also add the
session refresh logic. Save this in memory."

Future sessions in any project will benefit. See Memory system for the format.

Pattern 10: Commit and rollback as safety net

Frequent, focused commits give you a safety net. When something breaks:

git reset --hard HEAD~1

You’re back to the last good state. The lost work is small (one focused commit) and you can try again.

Without frequent commits, “something broke” means hours of investigation and selective undo. With frequent commits, it means 5 seconds of reset.

Don’t commit just-in-case work; commit at every coherent milestone.

Pattern 11: Use the right subagent for the job

Beginners use the main session for everything. Pros distribute:

  • “Where does X live?” → Explore subagent
  • “Plan a complex change” → Plan subagent
  • “Independent code review” → claude subagent (avoids confirmation bias)
  • “Custom recurring task” → custom subagent definition

This keeps the main session focused on driving and the subagents focused on their specialty.

Pattern 12: Permissions tuning is ongoing

Your settings.json permissions evolve over months. Whenever you find yourself re-approving the same kind of action repeatedly, add it to allow. Whenever you see a permission prompt for something that should never be allowed, add it to deny.

After a few months, your permissions reflect your actual work patterns. Sessions become much smoother.

Pattern 13: Use hooks for non-negotiable behavior

Some things must happen every time, regardless of the model’s choices:

  • “Run prettier after every edit” → PostToolUse hook
  • “Beep when Claude finishes a long task” → Stop hook
  • “Block writes to .env files” → PreToolUse deny hook

When you find yourself wishing for a guarantee, that’s a hook candidate. See Hooks.

Pattern 14: The two-track session

For some work, you run two Claude Code sessions in parallel: one in your main project, one in a docs / scratch / encyclopedia folder. The first does the work; the second captures the lessons (or you ask it for parallel research).

This is the pattern I’m using right now to build this encyclopedia.

Pattern 15: Choose the model for the task

Don’t run Opus for everything. The mix:

  • Opus — planning, hard reasoning, long agent runs
  • Sonnet — most actual coding work
  • Haiku — quick lookups, simple yes/no, drafts you’ll heavily edit

Use /model to switch mid-session. Many tasks benefit from “plan with Opus → execute with Sonnet” specifically.

A concrete example: building a feature with these patterns

End-to-end for a typical feature:

1. Open a fresh session (Pattern 5).
2. State the goal clearly: "Add a dark-mode toggle to the navbar that persists across sessions."
3. Spawn Plan subagent (Pattern 11): "Plan the implementation."
4. Read the plan. Redirect if needed. Approve.
5. Switch to Sonnet (Pattern 15): "Execute the plan."
6. Watch the diffs. Interrupt if Claude veers (Pattern 7, 8).
7. Verify (Pattern 1): "Run the dev server and test the toggle works in both modes."
8. Read the final diff. Commit (Pattern 10).
9. Save any lessons learned as memory (Pattern 9).
10. Close the session. Open a new one for the next thing (Pattern 5).

Total time: maybe 20 minutes. Quality: production-ready. Confidence: high — because verification happened.

Anti-patterns to avoid

  • “Just trust the model” without verification. Path to subtle bugs.
  • Long sessions with many unrelated tasks. Context decays. Memory of decisions blurs.
  • Vague prompts and accepting whatever you get. Bad input, bad output.
  • Skipping the plan step for “small” changes. “Small” changes are often where bugs hide.
  • Committing only when “ready.” Hours of work lost when something goes wrong.
  • Letting Claude work in silence for 5 minutes without checking in. It might be going the wrong way the whole time.
  • Not reading diffs. You’re co-signing every line.
  • Never updating settings. Sessions stay frustrating forever.

See also

Sources

Graph View

Backlinks