AI Coding Patterns: Repeatable Workflows

The foundational pattern. Instead of jumping to code, you design first, then ruthlessly critique the design, then implement. The critique step catches architectural mistakes before they become expensive code.

Step 1: "Design a solution for [feature]. Show me the
         component structure and data flow."

Step 2: "Now critique this design. What's wrong with it?
         What will break at scale? What did you miss?"

Step 3: "Improve the design based on those critiques."

Step 4: "Now implement it, following the improved design."

Result: Fewer bugs, better architecture, less rework. The critique step consistently surfaces issues that would otherwise require debugging later.

Simulate an entire development team by switching AI roles across the workflow. Each role brings a different analytical lens to the same code.

Round 1 — Senior Backend Engineer:
"Design the API endpoints and data model."

Round 2 — Security Engineer:
"Review this design for vulnerabilities."

Round 3 — Performance Engineer:
"Where will this hit bottlenecks at 1000 concurrent users?"

Round 4 — QA Engineer:
"What test cases are needed? What edge cases exist?"

Synthesis: "Combine all findings into a prioritized action list."

This pattern is especially powerful for solo developers who don't have access to a real team of specialists. You get much of the value of multi-person review in a fraction of the time.

At the start of every session, establish a "context lock" — a summary of the project that anchors all subsequent prompts. This prevents AI from making wrong assumptions or drifting to generic solutions.

PROJECT CONTEXT (paste at session start):

Project: Family Schedule Planner
Stack: the project's declared React version + TypeScript, Zustand, Express, MySQL
Principles: simplicity first, mobile-responsive, accessible
Current state: Milestones 1-5 complete (calendar, CRUD, filters)
Working on: Milestone 6 (member-specific views)

Key types:
- Activity { id, name, day, time, member, color }
- FamilyMember { id, name, color, avatar }

All code should follow existing patterns in the codebase.

The context lock saves you from repeating project details in every prompt. It also prevents the common issue where AI generates code that's technically correct but doesn't match your project's patterns, stack, or conventions.

Large requests create more assumptions and make review harder. Split work into coherent, testable units while retaining enough system context to avoid locally correct but incompatible changes.

The focused version is easier to review and test. Add the next behavior only after the current increment meets its acceptance criteria.

When something is broken, ask for likely causes and ways to distinguish them before changing code. Then verify the chosen fix against the observed failure and regression tests.

"Fix this bug."

    "This component re-renders every second even when
   data hasn't changed.

   Step 1: Explain WHY this is happening.
   Step 2: Propose 2-3 possible fixes with trade-offs.
   Step 3: Implement the best fix."

Skipping the explanation step is how developers accumulate fixes they don't understand — patches on patches that eventually collapse. The explain-first approach builds understanding alongside working code.

Don't save refactoring for later. After every significant milestone (every 2-3 features), pause and refactor. This prevents technical debt from accumulating to the point where refactoring becomes a major project in itself.

After completing milestone 4:

"Review the code we've built in milestones 1-4.

What would a senior developer improve?
Focus on:
- Functions that have grown too long
- Duplicated logic that should be extracted
- Naming that no longer reflects current behavior
- Components that have accumulated too many responsibilities

Fix the top 3 issues. Leave the rest for now."

The "fix the top 3" constraint is important. It prevents refactoring from becoming an open-ended time sink while still keeping the codebase healthy.

This pipeline combines several patterns into one end-to-end workflow. Use it when the cost of a wrong direction justifies explicit planning, critique, review, tests, and refactoring checkpoints.

Each step has its own prompt and completion check. The pipeline reduces skipped stages, but its depth should match the task and it cannot ensure quality by itself.

Periodically ask AI to reflect your project back to you — summarizing what's been built, surfacing hidden assumptions, and identifying where the architecture has drifted from the original plan.

"Summarize everything we've built so far in this session.

Then answer:
- What assumptions are we making that might not hold?
- Has the architecture drifted from the original plan?
- What technical debt have we accumulated?
- What should we address before adding more features?"

Ask AI for more than you need, then simplify. This is counterintuitive but consistently effective — it's easier to remove complexity than to add it. The expanded version reveals the full possibility space, and the reduction step ensures you keep only what matters.

Step 1: "Build a comprehensive activity form with
         all possible fields: name, description, day, time,
         duration, recurring, priority, tags, color, member,
         location, notes, attachments."

Step 2: "Now simplify this to the minimum viable version.
         Keep only fields essential for the core use case.
         Remove everything that isn't needed for MVP."

Step 1 gives you a complete picture of what's possible. Step 2 forces disciplined reduction. The result is a form that's simple but informed — you know what you left out and can add it later if needed.

Use AI to structure a decision, not to make it for you. Explicit criteria, assumptions, and evidence can support a timely choice when several approaches remain credible.

"I'm deciding between these two approaches:

A: Store activities in Zustand with local persistence
B: Store activities in MySQL with API calls

Help me decide by analyzing:
1. User experience (latency, offline support)
2. Data integrity (conflict resolution, backups)
3. Implementation complexity (for one developer)
4. Migration path (if I start with A, how hard to move to B?)

Which is best for MVP? Which is best long-term?"

Comparing immediate needs with longer-term assumptions can reveal over-engineering or migration risk. Verify that any proposed migration path is technically and operationally realistic.