O CEO da Vercel revelou seu próprio workflow de programação com IA

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Vercel’s CEO Just Revealed His Own AI Coding Workflow · Canal: AI LABS · 14:07 · Assistir no YouTube

Tópicos: Agentes de IA, Aplicações empresariais de IA, Cibersegurança e segurança de software, Engenharia de software com IA

Resumo

O vídeo apresenta sete práticas que o CEO da Vercel usa ao trabalhar com agentes de IA: testar ideias com MVPs, acompanhar se o produto continua alinhado ao plano e cuidar da segurança e da qualidade. Também recomenda definir requisitos inegociáveis, usar um agente para tentar quebrar o app e avaliar a experiência como um novo cliente. Por fim, explica como acompanhar sessões sem erros e responder com agilidade ao feedback dos clientes. Para cada prática, o vídeo sugere formas de aplicá-la com ferramentas e agentes.

Pontos-chave

Teste ideias em projetos separados e crie um MVP antes de investir na construção completa do app.
Acompanhe se o desenvolvimento segue os requisitos e o PRD, não apenas métricas como tokens gastos ou mudanças enviadas.
Use uma verificação de direção para identificar funcionalidades que desviam o produto do plano.
Faça scans de segurança e estabeleça quality gates para controlar riscos e qualidade do código.
Registre no CLAUDE.md o que não pode ser sacrificado e associe cada regra a uma forma de testá-la.
Crie um agente breaker para procurar falhas e testar o app em condições difíceis, sem arriscar os dados reais.
Peça a um agente que use o app como alguém que o está vendo pela primeira vez e identifique pontos de confusão.
Acompanhe sessões sem erros e teste os fluxos dos clientes do início ao fim antes de enviar mudanças.
Conecte fontes de feedback e erros para classificar relatos, corrigir problemas claros e encaminhar decisões que exigem julgamento humano.

Capítulos

Início	Capítulo	Resumo
00:00	Testar ideias antes de construir	O vídeo apresenta as dicas da entrevista e recomenda testar ideias em um projeto separado e criar um MVP antes de desenvolver o app completo.
02:07	Manter o produto na direção certa	Acompanhe o alinhamento com o plano usando um comando de direção que compara o app com os requisitos e identifica desvios.
04:39	Segurança, qualidade e requisitos inegociáveis	O vídeo aborda scans de segurança, quality gates e a importância de registrar regras que o agente deve seguir e testar.
07:16	Definir trade-offs e tentar quebrar o app	Defina o que não pode ser sacrificado e use um agente breaker para procurar falhas em situações adversas.
10:26	Testar a experiência de novos clientes	Use agentes sem acesso ao código para avaliar o app como um novo usuário e testar os fluxos de ponta a ponta.
13:02	Agir sobre o feedback dos clientes	Conecte fontes de feedback e erros para corrigir problemas claros rapidamente e encaminhar ao julgamento humano os casos que exigem contexto.

Citações

Eles só dizem quanto você está fazendo, não para onde isso está levando você. — 02:07

Os testes só dizem se algo funciona; um quality gate também verifica se está bom o suficiente. — 06:44

A quinta dica é fazer um agente tentar quebrar seu app de propósito. — 08:19

Você nunca pode ser um usuário iniciante do seu próprio app. — 10:56

Você precisa medir quanto tempo tudo isso leva desde o momento em que o relato chega. — 13:02

Conceitos e entidades

Vercel (empresa): Empresa cujo CEO compartilha práticas de desenvolvimento de produtos com agentes de IA.
AI Labs (empresa): Canal que apresenta e adapta as dicas discutidas na entrevista.
Claude Code (ferramenta): Ferramenta usada nos exemplos para criar comandos e agentes e executar verificações no app.
DeepSec (ferramenta): Ferramenta mencionada para identificar falhas de segurança no código.
Victor (ferramenta): Funcionário de IA apresentado no patrocínio, capaz de executar tarefas em um computador na nuvem.
MCP (conceito): Meio citado para conectar Claude a fontes de feedback, como e-mails de suporte e relatórios de erros.
breaker agent (conceito): Agente configurado para tentar quebrar o app e revelar pontos fracos antes que sejam encontrados por outras pessoas.
quality gates (conceito): Verificações que avaliam se uma mudança atende a padrões de qualidade antes de ser enviada.
MVP (conceito): Primeira versão funcional de um app, usada para avaliar rapidamente se a ideia vale a pena.

Tradução completa (pt-BR)

00:00 O CEO da Vercel deu uma entrevista em que falou sobre como trabalha com agents de IA. E, curiosamente, ele disse que a maioria das pessoas avalia o quanto está construindo bem com IA por um número que não importa nem de longe tanto quanto elas pensam. Isso porque esse número só mostra quanto você está construindo, não para onde isso está levando você. Então, o que importa para ele é saber se todo esse trabalho está realmente indo na direção que você planejou. E transformamos essa ideia em um comando que você mesmo pode executar. Mas essa nem é a coisa mais surpreendente que ele faz. Uma delas parece absurda quando você ouve pela primeira vez. Mas, quando entende

00:30 por que ele faz isso, acaba sendo uma das dicas mais valiosas de toda a entrevista. E essa é só uma das muitas coisas sobre as quais ele falou. Então, analisamos tudo e selecionamos as sete dicas que são realmente úteis. Se esta é a sua primeira vez aqui, somos uma empresa de software, e este é o nosso canal AI Labs. Neste vídeo, vamos apresentar cada uma das sete dicas dele e mostrar como você pode configurá-las por conta própria. A primeira dica da entrevista é sobre testar as coisas antes de decidir usá-las. Ele disse que, sempre que tem uma ideia, cria um projeto novo para ela e testa suas ideias ali. Depois, pede para um agent verificar do zero se ela realmente funciona, em vez de confiar no que alguém diz a respeito. Talvez você esteja se perguntando por que ele não simplesmente segue o que todo mundo diz. Ele afirmou que muita gente decide com base na impressão que tem dos modelos. Ele soube de alguém que leu um guia de prompting que dizia que Astra se saía melhor com certo tipo de prompt, então essa pessoa começou a usar esse tipo de prompt. Mas nunca verificou se aquilo era verdade. Para ele, testar por conta própria é importante porque assim sabe o que realmente funciona e o que não funciona. Nós também fazemos o mesmo. Sempre que temos um projeto novo, começamos com uma pasta specs que contém o arquivo PRD. Esse arquivo lista todos os principais recursos que planejamos

01:00 adicionar ao app. Então, é o primeiro documento de todo projeto que criamos. Mas, se você pegar esse PRD e começar imediatamente a construir o app inteiro, só vai descobrir muito tarde que a própria ideia tinha problemas. Isso também prejudica todas as suas decisões iniciais. Se alguma delas estiver errada, todo o resto já terá sido construído em cima dela. Então, para corrigir, você terá que voltar e revisar o app inteiro. Por isso, seja qual for o app que estivermos criando, sempre começamos pedindo ao Claude Code ou ao agent que estivermos usando para criar um MVP, e passamos no prompt todos os recursos básicos. Um MVP é basicamente a primeira versão funcional do seu app, na qual você

01:34 constrói os recursos rapidamente para ver como sua ideia realmente fica depois de implementada. É nesse momento que podemos ver se vale mesmo a pena construir o app. E, se não valer, podemos simplesmente abandonar a ideia sem desperdiçar muito esforço. A segunda dica é garantir que tudo o que você constrói esteja levando o app na direção certa. Ele disse que muita gente avalia o próprio progresso pelo número de tokens que usa ou pela quantidade de mudanças que publica, e esses números são úteis para acompanhar. Mas eles só mostram quanto você está fazendo, não para onde isso está levando você. Isso significa que você pode continuar publicando e, mesmo assim, não chegar a lugar nenhum. Isso importa muito mais agora

02:07 porque, com agents, construir é a parte barata. Você pode pedir um novo recurso ao Claude e tê-lo funcionando em poucos minutos. Então, cada ideia que surge enquanto você está construindo vira um recurso, e cada novo recurso parece um progresso. E o Claude não vai impedir você, porque constrói qualquer coisa que você pedir e não tem ideia de quais desses recursos realmente importam para o seu app. Mas você já tem o plano na pasta specs, com todos os documentos de requisitos e o PRD. O problema é que, depois que você começa a construir, o app pode se afastar aos poucos desse plano e passar a incluir recursos que nem sequer importam para o seu

02:37 app. Para evitar que isso aconteça, você pode pedir ao seu agent para criar um comando chamado direction, que verifica se o que você construiu está saindo do rumo ou ainda corresponde ao plano. Você também precisa dizer onde está a pasta do plano. Quando você envia esse prompt, ele cria o comando e o coloca na pasta commands, dentro da pasta Claude, se estiver usando o Claude Code. Depois, quando você executa o comando reload plugin no Claude Code, ele carrega esse comando na sua sessão. Aí, você pode executar o comando direction, e ele analisa todos os documentos de requisitos da pasta, usando um agent separado para

03:07 cada um. Em seguida, o agent principal verifica por conta própria se há mudanças que não estão em nenhum dos seus planos. Quando todos os agents terminam, ele apresenta um relatório completo que informa se o app saiu do rumo ou não. Também fornece uma tabela de avaliação e uma lista de tudo o que você precisa fazer. Com base nesse relatório, você pode manter o desvio e atualizar os documentos de requisitos para que correspondam a ele, ou remover essas mudanças se achar que se afastaram demais do plano. Mas, antes de passarmos para a próxima dica, vamos ouvir algumas palavras do nosso patrocinador, Victor. A maioria das ferramentas de IA para na resposta. Elas escrevem o código para você, e depois é você quem

03:39 abre o editor, cola o código e faz o deploy por conta própria. Victor resolve isso. Victor não é uma ferramenta; é uma contratação, um funcionário de IA que vive no Slack e no Microsoft Teams. Ele usa o próprio computador na nuvem, então consegue realmente fazer o trabalho, em vez de apenas descrevê-lo. Mencionamos ele em um canal, como você faria ao mandar uma mensagem para um colega de equipe, e pedimos um pequeno app web para reunir nossas ideias para vídeos, com um banco de dados por trás. Victor montou tudo e voltou para pedir autorização antes de fazer o deploy. Aprovamos e, 10 minutos depois, havia um link funcional na conversa, pronto para a equipe começar a

04:09 enviar ideias. Ele se conecta a mais de 3.200 ferramentas e se lembra da sua configuração entre tarefas, então você não precisa explicar a empresa de novo toda manhã. Você ganha US$ 100 em créditos grátis, sem precisar de cartão. Contrate Victor em victor.com e use o código AI Labs 100. Os links estão na descrição. A terceira dica é sobre segurança, um assunto de que ele falou bastante. Ele disse que um dos maiores desafios para ele e para a Vercel é entender a dívida de segurança. Dívida de segurança é basicamente o conjunto de problemas de segurança que

04:39 se acumula quando você trabalha com agents. E isso está piorando porque os agents estão escrevendo mais código do que jamais foi possível antes. Então, ninguém consegue analisar todo esse código sozinho para encontrar problemas. Mas as pessoas que tentam invadir o seu app também têm agents. Os modelos ficaram tão bons e tão baratos para encontrar falhas de segurança que qualquer pessoa que queira causar danos pode usá-los para encontrar problemas no seu app. Por isso, o conselho dele é se antecipar e começar a proteger seu código tanto quanto puder. A primeira regra é fazer verificações de segurança no seu app depois de terminar de criar um recurso. A Vercel, na verdade, criou sua própria

05:10 ferramenta para isso, chamada DeepSec, que encontra falhas de segurança no código criado pelo agent. Nós também já usamos essa ferramenta e temos um vídeo inteiro sobre DeepSec no canal, que você pode conferir. Você pode criar seus próprios métodos para verificar a segurança, mas, se quiser usar o DeepSec, também é muito fácil configurá-lo. Basta executar o comando de configuração do DeepSec, que cria uma pasta .deepsec no seu projeto. Ele fornece um prompt que você cola no Claude Code, para que o Claude escreva um arquivo curto sobre o seu app e sobre como as pessoas fazem login nele. Depois, você pede ao Claude para executar a verificação, e

05:42 ferramenta própria para isso, chamada DeepSec, que encontra falhas de segurança no código criado pelo agent. Também já usamos essa ferramenta antes e temos um vídeo inteiro sobre o DeepSec no canal, que você pode conferir. Você pode criar suas próprias maneiras de verificar a segurança, mas, se quiser usar o DeepSec, também é muito fácil configurá-lo. Basta executar o comando de configuração do DeepSec, que cria uma pasta .deepsec no seu projeto. Ele fornece um prompt que você cola no Claude Code para que o Claude escreva um arquivo curto sobre seu app e sobre como as pessoas fazem login nele. Depois, você pede ao Claude para executar a verificação, e

06:13 Claude executa todas as verificações para você. Quando termina, ele apresenta um relatório completo do que encontrou. Agora, a segunda regra é decidir quanto cuidado você precisa ter com cada parte do seu app. Ele disse que você precisa entender quanto de dívida de código bagunçado está assumindo. Essa dívida é basicamente todo o código desorganizado que você escolhe aceitar para conseguir desenvolver rápido. Para um app pequeno, isso não é um grande problema, mas você precisa ter muito cuidado com as partes mais importantes do seu produto. Isso porque seus clientes precisam saber que os dados deles estão seguros e que o app foi muito bem construído. Você pode fazer isso configurando verificações de qualidade

06:44 antes de desenvolver o app. Há muitas maneiras de configurar isso, e já falamos sobre várias delas no nosso canal, mas a melhor forma é criar barreiras de qualidade. Os testes só dizem se algo funciona, mas uma barreira de qualidade também verifica se está bom o suficiente. Isso é feito com coisas como um agent de revisão, que avalia cada mudança segundo seus padrões, e nenhuma mudança deve entrar em produção até passar por todas essas barreiras. Mas, antes de passarmos à próxima dica, seria ótimo se você se inscrevesse no canal e apertasse o botão de hype. Esse pequeno gesto de apoio significa muito para nós. A quarta dica é sobre decidir

07:16 o que você não vai sacrificar. Sempre que você está desenvolvendo um app, grande ou pequeno, está trocando uma coisa por outra. Você pode adicionar mais recursos, mas isso leva mais tempo. Pode lançar mais rápido, mas aí alguma outra coisa precisa ficar de lado, como o nível de acabamento do app ou quanto ele custa para você. Mas há algumas coisas que você não pode sacrificar de jeito nenhum, porque são realmente importantes para o que está construindo. Foi exatamente sobre isso que ele falou. Ele disse que tudo o que o agent constrói envolve concessões, como velocidade em troca de segurança. O agent não pode dedicar esforço ilimitado a cada tarefa, então precisa escolher. Por isso, você e o agent precisam concordar sobre suas regras e concessões antes de começar. Ele disse

07:49 que seu tempo deve ser dedicado a verificar se o app faz o que deveria fazer e qual velocidade ele precisa ter. Isso porque, se o modelo não souber o que você quer, vai levar você na direção que ele quiser. Então, você precisa de uma seção separada, chamada “não sacrificar”, no arquivo claw.md, na pasta principal do seu projeto. É lá que você lista todas as coisas importantes que seu app precisa ter e aquelas das quais você nunca abriria mão. Esse arquivo contém apenas instruções por escrito para o agent seguir, mas agents mantêm muito contexto em mente e, por isso, tendem a esquecer essas regras. É por isso que cada regra deve vir acompanhada de uma maneira de o agent

08:19 testar se ela está sendo cumprida ou não. Então, para garantir que o app continue de acordo com seu plano, criamos o comando direction em uma seção anterior. Você também pode criar os arquivos de teste e fazer commit deles no Git, para que o agent não possa ignorar essas regras. A quinta dica é fazer com que um agent tente quebrar seu app de propósito. Quando Versel lançou um produto novo, ele não se limitou a verificar se funcionava. Ele entregou o produto a um agent e pediu que tentasse quebrá-lo, simulando a pressão que um site sofre quando muitas pessoas o usam ao mesmo tempo. Isso envolve coisas como fazer várias ações simultaneamente que podem entrar em conflito, medir quanto o site ficou lento e compará-lo

08:51 com outros produtos. Ele disse que isso é importante porque, quando um modelo escreve o código, é muito fácil escrever código que só funciona quando tudo dá certo, mas é muito difícil pensar em todas as maneiras como as coisas podem dar errado, como alguém pular uma etapa ou fazer duas coisas ao mesmo tempo. É exatamente assim que seu agent testa o próprio trabalho. Ele construiu o app para ser usado de determinada maneira e, quando o verifica, usa-o exatamente dessa maneira, e tudo passa. Mas seus clientes não usam o app assim e, quando você tem muitos clientes, surgem problemas que seu agent nem sequer pensou em testar. Então, você precisa fazer a mesma coisa

09:23 e testar seu app de muitas maneiras diferentes, especialmente em situações que certamente vão acontecer quando ele estiver no ar. Para isso, você precisa criar um agent de testes destrutivos. Você pode pedir ao agent com quem está trabalhando que crie um, e precisa dizer a ele que sua principal função é quebrar o app de propósito e depois contar todas as maneiras como conseguiu quebrá-lo. Basicamente, ele ataca seu próprio app como alguém de fora faria, para encontrar todos os pontos fracos antes que qualquer outra pessoa os encontre. Isso ajuda porque, se seu agent encontrar uma maneira de quebrar o app, você pode corrigir o problema. Mas, se outra pessoa o encontrar primeiro, isso pode

09:54 custar muito caro. Mas e se ele quebrar seus dados reais durante o ataque? Quando você fornece o prompt, ele cria o agent de um jeito que faz cópias dos dados do app, para que seus dados reais continuem seguros. Quando esse agent estiver pronto, basta pedir ao Claude para executá-lo, e ele inicia um agent separado, na própria context window, para fazer um teste de estresse no app. Quando termina, ele apresenta um relatório completo. Depois, você pode pedir que corrija os problemas e execute os testes novamente para garantir que nenhum deles volte a ocorrer. Você também pode pedir ao seu agent que execute um ciclo de revisão com o agent de testes destrutivos, no qual ele continua encontrando e corrigindo problemas. A

10:26 sexta dica é ver seu app como um cliente novo o veria. Ele disse que um dos valores da Versel é conhecer o cliente e explicou o que isso significa ao desenvolver com IA. Ele disse que é muito fácil desenvolver quando você é o único cliente, porque só está verificando se gosta ou não do app. Mas é completamente diferente quando você o vende para outras pessoas. Por isso, um dos números que ele mais gosta de acompanhar é o de sessões sem erros, que basicamente indica quantas pessoas conseguem percorrer o app inteiro sem que nada dê errado. E é exatamente para isso que ele usa agents. Sempre que

10:56 a Versel cria algo novo, ele pede a um agent que experimente e, depois, pergunta o que poderia ter sido feito melhor. Isso é importante porque você nunca pode ser um usuário iniciante do seu próprio app. Você o construiu, então já sabe onde fica cada botão e para que serve cada página, mas um cliente novo não sabe nada disso. Então, se a página de cadastro pedir algo confuso, você nunca vai perceber, porque não fica preso nela. Seu cliente fica preso e sai do app, e você nunca descobre o motivo. Para testar seu app como eles fazem, você pode pedir ao Claude Code que crie um agent que use o app como um usuário iniciante

11:28 e teste tudo sem saber nada sobre o que o app faz. Ele só executa o app em um navegador e encontra todos os lugares em que um usuário novo pode ter dificuldades. Isso é muito importante porque ajuda a tornar o app mais fácil de usar e a conduzir as pessoas para onde você quer que elas cheguem. Mas, se esse agent pudesse ler seu código, já saberia como tudo funciona. Então, ele não seria realmente um usuário iniciante. Por isso, esse agent é impedido de ler o app, e a única coisa que pode fazer é executá-lo. Isso é feito com um hook que impede o agent de usar a ferramenta bash para qualquer coisa além de executar o app.

11:59 Se ele tentar editar o app ou apagar qualquer código, o hook o bloqueia. Assim, você recebe opiniões sinceras sobre o app que construiu e pode executar esse agent para descobrir onde os usuários ficam presos. Mas descobrir onde as pessoas ficam confusas é só metade do trabalho. Para realmente acompanhar as sessões sem erros de que ele falou, você precisa de um agent separado que execute testes no navegador para todas as etapas pelas quais cada cliente precisa passar e relate os resultados. Isso é muito importante porque ajuda a encontrar problemas como etapas lentas, etapas que não funcionam ou fluxos que falham pela metade. Sempre que algo não funciona direito, o agent consegue encontrar o problema

12:30 e escrever o código para corrigir o problema. Ele testa cada um desses caminhos do início ao fim e salva os resultados em um arquivo JSON. Isso também ajuda você a avaliar o desempenho do app, e você precisa executar o teste toda vez antes de lançar. A sétima e última dica é sobre a rapidez com que você age com base no que seus clientes dizem. Ele disse que uma das melhores maneiras de avaliar como uma empresa está usando agents é observar o que acontece quando um cliente relata um problema. Você precisa verificar se alguém responde adequadamente e confere o que deu errado. Se o problema for claro, ele deve ser realmente corrigido. E, acima de tudo, você precisa ver quanto tempo tudo isso

13:02 leva desde o momento em que a reclamação chega. Agora, o feedback que você recebe dos seus clientes não é todo igual. Às vezes, um cliente envia uma captura de tela de um botão que não está funcionando, e não é preciso pensar muito nesse caso. Então, você só precisa corrigir o problema o mais rápido que puder. Mas, em outras ocasiões, um cliente diz que está confuso com o seu app, e não dá para transformar isso exatamente em um prompt. Então, você precisa conversar com ele e entender o que quer dizer antes de mudar qualquer coisa. Para lidar com essas duas situações, você pode conectar o Claude aos lugares de onde vem o seu feedback usando servidores MCP. Por exemplo, você pode conectar o Gmail MCP para que ele possa ler

13:34 seus e-mails de suporte. Você também pode conectar o Sentry MCP, que informa todos os erros que acontecem no seu app, mesmo que nenhum cliente tenha falado sobre eles. Depois de conectar, o Claude lê cada novo relato assim que chega e o classifica. Se algo estiver realmente quebrado, como uma falha no pagamento, ele corrige na hora. E, se precisar do seu julgamento, o Claude encaminha o caso para você, para que possa decidir o que fazer. Agora, todos os agents e skills que você viu neste vídeo estão disponíveis para você usar no AI Labs Pro, que é a nossa comunidade. Então, se você achou nosso conteúdo útil e quer apoiar o canal, essa é a melhor maneira de

14:07 fazer isso. O link está na descrição. Com isso, chegamos ao fim deste vídeo. Se quiser apoiar o canal e nos ajudar a continuar fazendo vídeos como este, você pode fazer isso usando o botão Super Thanks abaixo. Como sempre, obrigado por assistir e até o próximo vídeo.

Transcrição original

[00: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

[00: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 and tests his ideas in there. Then he

[01:00] 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 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

[01:34] 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 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

[02:07] quickly build the features to see how 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

[02: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

[03: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

[03: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 the code and then you’re the one who

[04:09] 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 thread, ready for the team to start

[04:39] 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

[05: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 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

[05:42] 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 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 your app and how people sign into it. Then you ask Claude to run the scan, and

[06:13] 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 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

[06:44] 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 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

[07:16] 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 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

[07:49] 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 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

[08:19] test if it’s being met or not. So, to make sure the app still matches your plan, we made the direction command in 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 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

[08:51] 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 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

[09:23] 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 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

[09:54] cost you a lot. But what if it breaks 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

[10:56] Versel makes something new, he has an 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 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

[11:28] 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 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.

[11:59] 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 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

[12:30] and write the code to fix it. It tests each of those paths from start to finish 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 can connect the Gmail MCP so it can read

[13:34] 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 value in what we do and want to support the channel, this is the best way to do

[14:07] 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 one.