The New AI Coding Stack I Would Pick Today

If I were rebuilding my AI coding setup today, I would not start with the question most people ask.

The question is usually:

Which AI coding tool should I use?

That question is too small now.

The useful question is:

Which stack gives me fast local edits, long-running delegation, app-level agents, reviewable logs, and bounded cost?

That is a stack question, not a tool question.

As of May 30, 2026, this is the stack I would pick. If you want the update filter before the shopping list, read the model, IDE, CLI, and agent framework changes that actually matter.

Sources Worth Reading

Pricing and access change quickly. Treat the exact plan numbers as a source check, not timeless advice.

The Stack

Here is the short version.

This is not the cheapest stack.

It is the stack I would choose if I cared about shipping speed without giving up review, security, and cost discipline.

The Take

The best AI coding setup is no longer one subscription.

It is a layered workflow:

Cursor for active editing.
Claude Code for local autonomous work.
Codex for background delegation.
Mastra for product agent backends.
CopilotKit for agent-facing product UI.
MCP for tools.
Run ledgers for trust.
Usage ledgers for cost.

That sounds like more moving parts than "just use one tool." It is.

But serious work already has different shapes.

Some work needs a tight feedback loop. Some work needs a terminal agent that can run tests and inspect the repo. Some work should happen in a sandbox while you do something else. Some work needs an agent inside your product, not your editor. Some work needs audit trails because the agent can touch real systems.

One tool will not be best at all of that.

The stack wins because each layer has a job.

Layer 1: Claude Code for Local Agent Work

Claude Code is still my default heavy-lift agent.

The reason is not that every answer from Claude is magic. The reason is architectural: it lives in the terminal, sees the repo, runs commands, uses MCP, and fits naturally into the way senior engineers already work.

Use it for:

• multi-file implementation,
• refactors,
• test repair,
• migration prep,
• repo exploration,
• writing focused docs from code,
• spawning subagents across independent slices.

If I could only buy one premium coding subscription for serious local engineering work, I would still start with Claude Code Max.

The caveat is cost and capacity. Anthropic's Max plan gives 5x or 20x usage options, and the May 2026 compute update increased Claude Code limits. That helps, but it does not remove the need for discipline. Claude Code can burn through context quickly when the task is vague or the repo is large.

So my rule is simple:

Use Claude Code for work where shell access and repo-wide judgment matter.
Do not use it as an expensive autocomplete engine.

Layer 2: Cursor for Visual Editing

Cursor is still the editor I would keep open next to the terminal.

Not because it replaces Claude Code. It does not.

Cursor is the visual loop:

• adjust a component,
• inspect diffs,
• accept one hunk and reject another,
• refine CSS,
• ask a question about open files,
• keep momentum while you are actively shaping the code.

Claude Code is better when I want to hand off a bounded task and come back to verified output. Cursor is better when I am still making taste decisions.

This split matters especially on frontend work. Visual polish, information density, responsive layout, and copy rhythm usually need iteration. A terminal agent can do the work, but the editor loop makes the review cheaper.

My default:

Claude Code builds the first working version.
Cursor sharpens the visible surface.

Layer 3: Codex for Background Work

Codex is the background lane.

OpenAI's Codex app is explicitly framed around multiple agents, worktrees, skills, automations, and review queues. The product direction is clear: not just "write code for me," but "let me supervise many agent runs."

Use Codex for work that can be isolated:

• issue cleanup,
• documentation backfill,
• small bug fixes,
• tests for stable code,
• dependency research,
• migration drafts,
• parallel implementation attempts.

The important word is isolated.

Codex is most useful when the job can run in its own workspace and come back with a reviewable artifact. If the task depends on your local database, private machine state, live app session, or messy uncommitted work, Claude Code or Cursor will usually be a better fit.

My default:

Codex gets background tasks with clear acceptance criteria.
Claude Code gets local tasks with live repo context.
Cursor gets active editing and polish.

Layer 4: GitHub Copilot When Governance Matters

GitHub Copilot is no longer only the autocomplete brand.

The official plan docs now surface Copilot cloud agent, agent mode, code review, MCP, third-party agents, AI credits, policy control, and enterprise rollout. That makes Copilot most interesting for teams that already live in GitHub and need governance more than another standalone coding agent.

For solo developers, I would not make Copilot the center of the stack unless you strongly prefer GitHub-native workflows.

For companies, I would evaluate it differently:

• Can admins control which agents and models are available?
• Can usage be tracked by org, team, or user?
• Can repository policies prevent risky agent access?
• Can agent work remain inside normal PR review?
• Can finance understand the AI credit model?

That is Copilot's real lane: governed adoption at scale.

Layer 5: Next.js, Clerk, and Convex for Product Plumbing

The application stack still matters because agents inherit your architecture.

If your app stack is messy, every agent task becomes harder. If auth is custom, billing is custom, database access is custom, and deployment is custom, the agent spends more effort rediscovering private patterns.

For most new AI products, I would start boring:

• Next.js for the app,
• Vercel for deploys,
• Clerk for auth and organizations,
• Convex or Supabase for backend data,
• Stripe only when the pricing model is ready.

That is close to the existing agentic dev stack and solo developer AI toolkit, but with one update: I would now separate app plumbing from agent plumbing.

The product app needs users, routes, auth, billing, data, and deployment.

The agent system needs workflows, tools, memory, evals, traces, approval, and rollback.

Do not blur those two too early.

There is a middle lane too: simple AI features.

If the feature is a chat box, extraction endpoint, autocomplete helper, or one-step tool loop, I would start with a lightweight TypeScript SDK such as the Vercel AI SDK before introducing Mastra. The SDK lane is for "the model responds." The Mastra lane is for "the agent runs a process."

Layer 6: Mastra for Backend Agent Workflows

Mastra is the backend agent framework I would reach for first in a TypeScript product.

Not for every AI feature.

For a simple chat endpoint, use the simplest SDK that works. A direct model call or Vercel AI SDK route is often enough.

Use Mastra when the agent run starts needing structure:

• workflow steps,
• branches,
• parallel execution,
• memory,
• typed tools,
• MCP,
• suspend/resume,
• evals,
• tracing,
• runtime context,
• guardrails.

The line is this:

If the feature is one response, keep it simple.
If the feature is a repeatable agent process, use Mastra.

The practical example is customer support, sales ops, internal research, codebase analysis, or product onboarding. Those are not one prompt. They are processes with decisions, data access, human checkpoints, and audit requirements.

That is where Mastra belongs.

Layer 7: CopilotKit for the Agent UI

CopilotKit is where I would put the user-facing agent interaction.

This is the most common mistake in agent app architecture: teams build a decent backend agent, then expose it as a generic chat box. The user cannot see state, cannot approve the risky step in context, cannot inspect tool output cleanly, and cannot steer the run except by typing another paragraph.

CopilotKit and AG-UI are aimed at that boundary.

Use CopilotKit when the app needs:

• shared state between UI and agent,
• custom tool-call rendering,
• human-in-the-loop approvals,
• agent progress in the product surface,
• generative UI components,
• a frontend layer around Mastra, LangGraph, or another backend agent.

This is why CopilotKit is the UI layer, not the whole agent framework.

My default architecture:

Mastra handles backend agent workflow.
CopilotKit handles user-agent collaboration.

That pairing is more useful than forcing either tool to do the other's job.

Layer 8: MCP for Tool Access

MCP is the default tool protocol layer.

The practical value is not "install 80 servers." That is how you create a security problem and a context tax.

The practical value is portable tool access:

• docs,
• database reads,
• local files,
• ticket systems,
• GitHub,
• observability,
• internal APIs.

My rule:

Start with three MCP servers maximum.
Each one needs a reason, a permission boundary, and a rollback story.

For most developers, the first three are:

1. filesystem or repo docs,
2. GitHub,
3. one product-specific service.

Anything beyond that should earn its place.

Layer 9: Context as Infrastructure

The new stack needs a context layer.

Not a giant prompt. Not a dumping ground.

A useful context layer has:

• project instructions,
• skills,
• local docs,
• code maps,
• route maps,
• known runbooks,
• source links,
• decision records.

This is where the older advice about CLAUDE.md, Cursor rules, skills, and MCP starts to converge. The model is not the memory system. The repo should carry the memory system.

For larger repos, I would also test local code graphs or indexes. The goal is not to make the graph the source of truth. The goal is to route the agent toward the right files before it wastes a thousand tool calls rediscovering the same structure.

That is the shape behind local code graphs as the next agent context layer.

Layer 10: Security as a Run Ledger

The stack is incomplete without a security loop.

Every meaningful agent run should produce a small ledger:

goal:
agent:
workspace:
permissions:
files touched:
commands run:
external tools used:
approvals requested:
tests passed:
known risks:
rollback:

This does not need to be fancy. It can live in a PR description.

But it needs to exist.

OpenAI's prompt injection guidance makes the key point: you cannot rely only on filtering hostile content. You need to limit what a manipulated agent can do. For coding agents, that means permissions, tool boundaries, logs, approvals, and rollback.

The run ledger is the smallest practical artifact that ties those together.

Pair it with permissions, logs, and rollback and the agent security checklist.

Layer 11: Cost as a Monthly Ritual

AI coding costs are not a subscription line anymore.

They are workload costs.

The same $20 or $200 plan can be cheap or expensive depending on what you use it for. A good agent run can replace a day of work. A bad run can burn context, rewrite working code, and create a review queue.

So I would track:

• cost per shipped feature,
• cost per merged PR,
• failed run rate,
• median review time,
• number of agent runs abandoned,
• expensive model usage by task type.

Then once a month, change the stack.

That is the point of the Q2 pricing update and AI cost calculator: stop treating pricing pages as the plan. Your workflow is the plan.

The Three Stack Versions

Not everyone needs the same setup.

Bootstrap Stack

Use this when money matters more than maximum throughput:

The goal is to ship the first version without creating a monthly bill you resent.

Serious Solo Stack

This is what I would use for a solo developer shipping real products:

This is the highest leverage stack for a builder who can review their own work.

Small Team Stack

Use this when multiple people, repos, and policies are involved:

The team version is not about giving everyone every tool. It is about matching tools to lanes.

What I Would Not Do

I would avoid four traps.

1. Do Not Standardize Too Early

Run one month of real work before declaring a company-wide standard.

Teams often standardize on the tool with the best demo. Then the real cost shows up in review time, usage limits, environment setup, and unmerged agent PRs.

2. Do Not Build Every Agent App as Chat

Chat is a fallback UI.

If the agent is doing structured work, show structured state. Show the plan. Show the tool calls. Show the approval card. Show the diff. Show the receipt.

That is why CopilotKit matters.

3. Do Not Use Mastra for One Model Call

Mastra is useful when the agent needs workflow infrastructure.

If all you need is one streamed answer, do not add a framework because it feels more serious.

4. Do Not Connect Tools Without a Ledger

The moment an agent gets tools, the product changes.

It can do things now. That means it needs scope, logs, and rollback.

The Stack I Would Pick Today

For my own work, the answer is:

Claude Code Max
Cursor Pro
Codex for background tasks
Next.js + Vercel
Clerk
Convex or Supabase
Mastra for backend agent workflows
CopilotKit for product agent UI
MCP with tight allowlists
local repo context and skills
run ledgers
monthly cost review

The important part is not the exact vendor list.

The important part is the separation of jobs.

One layer writes and edits. One layer delegates. One layer owns the product backend. One layer exposes the agent to users. One layer controls tools. One layer records what happened.

That is the new AI coding stack.

Not a magic assistant.

A workflow system you can operate.