Eu venho do código.

Fui DevOps, mesmo que na época ninguém chamasse isso assim. Fui desenvolvedor. Fui arquiteto de software. Depois, aos poucos, fui me afastando dessas profissões para ir na direção da gestão de times de dev, do projeto, da agilidade, do product management.

Não parei de programar de uma hora para outra. No começo, eu ainda escrevia alguns scripts Python para automatizar uma tarefa, organizar arquivos, converter um formato, montar uma ferramentinha. Depois comecei a delegar parte desse desenvolvimento para o ChatGPT, em modo chat. Em seguida migrei aos poucos para o Claude Code. Mas, em todos os casos, continuavam sendo pedaços pequenos de código para fazer ferramentas, não desenvolvimento de produto no sentido pleno.

Até aqui, era tudo bem delimitado. Um script Python, uma função. Uma tarefa precisa. Uma espécie de delegação limpa: em vez de pedir para o LLM organizar os arquivos dentro do contexto dele, a gente fazia ele escrever um script. Ele executava uma operação, a gente conferia, e seguia.

Mas faz alguns dias que não é mais isso.

Faz quatro dias que voltei a desenvolver. Ou melhor: eu faço o Claude Code desenvolver. E dessa vez não estou falando de um script utilitário. Estou falando de um produto de verdade, criado do zero, com telas, APIs internas, comportamentos avançados, alteraçõ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 é pouco demais para fabricar uma doutrina. Talvez esse seja até o ponto mais importante: eu ainda estou dentro. Estou documentando uma travessia.

A lua de mel

A primeira coisa que salta aos olhos é a velocidade.

Em quatro dias, produzi algo que, na época em que eu desenvolvia, teria me tomado provavelmente um mês. Talvez dois. E não digo isso para ficar bonito. Comecei do zero. Fiz mais de 180 commits. Construí, quebrei, corrigi, reorganizei, testei, acrescentei comportamentos, apresentei o produto, recebi pedidos de evolução, continuei.

É inebriante.

Tem um momento em que você pensa: é inacreditável. Posso ter uma ideia, formular, pedir para o Claude implementar, testar, ajustar, recomeçar. Não estou mais escrevendo uma spec imaginando como o produto vai ficar mais tarde. Já estou dentro dele.

E isso muda muita coisa.

Com um protótipo, já dá para iterar. Você vê uma tela, um fluxo, uma intenção. E pensa: no fim das contas, o botão não está no lugar certo, esse caso de uso não está claro, falta uma informação. Mas com um produto que funciona, mesmo imperfeito, a iteração fica ainda mais direta. Você usa de verdade. Você vê de verdade. Você sente os atritos.

No meu caso, a virada aconteceu de um jeito bem natural. No começo, parecia um protótipo. Depois o protótipo começou a funcionar. Depois eu apresentei. Depois me pediram evoluções. Depois me perguntaram quando dava para usar.

Muitas vezes é aí que o perigo começa: quando o descartável vira útil.

O balde de água fria

A segunda coisa que salta aos olhos é que o Claude Code, se você deixar sozinho, é capaz de fazer absolutamente qualquer coisa.

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

O Claude tem uma tendência natural a acelerar. Ele programa. Ele acrescenta. Ele infla. Começa com um arquivo razoável, e aí esse arquivo incha, incha, incha, até virar um bloco que faz um pouco de tudo. Na hora de alterar, se perde tempo. Na hora de entender a intenção, fica mais difícil. Quando aparece um bug, ninguém sabe mais exatamente onde olhar.

Um desenvolvedor experiente pensa bem rápido na separação de responsabilidades. Ele se pergunta onde colocar a lógica de negócio, onde isolar o transporte, onde colocar a renderização, como nomear os conceitos, como evitar que tudo fique acoplado a tudo. O Claude consegue fazer isso, mas não faz de forma espontânea e constante. Precisa ser guiado.

O mesmo vale para o volume de dados.

No meu projeto, algumas APIs podem devolver algumas centenas de itens. Outras podem devolver dezenas de milhares. Não é nem de longe o mesmo mundo. Carregar 200 itens para mostrar numa página não é a mesma coisa que carregar 20 mil ou 30 mil itens e depois torcer para o navegador, o usuário e o backend continuarem de bom humor.

Mas se ninguém avisa nada, o Claude pode tranquilamente carregar tudo, mandar tudo para a página web, filtrar tudo no front e achar que o problema está resolvido. Em teste, com poucos dados, isso pode dar a impressão de funcionar. No uso real, explode. Ou pior: não quebra de verdade, 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 foram carregados 5 mil itens em silêncio, sem log, sem paginação, sem uma estratégia clara. E aí um PM não técnico pode não entender o que está acontecendo.

Guiar um desenvolvedor júnior muito rápido

A relação com o Claude Code me lembrou muito o trabalho de guiar um desenvolvedor júnior extremamente rápido.

Ele consegue produzir enormemente. E também consegue tomar liberdades absurdas. Você dá para ele o print de um componente, e ele não faz exatamente o que foi pedido. Ele interpreta. Ele simplifica. Ele vai para uma direção qualquer. Às vezes é preciso explicar de novo coisas básicas para ele: por que esse arquivo não deve conter tudo, por que essa camada não deve conhecer aquela outra camada, por que não se carrega o conjunto inteiro de dados, por que é preciso escrever os testes, por que é preciso rodar os testes de novo.

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

Isso não é grave em si. Desenvolvedores humanos também erram. Coisas feitas por desenvolvedores às vezes vão para produção e não aguentam a carga. A dívida técnica não nasceu com os PMs que fazem vibe coding.

Mas a IA acrescenta uma velocidade que muda o problema. Ela permite produzir muito rápido um monte de código mediano. Se o enquadramento não for bom, a dívida chega rápido. Muito rápido.

Do meu lado, meu passado técnico ajuda. Entendo as linhas gerais da arquitetura. Percebo quando um arquivo começa a ficar grande demais. Percebo quando as camadas se misturam. Sinto quando alguma coisa vai dar problema de volume ou de manutenção.

Mas não domino tudo. Tem partes do código que eu não saberia explicar na hora. Se eu tirar um tempo, consigo entender. Mas não posso dizer que tenho o mesmo domínio que teria se tivesse escrito cada linha.

Neste produto aqui, eu aceito isso. Em outros produtos, eu não aceitaria.

E essa diferença é essencial.

O assunto de verdade: competência multiplicada por risco

Dá para colocar a pergunta assim: será que agora todo PM pode desenvolver software com a IA?

Minha resposta espontânea seria: não.

Ou melhor: depende.

Só que esse "depende" não é uma saída pela tangente. 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. A gente abre logo de cara para um júnior o repositório mais complexo, mais crítico, com mais impacto no negócio? Não necessariamente. A gente dá para ele acesso a todos os repositórios, a todos os dados, a todas as permissões? Também não.

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

Não se trata de dizer: os PMs têm direito ou não têm direito. O que importa é definir o que eles podem fazer, em que território, com quais limites, conforme o nível de cada um e conforme o risco.

Gosto da analogia com a carteira de motorista. Você não dirige qualquer veículo sem habilitação, porque pode virar um perigo. E mesmo com a habilitação, você não dirige tudo. Talvez um PM enferrujado consiga pilotar uma 125 cilindradas. Isso não quer dizer que ele deva subir numa moto de alta cilindrada e pegar a estrada debaixo de chuva.

"Código de PM", quando eu digo isso, não é xingamento. Não estou dizendo que o código de um PM é necessariamente ruim. Estou dizendo que é 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, é preciso aceitar o trabalho de definir essas limitações.

Verde, amarelo, vermelho

Não acredito numa tabela universal.

Cada empresa vai ter que definir a própria política. Mas o princípio me parece bem claro: quanto mais o produto mexe com dados sensíveis, com escrita, com workflows críticos, com segurança, com faturamento, com permissões, mais as exigências precisam subir.

Uma ferramentinha interna, pessoal, de vida curta, com impacto limitado, provavelmente consegue viver com pouco formalismo. Se quebrar, não é grave. Joga fora, corrige, segue a vida.

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

E na hora em que se mexe com produção crítica, com dados sensíveis de cliente, com permissões, com escritas irreversíveis, com workflows de forte impacto no cliente ou no negócio, muda de categoria de novo.

A segurança, por exemplo, me parece inegociável. Dá para discutir o nível de testes necessário para uma ferramentinha descartável. Dá para discutir a revisão. Dá para discutir o nível de documentação. Mas a segurança não deveria depender do humor do dia.

Felizmente, os desenvolvedores já têm bastante ferramental para isso: integração contínua, scanners, regras, práticas, competências, às vezes até prompts ou skills internas. Então o assunto não é reinventar tudo para os PMs. É conectar os PMs aumentados ao ferramental que já existe.

Não, não acredito na revisão sistemática

Dá para responder: basta que tudo seja revisado por desenvolvedores.

Desconfio bastante dessa resposta.

A revisão sistemática virou um reflexo, mas merece ser discutida. Ela vem principalmente do mundo open source, por várias razões: qualidade, segurança, transmissão, governança, confiança entre contribuidores. Mas dentro de 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 monta uma ferramenta pessoal, descartável, de baixo risco, vale mesmo a pena mobilizar um desenvolvedor para revisar? Talvez não. Senão a gente recria exatamente a dependência que estava tentando reduzir.

Por outro lado, a revisão pode ter um papel no início, para ajudar os PMs a pegar boas práticas. E 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 eu decido montar uma ferramenta, tenho que aceitar comer da minha própria comida. Se der bug, também sou eu que me viro. E é aí que pode doer, porque muitos PMs não sabem necessariamente resolver os bugs que acabaram de criar com a IA.

Os testes como alavanca de controle

Nessa experiência, os testes viraram centrais.

Não só porque "teste é bom". Mas porque eles são um dos poucos jeitos de manter o controle sobre um código que você não escreveu inteiro.

O Claude não escreve os testes certos espontaneamente se ninguém pedir. Ele 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 tem testes, quando na verdade falta uma estratégia de teste de verdade.

Um PM não conhece necessariamente TDD. Não conhece necessariamente a diferença entre um teste unitário, um teste de integração e um teste end-to-end. Não conhece necessariamente a pirâmide de testes. Nem sempre sabe quando é preciso testar um comportamento antes de programar, nem como expressar uma regra de negócio em forma de teste.

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

No meu projeto, tem mais de 500 testes. É muito para um projeto desse tamanho. Na maior parte do tempo, nada quebra, justamente porque o Claude roda os testes com muita frequência. Quando quebra, os testes dão um ponto de apoio. Eles ajudam a entender onde o comportamento esperado deixou de ser respeitado.

Não estou dizendo que tudo precisa ser testado com o mesmo nível de exigência. Uma ferramentinha interna bem simples, de baixo risco, não precisa necessariamente de uma estratégia de teste completa. Aqui também, é uma questão de tamanho.

Mas assim que o produto fica mais sério, os testes não são um bônus. Eles viram parte do volante.

Os trilhos aceleram tanto quanto protegem

Quando falo de trilhos, não falo só de barreiras que impedem os PMs de fazer besteira.

Os trilhos servem também para ir mais rápido.

Se você deixa um PM e o Claude Code sozinhos diante do código-fonte, a IA pode muito bem 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 que não funciona, ou que perde um tempo enorme contornando a arquitetura existente.

Já se os desenvolvedores fornecem trilhos, o PM e a IA sabem para onde ir.

Esses trilhos podem ter várias formas: um catálogo das APIs internas utilizáveis, uma 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 em que um PM cria telas internas, montadores de consultas, 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 parte de uma página em branco. Ele compõe dentro de um enquadramento.

Já é o que algumas ferramentas fazem há muito tempo com linguagens de consulta, dashboards ou plataformas internas. A IA só deixa essa lógica mais potente.

O ponto importante é esse: os trilhos não só freiam. Eles aceleram, porque evitam que a IA erre o caminho.

Da ferramentinha interna ao product builder

Talvez exista mais um degrau.

Até aqui, dava para achar que estou falando só de ferramentinhas internas: uma tela de consulta, uma exportação, um dashboard, um montador de consultas, uma interface temporária para ajudar o time de produto. Esse caso existe, e já é interessante. Pode aliviar os desenvolvedores, acelerar o dia a dia, permitir que um time de produto atenda por conta própria a certas necessidades.

Mas não é necessariamente o único horizonte.

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

Não um desenvolvedor autônomo sobre qualquer assunto. Não alguém a quem se entregam sem limite 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 é importante.

No caso da ferramentinha interna, o PM costuma construir ao lado do produto. Ele consome APIs, agrega informações, produz uma interface útil para ele ou para o time dele.

No caso do product builder, ele constrói mais no prolongamento do produto. Usa os blocos existentes, a linguagem de negócio do código, os componentes da empresa, os trilhos colocados pelos desenvolvedores. Ele não parte de uma página em branco. Compõe com um material já estruturado.

E é exatamente aí que a qualidade da codebase vira decisiva. Uma codebase mal delimitada prende o PM e a IA na gambiarra. Uma codebase legível, documentada, orientada ao negócio e bem ferramentada pode, ao contrário, abrir um espaço de contribuição bem maior.

O vibe coding, portanto, não transforma automaticamente um PM em product builder. Não basta dar a ele o Claude Code e um repositório Git. É preciso um terreno praticável.

Se esse terreno existe, então o assunto fica bem mais interessante do que "será que os PMs conseguem fazer as ferramentinhas deles?". A pergunta de verdade vira: até onde uma organização pode permitir que perfis de produto construam diretamente certas partes do produto, sem perder o domínio técnico, a coerência e a segurança?

E as specs no meio disso tudo?

Essa experiência também me fez recolocar uma pergunta quase provocativa: ainda é preciso escrever specs?

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

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

No meu caso, não escrevi spec nenhuma. Eu me joguei. Construí. Mostrei. Me disseram: falta isso, precisava daquilo, por tal e tal razão. Acrescentei. Iterei.

Para que fazer um protótipo se posso construir direto uma primeira versão utilizável? Para que escrever uma spec descritiva se posso fazer o comportamento emergir dentro do produto e depois gerar a documentação funcional a partir do código?

Eu tinha escrito recentemente que a pergunta de produto deveria partir do código-fonte. Essa experiência vai no mesmo sentido, mas pelo outro lado. Se o código vira a verdade do comportamento, então parte da documentação pode ser regerada a partir dele. A spec não desaparece necessariamente, mas não pode mais se apresentar, de forma durável, como a verdade do produto.

Para certos territórios, dá quase para dizer: a gente não escreve mais a spec antes. A gente constrói, valida, e depois gera o negócio a partir do que está rodando.

Estou forçando um pouco a barra, claro. Mas nem tanto.

O risco organizacional

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

Se todo mundo começa a fabricar as ferramentinhas no próprio canto, a coisa pode sair do eixo bem rápido. Ferramentas internas sem manutenção podem virar importantes. Scripts descartáveis podem acabar usados toda semana. Uma tela feita de qualquer jeito para um time pode virar passagem obrigatória. Uma ferramenta sem governança pode virar crítica sem que ninguém tenha decidido isso.

Mas esse risco não é exclusivo do vibe coding. As empresas já conhecem isso com as planilhas Excel, as macros, os scripts, as ferramentas no-code, os dashboards montados num canto qualquer. O vibe coding não cria o problema. Ele acelera, porque deixa 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, os trilhos.

O que isso muda para os desenvolvedores

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

Por outro lado, acho que certas ferramentinhas internas que a gente pedia para os desenvolvedores vão poder ser produzidas direto pelos times de produto, suporte, ops ou negócio, desde que bem delimitadas. E isso pode aliviar os desenvolvedores.

Quantas vezes um time de dev é tirado do coração do produto para fazer uma ferramentinha interna, uma exportação, uma tela de consulta, um dashboard, uma interface temporária? Se parte desses pedidos puder ser absorvida em outro lugar, não é necessariamente má notícia.

Mas isso não faz o papel dos devs desaparecer. Ao contrário, pode deslocar esse papel. Eles passam a ser também os que constroem os trilhos, as plataformas, as APIs limpas, as convenções, os ambientes seguros dentro dos quais outras pessoas conseguem 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 um momento só de euforia.

É cansativo.

Fazer mais de 180 commits em quatro dias, mesmo com uma IA, não é neutro. Você não digita todo o código, mas conduz, relê, testa, corrige, decide, retoma, fica de olho, explica de novo. A gente avança muito rápido, mas tem que acompanhar a velocidade.

O vibe coding dá uma sensação de potência, mas não é uma potência de graça. O PM vira uma espécie de piloto, de arquiteto de proximidade, de testador, de revisor, de quem dá a intenção, de barreira de proteção. E se ele não tiver cultura técnica suficiente, pode acabar conduzindo algo que não entende de verdade.

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

A gente já viveu isso com o no-code. Tinha gente que achava que não precisava mais de desenvolvedores, e três dias depois descobria que um site sem segurança, sem proteção contra ataques de força bruta, sem circuit breaker, podia virar um problema muito rápido. Não era que a ferramenta fosse ruim. É que ela dava acesso a uma potência sem transmitir automaticamente a cultura de segurança e de arquitetura que vem junto.

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

Estou documentando uma travessia

Não tenho conclusão definitiva.

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

Continuo fazendo vibe coding. Continuo aprendendo. Continuo vendo o que funciona, o que quebra, o que me escapa, o que os testes recuperam, o que os trilhos aceleram, o que minha antiga bagagem técnica ainda me deixa sentir.

Não quero fabricar uma opinião da arquibancada. Quero chegar a ela pela prática.

Por enquanto, o que vejo é uma capacidade nova, muito potente, mas que não elimina as perguntas antigas do software. Às vezes ela as deixa mais visíveis. Ela as acelera. Ela as desloca.

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

Então eu continuo.

Estou documentando uma travessia.