Vercel CEO's AI Coding Workflow: 7 Key Principles

When AI coding assistants can generate a feature in minutes, the new question developers face is no longer "can it be built?" but "is what we're building still heading in the right direction?" In a deep-dive interview, the Vercel CEO shared his complete workflow for collaborating with AI agents, and a Bilibili creator systematically broke down the interview into seven directly actionable practices. These methods cover the entire chain from idea validation, direction correction, and security protection to a closed-loop customer feedback system. This article analyzes the logic and operational details behind each one.

Validate ideas with a minimal version, not just a "gut feeling"

The Vercel CEO noted that many people judge a model's quality by "gut feeling"—they hear that a certain model works better for a certain type of prompt and just go with it, never verifying for themselves. His approach: every time a new idea comes up, create a new project to test it, then have an independent agent check from scratch whether the idea is actually viable, rather than listening to what others say.

In practice, this logic corresponds to an MVP-first strategy. The creator shared his own approach: for each project, first create a specs folder containing the PRD document, listing the planned core features. But building the full application directly from a PRD is dangerous—directional errors permeate all early decisions, and by the time you notice, the cost of rework is already high. So the first step is always to have an agent like Claude Code build an MVP, using the least amount of code to verify "is this thing even worth building?" If the answer is no, abandon it early with minimal sunk cost.

Beware of "direction drift": don't measure progress by output volume

One of the most counterintuitive points in the interview: most people measure AI coding progress by token consumption or lines of code changed, but these numbers only tell you how much you did, not where you've gotten to. In the agent era this problem is magnified dramatically—building itself has become cheap, and any passing idea can turn into something that "looks like progress" within minutes, and the model won't stop you, because it only executes what you ask and doesn't understand which features actually matter for your product.

The solution is a custom command called direction. Tell the agent the path to your plan folder, and it assigns an independent agent to cross-check each requirements document, then the main agent aggregates and outputs a full report: whether the app has drifted from the plan, a drift score, and a to-do list. With the report in hand, you have two options—accept the drift and update the requirements documents, or roll back changes that deviated too far. The essence of this mechanism is turning the "plan" into an executable verification gate rather than a static document sitting in a folder.

Custom command is an extension mechanism provided by AI coding tools like Claude Code: users can create Markdown files in a specific project directory (usually .claude/commands/), where the filename is the command name and the file content is a prompt template. Afterwards, typing /command-name in the conversation causes the agent to load and execute the template. This effectively "solidifies" a fixed workflow into a reusable instruction, avoiding the need to manually re-describe it each time. The direction command mentioned in the article is implemented on this mechanism: it packages the multi-step process of "read the plan folder, assign sub-agents to each requirements document, aggregate and compare reports" into a single command, making direction verification a routine operation rather than a one-off action.

Security debt and quality debt: must be actively managed in the agent era

The challenge the Vercel CEO repeatedly emphasized is security debt—the volume of code written by agents far exceeds the capacity for human review, and attackers equally have cheap and efficient models to find vulnerabilities. His first rule: run a security scan immediately after a feature is complete. Vercel developed the DeepSec tool for this; after initialization it generates a configuration file, and then Claude runs the scan and outputs a full report.

The second rule is tiered management of "slop debt" (rough code accepted in the pursuit of speed). Small projects can tolerate a higher degree of roughness, but core modules must have a quality gate. Tests only answer "does it work"; a quality gate must also answer "is it good enough"—a review agent performs standard checks on every change, and nothing that fails can go live.

Define non-negotiables and pair every rule with a verification method

Every project involves trade-offs: adding features takes time, and shipping faster means sacrificing polish or cost. But some things cannot be traded. The Vercel CEO's advice is to create a dedicated "non-negotiables" section in the project's claude.md file, listing the baseline requirements the app must satisfy.

The key detail: agent context is long, and rules are easily forgotten. So every rule must be accompanied by a rule for "how to verify this rule is satisfied." Furthermore, verification test files can be committed to git so the agent cannot skip them. This complements the direction command mentioned earlier—the latter ensures direction doesn't drift, while the former ensures the baseline isn't broken.

claude.md is a configuration file that Claude Code reads in the project root, functioning like a "project manual" for the agent: it is automatically loaded into context at the start of each session, declaring project structure, tech stack conventions, coding standards, and prohibitions. Because it is committed with the repository, team members share the same constraints, keeping the agent's behavior consistent across the team. In practice it is usually kept concise—the more rules there are, the lower the "attention weight" of each individual rule in a long context, and the more easily it is ignored. This is also why the article emphasizes that "every rule must come with a verification method": declaration alone cannot guarantee execution; you must provide checkable criteria.

Let an agent actively attack your application

When launching the product, the Vercel CEO didn't just verify that features worked; he handed the product to an agent and asked it to simulate high-concurrency pressure to "cause trouble": concurrency conflicts, performance degradation, cross-product comparisons. The reason is straightforward: when models write code, writing code that "works when everything goes smoothly" is easy, but enumerating all failure paths is hard. When an agent tests its own work, it uses it the way it designed it to be used, so everything naturally passes; but real users don't use it that way.

The specific approach is to create a breaker agent whose sole job is to deliberately break the app and report every successful breach path. The creator highlighted an engineering detail: this agent makes a copy of the app's data when attacking, so real data is unaffected. After the attack, you can have the agent fix the issues and re-run the tests, or even enter a "find—fix" iterative review loop.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic that lets models connect to external tools and data sources in a standardized way. Each MCP server exposes a set of tools (such as reading email, querying error logs, accessing databases), and the model discovers and calls these tools through the protocol without writing separate integration code for each data source. The Gmail MCP and Sentry MCP mentioned in the article are examples: the former lets the agent read customer messages in the support inbox, and the latter lets it pull the app's exception monitoring data. The value of MCP is that it turns "feedback sources" into a toolset the agent can directly operate, enabling end-to-end automation of the path from bug report to fix.

Examine the product from the "first-time user" perspective

One of the metrics the Vercel CEO values most is the number of error-free sessions—the number of users who complete the flow without encountering any errors. This metric matters because developers can never be the first-time user of their own product: you know where every button is and what every page does, but new users know nothing. A confusing field on the signup page—you will never get stuck there, but a new user gets stuck and leaves immediately, and you have no way of knowing why.

The corresponding methodology is to create a "first-visit user" agent. The key constraint: this agent is forbidden from reading source code—through a hook, its bash tool is restricted to running the app only, and cannot edit or delete code. Once it can read the code, it is no longer a first-time user. In addition, an independent browser testing agent is needed to run through all customer-critical paths, record results step by step and save them as JSON, and run before each release to find stalling steps, broken links, and interrupted flows.

Hook in AI coding tools refers to an interception script automatically triggered before or after an agent performs a specific action. Once configured, whenever the agent attempts to call a tool (such as bash or file editing), the hook first runs custom logic and decides whether to allow or block based on the return result. This lets developers impose hard boundaries on the agent's capabilities rather than relying on soft constraints like "please don't..." in prompts—which are unreliable in long contexts. The article's "forbid the first-visit user agent from reading source code" is implemented precisely by using a hook to restrict the purpose of its bash tool: it can only run the app, and cannot edit or delete code, ensuring the agent's perspective stays close to that of a real new user.

Response speed to customer feedback is the best yardstick for AI usage

The interview's closing point is quite insightful: to judge whether a company is truly making good use of agents, just look at how it handles customer bug reports—did anyone reply seriously, was the cause investigated, were clear issues fixed, and how long did it take from report to fix.

Feedback comes in two types. Clear screenshot-level faults require no deliberation—the faster they're fixed, the better; but vague feedback like "I don't understand how to use this" cannot be directly converted into prompts and must first be understood through conversation with a human. Through MCP servers, Claude can be connected to feedback sources: the Gmail MCP reads support emails, and the Sentry MCP captures app errors (even if the customer didn't report them). Claude reads new reports one by one, directly fixes clear faults, and escalates judgment calls to humans. This chain turns "response speed" from a management slogan into an automatable engineering process.

The shared underlying logic of the seven principles

Looking at the seven suggestions together, they all point to the same core: in the agent era, building costs approach zero, and what is truly scarce is direction judgment and quality constraints. MVP validation, direction correction, the non-negotiables list, the breaker agent, the first-visit user perspective, the feedback loop—these mechanisms essentially put a steering wheel and brakes on "cheap building capability." The Vercel CEO repeatedly returns to the same criterion in the interview: don't look at how far you've run, look at whether you're running in the right direction. For teams bringing AI coding into production environments, this may be a more important principle than any specific tool.

One-line Summary

Vercel CEO's seven AI coding principles: once building becomes cheap, direction and quality constraints are what's scarce.

Paragraph Summary

The article systematically breaks down the Vercel CEO's complete workflow for collaborating with AI agents and distills seven actionable practices. The core argument: in the agent era, building costs approach zero; token consumption and lines of code changed only show how much you did, not whether the direction is right, and what is truly scarce is direction judgment and quality constraints. The seven methods cover the entire chain—validating ideas with an MVP, automatically correcting direction with the direction command, running a security scan immediately after a feature is complete and setting quality gates for core modules, listing non-negotiables in claude.md and pairing each rule with a verification method, using a breaker agent to actively attack the app, using a first-visit user agent forbidden from reading source code to uncover experience blind spots, and closing the customer feedback loop through MCP. The article concludes that the common essence of these mechanisms is putting a steering wheel and brakes on cheap building capability.