YT YouTube2Text

YouTube2Text → Transcripts → Vercel's CEO Just Unveiled The Greatest AI Coding Workflow Ever

Vercel's CEO Just Unveiled The Greatest AI Coding Workflow Ever — Transcript

by AI LABS · 3,260 words · 442 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00The CEO of Vercel gave an interview
0:02where he talked about how he works with
0:04AI agents. And interestingly, he said
0:06that most people judge how well they're
0:08building with AI by a number that
0:10doesn't matter nearly as much as they
0:12think. That's because the number only
0:13tells you how much you're building, not
0:15where it's taking you. So, what he cares
0:17about is whether all that work is
0:19actually heading where you planned it to
0:21go. And we turned that idea into one
0:23command you can run yourself. But that's
0:24not even the most surprising thing he
0:26does. One of them sounds absurd when you
0:28first hear it. But once you understand
0:30why he does it, it turns out to be one
0:32of the most valuable tips in the whole
0:34interview. And that's just one of the
0:35many things he talked about. So, we went
0:37through all of it and pulled out the
0:39seven tips that are genuinely helpful.
0:41If this is your first time, we're a
0:42software company and this is our channel
0:44AI Labs. And in this video, we're going
0:47over each of his seven tips and how you
0:49can set them up for yourself. The first
0:51[snorts] tip from his interview is about
0:52testing things before you choose to go
0:54with them. He said that whenever he gets
0:56an idea, he makes a new project for it
0:58and tests his ideas in there. Then he
1:00has an agent check from scratch if it
1:02really works instead of trusting what
1:04anyone says about it. Now, you might
1:06wonder why he doesn't just go with what
1:08everyone's saying. He said a lot of
1:09people just go off vibes with models. He
1:12heard about someone who read a prompting
1:13guide that said Astra does better with a
1:16certain kind of prompt, so they started
1:18prompting it that way. But they never
1:19checked if that was actually true.
1:21Testing it himself matters to him
1:23because that's how he knows what really
1:25works and what doesn't. We also do the
1:26same thing. Whenever we have a new
1:28project, we always start with a specs
1:30folder that holds the PRD file. This
1:32file lists all the main features we plan
1:34to add to the app. So, it's the first
1:36document for every project we make. But
1:38if you take that PRD and jump straight
1:40into building the whole app, you'll find
1:42out really late that the idea itself had
1:44problems. This also hurts all your early
1:46decisions. If any of them turns out to
1:48be wrong, everything else is already
1:50built on top of it. So, fixing it means
1:52going back through the whole app. So,
1:54whatever app we're building, we always
1:56start by asking Claude Code or whichever
1:58agent we're using to make an MVP, and we
2:01give it all the basic features in the
2:02prompt. An MVP is basically the first
2:05working version of your app where you
2:07quickly build the features to see how
2:09your idea really looks once it's built.
2:10This is the point where we can see if
2:12the app is even worth building. And if
2:14it's not, we can just drop the idea
2:16without wasting much effort. The second
2:18tip is about making sure everything you
2:20build is taking your app in the right
2:22direction. He said a lot of people judge
2:24their progress by how many tokens they
2:26spend or how many changes they ship, and
2:28those are fine numbers to track. But
2:30they only tell you how much you're doing
2:32and not where it's taking you. This
2:33means you can keep shipping and still be
2:35going nowhere. This matters way more now
2:37because with agents, building is the
2:38cheap part. You can ask Claude for a new
2:40feature and have it working in a few
2:42minutes. So every idea you get while
2:44you're building turns into a feature,
2:46and every new feature feels like
2:48progress. And Claude won't stop you
2:49because it builds whatever you ask for,
2:51and it has no idea which of those
2:53features really matter for your app. But
2:55you already have the plan in your specs
2:57folder with all the requirement
2:59documents and the PRD. The problem is
3:01that once you start building, the app
3:03can slowly move away from that plan into
3:05features that don't even matter for your
3:07app. So to stop that from happening, you
3:09can ask your agent to create a command
3:11called direction that checks if what
3:13you've built is drifting off course or
3:15still matches the plan. You also need to
3:18tell it where you're keeping the plan
3:19folder. When you send that prompt, it
3:21creates the command for you and puts it
3:23in the commands folder inside Claude
3:25folder if you're on Claude Code. Then
3:27when you run the reload plugin command
3:29in Claude Code, it loads this command
3:31into your session. After that, you can
3:33run the direction command and it goes
3:35through all the requirement documents in
3:37the folder with a separate agent for
3:39each one. The main agent then checks by
3:41itself for any changes that aren't in
3:42any of your plans. When all the agents
3:44finish, it gives you a full report that
3:46tells you if the app is off course or
3:48not. It also gives you a scorecard and a
3:50list of everything you need to do. From
3:52this report, you can either keep the
3:54drift and update your requirement
3:56documents to match it, or you can remove
3:57those changes if you think they've gone
3:59too far from your plan. But before we
4:01move on to the next one, let's have a
4:03word by our sponsor, Victor. Most AI
4:05tools stop at the answer. They write you
4:07the code and then you're the one who
4:09opens the editor, pastes it in, and
4:11deploys it yourself. Victor fixes that.
4:13Victor isn't a tool, he's a hire, an AI
4:15employee who lives in Slack and
4:17Microsoft Teams. He runs his own
4:19computer in the cloud, so he can
4:20actually do the work instead of
4:22describing it. We mentioned him in a
4:24channel the way you'd message a teammate
4:26and asked for a small web app to collect
4:28our video ideas with a database behind
4:30it. Victor put it together and came back
4:32asking for the go ahead before
4:34deploying. We approved it and 10 minutes
4:36later a working link was sitting in the
4:38thread, ready for the team to start
4:39dropping ideas in. He connects to 3,200
4:42plus tools and remembers your setup
4:44between tasks, so you're not
4:46re-explaining the company every morning.
4:48You get $100 in free credits with no
4:50card needed. Go and hire Victor at
4:52victor.com and use code AI Labs 100.
4:55Links in the description. The [snorts]
4:57third tip is about security, which is
4:59something he talked about a lot. He said
5:01one of the biggest challenges for
5:03himself and for Versel is understanding
5:05the security debt. Security debt is
5:07basically all the security problems that
5:10grow when you're working with agents.
5:12And it's getting worse because agents
5:14are writing more code than was ever
5:16possible before. So no one can go
5:18through all of that code by themselves
5:20to find problems. But the people trying
5:22to break into your app have agents too.
5:24Models have gotten so good and so cheap
5:26at finding security holes that anyone
5:28who wants to cause harm can use them to
5:30find problems in your app. So his advice
5:33is to get ahead of this and start
5:34protecting your code as much as you can.
5:37The first rule is to run security scans
5:39on your app after you finished building
5:40a feature. Versel actually made their
5:42own tool for this, which is called
5:44DeepSec, and it finds security gaps in
5:46the code that the agent built. We've
5:48used this tool before, too, and we
5:50already have a whole video on DeepSec
5:52that you can check out on the channel.
5:54You can make your own ways of checking
5:55security, but if you want to use
5:57DeepSec, it's really easy to set up,
5:59too. You just need to run DeepSec's
6:01setup command, which creates a .deepsec
6:03folder in your project. It gives you a
6:05prompt that you paste into Claude code
6:07so that Claude writes a short file about
6:09your app and how people sign into it.
6:11Then you ask Claude to run the scan, and
6:13Claude runs all the scans for you. Once
6:15that's done, it gives you a full report
6:18on what it found. Now, the second rule
6:19is about deciding how careful you need
6:21to be with each part of your app. He
6:23said you need to understand how much
6:25slop debt you're taking on. Slop debt is
6:27basically all the messy code you choose
6:30to accept so that you can build fast.
6:32For a small app that isn't a big
6:33problem, but you need to be really
6:35careful with the most important parts of
6:37your product. That's because your
6:38customers need to know their data is
6:40safe and the app is built really well.
6:42You can do this by setting up quality
6:44checks before you build the app. There
6:46are many ways to set this up, and we've
6:47covered a lot of them on our channel
6:49before, but the best way is to set up
6:51quality gates. Tests only tell you if
6:53something works, but a quality gate also
6:56checks if it's good enough. It does this
6:58with things like a review agent that
6:59holds every change to your standards,
7:01and no change should go live until it
7:03passes every one of those gates. But
7:06before we go into the next tip, it would
7:08be great if you subscribe to the channel
7:10and hit the hype button. This small
7:12gesture of support goes a long way for
7:14us. The fourth tip is about deciding
7:16what you won't trade off. Whenever
7:17you're building an app, big or small,
7:19you're always trading one thing for
7:21another. You can add more features, but
7:23that takes more time. You can ship
7:24faster, but then something else has to
7:26give, like how polished the app is or
7:28how much it costs you. But there are
7:30some things you can't trade off at all
7:31because they really matter to what
7:33you're building. This is exactly what he
7:35talked about. He said everything the
7:37agent builds comes with trade-offs like
7:39speed against safety. It can't spend
7:41unlimited effort on every task, so it
7:43has to pick. That's why you and the
7:45agent need to agree on your rules and
7:47trade-offs before you start. He said
7:49your time should go into whether the app
7:51does what it's supposed to and how fast
7:53it needs to be. That's because if the
7:54model doesn't know what you want, it'll
7:56take you in whatever direction it wants.
7:58So, you need a separate must not
8:00trade-off section in the claw.md file in
8:03the main folder of your project. That's
8:04where you list all the important things
8:06your app has to have and the things
8:08you'd never give up. Now, this file is
8:10just written instructions for the agent
8:11to follow, but agents keep a lot of
8:13context in mind, so they tend to forget
8:15these rules. That's why every rule
8:17should come with a way for the agent to
8:19test if it's being met or not. So, to
8:21make sure the app still matches your
8:23plan, we made the direction command in
8:25an earlier section. You can also create
8:27the test files and commit them to get,
8:29so the agent can't skip these rules. The
8:32fifth tip is about having an agent try
8:34to break your app on purpose. When
8:36Versel launched a new product, he didn't
8:37just check that it worked. He gave it to
8:39an agent and told it to try to break it
8:41by copying the pressure a site gets when
8:44lots of people use it at the same time.
8:46That means things like doing several
8:48things at once that might clash,
8:49measuring how slow it got, and comparing
8:51it with other products. He said this
8:53matters because when a model is writing
8:55the code, it's really easy to write code
8:57that only works when everything goes
8:59right, but it's really hard to think of
9:01every way it can go wrong, like someone
9:03skipping a step or doing two things at
9:05once. That's exactly how your agent
9:07tests its own work. It built the app to
9:09be used a certain way, so when it checks
9:11the app, it uses it that exact way and
9:13everything passes. But your customers
9:15don't use it that way, and once you have
9:17a lot of customers, problems come up
9:19that your agent never even thought to
9:20test. So, you need to do the same thing
9:23and test your app in lots of different
9:25ways, especially in the situations that
9:27are sure to happen once your app is
9:29live. To do that, you need to create a
9:31breaker agent for yourself. You can ask
9:33whichever agent you're working with to
9:35create one, and you need to tell it that
9:36its main job is to break the app on
9:39purpose and then tell you every way it
9:41managed to break it. Basically, it
9:42attacks your own app the way someone
9:44outside would, so it can find all the
9:46weak spots before anyone else does. This
9:48helps because if your agent finds a way
9:50to break your app, you can fix it. But
9:52if someone else finds it first, it could
9:54cost you a lot. But what if it breaks
9:55your real data while it's attacking?
9:57When you give it the prompt, it creates
9:59the agent in a way that makes copies of
10:01the app's data, so your real data stays
10:03safe. Once this agent is ready, you can
10:05just ask Claude to run the breaker
10:07agent, and it starts a separate agent in
10:09its own context window to stress test
10:12the app. When it's done, it reports
10:14everything back. Then you can ask it to
10:16fix the problems and run the tests again
10:18to make sure none of them come back. You
10:20can also ask your agent to run a review
10:22loop with the breaker agent, where it
10:23keeps finding and fixing problems. The
10:26sixth tip is about seeing your app the
10:28way a new customer does. He said one of
10:30the values at Versel is knowing your
10:32customer, and he explained what that
10:34means when you're building with AI. He
10:36said it's really easy to build when
10:37you're the only customer, because all
10:39you're checking is whether you like the
10:41app or not. But it's a completely
10:42different thing once you're selling it
10:44to other people. That's why one of his
10:46favorite numbers to track is error-free
10:48sessions, which is basically how many
10:50people get all the way through your app
10:52without anything going wrong. And he
10:54uses agents for exactly this. Whenever
10:56Versel makes something new, he has an
10:58agent go and try it, and then he asks it
11:00to tell him what he could have done
11:02better. This matters because you can
11:03never be a first-time user of your own
11:06app. You built it, so you already know
11:07where every button is and what every
11:09page is for, but a new customer knows
11:11none of that. So if the sign-up page
11:13asks for something confusing, you'd
11:15never notice because you never get stuck
11:17there. Your customer gets stuck and
11:19leaves the app, and you never learn why.
11:21To test your app the way they do, you
11:23can ask Claude Code to create an agent
11:25that uses the app as a first-time user
11:28and tests everything without knowing
11:30anything about what the app does. It
11:32only runs the app in a browser and finds
11:34all the places where a new user might
11:36struggle. This really matters because it
11:38helps you make the app easier to use and
11:40lead people to where you want them to
11:42go. But if this agent could read your
11:44code, it would already know how
11:46everything works. So it wouldn't really
11:47be a first-time user. That's why this
11:49agent is blocked from reading the app,
11:51and the only thing it's allowed to do is
11:53run it. This is done with a hook that
11:55stops the agent from using its bash tool
11:57for anything other than running the app.
11:59If it tries to edit the app or delete
12:01any code, the hook blocks it. This way
12:03you get honest feedback on the app
12:05you've built, and you can run this agent
12:06to see where users get stuck. But
12:08finding where people get confused is
12:10only half of it. To actually track the
12:12error-free sessions he talked about, you
12:14need a separate agent that runs browser
12:16tests for all the steps every customer
12:18has to get through and reports the
12:20results. This really matters because it
12:22helps you find problems like slow steps,
12:24steps that don't work, or flows that
12:26break halfway. Whenever something isn't
12:28working properly, the agent can find it
12:30and write the code to fix it. It tests
12:32each of those paths from start to finish
12:34and saves the results in a JSON file.
12:36This also helps you judge how well the
12:38app performs, and you need to run it
12:40every time before you ship. The seventh
12:42and final tip is about how fast you act
12:45on what your customers tell you. He said
12:46one of the best ways to tell how well a
12:48company is using agents is to look at
12:50what happens when a customer reports a
12:52problem. You need to check if someone
12:54replies to them properly and checks what
12:56went wrong. If it's a clear problem, it
12:58should actually get fixed. And most of
13:00all, you need to how long all of that
13:02takes from the moment the report comes
13:04in. Now, the feedback you get from your
13:06customers isn't all the same. Sometimes
13:08a customer sends you a screenshot of a
13:10button that isn't working, and there's
13:12no thinking needed there. So you just
13:14need to fix it as fast as you can. But
13:16other times a customer tells you they're
13:17confused by your app, you can't really
13:19turn that into a prompt, so you actually
13:21have to talk to them and understand what
13:23they mean before you change anything. So
13:25to handle both of these, you can connect
13:27Claude to the places your feedback comes
13:29from using MCP servers. For example, you
13:32can connect the Gmail MCP so it can read
13:34your support emails. You can also
13:36connect the Sentry MCP, which reports
13:38every error your app hits even if no
13:40customer has said anything about it.
13:42Once that's connected, Claude reads each
13:44new report as it comes in and sorts it.
13:47If something is actually broken, like a
13:48payment failing, it fixes it straight
13:50away. And if it needs your judgment,
13:52Claude sends it to you so you can decide
13:54what to do with it. Now, all the agents
13:56and skills you saw in this video are all
13:58available for you to use in AI Labs Pro,
14:01which is our community. So, if you found
14:03value in what we do and want to support
14:05the channel, this is the best way to do
14:07it. The link's in the description. That
14:09brings us to the end of this video. If
14:10you'd like to support the channel and
14:12help us keep making videos like this,
14:14you can do so by using the Super Thanks
14:16button below. As always, thank you for
14:18watching and I'll see you in the next
14:20one.

About this transcript

This page contains the full transcript of Vercel's CEO Just Unveiled The Greatest AI Coding Workflow Ever by AI LABS, generated from the public captions YouTube serves with the video. The transcript has 3,260 words across 442 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.