AI Coding Patterns: 10— 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 alone typically prevents 2-3 issues that would have required 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 80% 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: React 18 + 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.

AI quality degrades sharply when you ask for too many things simultaneously. The solution is radical focus: one function, one component, one responsibility per prompt.

The focused version produces dramatically better code — cleaner, more testable, and more likely to be correct. You add the next feature in the next prompt, building on a solid foundation.

When something is broken or needs improvement, always ask AI to explain the problem before implementing a fix. This ensures you understand the issue and can verify the fix addresses the root cause.

"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.

The complete AI coding pipeline, combining multiple patterns into one end-to-end workflow. Use this for any feature that takes more than 15 minutes to build.

Each step has its own prompt. The pipeline eliminates improvisation and ensures consistent quality regardless of the task. After using this pipeline for a few weeks, it becomes second nature — you don't think about the steps, you just follow the flow.

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 not to make decisions for you, but to structure decisions so you can make them faster and with more confidence. This is especially valuable when you're stuck choosing between approaches.

"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?"

The key question — "Which is best for MVP? Which is best long-term?" — forces AI to separate immediate needs from future needs, preventing over-engineering while ensuring a viable migration path.