Numa aula de Laravel sobre arquitetura de sistemas, eu contei que mexi numa verificação de segurança e bloqueei o acesso de colegas à aplicação. Eu queria ajustar uma condição, mas perdi de vista as telas afetadas. O teste encontrou o problema enquanto a mudança ainda estava no repositório. Sem esse retorno, a primeira notícia viria do suporte, depois de uma tentativa de login recusada.

Levo esse episódio para o Vibe Coding. A IA pode criar a tela e escrever os arquivos em pouco tempo, mas uma aplicação continua precisando de permissões, registros preservados, testes e uma forma de investigar falhas.

Eu uso o Laravel porque ele deixa essas partes em lugares conhecidos. O framework não confere a qualidade da alteração por mim. Ele só desloca a revisão da memória do chat para os arquivos que definem o comportamento da aplicação.

Direto ao ponto

O Laravel permite revisar código gerado por IA quando você consegue localizar a mudança pelo efeito que ela produz. Uma permissão pode ficar em uma policy, uma alteração no banco em uma migration e o comportamento esperado em um teste de feature. Esses lugares não substituem a leitura, mas mostram onde procurar.

Quando você envia à IA uma instrução para criar uma função, a pergunta não termina em “a tela está abrindo?”. Ela continua no acesso que deve ser aceito ou negado, no registro que será criado e no teste que precisa falhar quando outra alteração quebrar aquele comportamento. O framework deixa esse diálogo registrado no repositório.

Laravel deixa a permissão fora do formulário

Pense numa área onde um membro de um grupo edita um artigo. A IA pode montar o formulário, carregar os registros e devolver uma mensagem de sucesso. Ainda falta uma pergunta que o formulário não responde: esse membro pode editar qualquer artigo ou somente os artigos do grupo ao qual pertence?

No Laravel, uma policy concentra essa autorização. Você abre a classe, compara a condição com o requisito e testa dois casos: uma edição aceita e outra recusada. A Form Request pode validar a entrada e também avaliar a autorização da requisição.

Eu prefiro revisar por esse caminho porque uma condição espalhada pelo controller, pelo componente e pela consulta ao banco fica difícil de perceber na próxima interação com o agente. A policy não impede que alguém escreva uma condição ruim. Ela cria um arquivo que você pode abrir, discutir e cobrir com um teste ligado ao acesso real.

A requisição percorre mais que a página aberta

Middleware examina a requisição no caminho até a rota ou o controller. O Laravel já inclui middleware para autenticação e proteção contra falsificação de requisição. A documentação oficial mostra que ele pode recusar uma entrada sem autenticação ou deixá-la seguir.

Essa separação aparece quando você revisa uma área administrativa. A rota pode exigir autenticação. A policy pode decidir se você, já autenticado, executa uma ação sobre determinado registro. A request pode validar o conteúdo enviado. São três perguntas diferentes. Se a IA altera apenas a tela, você ainda precisa verificar se as três partes continuam coerentes com o que a aplicação promete.

Você não precisa decorar toda a arquitetura do Laravel. Precisa saber apontar a parte afetada e abri-la depois que a IA termina.

A migration registra o que mudou no banco

Uma coluna nova no formulário também cria uma responsabilidade no banco. A migration torna essa alteração visível no histórico do projeto. Quando a IA acrescenta um campo, eu quero ver qual tipo foi escolhido, se registros antigos podem ficar sem valor e se uma reversão preserva a aplicação em um estado consistente. A tela preenchida não responde a essas perguntas.

Esse cuidado importa mais quando o sistema já tem clientes e registros salvos. Um campo obrigatório pode quebrar uma edição antiga. A revisão começa pelo efeito esperado, passa pela migration e termina no teste que cria ou atualiza o registro naquele estado.

No Laravel, a estrutura do projeto permite encontrar migrations e modelos, mas o conteúdo ainda precisa ser lido. Framework não converte um requisito mal definido em comportamento confiável. Ele reduz a distância entre a frase que explica a mudança e o arquivo que você precisa conferir.

Um teste vale mais que a confirmação do agente

O agente pode resumir bem o que fez. O resumo não mostra se uma permissão foi mantida, se a validação recusou um campo inválido ou se a migration mudou uma criação existente. O teste permite executar essas situações de novo.

O Laravel separa testes unitários de testes de feature. Os unitários avaliam uma parte isolada do código. Os testes de feature podem atravessar uma porção maior da aplicação, incluindo uma requisição HTTP. Para mudanças que envolvem rota, autenticação e autorização, eu começo pelo comportamento que você encontra no navegador. A documentação de testes explica essa diferença e mostra o suporte do framework a Pest e PHPUnit.

O teste não prova que todo o sistema está certo. Ele preserva uma condição que você escolheu manter. Quando outra alteração remove por engano uma permissão ou quebra a criação de um registro, o teste vira a parte do repositório que contesta a resposta do agente. É melhor do que uma instrução vaga, porque o comportamento esperado está escrito e pode falhar.

No artigo sobre como o Hermes Agent usa memória, skills e ferramentas, eu trato a saída do agente como algo que precisa ser aberto e conferido. O Laravel oferece uma estrutura útil para repetir essa conferência em aplicações web.

O aceite continua com você

Eu uso o Laravel como trilho de revisão porque ele dá nomes para a instrução da a IA. Você descreve a ação, a permissão e o comportamento que o teste deve confirmar. Depois abre a comparação dos arquivos, lê a autorização alterada, executa o teste e confere a migration. A IA Makers da Promovaweb trabalha essa relação entre implementação assistida e revisão técnica. A IA escreve parte do código. o entendimento da arquitetura e o aceite permanecem com você.