ninja nerdingGuillermo Rauch's agentic engineering workflow
Guillermo Rauch's agentic engineering workflow
Guillermo Rauch runs Vercel and made Next.js. In a 98-minute talk with David Ondrej he opens his terminal and shows how he works with agents now. The short of it: a tiny agent in the terminal, a folder that remembers, and a person who sets the rules before and asks questions after.
Jump to the workflow map, the tools, or try it yourself. Want the checks he describes, built in Claude Code? See the kit, from a second video by AI LABS.
The video
98 minutes, posted Oct 2, 2026. The screen share shows Sept 23. Every timestamp on this page opens the video at that moment. The video has no chapters, so these are ours. A second, shorter video below turns the talk into checks you can build.
- 0:33 What matters after AGI: staying in control
- 4:12 Sponsor read: Supabase (until 5:27)
- 5:27 Where the advantage is: timing and your own evals
- 11:36 The software factory: from customer signal to fix
- 17:41 Speed vs velocity, build vs buy
- 20:32 Ondrej's own product: Cloudroom (until 21:38)
- 21:38 His setup: try everything, AI Gateway, the spend meter
- 23:05 From a deploy CLI to Claude Code to fx
- 28:06 Files are all you need: Drives, the r and p aliases
- 31:35 Models, libfx and the FX0 demo: brain and hands
- 37:20 The human is the limit: three ways to work with agents
- 39:50 Planning live, and verification engineering
- 42:59 What to learn: concepts and latency numbers
- 50:06 Reject non-understanding: agentic inquiry
- 54:38 Tech debt and slop debt
- 58:42 Know your customer: flags, metrics, production data
- 61:35 deepsec and why old code is exposed
- 69:00 Open source or write your own
- 71:57 Cloud agents, and why local stays
- 76:10 What to build now
- 81:35 Keeping a high bar, hype and fear
- 93:00 Infrastructure vs apps, and starting from zero
Second video · AI LABS · 14 min · posted Oct 19, 2026
- 0:00 Intro
- 0:51 Test ideas first
- 2:18 Stay on course: the /direction command
- 4:01 Sponsor read: Viktor (until 4:57)
- 4:57 Security debt and slop debt
- 7:14 Non-negotiables in CLAUDE.md
- 8:33 The breaker agent
- 10:26 The first-time user agent
- 12:42 Customer feedback triage
A software company's channel picks seven tips from the same interview and builds each one in Claude Code on a sample booking app. Chapters are theirs. Their part is on this page under Build it in Claude Code.
Eight signals
The whole talk in eight boxes. Each links to the part of this page that explains it.
- 010:33
The job is staying in control
The work moved up a level: you run the harness, the factory, the fleet of agents. His whole setup is built so a person still decides what's good.
How - 0229:41
One letter starts an agent
He types r and an agent opens in his research folder. He types p and a new project starts. Nothing sits between the idea and the agent.
How - 0329:20
A folder and a rule file are the memory
An AGENTS.md in the folder tells the agent what to do and where to save. A small program plus the file system is all an agent needs.
How - 0434:12
Brain and hands
The harness is the brain. You give it hands: a sandbox to run code, a drive to keep files, a browser to look at the result.
How - 0540:20
Before: set the guardrails
He calls it verification engineering. Agree the rules, limits and trade-offs with the agent first. Skip the tiny unit tests.
How - 0651:53
After: ask what just happened
He calls it agentic inquiry. You don't read every line. You have the agent explain, draw and measure its own work.
How - 0712:41
Grade yourself on signal to fix
A customer reports something clearly broken. How long until the fix ships? That number tells you how agentic your company is.
How - 0861:35
Old code is exposed. Scan it and sandbox it
Models find holes in human-written code fast and cheap. He scans with agents, builds in cloud sandboxes and wants core libraries rewritten in safer languages.
How
Words on this page
Twenty-three terms, in plain words. Skip this if you already work with coding agents.
- Alias
- A short word you set up in your terminal that runs a longer command. His r opens the agent in his research folder. His p makes a new project folder and opens the agent in it.
- Harness
- The program around a model that sends it your request, runs the tools it asks for, reads what came back and tries again. Rauch calls it the brain. fx is his.
- Token
- The unit AI models count and charge in. Every request and every reply costs tokens, so an agent can't spend unlimited amounts on every task.
- Verification engineering
- Rauch's name for your job before the agent builds. You and the agent agree what must always be true, which limits you won't give up and what you'll trade. Those become the checks.
- CI
- Short for continuous integration: the automatic checks that run on a change before it's merged. More time in CI is one of the trades he says you might accept.
- Agentic inquiry
- Rauch's name for your job after the agent is done. You don't read every line. You have the agent explain, draw and measure what it changed.
- Public API
- The parts of a project that other people's code depends on, such as a route, an exported function, a command-line flag or a config key. Change one and someone else's work can break.
- Slop debt
- Tech debt is the cost of shortcuts you'll pay back later. Slop debt is the same thing built from rough code an agent wrote. His advice is to pick where you take it on.
- Vibe coding
- Building with an agent and accepting what it writes without much checking. He says it's fine in some places, and that you should do the opposite wherever security or customer data is involved.
- PR
- Pull request: a proposed change to the code, waiting to be reviewed and merged. Landing lots of them measures speed, he says, not velocity.
- Software factory
- Agents and people set up so a signal, like a customer's bug report or an error on the live site, turns into a shipped fix. He grades it on how long that takes.
- Supply chain attack
- Harm that arrives inside someone else's package you install, then runs with access to your machine. He argues that building in cloud sandboxes keeps a bad package away from your laptop.
- Memory-safe language
- A programming language that is safe by how it's built, not by luck. He names Rust and wants core libraries, like the C and C++ ones inside image pipelines, rewritten in languages like it.
- PRD and specs
- A product requirements document: what the app is for, its goals and its non-goals. AI LABS keeps it in a specs folder next to one doc per feature. Their /direction command checks the code against it.
- MVP
- Minimum viable product: the first rough version that works, built to see if the idea holds up before you build the whole thing.
- Slash command
- A saved prompt you run by typing / and its name, like /direction. In Claude Code it's a Markdown file in .claude/commands/.
- Subagent
- A helper agent with its own instructions, tools and fresh memory, which the main agent hands a job to. In Claude Code it's a Markdown file in .claude/agents/. The breaker and first-timer are subagents.
- Hook
- A small script that runs automatically at a set moment, such as before the agent uses a tool. It can block the action. AI LABS uses one to keep the first-timer agent out of the code.
- MCP server
- A connector that lets an agent use another app, such as your email or your error tracker. MCP stands for Model Context Protocol.
- Quality gate
- A check every change has to pass before it goes live. A test says whether something works; a gate, such as a review agent, also says whether it's good enough.
- Race condition
- A bug that only shows up when two things happen at the same moment, like two people booking the last slot at once.
- Error-free session
- One visit where a person gets all the way through what they came to do with nothing going wrong. Rauch's favorite number for knowing your customer.
- Sentry
- A service that records every error your live app hits, even ones no customer reports. It has an MCP server so an agent can read them.
Everything he names
Vercel doesn't tell its engineers which agent or model to use. His own advice is to try everything, models most of all. Most of what he reaches for is Vercel's own, and a lot of it is open source. 21:38
At the terminal
The coding agentVercel Labs · open source
fx
A coding agent that looks and feels like a shell. It starts about as fast as one, works with any model, and is meant to stay small. The download is about 6.5 MB. On screen it reads v0.0.11.
The terminalOpen source
Ghostty + zsh
He opens a new tab or split and it lands in zsh. fx runs inside it. Two one-letter aliases start most of his work.
The rule fileA plain text file
AGENTS.md
A file in a folder that tells the agent how to behave there. His research folder has one: read the instructions, answer, save the research in this folder.
Models
Every model, one accountVercel
Vercel AI Gateway
One account that reaches models from many companies. He says it's Vercel's fastest growing product, with no markup on model prices. fx uses it by default.
Menu bar appVercel, internal
The spend meter
Every Vercel engineer gets a menu bar app showing what they spent on each model. On his screen it reads 37.41k and $7.96.
What he was testingAnthropic
Opus 5.5 fast
He tries every new model. That week it was Opus 5.5 in fast mode, which is the default in his FX0 demo. Speed matters most for live back-and-forth.
Hands for the agent
A computer for the agentVercel
Vercel Sandbox
A small, sealed Linux machine in the cloud where an agent can run code. Start many at once. If one goes wrong, your laptop is untouched.
A disk that outlives the sandboxVercel · beta
Drives
A file system in the cloud. Attach it to a sandbox, let agents work on it, attach it again later. Announced the day this was recorded.
Eyes for the agentBrowserbase or Kernel
A browser
His demo has no browser, and he says the model does better with one. Run it inside the sandbox or use a hosted one.
Agents inside your own app
fx as a libraryVercel Labs · open source
libfx
The same agent, as code you put inside your own product. One call, createFxAgent, replaces the harness Vercel spent years building for v0.
The demoVercel Labs · not public yet
FX0
A small v0-style builder made with libfx. He says it's about 100 lines on top of the library. Three modes: design, app, agent.
Agent frameworkVercel · open source
eve
Vercel's framework for building agents. FX0's agent mode makes one from a prompt.
Security
Security scan, run by agentsVercel Labs · open source
deepsec
Points coding agents at your code with one job: find the holes. For big code it spreads the work across sandboxes.
Which model finds holesVercel
DeepsecBench
A public scoreboard. Each new model is run through deepsec and ranked by what it finds and what it costs. A new round went out the day of the recording.
Production
Production data for agentsVercel CLI
vercel metrics, vercel traces
Vercel is turning its dashboards into commands, so an agent can read what's happening on the live site before it changes anything.
Careful rolloutAny provider
Feature flags and experiments
Ship to a few people first and compare. He points to the Claude Code team as people who work this way.
The agent pings youA connector
Slack MCP
A rule in AGENTS.md: if a change alters the public API, message me. He's seen others set this up and calls it better than auto-merging everything.
Also named, not part of the setup
- NeovimHis editor for years. Why a terminal agent was the natural next step.24:00
- Claude CodeThe step before fx. He liked how little there was to it at first. His complaint now is the wait at startup.24:11
- try, by Tobi Lütke A small tool that gives every experiment its own folder. His p alias does the same job.30:12
- PiOndrej brings it up as the closest small agent to fx.25:43
- Cloudroom Ondrej's own open source project for running agents in the cloud. A plug, not part of Rauch's setup.20:32
- SupabaseThe video's sponsor. Not part of the workflow.4:12
The workflow map
Seven steps in a loop, plus three lanes beside it. Darker boxes are the steps that need you: four of the seven. Click any box to read it, or press Start and follow one real experiment.
The loop · one piece of work · darker boxes need you
Beside the loop
Follow one experiment through the loop
Six beats, using a test Rauch describes: the day Vercel announced Drives, he had an agent try to break it. Watch which boxes light up, and which one gets skipped.
The loop · step 1 of 7 · You
Watch at 29:41Open an agent in one letter
He types one letter in the terminal. r jumps to his research folder and opens fx there. p makes a new folder in his projects folder and opens fx in it. Then he types the question or the idea.
Why: Speed. He wants the thought out of his head at once. fx was built to start as fast as a shell so there's no wait and no app to find.
What you see
A terminal split with an fx prompt, already in the right folder.
Watch out
The video shows the aliases being used, not how they're written. Ours are in the next section. Any terminal agent works.
Rauch never lays the steps out in a row like this. They come from things he says across the talk, and the order is ours.
Two habits to copy
A one-letter alias and a rule file. This is the part of his setup he shows from start to finish. The video shows them in use, not how they're written, so the starters below are FakeNerd's. 29:20
r
Ask anything
Goes to ~/projects/research and opens the agent. He asks, it researches, the answer is saved in the folder. He says this replaced Google for him.
p
Start anything
Makes a new folder in his projects folder and opens the agent in it. He uses it for Mac apps, Next.js apps, small Zig and Rust programs, and benchmarks for Vercel's teams.
Why it works
Files are all you need
His view: an agent is a small program plus a file system. The folder holds the work. The rule file holds the habits. You improve it in plain English as you go.
FakeNerd starter · the two aliases
# ~/.zshrc
# r: ask a question in the research folder
alias r='cd ~/projects/research && fx'
# p <name>: start a new project and open the agent in it
p() {
mkdir -p ~/projects/"$1" && cd ~/projects/"$1" && fx
}
# No fx? Swap it for the agent you use: claude, codex, pi.FakeNerd starter · research/AGENTS.md
# Research folder This folder is my research notebook. When I ask a question: 1. Look in this folder first. If a file already covers it, start from that. 2. Research it. Use the web. Prefer the original source and link every claim. 3. Save the answer as a new Markdown file here: YYYY-MM-DD-short-topic.md Start with a three-line summary, then the detail, then the sources. 4. Reply with the file name and the summary. Keep the chat reply short. Never delete or rewrite an old file. Add a new one and link back to it.
FakeNerd starter · a tell-me-when rule
## Tell me when If a change alters the public API of this project (a route, an exported function, a CLI flag, a config key), stop and message me on Slack before you merge. Say what changed and why.
The third starter is the rule he describes for a project's AGENTS.md: when the agent changes something other people depend on, it messages you. The agent needs a Slack or Discord connector for this to work. 53:50
Brain and hands
This is how Vercel says to build any agent. Run the harness, then give it tools. The same picture explains fx on his laptop and an agent inside someone else's product. 34:12
Models · any of them
Reached through AI Gateway, a subscription you already pay for, or a model running on your own machine.
The brain · the harness
fx in the terminal, libfx inside an app
The loop that talks to the model, calls tools, reads what came back and tries again. Small on purpose.
The same brain with more hands · FX0, his demo 32:30
v0 took Vercel a big team and, by his count, 90% of the effort went into the harness. FX0 is about 100 lines on top of libfx. On screen it runs at fx0.playground-vercel.tools with Opus 5.5 selected. He says they plan to open source it.
Three ways he works with an agent
Live
37:55You're in the loop, deciding and trying things. It needs a very fast model. His example: shaping a page or a short video, change by change.
In the background
38:16Go and solve this. The agent gets a computer and works without you watching.
On a signal
38:30Nobody prompts it. Something breaks, or a customer reports a problem, and that starts the work.
Your two jobs: before and after
Rauch has a name for each. Before the agent builds, verification engineering. After it's done, agentic inquiry. The agent does the middle. The two prompts are FakeNerd's, built from what he lists.
Before · verification engineering
40:20Settle these with the agent
- What must always be true about the system.
- The look and feel you want built in.
- Speed and size limits you won't give up.
- What you're willing to trade: safety against speed, time in CI, file size.
FakeNerd starter · guardrails
Before you write any code, let's agree on the rules for this task. MUST ALWAYS BE TRUE - [e.g. no page loads without checking the session] LIMITS - [e.g. the page loads in under 300 ms from Europe] - [e.g. the download stays under 10 MB] OK TO TRADE - [e.g. slower CI is fine. More dependencies is not.] HOW WE'LL KNOW - [the check, benchmark or end-to-end test that proves each line above] Push back on anything here that's vague or that conflicts.
After · agentic inquiry
51:53Ask the agent to show you
- Draw which function calls which. He points to a post by Dillon Mulroy showing exactly this.
- Measure the speed.
- Count the memory it uses.
- Show how the public API changed.
FakeNerd starter · inquiry
Before I accept this, help me understand it. 1. Draw the call path for what you changed: which function calls which. 2. List anything that changed in the public API. 3. Measure it: speed and memory, before and after. Run it and show the numbers. 4. What did you trade off to get here? 5. What could I have done to make this easier for you?
Know your levers · rough numbers he wants every engineer to carry 44:09
- Read from the CPU's closest cache (L1) · said in the video0.5 ns
- CPU guesses a branch wrong5 ns
- Read from main memory100 ns
- Round trip inside one data center0.5 ms
- California to the Netherlands and back · said in the video150 ms
The bars are not to scale: each step right is about ten times longer. From Latency Numbers Every Programmer Should Know, the 2012 list credited to Jeff Dean. Rauch uses the last row as an interview question. Good answers land between 100 and 200 ms. People guess seconds, or 10 ms.
You don't need to memorize the list. His point is that knowing the rough sizes, and ideas like what a library, a framework and a compiler are, is what lets you tell an agent to make it faster and know it's possible. The agent can't spend unlimited tokens on every task, so you choose what matters.
Slop debt: choose where you take it
Tech debt was always part of moving fast. Rauch's advice to vibe coders: know how much sloppy code you're taking on, and pick the places on purpose. 56:25
Move fast here
Ask no questions, auto-merge, ship
- Parts where you need to move and nothing important breaks if it's rough.
- Experiments and things only you use.
- His history lesson: Twitter was built fast on Ruby on Rails while purists argued. Taking on some debt is healthy.
Be strict here
The opposite of vibe coding
- Anything that touches security or holds a customer's data.
- Software you're about to adopt from someone else. Check the security debt before you take it on.
- Then say so in public. A big customer has to believe your product is safe. Showing you did the opposite of vibe coding helps you sell.
Rauch
17:41Speed vs velocity
Tokens spent and PRs landed measure speed. Velocity is speed in a direction. You can land PR after PR and go nowhere.
Rauch
18:25Build a few things, buy the rest
A founder told him she was also building her own email service and payment system. His advice: pick the few problems where you can be far better than anyone, and spend your tokens there.
Ondrej
58:10Lines of code per decision
Ondrej tracks lines of code against decisions written down. Lots of code and few decisions means he's shipping without telling the agents what matters.
Signal to fix
The same loop at company size. Rauch's test for how agentic a company is: take a clear signal from a customer and time how long the fix takes to ship. 12:41
His three questions
- 1When a customer reaches out, do they get a good answer from an agent?
- 2When they report a problem, does an investigation start on its own?
- 3When they report something concrete and fixable, is it fixed without waiting for a person?
Autonomous in a good way, he adds. Not letting agents ship slop.
How a signal moves
1A signal arrives: a post, an email, an error. Is something clearly broken or clearly better another way?
Yes
No taste needed. An agent starts the fix or the investigation right away.
No
A person takes it. Vercel's dashboard lead went back and forth with a user confused by the navigation, collecting videos and detail.
2After talking to the customer, is there a decision?
Yes
It becomes a prompt, then a shipped change.
No
It stays feedback. You aren't a machine that turns every request into product.
3It shipped. How long did it take from signal to fix?
Then
That number is the grade. Ondrej's version: the company that fixes things in under 30 minutes beats the one that takes two days.
Other software factories on this site: Steve Sewell's, Ras Mic's and Warp's.
Security: scan it, sandbox it, rewrite it
A third of the talk is about this. His claim: the amount of hidden holes in code people wrote by hand is close to impossible to measure, and models can now find them cheaply. 61:35
Why now
63:49People write for the case that works
Thinking through every odd case is tiring, so most code skips them. Short, simple-looking code hides the most. Languages that force you to cover every case never caught on.
Why now
67:52Models are good detectives now
Tell a model to hunt for holes, give it time and sandboxes, and it finds a scary number. On Vercel's scoreboard a cheap model, DeepSeek V4 Flash, does this well. Attackers can run it on everything.
Why now
66:35One library, everyone exposed
His example is libheif, an image library written in C and C++ that sits inside image pipelines all over the internet. One hole there reaches everyone who uses it.
What he does about it
- 1Scan your own code firstGet ahead of it. Run agents over your code before someone else does. deepsec is Vercel's tool for this; he says there are others. deepsec on GitHub 68:23
- 2Lean on code the whole world checksLinux, React, Next.js: lots of people and lots of tokens are already hunting for holes there. He would not write his own encryption library today.69:46
- 3Move core libraries to safer languagesCode that's safe by how it's built, not by luck. He names Rust, and says Vercel wants to fund this kind of rewrite.68:48
- 4Build in cloud sandboxesIf a bad package runs in a sandbox, it can't reach your password manager. The network can be watched and locked down. His bold claim: this could end supply chain attacks. Vercel Sandbox docs 73:35
- 5Tell people you did itSecurity work is part of your story. Someone told him they plan to put a line about being scanned with deepsec in their README.71:27
What a deepsec run does · from its README, not the video
- scanFast pattern search. Free.
- processAgents read the flagged files and trace what's really wrong.
- triageSort by how serious: P0, P1, P2.
- revalidateCheck each finding again.
- exportA report in Markdown or JSON.
DeepsecBench ranks models on this job. Per Vercel's write-up from July 2026, each model is scored against 231 findings judged by people, and missing a real hole costs twice as much as a false alarm.
Why agents move to the cloud
72:40- A laptop runs out of memory, CPU and battery.
- Agents work in parallel across many sandboxes.
- They work while you sleep, and fix things when your computer is off.
- A break-in stays inside the sandbox.
Why local stays
75:12- Sometimes you need to look at a thing under the microscope.
- See the files, watch the processes, try it next to your other apps.
- Nothing responds faster than your own machine.
- He wants the option to pull work down to stay open.
Build it in Claude Code: seven checks, one prompt each
AI LABS took seven tips from the interview and built each one in Claude Code on Sitfirst, a sample booking app for furniture stores. Prompts marked “as typed” are read off their screen, typos and all. Fill-in versions and starters are FakeNerd's. Works in any agent that has commands, subagents and hooks.
The seven tips at a glance
A new folder.claude/commands/direction.md.deepsec/ and a reviewer agentCLAUDE.md and tests/.claude/agents/breaker.md.claude/agents/first-timer.md, pathrunner.md, .claude/hooks/MCP servers (email, Sentry)All seven run on the same app, so you can follow one thread: the MVP prompt asks for furniture ordering and chat, the plan says the app books showroom visits, and /direction later flags the ordering feature as off course.
01Test before you choose
AI LABS 0:51Try an idea in a fresh project and have an agent check it from scratch. Don't go off vibes or a prompting guide.
1 · Plan
A specs/ folder with prd.md and a doc per feature. Goals get a number you can measure.
2 · MVP first
One prompt, core features only. Look at it running and ask: is this worth building?
3 · Then the full build
Only if yes. A bad early decision found now costs a prompt. Found later, it means reworking the app.
AI LABS prompt · as typed
I want you to create an mvp of a booking platform that basically lets user sign in to the platform and then book the order of the furniture and all the other things and let the users connect with the team to coordinate the order as well
FakeNerd fill-in
Build an MVP of [your app in one line]. Only these features: [3 to 5 core features]. Keep it rough: no polish, no settings pages, fake data is fine. When it runs, tell me how to open it, and list what you left out on purpose.
02Check the direction
AI LABS 2:18Tokens spent and changes shipped measure how much you build, not where it's going. Building is the cheap part now, so every passing idea becomes a feature and the agent won't stop you. The fix is a command that compares the code with the plan.
AI LABS prompt · as typed
i want you to create a command called direction that checks that the implementation is drifting off course or is it still aligned with the plan. the plan and all the rds are in the specs folder
- Writes the commandClaude saves it to .claude/commands/direction.md (105 lines on screen).
- Loads itThey ran /reload-plugins. A new session also picks it up.
- Runs /directionOne agent per feature doc; four ran at once. The main agent looks for work no doc mentions.
- ReportsA verdict, a scorecard per feature and a to-do list. You keep the drift and update the spec, or remove it.
What it printed · Direction: OFF COURSE AI LABS 3:44
The plan says Sitfirst books showroom visits and that “sales, delivery and returns stay with the store”. The code had grown a product catalog, delivery orders and chat on each order, with no spec. The ten planned features matched their specs closely. The verdict was red because ordering crosses a non-goal and breaks the privacy rule “collect only name, email, phone, note”.
| FR | Feature | Met | Partly | Missing | Changed | Note |
|---|---|---|---|---|---|---|
| 01 | Auth & sessions | 17 | 2 | 0 | 0 | Too-long name and email are cut short instead of rejected |
| 02 | Password reset | 8 | 1 | 0 | 0 | no-referrer is a meta tag, not an HTTP header |
| 03 | Discovery | 9 | 0 | 0 | 0 | — |
| 04 | Store page | 10 | 0 | 0 | 0 | “No catalog yet” known-limit is now false |
First four of ten rows. The screen shows icons for the four count columns (✅ 🟡 ❌ 🔀); the column names here are our reading of them.
FakeNerd starter · direction.md
---
description: Check whether the code still matches the plan in specs/, or is drifting off course
argument-hint: "[all | FR-05 FR-08 … | changed]"
allowed-tools: Read, Grep, Glob, Agent, Bash(git status:*), Bash(git diff:*), Bash(git log:*)
---
Check this project against its plan. The plan is specs/prd.md and the
feature docs in specs/features/. Scope: $ARGUMENTS (default: all).
1. Read the PRD, including its goals and non-goals.
2. Start one agent per feature doc. Each one reads its doc and the code
for that feature, then lists every requirement as: met, partly met,
missing, or changed.
3. While they run, look for work that is in the code but in no doc at all:
new routes, pages, tables, features.
4. Report:
- Verdict: ON COURSE, DRIFTING or OFF COURSE, with two or three
sentences on why. Quote the PRD section you're judging against.
- Scorecard: one row per feature doc, with the four counts and a note.
- Unplanned work: each item, and whether it breaks a goal or non-goal.
- To-do: for each drift, say "update the spec" or "remove the code",
and let me choose.
Don't change any code or docs. This command only reports.Save it as .claude/commands/direction.md. Their file isn't shown past its first lines. The argument hint and allowed tools in the starter follow those lines; the steps are ours, built from what the run printed.
03Pick your careful zones
AI LABS 4:57Agents write more code than anyone can read. Scan after every feature, and hold the parts that matter to a higher bar. People trying to break in have cheap agents too. The why is in Security and Slop debt above; this is the how.
Security debt · scan after every feature
- Run
npx deepsec init. It makes a.deepsecfolder in your project. - It hands you a prompt. Paste it into Claude Code, which writes a short file about your app and how people sign in.
- Ask Claude to run the scan. It runs them and gives you a report.
Any scanner works. deepsec is Vercel's; it spends model tokens, so cap the cost first. deepsec on GitHub
Slop debt · gates on the parts that matter
A test says whether something works. A quality gate also says whether it's good enough: for example a review agent that holds every change to your standards. Nothing goes live until it passes every gate.
Small side project: rough code is fine. Payments and customer data: strict. Decide which is which before you build.
04Say what you won't trade
AI LABS 7:14Every task trades speed, polish, cost and safety. Agree the ones that can't move before the agent starts. Rauch says your time goes into two things: does it do what it should, and how fast must it be. If the model doesn't know, it picks the direction for you.
Their CLAUDE.md section · opening, as shown
## MUST NOT TRADE OFF These are not negotiable for deadlines, scope cuts, "quick fixes" or simpler code. If a change would weaken one, stop and raise it instead of shipping it. If two conflict, the earlier one in this list wins.
Their six rules, in order AI LABS 8:00
- Security and privacy: every action re-checks who you are; tokens stored only as hashes.
- Data integrity: no double bookings, ever; a clash ends in a friendly message.
- Speed: a page shell first, data streamed in; set load-time targets.
- Availability: a failing outside service only breaks its own feature; every call has a timeout.
- User experience: booking under 60 seconds; no dead ends; errors in plain words.
- Accessibility: WCAG 2.2 AA.
FakeNerd fill-in · paste into CLAUDE.md or AGENTS.md
## MUST NOT TRADE OFF These are not negotiable for deadlines, scope cuts, "quick fixes" or simpler code. If a change would weaken one, stop and raise it instead of shipping it. If two conflict, the earlier one in this list wins. 1. **Security and privacy.** [Who can see what. What you never store in plain text. What data you never collect.] 2. **Data integrity.** [What must never be lost, duplicated or corrupted, and how a clash should end.] 3. **Speed.** [Your targets, e.g. page loads under 2 s on a phone.] 4. **Availability.** [What keeps working when an outside service fails. Timeouts on every outside call.] 5. **User experience.** [How long the main task may take. No dead ends. Errors in plain words.] 6. **Accessibility.** [The standard you hold to, e.g. WCAG 2.2 AA.] Each rule has a test in tests/must-not-trade-off/. If a change makes one fail, stop and tell me.
Why each rule needs a test
The file is only written instructions. Agents hold a lot in their context and drop rules as it fills. A test committed to git fails loudly when a rule breaks, so the agent can't skip it.
FakeNerd starter · back each rule with a test
Read the MUST NOT TRADE OFF section in CLAUDE.md. For each rule, write at least one test that fails if the rule is broken. Put them in tests/must-not-trade-off/, one file per rule. Run them and show me the result. Don't change app code to make them pass; tell me which ones fail.
05Break it on purpose
AI LABS 8:33Code an agent writes works on the happy path. Real users skip steps and do two things at once. An agent tests its own work the way it built it, so everything passes. When Vercel launched Drives, Rauch had an agent try to break it: race conditions, latency, comparisons with the alternatives.
AI LABS prompt · as typed
I want you to create an agent that's called a breaker. And the main task that this agent has to do is to purposefully break the app, and try to find the issues uh, by measuring latency, finding race conditions. basically a red hat hacking test that finds and reports all the vulnerabilities
FakeNerd fill-in · with the safety rules
Create a subagent called breaker in .claude/agents/breaker.md. Its only job: break this app on purpose and report every way it broke. - Load: many users at once. Measure how slow it gets. - Clashes: two people doing the same thing at the same moment (race conditions). - Odd use: skipped steps, back button, double clicks, strange input. - Security: what an outsider could see or change that they shouldn't. Safety rules for the agent: - Only test the app running on localhost. Never send requests anywhere else. - Copy the database to a backup folder first and restore it when done. - Make its own test accounts. Never touch data it didn't create. - Report, don't fix. Each finding gets: severity, steps to reproduce, file and line.
What their breaker.md says · read off the screen
- An adversarial tester. Find where the app fails its own specs: under load, under concurrency, under hostile-but-realistic input. Report it so a developer can reproduce and fix it.
- Test only the app on localhost. Never send requests to any other host or third party.
- Before testing, copy
data/app.db*to abreaker-backup/folder and restore it after. - Make its own test accounts and stores. Don't touch seed data it didn't create.
One run: 3 high, 4 medium, 9 low · nothing fixed yet AI LABS 10:12
- 1Open redirect after login. A crafted link could send a user who just logged in to another site.
- 2Password reset reveals which emails have accounts. The reply came back slower for real accounts, so an outsider could tell who signs in there.
- 3Email calls can hang forever. The email call had no timeout, so a slow provider could stall booking and reset.
Then: fix all the issues, and run the breaker again so they don't come back. Or loop the two until it finds nothing.
06See it as a new customer
AI LABS 10:26You can never be a first-time user of your own app. Track error-free sessions: visits that finish with nothing going wrong. You know where every button is. A new customer who gets stuck on sign-up just leaves, and you never learn why. Two agents cover it.
You, testing your own app
Know what every page is for. Take the path you built. Never get stuck, so never see the confusing field.
The first-timer agent
Has only the address. Clicks what's on screen. Every moment of doubt is written down as a finding before it works things out.
AI LABS prompt · as typed
create an agent that checks the app as a first-time user and test everything without having any context of what the app does by running it on the browser and find all the ways that the first-time user would struggle.
The hook keeps it blind AI LABS 11:52
Why a hook and not a rule in the prompt: an agent that can read the code already knows how everything works, so it's no longer a first-time user. A rule can be forgotten. A hook runs before every tool call and exit code 2 blocks it.
Their hook · first lines, as shown
// PreToolUse hook for the first-timer agent: Bash may only run the app, its checks,
// and headless screenshots of localhost; Read may only open those screenshots.
// Everything else is blocked (exit 2).
import { readFileSync } from "node:fs";
const { tool_name, tool_input } = JSON.parse(readFileSync(0, "utf8"));
if (tool_name === "Read") {
if (!/^\/tmp\/first-timer-[\w-]+\.png$/.test(String(tool_input?.file_path ?? ""))) {
process.stderr.write("Blocked: first-timer may only read its own screenshots at /tmp/first-timer-<name>.png.");
process.exit(2);
}
process.exit(0);
}FakeNerd starter · first-timer.md
---
name: first-timer
description: Uses the app in a real browser like a brand-new customer and reports where they'd get confused, stuck or give up. Use for a "fresh eyes" review.
disallowedTools: Edit, Write, NotebookEdit, Grep, Glob
hooks:
PreToolUse:
- matcher: "Bash|Read"
hooks:
- type: command
command: node "$CLAUDE_PROJECT_DIR/.claude/hooks/first-timer-guard.mjs"
---
You are a first-time visitor. You have never seen this app.
## Stay blind
Your value is that you know nothing. Don't read the code, the specs, the README or the database. Don't guess URLs: get everywhere by clicking what's on screen. When you're unsure what something means, that uncertainty is a finding. Write it down before you work it out.
The only thing you're told: the app runs at http://localhost:3000. If nothing loads there, say so and stop.
## Report
For each place you got confused, stuck or felt like leaving: the page, what you tried, what you expected, what happened.FakeNerd starter · first-timer-guard.mjs
// .claude/hooks/first-timer-guard.mjs
// Runs before every Bash or Read call the first-timer agent makes.
// Exit 2 blocks the call and shows the agent the message.
import { readFileSync } from "node:fs";
const { tool_name, tool_input } = JSON.parse(readFileSync(0, "utf8"));
function block(why) {
process.stderr.write("Blocked: " + why);
process.exit(2);
}
if (tool_name === "Read") {
const file = String(tool_input?.file_path ?? "");
if (!/^\/tmp\/first-timer-[\w-]+\.png$/.test(file)) {
block("first-timer may only read its own screenshots in /tmp/first-timer-<name>.png.");
}
process.exit(0);
}
if (tool_name === "Bash") {
const cmd = String(tool_input?.command ?? "").trim();
const allowed = [
/^npm run dev$/,
/^npm (run )?start$/,
/^curl -s(I)? http:\/\/localhost:3000\S*$/,
];
if (/[;&|`$<>]/.test(cmd) || !allowed.some((re) => re.test(cmd))) {
block("first-timer may only start the app and check that localhost answers.");
}
process.exit(0);
}
process.exit(0);Save them as .claude/agents/first-timer.md and .claude/hooks/first-timer-guard.mjs. Our starters wire the hook through the agent's own front matter, which Claude Code supports for project agents once you trust the folder. The agent also needs a browser tool to click with, such as a Playwright MCP server. Their file lets Bash take headless screenshots instead; that part isn't shown.
Second agent · pathrunner AI LABS 12:12
Finding confusion is half of it. To track error-free sessions, a second agent runs a browser test on every flow a customer must get through, start to finish. It flags slow steps, broken steps and flows that stop halfway, saves results to e2e/results/latest.json, and runs before every ship.
AI LABS prompt · as typed
I want you to create an agent that basically runs the browser test on all critical paths and then return a report on how they perform.
FakeNerd fill-in · pathrunner
Create a subagent called pathrunner in .claude/agents/pathrunner.md. 1. List the flows every customer must get through: [sign up, log in, find X, book or buy, pay, get the confirmation]. 2. Write one browser test per flow, start to finish (Playwright is fine). 3. Run them all. For each flow record: passed or failed, time per step, where it broke. 4. Save the run to e2e/results/latest.json and print the error-free rate: flows that finished with nothing going wrong, out of all flows. I run this before every ship.
07Act on feedback fast
AI LABS 12:42Clear bugs get fixed right away. Anything that needs judgment goes to a person. Rauch's test of how well a company uses agents: when a customer reports a problem, does someone answer properly, look into it, fix it if it's clear, and how long does that take?
How a report moves
1A report arrives: a support email, or an error Sentry caught before anyone wrote in. Is something clearly broken?
Yes
Claude fixes it right away. Their example: a payment failing.
No
Claude sends it to you. A customer who is confused can't be turned into a prompt; you talk to them first.
2It's fixed. How long did it take from the report coming in?
Then
That's the number Rauch grades a company on. Track it.
Connect the two places reports come from
- Your support email, through an email MCP server. They use Gmail.
- Your error tracker. They use Sentry's MCP server, which catches errors no customer has reported.
FakeNerd starter · the triage prompt
Read the new reports since [yesterday] in two places: - the support inbox (email connector), label "[support]" - Sentry, project "[my-app]" Sort each one: 1. Clearly broken, and clear how to fix (a failing payment, a dead button, an error with a stack trace): find the cause, fix it on a branch, run the tests, and draft a reply to the customer. 2. Needs judgment (confused by the app, wants something different, unclear what's wrong): don't change code. Summarize it for me in one line with a link. 3. Noise or duplicates: group them, one line each. End with a table: report, bucket, what you did, time from report to fix.
The video shows this part as a diagram, not a run, and no prompt. The starter is ours.
Try it, smallest version first
Seven steps, cheapest first. Steps 1 to 5 cost nothing beyond the agent you already pay for. You can stop after step 3 and already have the research habit.
- 01
Have one terminal agent
Keep the one you use, or try fx. This is fx's own install command, from its site. Then type fx in any folder.
curl -fsSL https://fx.sh/setup.sh | bash
fx.sh - 02
Add the two aliases
Copy the r and p starter into your shell config. Open a new terminal tab and type r.
The aliases - 03
Give the research folder its rule file
Put the AGENTS.md starter in ~/projects/research. Send your next three Google questions there instead.
The AGENTS.md starter - 04
On your next real task, do both jobs
Guardrails prompt before the agent builds. Inquiry prompt after. See how much you learn from the second one.
The two prompts - 05
Add one tell-me-when rule
Pick the one kind of change you never want to miss. Write it into the project's AGENTS.md.
The rule - 06
Scan one repo
This command is from deepsec's README. It walks you through setup and starts the scan. It spends real money on model tokens, so read the README's section on capping cost first.
npx deepsec init
deepsec on GitHub - 07
Add one guard agent
Pick the one you need most from the Claude Code kit: /direction if you keep adding features, the breaker before real users arrive, the first-timer once strangers sign up. One prompt each.
The kit
FakeNerd's take
The cheapest idea is the best one
One letter, one folder, one rule file. It's free, it works with any agent, and it's the only part of the setup he shows from start to finish.
He sells what he recommends
fx, AI Gateway, Sandbox, Drives, eve and deepsec are all Vercel's. The ideas work without them, and this page says where. Ondrej also plugs his own Cloudroom, and Supabase paid for a slot.
fx is early
v0.0.11 on screen. The promise is that it stays small and doesn't grow more UI. Every agent says that at the start, Rauch included: it's what he first liked about Claude Code.
Inquiry needs real numbers
Asking the agent to explain its work is a good middle path. But an agent describing its own work can be wrong. Make it run the measurement and show the output.
The loop is assembled, not shown
He never builds a feature on camera. The seven steps come from things he says across 98 minutes; the order is ours. AI LABS's video fills part of the gap: it builds the checks he describes, in Claude Code, on one app.
The kit is the useful half
AI LABS adds no new ideas from Rauch; all seven are already on this page. What's new is the build: a prompt per check, the files it made, a run on a real app. Their full agents sit behind a paid community, but the prompts on screen are enough to start.
They ran with permissions off
Every run in their video uses claude --dangerously-skip-permissions, which lets the agent do anything without asking. Don't copy that for the breaker. Keep it on localhost and on a copy of the data, as their breaker file says.
Some of the security talk is guessing
The last half hour includes his read on a recent incident at an AI lab. He says himself the details aren't public. We left that part off the page.
Related on this site: Pi, the other small agent Ondrej compares fx to. Autoresearch, the leave-it-running-for-days idea Ondrej raises. Theo on token-maxing, the habit Rauch calls speed without direction.
Attribution
- David Ondrej's interview with Guillermo Rauch (posted Oct 2, 2026). YouTube shows it under two titles: “Vercel CEO reveals his Agentic Engineering Workflow” and “How Vercel Ships 100x Faster”. The habits, tools, terms and reasoning are from this video, in our words. Version numbers, folder names, the spend meter figures and the FX0 address are read from the screen. Sponsored by Supabase, which isn't part of the workflow.
- AI LABS, “Vercel's CEO Just Unveiled The Greatest AI Coding Workflow Ever” (posted Oct 19, 2026), a summary of the same interview. The seven tips, their order, the sample app and every prompt marked “as typed” are theirs, read off the screen. The CLAUDE.md lines, breaker.md lines, hook lines and run results are read off the screen and summarized. Sponsored by Viktor, which isn't part of the workflow. AI LABS is a software company; it also promotes its own build service and a paid community that holds its full agents.
- fx and deepsec by Vercel Labs, both Apache-2.0. Download size, install commands, the createFxAgent name and the deepsec steps are from their sites and READMEs, summarized.
- Latency Numbers Every Programmer Should Know, credited to Jeff Dean, from the 2012 list.
- Claims about Vercel's products, growth and prices are Rauch's own. He is Vercel's CEO. Nobody has checked them.
- The seven-step loop, the six-beat walkthrough, every starter file and prompt (including the fill-in versions, direction.md, first-timer.md, the hook and the triage prompt), the scorecard column names, the setup order and the takes are FakeNerd's. Not sponsored by anyone on this page.