Ship 10x Faster: The Exact AI Stack I Use to Build Frontend Projects in 2026

---

I'm going to say something that would've gotten me laughed out of a standup meeting two years ago: I don't write most of my frontend code anymore. I architect it, review it, steer it, and ship it — but the actual typing? That's the AI's job.

Before you roll your eyes — no, I'm not using ChatGPT to vomit out a create-react-app and calling it a day. I'm talking about a deliberate, multi-tool workflow where different AI tools handle different stages of development, each playing to its strengths. The result isn't "AI slop." It's production-grade code that passes PR review, follows our team's conventions, and ships to real users.

Here's the exact stack, the exact workflow, and the exact prompts. Steal all of it.

---

The Stack: Three Tools, Three Jobs

Let me be upfront — I don't use one tool for everything. That's the mistake most developers make. They pick Cursor OR Claude Code OR Copilot and try to make it do everything. Each tool has a sweet spot:

Tool	Role in My Workflow	Why It Wins Here
Claude Code	Architecture, planning, complex refactors, codebase-wide changes	200K token context, terminal-native, understands entire project structure, Plan Mode
Cursor	Multi-file feature implementation, rapid iteration, visual debugging	Agent Mode, IDE integration, inline diffs, built-in browser for testing
CLAUDE.md / .cursorrules / Skills	Making AI output consistent and production-grade	Persistent context, team conventions, reusable patterns

The third row is the secret weapon. Without project-level configuration files, AI tools produce generic, inconsistent output. With them, every generation follows your team's patterns automatically. More on this in a minute.

---

Phase 1: Architecture With Claude Code (Plan Mode)

Every feature starts in Claude Code's Plan Mode. Not Agent Mode. Not "just start coding." Plan Mode.

Here's why: when you let AI start writing code immediately, it makes architectural decisions implicitly — and those decisions are usually wrong for your specific project. By planning first, you get a reviewable artifact before a single file is touched.

My Actual Workflow

I open Claude Code in my terminal, switch to Plan Mode, and give it the full picture:

I need to add a real-time notifications system to our Next.js 15 app.

Requirements:
- WebSocket connection to our existing API at /api/ws
- Toast notifications for new messages, mentions, and system alerts
- Notification center dropdown in the header (unread count badge)
- Mark as read / mark all as read
- Persist notification preferences in user settings
- Must work with our existing AuthContext and our Zustand store pattern

Don't write code yet. Give me:
1. Component architecture (what components, where they live)
2. State management approach (what goes in Zustand vs local state)
3. Hook design (custom hooks and their responsibilities)
4. File structure
5. Potential gotchas with our existing SSR setup

Claude Code reads the entire codebase — the CLAUDE.md, the existing store patterns, the auth setup, the component directory structure — and gives me a detailed architectural plan. I go back and forth 2-3 times, asking questions, poking holes, adjusting.

The key insight from Boris Cherny (Claude Code's creator at Anthropic): "If my goal is to write a Pull Request, I will use Plan mode, and go back and forth with Claude until I like its plan. From there, I switch into auto-accept edits mode and Claude can usually 1-shot it. A good plan is really important!"

Once the plan is solid, I switch to auto-accept mode and Claude Code implements the entire feature — often in one pass across 8-12 files. It creates the components, the hooks, the store slice, the types, and wires everything together.

Why Claude Code Over Cursor For This Phase

Claude Code works in the terminal with your actual project. It has 200K tokens of context, so for a medium-sized Next.js app, it can hold the entire relevant codebase in memory. Cursor's Agent Mode is great, but its context window is smaller and it works best with scoped tasks, not full-project architectural reasoning.

Also — and this is underrated — Claude Code can run parallel sessions. I'll kick off one session implementing the notifications feature while another session writes the test suite for a different component. Boris Cherny runs five local sessions and 5-10 remote sessions simultaneously. I'm not that ambitious, but even two parallel sessions double my throughput.

---

Phase 2: Iteration With Cursor Agent Mode

Once the foundational feature is in place (from Claude Code), I switch to Cursor for the iteration phase. This is where Agent Mode shines — rapid multi-file edits with visual feedback.

Real Example: Polishing the Notification Component

The Claude Code output is architecturally sound but might need visual polish, edge case handling, or integration tweaks. I open Cursor, and use Agent Mode:

The notification dropdown closes when clicking "mark as read" 
because the click propagates to the overlay. Fix this and also:

1. Add a subtle entrance animation (slide down + fade in)
2. Group notifications by date (Today, Yesterday, Earlier)  
3. The empty state should show an illustration, not just text
4. Add keyboard navigation (arrow keys + Enter to open, Escape to close)

Cursor's Agent Mode reads the relevant files, makes coordinated changes across the component, the CSS, and the hook, then I can instantly preview the result in Cursor's built-in browser. The feedback loop is seconds, not minutes.

Why Cursor Over Claude Code For This Phase

Three reasons. First, inline diffs — I can see exactly what changed, accept or reject per-line. Claude Code works in the terminal, so reviewing changes requires git diff. Second, the built-in browser lets Agent Mode test its own changes visually. Third, Cursor 2.0's Composer model is optimized for fast, scoped edits. When I need to tweak a hover state or adjust spacing, I don't need a 200K context window — I need speed.

---

Phase 3: The Secret Weapon — Skills, Rules, and CLAUDE.md

This is where most developers leave 80% of AI productivity on the table. They use AI tools with zero project-level configuration and then complain that the output is "generic" or "doesn't match our patterns."

Configuration files are the difference between AI that writes random React and AI that writes your team's React.

CLAUDE.md — Claude Code's Memory

Every project I work on has a CLAUDE.md in the root. It persists across sessions and tells Claude Code how your team works:

# CLAUDE.md

## Project
Next.js 15 app with App Router, TypeScript strict, Tailwind CSS, Zustand for state.

## Conventions
- Components: functional, named exports, co-located with tests
- File naming: kebab-case for files, PascalCase for components
- Styling: Tailwind only, no inline styles, use cn() utility for conditionals
- State: Zustand slices in src/stores/, local state for UI-only concerns
- Data fetching: Server Components by default, 'use client' only when needed
- Tests: Vitest + React Testing Library, test files as component-name.test.tsx

## Patterns to Follow
- Use our ErrorBoundary wrapper for all page-level components
- Toast notifications via our useToast() hook, never window.alert
- All API calls go through src/lib/api-client.ts, never raw fetch

## Mistakes to Avoid
- Don't use useEffect for data fetching (use Server Components or use() hook)
- Don't create barrel exports (index.ts re-exports), import directly
- Don't use default exports except for page.tsx and layout.tsx

The "Mistakes to Avoid" section is gold. Anthropic's internal teams use this to document errors from past PRs, so Claude learns from real mistakes and never repeats them. Your CLAUDE.md should be a living document that grows with every code review.

.cursorrules — Cursor's Equivalent

Same concept for Cursor. Drop a .cursorrules file in your project root:

# Project Constraints
- Tech Stack: Next.js 15, TypeScript strict, Tailwind CSS, Zustand
- Always use App Router patterns (not Pages Router)
- Use Server Components by default, mark 'use client' explicitly

# Component Patterns
- Functional components with named exports
- Props interface defined above component, named {ComponentName}Props
- Use cn() from @/lib/utils for conditional Tailwind classes

# When generating tests
- Use Vitest + React Testing Library
- Test user behavior, not implementation details
- Use our renderWithProviders() wrapper from test-utils.ts

# Forbidden patterns
- No useEffect for data fetching
- No barrel exports
- No any types
- No inline styles

Agent Skills — Domain Knowledge on Tap

Both Claude Code and Cursor now support Skills (via SKILL.md files) — reusable domain knowledge that agents apply automatically when relevant.

I keep a skills/ directory with files like:

skills/react-patterns/SKILL.md

## Component Structure
- Keep components under 150 lines. Extract sub-components when exceeding.
- Co-locate hooks with their components unless reused elsewhere.
- Use composition over prop drilling. Prefer children and render props.

## Common Patterns
- Optimistic updates: use useOptimistic for any mutation the user sees
- Form submissions: use useActionState, not useState + onSubmit
- Loading states: use Suspense boundaries, not isLoading booleans

## Performance
- The React Compiler handles memoization. Don't add useMemo/useCallback.
- Use <Activity> for tab interfaces to preserve state.
- Lazy load below-the-fold components with React.lazy + Suspense.

When I ask the agent to "build a settings form," it automatically applies these patterns — using useActionState instead of the old useState triplet, skipping unnecessary memoization, and structuring the component exactly how our team expects.

This is the multiplier. Without skills and rules, you're prompting from scratch every time. With them, every generation starts from your team's best practices.

---

Real-World Walkthrough: Building a Dashboard Page

Let me walk through a real feature end-to-end to show how this all fits together.

The task: Build an analytics dashboard page with chart widgets, date range filter, and export-to-CSV functionality.

Step 1: Claude Code (Plan Mode) — 15 minutes

Plan the architecture for a new /dashboard/analytics page. It needs:
- Date range picker (preset ranges + custom)
- 4 chart widgets: revenue trend (line), user signups (bar), 
  top pages (horizontal bar), conversion funnel (custom)
- Each widget should load independently with its own Suspense boundary
- Export all visible data as CSV
- Respect our existing permission system (only admin and analyst roles)

Use our existing chart library (recharts) and our API client pattern.
Plan only, no code.

Claude Code produces a detailed plan: component tree, data flow, which API endpoints to call, which parts are Server vs Client Components, the Zustand slice for date range state. I tweak a few things, approve the plan.

Step 2: Claude Code (Auto-Accept Mode) — 20 minutes

I switch to auto-accept and Claude Code implements: the page component, 4 chart widget components, the date range picker, the export utility function, the Zustand slice, and the TypeScript types. Across 11 files. It follows every convention from CLAUDE.md.

Step 3: Cursor (Agent Mode) — 30 minutes

I open the project in Cursor and iterate:

• "The revenue chart needs a loading skeleton that matches the final chart dimensions"

• "Add a tooltip to the conversion funnel that shows drop-off percentages"

• "The date range picker should remember the last selection in localStorage"

• "Make the export button disabled with a spinner while generating CSV"

Each prompt → Agent Mode edits 1-3 files → I preview in the built-in browser → accept or adjust. Tight loop.

Step 4: Claude Code (Testing) — 10 minutes

Back to Claude Code for the test suite. One prompt:

Write tests for the analytics dashboard. Cover:
- Each chart widget renders with mock data
- Date range filter updates the store and triggers refetch
- Export generates correct CSV from current data
- Permission gate redirects non-admin users
Use our existing test patterns.

Claude Code generates comprehensive tests following our renderWithProviders() pattern, using the mock data factories we already have. It runs them, fixes the two that fail, and I'm green.

Total time: ~75 minutes for a full analytics dashboard with 4 chart types, filtering, export, permissions, and tests. A year ago, this was a 2-3 day task.

---

The Honest Take: Where AI Still Falls Short

I'd be lying if I said this workflow is flawless. Here's where I still spend most of my human time:

Design decisions. AI can implement a date picker, but it can't tell you whether your dashboard should use cards or a dense data table. UX taste is still 100% human.

Edge cases the AI can't see. What happens when the WebSocket disconnects mid-session? What if the CSV export runs on a dataset with 100K rows and the browser tab freezes? AI handles the happy path brilliantly. You handle the "what could go wrong" thinking.

Code review is non-negotiable. I review every AI-generated PR with the same rigor as human-written code. AI is a brilliant junior developer who writes fast and confidently, but still makes subtle mistakes — especially around race conditions, security boundaries, and accessibility.

Third-party library integration. AI sometimes generates code for outdated API versions or invents methods that don't exist. Always verify against the actual library docs.

The workflow isn't "AI replaces me." It's "AI handles the 70% of coding that's pattern-matching, so I can focus on the 30% that's actual engineering."

---

Getting Started: The Minimum Viable Setup

If you want to try this workflow, here's the simplest starting point:

1. Create a CLAUDE.md in your project root. Even 10 lines about your tech stack and conventions will dramatically improve Claude Code's output. Add to it every time you correct the AI.

2. Create a .cursorrules file. Same idea for Cursor. Your conventions, your forbidden patterns, your testing setup.

3. Use Plan Mode before Agent Mode. Whether in Claude Code or Cursor, always plan before executing. The 5 minutes you spend on a plan saves 30 minutes of fixing bad architectural decisions.

4. Match the tool to the task. Architecture and big refactors → Claude Code. Rapid iteration and visual polish → Cursor. Quick inline completions → Copilot. Don't force one tool to do everything.

5. Invest in skills files. Every time you correct the AI, ask yourself: "Can I encode this in a skill so it never makes this mistake again?" Over time, your skills become your team's collective knowledge, and every AI session starts smarter.

---

The Bigger Picture

We're at an inflection point. The developers who are thriving in 2026 aren't the ones who write the fastest code — they're the ones who direct AI the most effectively. That's a different skill set. It's part prompt engineering, part systems thinking, part having the taste to know when AI output is good enough and when it needs a human touch.

The tools will keep getting better. Claude Code is getting plugins, MCP servers for Figma-to-code, and parallel agent teams. Cursor 2.4 shipped subagents, cloud execution, and skill files. The gap between "developer who uses AI" and "developer who doesn't" is already wide. The gap between "developer who uses AI well" and "developer who uses AI poorly" is about to be just as wide.

Invest in learning the tools. Invest more in learning when and how to use them. Your CLAUDE.md and .cursorrules files are now as important as your tsconfig.json.

Now stop reading and go set up your project files. Your AI is only as good as the context you give it.

---

Found this useful? Follow for more AI-powered dev workflows. If you've got a CLAUDE.md or .cursorrules setup that works well, drop it in the comments — I'm always looking to steal good patterns.