My AI-Powered Coding Workflow: From Design to Deployment
The Modern AI-Assisted Development Stack
I rely on Claude Opus 4.6 and Sonnet 4.6 plus Cursor Composer 2 for planning and design, Mermaid as its own step for architecture and flow diagrams, VZero for UX/UI exploration, and Composer 2 first for implementation—then Sonnet 4.6 and sometimes Opus 4.6. I no longer route day-to-day work through OpenAI models; I only reach for them occasionally when I want a different angle on a tough reasoning problem. The product stack stays focused on React, Next.js, Tailwind CSS, TypeScript, and Node.js.
AI-Powered Development Tool Ecosystem
Planning & design
Diagrams
UX/UI design
Development
Advanced reasoning
Technology stack
1. Planning & design: Claude and Composer 2
The foundation of a solid app is clear requirements and architecture. I use Claude—usually Opus 4.6 for deep design threads or Sonnet 4.6 for faster iteration—and Cursor Composer 2 when I want planning tied directly to the repo. Composer is especially useful when the conversation needs file context, imports, and concrete constraints from the codebase.
What I use this phase for:
- Design patterns: MVC-style boundaries, server vs. client components in Next.js, where state should live
- Architecture: API shape, data flow, caching, and deployment boundaries
- Refactoring strategy: Safe sequencing, riskiest areas first, how to avoid big-bang rewrites
- Stack fit: Keeping choices aligned with React, Next.js, Tailwind, TypeScript, and Node.js
- Scalability: What will break first as traffic or data grows
I treat these tools as senior collaborators: I bring goals and constraints, they propose structures and tradeoffs, and we refine until there is a plan I can diagram and implement.
2. Diagrams: Mermaid as its own step
After the plan stabilizes, I translate it into visuals. Mermaid is a dedicated stage in my workflow—not bundled with UX tools—so architecture, sequences, and state machines stay separate from screen-level design. I generate and iterate on Mermaid with the same assistants I use for planning (Claude or Composer 2), but the artifact is diagram syntax I can drop into docs, MDX, or reviews.
Block diagrams
System overviews: services, boundaries, and how data moves between them.
Sequence diagrams
Ordered interactions—auth flows, webhooks, real-time channels—so edge cases are visible early.
Typical prompts look like: "Mermaid sequence diagram: Next.js server action validating input, calling Node API, persisting to DB, returning a typed result." Keeping Mermaid in its own lane avoids mixing structural diagrams with UI mock thinking.
3. UX/UI design: VZero
For screen-level work I use VZero (v0.dev). It is my primary place to explore layout, hierarchy, and interaction before I commit components in the app.
VZero workflow:
- Reference: Screenshots of current UI or rough wireframes
- Context: Snippets of React/Next structure when it helps
- Iteration: Alternative layouts, density, and component patterns
- Handoff to code: Strong designs often go straight to Composer 2 as screenshots or specs; Sonnet or Opus handles trickier component logic
VZero is focused on product UI; Mermaid stays on system structure. That separation keeps architecture diagrams honest and UI exploration fast.
4. Development: Composer 2 first, then Claude
Day-to-day implementation lives in Cursor. Composer 2 is my default for multi-file edits, refactors, and anything that needs broad context. When I need especially careful TypeScript, React patterns, or debugging, I switch to Claude Sonnet 4.6. For the hardest problems—subtle concurrency, security reviews, or ambiguous specs—I bring in Opus 4.6.
| Tool / model | Primary use | Why I reach for it |
|---|---|---|
| Composer 2 | Default coding, cross-file changes, scaffolding aligned to the repo | Cursor-native workflow with strong project awareness |
| Claude Sonnet 4.6 | Components, hooks, server/client boundaries, routine debugging | Fast, high-quality TypeScript and React output |
| Claude Opus 4.6 | Complex refactors, design-of-code, thorny bugs | Deeper reasoning when Sonnet or Composer needs backup |
5. APIs, Node, and occasional OpenAI
Backend work uses the same editor stack: Composer 2 and Claude on Node.js with TypeScript, keeping API handlers, validation, and shared types consistent with the Next.js app. I do not use OpenAI models in my default loop; I only open them occasionally when I want another model family on a genuinely difficult reasoning problem (after Opus has had a pass or in parallel for comparison).
APIs & server logic
Route handlers, middleware, and typed contracts between client and server—usually Sonnet 4.6 or Composer 2.
Data & performance
Query shape, caching, and Node-side hot paths—often Composer 2 across the repo, Opus 4.6 when tradeoffs are unclear.
Security
Auth boundaries, secrets handling, and review of risky changes—Opus 4.6 when the stakes are high.
Stack consistency
Tailwind for UI, TypeScript end to end, Next.js conventions for routing and data fetching.
The workflow in action: a real example
Here is how the same pipeline might run for a real-time collaboration feature:
End-to-End Development Workflow
Step-by-step:
- Planning (Claude / Composer 2): Chose WebSockets vs. SSE, outlined rooms and scaling assumptions
- Diagrams (Mermaid): Sequence diagrams for connect, subscribe, and broadcast paths—separate from any UI work
- UX/UI (VZero): Explored message threading, presence, and density on top of screenshots
- Frontend (Composer 2 + Sonnet 4.6): Composer for cross-file wiring; Sonnet for nuanced React state and types
- Backend (Composer 2 + TypeScript Node): Socket or API handlers with shared types from the Next app
- Hard edge cases (Opus 4.6, OpenAI occasional): Ordering, reconnect races, or ambiguous failure modes
Why a multi-model setup still helps
Even within mostly Anthropic + Cursor, using different models and tools for different jobs pays off:
- Right abstraction level: Diagrams vs. UI vs. code each get a fitting tool
- Composer vs. chat: Repo-grounded edits vs. open-ended reasoning
- Sonnet vs. Opus: Speed vs. depth when debugging or designing
- Occasional OpenAI: A second family of models when I want an extra perspective, not a daily dependency
Challenges and considerations
This workflow still has friction:
Pitfalls to avoid:
- Over-reliance: AI augments judgment; it does not replace ownership of correctness and security
- Context switching: Jumping between Composer, Claude, and VZero has a cost—batching similar work helps
- Conflicting advice: When models disagree, fall back to requirements, metrics, and incremental validation
- Review everything: Especially generated TypeScript and auth-related code
Looking forward
The toolchain will keep changing; the pattern I care about is stable: separate concerns (plan, diagram, UI, code), default to Composer 2 and Claude for implementation, and keep the product stack narrow—React, Next.js, Tailwind, TypeScript, Node.js—so assistants and humans share the same mental model.
- Richer codebase awareness: Agents that reliably span tests, config, and deploy scripts
- Testing: Generated suites that match real app behavior, not boilerplate only
- Ops: Safer automation around releases and observability
Key takeaway
Effective AI-assisted development is not about using every provider—it is about matching each phase to a tool that fits. I plan and design with Claude and Composer 2, visualize systems with Mermaid on its own, explore UI in VZero, ship code primarily with Composer 2 and Claude, and reserve OpenAI for occasional hard reasoning. A consistent React / Next.js / Tailwind / TypeScript / Node stack keeps the loop tight.
What is working in your workflow? The space moves quickly, and different teams optimize for different stacks—always interesting to compare notes.