Quatro dias de vibe coding na pele de um PM enferrujado

Venho do código.

Fui DevOps, mesmo que na época não fosse necessariamente assim que chamávamos. Fui desenvolvedor. Fui arquiteto de software. Depois, gradualmente, me afastei dessas funções e migrei para gestão de times de dev, projetos, agile, product management.

Não parei de programar do dia para a noite. No início, ainda escrevia scripts Python por conta própria — automatizando uma tarefa, organizando arquivos, transformando formatos, construindo uma pequena ferramenta. Depois comecei a delegar parte disso ao ChatGPT, no modo chat. Em seguida, migrei progressivamente para o Claude Code. Mas em todos os casos, eram apenas pequenos pedaços de código para fazer ferramentas, não desenvolvimento de produto no sentido pleno.

Até então, era algo muito delimitado. Um script Python, uma função. Uma tarefa específica. Um tipo de delegação limpa: em vez de pedir ao LLM para organizar os arquivos dentro do seu contexto, você pedia que ele escrevesse um script. Ele executava a operação, você verificava, seguia em frente.

Mas não é mais isso que está acontecendo nos últimos dias.

Nos últimos quatro dias, voltei a desenvolver. Ou melhor: estou fazendo o Claude Code desenvolver. E desta vez, não estou falando de um script utilitário. Estou falando de um produto real, do zero, com telas, APIs internas, comportamentos avançados, modificações de dados, decisões de arquitetura, testes, documentação gerada a partir do código.

Este texto não é uma conclusão sobre vibe coding. Não tenho distância suficiente para isso. Quatro dias é tempo demais curto para construir uma doutrina. Talvez esse seja até o ponto mais importante: ainda estou no meio disso. Estou documentando uma travessia.

A lua de mel

A primeira coisa que impressiona é a velocidade.

Em quatro dias, produzi algo que, na época em que eu desenvolvía, teria levado provavelmente um mês. Talvez dois. E não estou exagerando. Comecei do zero. Fiz mais de 180 commits. Construí, quebrei, corrigi, reorganizei, testei, adicionei comportamentos, apresentei o produto, recebi pedidos de melhoria, continuei.

É estimulante.

Tem um momento em que você pensa: isso é incrível. Posso ter uma ideia, articulá-la, pedir ao Claude para implementar, testar, ajustar, recomeçar. Não estou mais escrevendo uma spec imaginando como o produto vai ser depois. Já estou dentro dele.

E isso muda muita coisa.

Com um mockup, você já consegue iterar. Vê uma tela, um fluxo, uma intenção. Pensa: o botão está no lugar errado, esse caso de uso não está claro, falta uma informação. Mas com um produto funcionando, mesmo imperfeito, a iteração fica ainda mais direta. Você usa de verdade. Vê de verdade. Sente os atritos.

No meu caso, a transição aconteceu de forma bastante natural. No início parecia um mockup. Depois o mockup começou a funcionar. Depois o apresentei. Depois pediram melhorias. Depois perguntaram quando poderiam usar.

É aí que o perigo costuma começar: quando o descartável se torna útil.

O banho de água fria

A segunda coisa que impressiona é que o Claude Code, deixado sozinho, pode fazer absolutamente qualquer coisa.

Não qualquer coisa no sentido de que nada funciona. É quase o contrário. Muitas vezes funciona. A tela renderiza. Os dados carregam. O botão faz algo. A demo passa. E é exatamente por isso que é perigoso.

Claude tem uma tendência natural a avançar. Ele codifica. Adiciona. Cresce. Começa com um arquivo razoável, depois esse arquivo vai inflando, inflando, até se tornar um bloco que faz um pouco de tudo. Quando você precisa modificá-lo, leva mais tempo. Quando precisa entender a intenção, fica mais difícil. Quando aparece um bug, você não sabe mais exatamente onde olhar.

Um desenvolvedor experiente pensa rapidamente na separação de responsabilidades. Pergunta onde colocar a lógica de negócio, como isolar o transporte, onde colocar a renderização, como nomear os conceitos, como evitar que tudo fique acoplado. Claude consegue fazer isso, mas não o faz espontaneamente com consistência. Você precisa guiá-lo.

O mesmo vale para o volume de dados.

No meu projeto, algumas APIs podem retornar algumas centenas de itens. Outras podem retornar dezenas de milhares. Não é nem de longe o mesmo mundo. Carregar 200 itens para exibir numa página é diferente de carregar 20.000 ou 30.000 itens e torcer para que o navegador, o usuário e o backend continuem de bom humor.

Mas se você não disser nada, o Claude pode tranquilamente carregar tudo, passar tudo para a página web, filtrar no front, e considerar o problema resolvido. Em testes, com poucos dados, pode parecer que funciona. No uso real, explode. Ou pior: não quebra de forma clara — só fica lento, travado, incompreensível.

Um bug nem sempre é um erro vermelho no console. Às vezes é só um produto que para de responder porque carregou 5.000 itens silenciosamente, sem log, sem paginação, sem estratégia clara. E aí, um PM sem base técnica pode não entender o que está acontecendo.

Gerenciar um desenvolvedor júnior muito rápido

Minha relação com o Claude Code me fez pensar muito em gerenciar um desenvolvedor júnior extremamente rápido.

Ele pode produzir muito. Também pode tomar liberdades absurdas. Você dá uma captura de tela de um componente, ele não faz exatamente o que foi pedido. Interpreta. Simplifica. Vai numa direção. Às vezes é preciso explicar tudo de novo do básico: por que esse arquivo não pode conter tudo, por que essa camada não pode conhecer aquela outra, por que não se carrega todos os dados, por que é preciso escrever os testes, por que é preciso rodá-los de novo.

E às vezes ele não entende de imediato.

Isso não é grave em si. Desenvolvedores humanos também erram. Coisas desenvolvidas por devs às vezes vão para produção e não aguentam a carga. A dívida técnica não surgiu com PMs fazendo vibe coding.

Mas a IA adiciona uma velocidade que muda o problema. Ela permite produzir muito código mediano muito rápido. Se as diretrizes não estiverem boas, a dívida vem rápido. Muito rápido.

Da minha parte, minha bagagem técnica ajuda. Entendo as linhas gerais da arquitetura. Vejo quando um arquivo começa a ficar grande demais. Vejo quando as camadas estão se misturando. Sinto quando algo vai causar um problema de volume ou de manutenibilidade.

Mas não controlo tudo. Há partes do código que não conseguiria explicar imediatamente. Se me der o tempo, consigo entendê-las. Mas não posso fingir ter o mesmo domínio de quem escreveu cada linha.

Nesse produto, aceito isso. Em outros, não aceitaria.

E essa distinção é essencial.

O verdadeiro assunto: competência multiplicada por risco

Você poderia formular a pergunta assim: todos os PMs podem agora desenvolver software com IA?

Minha resposta espontânea seria: não.

Ou melhor: depende.

Mas o "depende" não é esquiva. Não é só uma questão de competência individual. É uma relação entre o nível de competência e o nível de risco do produto.

É exatamente como com um desenvolvedor júnior. Você dá acesso imediato a um júnior ao repositório mais complexo, mais crítico, mais impactante para o negócio? Provavelmente não. Dá acesso a todos os repos, todos os dados, todas as permissões? Também não.

Para um PM que faz vibe coding, é a mesma coisa.

Não se trata de dizer: PMs podem ou não podem fazer isso. É definir o que eles podem fazer, em qual perímetro, com quais limites, conforme o nível de cada um e o risco envolvido.

Gosto da analogia da carteira de motorista. Você não dirige qualquer veículo sem habilitação, porque pode se tornar perigoso. E mesmo com habilitação, não dirige tudo. Talvez um PM enferrujado consiga pilotar uma 125cc. Isso não significa que deve pegar uma moto grande e sair na chuva na rodovia.

O "código de PM", na minha boca, não é insulto. Não quer dizer que o código de um PM é necessariamente ruim. Quer dizer que é um código produzido por alguém que não domina muito bem — ou não domina mais muito bem — o código. Então é preciso aceitar limitações. E principalmente, aceitar defini-las.

Verde, laranja, vermelho

Não acredito em uma grade universal.

Cada empresa terá que definir sua política. Mas o princípio me parece bastante claro: quanto mais o produto toca dados sensíveis, operações de escrita, fluxos críticos, segurança, faturamento, permissões — mais alto tem que ser o nível de exigência.

Uma pequena ferramenta interna, pessoal, de vida curta, com impacto limitado, provavelmente consegue viver com pouco formalismo. Se quebrar, não é catástrofe. Você descarta, corrige, segue em frente.

Uma ferramenta interna compartilhada, com comportamentos avançados, escritas limitadas, dependências de negócio, já é outra coisa. Aí é preciso fazer mais perguntas.

E quando você toca produção crítica, dados sensíveis de clientes, permissões, escritas irreversíveis, ou fluxos com forte impacto no cliente ou no negócio — muda de categoria novamente.

Segurança, por exemplo, me parece inegociável. Dá para debater o nível de testes necessário para uma ferramenta descartável. Dá para debater a revisão. Dá para debater o nível de documentação. Mas a segurança não deveria depender do humor do momento.

Felizmente, os desenvolvedores já têm muito ferramental para isso: CI/CD, scanners, regras, práticas, competências, às vezes até prompts ou skills internas. O ponto não é reinventar tudo para os PMs. É conectar os PMs aumentados ao ferramental que já existe.

Não acredito em revisão sistemática

Você poderia responder: basta que tudo seja revisado por desenvolvedores.

Sou bastante cético com essa resposta.

A revisão sistemática virou um reflexo, mas merece ser discutida. Ela vem principalmente do mundo open source, por múltiplas razões: qualidade, segurança, transmissão de conhecimento, governança, confiança entre contribuidores. Mas em uma empresa, para todos os tipos de código, em todos os contextos, não estou convencido de que seja preciso revisar tudo sistematicamente.

Se um PM constrói uma ferramenta pessoal, descartável, de baixo risco, você realmente precisa mobilizar um desenvolvedor para revisar? Talvez não. Caso contrário, recria exatamente a dependência que estava tentando reduzir.

Por outro lado, a revisão pode ter um papel no início — ajudando os PMs a adquirir boas práticas. Também pode ser necessária dependendo do que está em jogo. De novo: não é sim ou não. É uma questão de risco.

Em algum momento, também é preciso aceitar a responsabilidade. Se você decide construir sua própria ferramenta, precisa aceitar comer sua própria comida. Se quebrar, é você quem vai precisar resolver. E é aí que pode doer — porque muitos PMs não sabem necessariamente depurar o que acabaram de criar com a IA.

Testes como alavanca de controle

Nessa experiência, os testes se tornaram centrais.

Não só porque "testes são importantes". Mas porque são um dos poucos meios de manter o controle sobre um código que você não escreveu inteiramente.

Claude não escreve os testes certos espontaneamente se você não pedir. Pode esquecer. Pode escrever os testes depois. Pode escrever testes que validam a implementação dele em vez da intenção de negócio. Pode dar a impressão de que o produto está seguro porque há testes, quando na verdade falta uma estratégia real de testes.

Um PM pode não conhecer TDD. Pode não conhecer a diferença entre teste unitário, de integração e end-to-end. Pode não conhecer a pirâmide de testes. Não sabe sempre quando testar um comportamento antes de codificá-lo, nem como expressar uma regra de negócio como teste.

E mesmo assim, num projeto de vibe coding, esse pode ser um dos pontos mais importantes.

No meu projeto, há mais de 500 testes. É muito para um projeto desse tamanho. Na maioria das vezes, não quebra — justamente porque Claude relança os testes com muita frequência. Quando quebra, os testes dão um ponto de apoio. Eles permitem entender onde o comportamento esperado deixou de ser respeitado.

Não estou dizendo que tudo precisa ser testado com o mesmo nível de rigor. Uma ferramenta interna muito simples e de baixo risco não precisa necessariamente de uma estratégia completa de testes. Aqui também: é uma questão de escala.

Mas quando o produto fica mais sério, os testes não são um bônus. Eles se tornam parte do volante.

As diretrizes aceleram tanto quanto protegem

Quando falo de diretrizes, não estou falando só de proteções que impedem os PMs de cometer erros.

As diretrizes também servem para ir mais rápido.

Se você deixa um PM e o Claude Code sozinhos diante de uma codebase, a IA pode facilmente não usar as APIs internas certas. Pode usar o ponto de entrada errado. Pode reconstruir algo que já existe. Pode produzir uma ferramenta que funciona mal, ou não funciona, ou perde um tempo enorme contornando a arquitetura existente.

Mas se os desenvolvedores fornecem diretrizes, o PM e a IA sabem por onde ir.

Essas diretrizes podem tomar várias formas: um catálogo das APIs internas disponíveis, documentação funcional gerada a partir do código, um mapeamento entre os conceitos de negócio e os pontos de entrada técnicos, exemplos de requisições, componentes de interface reutilizáveis, convenções, acessos delimitados, CI de segurança, arquivos Claude, prompts, skills.

Dá para imaginar, por exemplo, um ambiente onde um PM pode criar telas internas, interfaces de consulta, listas, gráficos ou cenários de negócio — apoiado em APIs documentadas e validadas. Toda a camada operacional é construída pelos devs. O PM não começa de uma página em branco. Ele compõe dentro de um framework.

Isso já é o que algumas ferramentas fazem há anos com linguagens de consulta, dashboards e plataformas internas. A IA simplesmente torna essa lógica mais poderosa.

O ponto principal: as diretrizes não apenas freiam. Elas aceleram, porque evitam que a IA tome o caminho errado.

Da pequena ferramenta interna ao product builder

Talvez haja um nível adicional.

Até agora, você pode pensar que estou falando apenas de pequenas ferramentas internas: uma tela de consulta, um export, um dashboard, uma interface de busca, uma tela temporária para ajudar o time de produto. Esse caso existe e já é interessante. Pode aliviar os devs, acelerar o dia a dia, deixar o time de produto responder a algumas de suas próprias necessidades.

Mas pode não ser o único horizonte.

Se a codebase da empresa está bem estruturada, as APIs internas estão documentadas, os conceitos de negócio são legíveis, os componentes e convenções são estáveis — então o PM talvez consiga ir além da simples ferramenta interna. Pode se tornar uma espécie de product builder.

Não um desenvolvedor autônomo em qualquer assunto. Não alguém a quem se entrega sem limites as zonas críticas do produto. Mas alguém capaz de criar um módulo, uma tela, um fluxo ou uma variação funcional apoiado na codebase existente.

A diferença importa.

No caso da pequena ferramenta interna, o PM constrói geralmente ao lado do produto. Consome APIs, agrega informações, produz uma interface útil para ele ou para o time.

No caso do product builder, ele constrói mais na extensão do produto. Usa os blocos existentes, a linguagem de negócio do código, os componentes da empresa, as diretrizes que os devs estabeleceram. Não começa de uma página em branco. Compõe com material já estruturado.

E é exatamente aí que a qualidade da codebase se torna decisiva. Uma codebase mal estruturada prende o PM e a IA no improviso. Uma codebase legível, documentada, orientada ao negócio e bem instrumentada pode, ao contrário, abrir um espaço maior de contribuição.

O vibe coding não transforma automaticamente um PM em product builder. Dar a ele o Claude Code e um repositório Git não é suficiente. Você precisa de um terreno praticável.

Se esse terreno existe, então o assunto fica muito mais interessante do que "os PMs podem construir suas próprias ferramenrinhas?". A pergunta real passa a ser: até onde uma organização pode permitir que perfis de produto construam diretamente partes do produto sem perder o controle técnico, a coerência e a segurança?

E as specs nisso tudo?

Essa experiência também me fez revisitar uma pergunta quase provocadora: ainda precisamos escrever specs?

Não estou dizendo que as specs vão desaparecer em todo lugar. Para muitos produtos, contextos regulatórios e decisões estruturais, sempre será preciso escrever, delimitar, discutir, documentar o porquê.

Mas para algumas ferramentas internas, me pergunto se a spec não está mudando de status.

No meu caso, não escrevi spec nenhuma. Comecei direto. Construí. Mostrei. As pessoas disseram: falta isso, seria bom ter isso, por tal e tal razão. Adicionei. Iterei.

Por que fazer um mockup se posso construir uma primeira versão funcional diretamente? Por que escrever uma spec descritiva se posso deixar o comportamento emergir no produto e depois gerar a documentação funcional a partir do código?

Escrevi recentemente que a questão de produto deveria partir do código-fonte. Essa experiência aponta na mesma direção, mas pelo outro lado. Se o código se torna a verdade do comportamento, então parte da documentação pode ser regenerada a partir dele. A spec não necessariamente desaparece — mas não pode mais pretender ser a verdade duradoura do produto.

Para alguns perímetros, poderíamos quase dizer: não escrevemos mais a spec antes. Construímos, validamos e depois geramos o negócio a partir do que está rodando.

Estou forçando um pouco a barra, claro. Mas não tanto assim.

O risco organizacional

Há também um risco menos técnico, mais organizacional.

Se todo mundo começa a construir suas próprias ferramentas no seu canto, as coisas podem sair rapidamente do controle. Ferramentas internas sem manutenção podem se tornar importantes. Scripts descartáveis podem acabar usados toda semana. Uma tela improvisada para um time pode virar obrigatória. Uma ferramenta sem governança pode se tornar crítica sem que ninguém tenha decidido isso.

Mas esse risco não é exclusivo do vibe coding. As empresas já lidam com isso via planilhas Excel, macros, scripts, ferramentas no-code, dashboards construídos na surdina. O vibe coding não cria o problema. Ele o acelera, porque torna a produção de ferramentas mais fácil.

Aqui também a resposta não é proibir. É definir as zonas, as permissões, as responsabilidades, os limites, as diretrizes.

O que isso muda para os desenvolvedores

Não acredito que os PMs vão substituir os desenvolvedores.

Mas acredito que algumas pequenas ferramentas internas que antes eram solicitadas aos devs poderão ser produzidas diretamente pelos times de produto, suporte, ops ou negócio — desde que bem delimitadas. E isso pode aliviar os desenvolvedores.

Quantas vezes se pede a um time de dev que saia do core do produto para fazer uma pequena ferramenta interna, um export, uma tela de consulta, um dashboard, uma interface temporária? Se parte dessas demandas pode ser absorvida em outro lugar, não é necessariamente uma má notícia.

Mas isso não faz o papel dos devs desaparecer. Ao contrário, pode deslocá-lo. Eles também se tornam quem constrói as diretrizes, as plataformas, as APIs limpas, as convenções, os ambientes seguros onde outros podem produzir sem quebrar tudo.

Isso não é menos técnico. Talvez seja até mais arquitetural.

O cansaço

Não quero vender essa experiência como algo puramente eufórico.

É cansativo.

Fazer mais de 180 commits em quatro dias, mesmo com IA, não é neutro. Você não digita todo o código, mas pilota, relê, testa, corrige, decide, refaz, monitora, explica de novo. Você avança muito rápido, mas precisa acompanhar a velocidade.

O vibe coding dá uma sensação de poder, mas não é poder gratuito. O PM se torna uma espécie de piloto, arquiteto de proximidade, testador, revisor, definidor de intenção, proteção. E se não tiver bagagem técnica suficiente, pode acabar pilotando algo que não entende de verdade.

É aí que a ilusão de competência é perigosa.

Já vimos isso com o no-code. Pessoas achavam que não precisariam mais de desenvolvedores, e descobriram três dias depois que um site sem segurança, sem proteção contra ataques de força bruta, sem circuit breaker, podia se tornar um problema rapidamente. Não era que a ferramenta fosse ruim. É que ela dava acesso ao poder sem transmitir automaticamente a cultura de segurança e arquitetura que vem com ele.

O vibe coding levanta o mesmo tipo de questão.

Estou documentando uma travessia

Não tenho uma conclusão definitiva.

E talvez essa seja a única conclusão séria possível depois de quatro dias.

Ainda estou fazendo vibe coding. Continuo aprendendo. Continuo vendo o que funciona, o que quebra, o que me escapa, o que os testes salvam, o que as diretrizes aceleram, o que minha bagagem técnica ainda me permite sentir.

Não quero construir minha opinião da tribuna. Quero construí-la pela prática.

Por ora, o que vejo é uma capacidade nova — muito poderosa — que não elimina as velhas questões do software. Às vezes as torna mais visíveis. Às vezes as acelera. Às vezes as desloca.

O vibe coding permite ir muito rápido. Mas ir rápido não é a mesma coisa que saber para onde você está indo, nem saber o que corre o risco de quebrar.

Então continuo.

Estou documentando uma travessia.

Para saber mais

A pergunta de produto deve partir do código-fonte Em 8 dias, entendi que a profissão de Product Manager vai mudar completamente A IA não deveria servir só para produzir dez vezes mais. Ela também deveria nos obrigar a entender dez vezes melhor o que produzimos Code centric