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

Channel: AI LABS
Video: https://www.youtube.com/watch?v=y2ifUC9_zuU
Duration: 14 min
Language: English
Words: 3260
Transcript page: https://viewrankai.com/tools/youtube-transcript/y2ifUC9_zuU

---

[0:00] The CEO of Vercel gave an interview where he talked about how he works with AI agents. And interestingly, he said that most people judge how well they're building with AI by a number that doesn't matter nearly as much as they think. That's because the number only tells you how much you're building, not where it's taking you. So, what he cares about is whether all that work is actually heading where you planned it to go. And we turned that idea into one command you can run yourself. But that's not even the most surprising thing he does. One of them sounds absurd when you first hear it. But once you understand

[0:30] why he does it, it turns out to be one of the most valuable tips in the whole interview. And that's just one of the many things he talked about. So, we went through all of it and pulled out the seven tips that are genuinely helpful. If this is your first time, we're a software company and this is our channel AI Labs. And in this video, we're going over each of his seven tips and how you can set them up for yourself. The first [snorts] tip from his interview is about testing things before you choose to go with them. He said that whenever he gets an idea, he makes a new project for it

[0:58] and tests his ideas in there. Then he has an agent check from scratch if it really works instead of trusting what anyone says about it. Now, you might wonder why he doesn't just go with what everyone's saying. He said a lot of people just go off vibes with models. He heard about someone who read a prompting guide that said Astra does better with a certain kind of prompt, so they started prompting it that way. But they never

[1:19] checked if that was actually true. Testing it himself matters to him because that's how he knows what really works and what doesn't. We also do the same thing. Whenever we have a new project, we always start with a specs folder that holds the PRD file. This file lists all the main features we plan to add to the app. So, it's the first document for every project we make. But if you take that PRD and jump straight into building the whole app, you'll find out really late that the idea itself had problems. This also hurts all your early decisions. If any of them turns out to be wrong, everything else is already

[1:50] built on top of it. So, fixing it means going back through the whole app. So, whatever app we're building, we always start by asking Claude Code or whichever agent we're using to make an MVP, and we give it all the basic features in the prompt. An MVP is basically the first working version of your app where you quickly build the features to see how

[2:09] your idea really looks once it's built. This is the point where we can see if the app is even worth building. And if it's not, we can just drop the idea without wasting much effort. The second tip is about making sure everything you build is taking your app in the right direction. He said a lot of people judge their progress by how many tokens they spend or how many changes they ship, and those are fine numbers to track. But they only tell you how much you're doing and not where it's taking you. This means you can keep shipping and still be going nowhere. This matters way more now

[2:37] because with agents, building is the cheap part. You can ask Claude for a new feature and have it working in a few minutes. So every idea you get while you're building turns into a feature, and every new feature feels like progress. And Claude won't stop you because it builds whatever you ask for, and it has no idea which of those features really matter for your app. But you already have the plan in your specs folder with all the requirement documents and the PRD. The problem is that once you start building, the app can slowly move away from that plan into features that don't even matter for your

[3:07] app. So to stop that from happening, you can ask your agent to create a command called direction that checks if what you've built is drifting off course or still matches the plan. You also need to tell it where you're keeping the plan folder. When you send that prompt, it creates the command for you and puts it in the commands folder inside Claude folder if you're on Claude Code. Then when you run the reload plugin command in Claude Code, it loads this command into your session. After that, you can run the direction command and it goes through all the requirement documents in the folder with a separate agent for

[3:39] each one. The main agent then checks by itself for any changes that aren't in any of your plans. When all the agents finish, it gives you a full report that tells you if the app is off course or not. It also gives you a scorecard and a list of everything you need to do. From this report, you can either keep the drift and update your requirement documents to match it, or you can remove those changes if you think they've gone too far from your plan. But before we move on to the next one, let's have a word by our sponsor, Victor. Most AI tools stop at the answer. They write you

[4:07] the code and then you're the one who opens the editor, pastes it in, and deploys it yourself. Victor fixes that. Victor isn't a tool, he's a hire, an AI employee who lives in Slack and Microsoft Teams. He runs his own computer in the cloud, so he can actually do the work instead of describing it. We mentioned him in a channel the way you'd message a teammate and asked for a small web app to collect our video ideas with a database behind it. Victor put it together and came back asking for the go ahead before deploying. We approved it and 10 minutes later a working link was sitting in the

[4:38] thread, ready for the team to start dropping ideas in. He connects to 3,200 plus tools and remembers your setup between tasks, so you're not re-explaining the company every morning. You get $100 in free credits with no card needed. Go and hire Victor at victor.com and use code AI Labs 100. Links in the description. The [snorts] third tip is about security, which is something he talked about a lot. He said one of the biggest challenges for himself and for Versel is understanding the security debt. Security debt is basically all the security problems that

[5:10] grow when you're working with agents. And it's getting worse because agents are writing more code than was ever possible before. So no one can go through all of that code by themselves to find problems. But the people trying to break into your app have agents too. Models have gotten so good and so cheap at finding security holes that anyone who wants to cause harm can use them to find problems in your app. So his advice is to get ahead of this and start

[5:34] protecting your code as much as you can. The first rule is to run security scans on your app after you finished building a feature. Versel actually made their own tool for this, which is called DeepSec, and it finds security gaps in the code that the agent built. We've used this tool before, too, and we already have a whole video on DeepSec

[5:52] that you can check out on the channel. You can make your own ways of checking security, but if you want to use DeepSec, it's really easy to set up, too. You just need to run DeepSec's setup command, which creates a .deepsec folder in your project. It gives you a prompt that you paste into Claude code so that Claude writes a short file about

[6:09] your app and how people sign into it. Then you ask Claude to run the scan, and Claude runs all the scans for you. Once that's done, it gives you a full report on what it found. Now, the second rule is about deciding how careful you need to be with each part of your app. He said you need to understand how much slop debt you're taking on. Slop debt is basically all the messy code you choose

[6:30] to accept so that you can build fast. For a small app that isn't a big problem, but you need to be really careful with the most important parts of your product. That's because your customers need to know their data is safe and the app is built really well. You can do this by setting up quality checks before you build the app. There are many ways to set this up, and we've covered a lot of them on our channel before, but the best way is to set up quality gates. Tests only tell you if something works, but a quality gate also checks if it's good enough. It does this

[6:58] with things like a review agent that holds every change to your standards, and no change should go live until it passes every one of those gates. But before we go into the next tip, it would be great if you subscribe to the channel and hit the hype button. This small gesture of support goes a long way for us. The fourth tip is about deciding what you won't trade off. Whenever you're building an app, big or small, you're always trading one thing for another. You can add more features, but that takes more time. You can ship faster, but then something else has to give, like how polished the app is or

[7:28] how much it costs you. But there are some things you can't trade off at all because they really matter to what you're building. This is exactly what he talked about. He said everything the agent builds comes with trade-offs like speed against safety. It can't spend unlimited effort on every task, so it has to pick. That's why you and the agent need to agree on your rules and trade-offs before you start. He said your time should go into whether the app does what it's supposed to and how fast it needs to be. That's because if the model doesn't know what you want, it'll

[7:56] take you in whatever direction it wants. So, you need a separate must not trade-off section in the claw.md file in the main folder of your project. That's where you list all the important things your app has to have and the things you'd never give up. Now, this file is just written instructions for the agent to follow, but agents keep a lot of context in mind, so they tend to forget these rules. That's why every rule should come with a way for the agent to test if it's being met or not. So, to make sure the app still matches your plan, we made the direction command in

[8:25] an earlier section. You can also create the test files and commit them to get, so the agent can't skip these rules. The fifth tip is about having an agent try to break your app on purpose. When Versel launched a new product, he didn't just check that it worked. He gave it to an agent and told it to try to break it by copying the pressure a site gets when

[8:44] lots of people use it at the same time. That means things like doing several things at once that might clash, measuring how slow it got, and comparing it with other products. He said this matters because when a model is writing the code, it's really easy to write code that only works when everything goes right, but it's really hard to think of every way it can go wrong, like someone skipping a step or doing two things at once. That's exactly how your agent tests its own work. It built the app to be used a certain way, so when it checks the app, it uses it that exact way and

[9:13] everything passes. But your customers don't use it that way, and once you have a lot of customers, problems come up that your agent never even thought to test. So, you need to do the same thing and test your app in lots of different ways, especially in the situations that are sure to happen once your app is live. To do that, you need to create a breaker agent for yourself. You can ask whichever agent you're working with to create one, and you need to tell it that its main job is to break the app on purpose and then tell you every way it managed to break it. Basically, it

[9:42] attacks your own app the way someone outside would, so it can find all the weak spots before anyone else does. This helps because if your agent finds a way to break your app, you can fix it. But if someone else finds it first, it could cost you a lot. But what if it breaks

[9:55] your real data while it's attacking? When you give it the prompt, it creates the agent in a way that makes copies of the app's data, so your real data stays safe. Once this agent is ready, you can just ask Claude to run the breaker agent, and it starts a separate agent in its own context window to stress test the app. When it's done, it reports everything back. Then you can ask it to fix the problems and run the tests again to make sure none of them come back. You can also ask your agent to run a review loop with the breaker agent, where it keeps finding and fixing problems. The

[10:26] sixth tip is about seeing your app the way a new customer does. He said one of the values at Versel is knowing your customer, and he explained what that means when you're building with AI. He said it's really easy to build when you're the only customer, because all you're checking is whether you like the app or not. But it's a completely different thing once you're selling it to other people. That's why one of his favorite numbers to track is error-free sessions, which is basically how many people get all the way through your app without anything going wrong. And he uses agents for exactly this. Whenever Versel makes something new, he has an

[10:58] agent go and try it, and then he asks it to tell him what he could have done better. This matters because you can never be a first-time user of your own app. You built it, so you already know where every button is and what every page is for, but a new customer knows none of that. So if the sign-up page asks for something confusing, you'd never notice because you never get stuck there. Your customer gets stuck and

[11:19] leaves the app, and you never learn why. To test your app the way they do, you can ask Claude Code to create an agent that uses the app as a first-time user and tests everything without knowing anything about what the app does. It only runs the app in a browser and finds all the places where a new user might struggle. This really matters because it helps you make the app easier to use and lead people to where you want them to go. But if this agent could read your code, it would already know how everything works. So it wouldn't really be a first-time user. That's why this

[11:49] agent is blocked from reading the app, and the only thing it's allowed to do is run it. This is done with a hook that stops the agent from using its bash tool for anything other than running the app. If it tries to edit the app or delete any code, the hook blocks it. This way you get honest feedback on the app you've built, and you can run this agent to see where users get stuck. But finding where people get confused is only half of it. To actually track the error-free sessions he talked about, you need a separate agent that runs browser tests for all the steps every customer

[12:18] has to get through and reports the results. This really matters because it helps you find problems like slow steps, steps that don't work, or flows that break halfway. Whenever something isn't working properly, the agent can find it and write the code to fix it. It tests each of those paths from start to finish

[12:34] and saves the results in a JSON file. This also helps you judge how well the app performs, and you need to run it every time before you ship. The seventh and final tip is about how fast you act on what your customers tell you. He said one of the best ways to tell how well a company is using agents is to look at what happens when a customer reports a problem. You need to check if someone replies to them properly and checks what went wrong. If it's a clear problem, it should actually get fixed. And most of all, you need to how long all of that

[13:02] takes from the moment the report comes in. Now, the feedback you get from your customers isn't all the same. Sometimes a customer sends you a screenshot of a button that isn't working, and there's no thinking needed there. So you just need to fix it as fast as you can. But other times a customer tells you they're confused by your app, you can't really turn that into a prompt, so you actually have to talk to them and understand what they mean before you change anything. So to handle both of these, you can connect Claude to the places your feedback comes from using MCP servers. For example, you

[13:32] can connect the Gmail MCP so it can read your support emails. You can also connect the Sentry MCP, which reports every error your app hits even if no customer has said anything about it. Once that's connected, Claude reads each new report as it comes in and sorts it. If something is actually broken, like a payment failing, it fixes it straight away. And if it needs your judgment, Claude sends it to you so you can decide what to do with it. Now, all the agents and skills you saw in this video are all available for you to use in AI Labs Pro, which is our community. So, if you found

[14:03] value in what we do and want to support the channel, this is the best way to do it. The link's in the description. That brings us to the end of this video. If you'd like to support the channel and help us keep making videos like this, you can do so by using the Super Thanks button below. As always, thank you for watching and I'll see you in the next

[14:20] one.

---

About this transcript
Read from YouTube's own caption track and laid out by ViewRank AI (https://viewrankai.com).
ViewRank AI finds the videos already beating a creator's own average on Instagram, TikTok and YouTube Shorts, transcribes them from the audio itself in more than 60 languages, and turns what worked into new ideas and scripts.
Free transcript tools, no account needed: https://viewrankai.com/tools
How to read any video this way: https://viewrankai.com/llms.txt