Precisamos levar o vibe coding a sério

Pois a qualidade dos resultados tem sido melhor do que muitos gostariam de admitir.

Desde seu surgimento, o termo “vibe coding” se popularizou e inevitavelmente foi banalizado e distorcido, de modo que muitos ainda consideram essa prática como uma espécie de programação irresponsável. Confesso que essa generalização me incomoda, primeiro porque vibe coding nunca foi sinônimo de irresponsabilidade, e segundo porque a definição original já me parece ultrapassada.

Quando Andrej Karparthy cunhou o termo, no longínquo segundo dia de Fevereiro de 2025, começava a surgir uma forma de programar onde você não necessariamente precisava escrever código manualmente. Os primeiros agentes, dos quais o Cursor foi pioneiro, se tornaram capazes de navegar a codebase e realizar as mudanças, de modo que a IA deixou de funcionar como um pair programmer para se tornar um junior engineer (donde é questão de tempo até evoluir para um senior engineer, se ainda não o tiver feito).

Ora, se o trabalho se tornou supervisionar a IA, é evidente que o código passou a importar cada vez menos, sendo o nível de confiança despendido ao modelo proporcional à sua capacidade. Naturalmente, quando Karparthy escreveu pela primeira vez sobre o assunto, observar a IA trabalhando autonomamente parecia mágico, mas confiá-la a totalidade de um projeto ainda beirava a irresponsabilidade, a menos que não se importasse tanto com o resultado. Daí que originalmente partilhou-se da idéia de confinar esse inegavelmente divertido modo de construir software a projetos pessoais e áreas de baixo risco, como pequenas modificações de UI, tese que eu mesmo partilhei e escrevi sobre.

Passou-se um mês e o CEO da Anthropic, Dario Amodei, terminou por ampliar a antipatia ao termo quando previu ousadamente que em 3 a 6 meses a IA escreveria 90% do código e que, em um ano, essencialmente todo o código. Obviamente a declaração não foi bem recebida, ainda mais vindo de alguém cujo principal interesse era vender ferramentas de IA para desenvolvedores (o Claude Code havia sido lançado poucas semanas antes, e no dia anterior à declaração eu publiquei nesse espaço como ele era caro, caótico, mas divertido). Era o equivalente tech do adágio “never ask a barber if you need a haircut”.

Se a declaração de Amodei soava como clickbait ou uma tentativa desesperada de vender o próprio produto, a verdade é que ele estava certo. Nove meses se passaram e é justo dizer que a IA escreve a esmagadora maioria do código produzido hoje. De fato, não seria exagero dizer que foi a previsão mais impressionante de 2025.

Como alguém que programa todo dia, raramente escrevo código “na mão” nos dias de hoje, razão pela qual tenho preterido a IDE em favor da CLI. E no projeto que recentemente comecei no YouTube – onde pretendo criar um SaaS do zero utilizando tudo que tenho à minha disposição – posso afirmar que até o momento 100% do código foi escrito pela IA (ainda que debaixo de minha supervisão).

Mas o que aconteceu nesse meio tempo e como isso se relaciona com a necessidade de uma nova definição de vibe coding?

Em primeiro lugar, a capacidade agêntica aumentou muito, de modo que a supervisão dos modelos foi sendo cada vez menos necessária. De repente, criar software passou a ser possível com o mínimo de conhecimento técnico, até eventualmente cair para zero. Isso é natural: se o código não importa mais tanto, por que precisamos de desenvolvedores anyway?

Evidentemente essa é a parte onde as previsões apocalípticas se perdem. Sempre será necessário supervisão, se não do código, mas do projeto, da arquitetura, das tarefas, do contexto, das integrações, da segurança, e de um sem-número de condições que somente um desenvolvedor profissional conseguiria conceber. Ainda assim, isso não torna impossível criar ferramentas úteis em um escopo restrito, de forma extremamente personalizada, de forma saudável.

Considere que quanto mais específico é um problema, mais útil é um software que resolve exatamente aquele problema. Ora, se ele generaliza, menos incentivo os desenvolvedores tem de criar esses produtos. Resolve-se essa questão de duas formas diferentes: ou cria-se um software monstruoso, com inúmeras funções das quais você só precisa de um subconjunto muito pequeno, mas outra pessoa (ou empresa) precisa de outro, gerando que chamamos de bloated software, ou cria-se um software extremamente personalizado, que resolve 100% dos seus problemas e nada mais.

Mas se o software é apenas para você (ou sua empresa), então não há necessidade de escala. Se ele não vai ser exposto ao público, pois serve de controle interno ou como otimizador de processos, ele tem menos vetores de ataque e consequentemente menos preocupações com segurança. Se ele vai ser utilizado por um grupo controlado (você mesmo ou quem sabe um departamento), o treinamento é simples e a usabilidade pode ser otimizada para aquelas pessoas.

Então falamos de um projeto de escopo restrito, específico, utilizado por pessoas treinadas e que tenha pouca exposição a usuários maliciosos. Que técnica de programação parece adequada justamente para esse caso? Pois é.

A definição original de vibe coding propõe um modo de programar onde se “esquece que o código existe”. Em outras palavras, a preocupação é com o resultado, com a solução do problema. Se os modelos cometem cada vez menos erros, mais adequados eles são para esse modo de operar.

Portanto não se espantem ao verem ferramentas como o Replit ganharem cada vez mais popularidade nos próximos meses. Como consultor, tenho testemunhado cada vez mais empresas adotando ferramentas criadas em plataformas de no-code para substituir soluções insuficientes ou resolver problemas específicos. Considere que toda empresa moderna precisa de um conjunto de ferramentas para operar, seja no back-office ou na operação. E se eu posso criar um app que resolve um processo específico do meu financeiro, talvez eu não precise mais daquele SaaS, ou possa eliminar a maior parte das minhas planilhas.

Nem todo software está destinado a ser o novo Facebook, Instagram, Twitter ou YouTube. Nem todo software precisa ser distribuído globalmente, trabalhar sob escala massiva, movimentar dinheiro ou coisa que o valha. Muitas vezes todo o necessário são apenas CRUDs, notificações, automações, uma boa interface, alguns gráficos, e o mais importante, ciclos curtos de iteração.

Outro fato que as pessoas parecem esquecer é que criar MVPs de qualidade duvidosa para se tirar um projeto do papel sempre existiu. Por exemplo, era extremamente comum que se fizesse o outsource de um software para um time indiano, ou algum freelancer obscuro, de quem ninguém verificava a qualidade do código mas cuja vitrine era o portfólio. Ora, não é isso que buscamos quando criamos um app com IA? Com a diferença que a qualidade do código gerado pelos modelos de hoje é significativamente melhor do que era tipicamente contratado no passado.

Para provar essa tese, mostrei em um vídeo como criar uma simples landing page oferecendo um produto digital integrado ao Stripe, com automações e notificações via email, tudo isso utilizando apenas linguagem natural e com tempo de desenvolvimento abaixo de uma hora.

O produto oferecido é um ebook com a compilação de 22 artigos que escrevi sobre IA este ano. Todos estão disponíveis de graça no Substack, mas se você quiser tê-los de forma organizada e num formato que possa enviar facilmente para o Kindle ou ler num tablet, é possível adquirir o ebook por R$ 19,90.

Não deixe o fato desse vídeo ter sido uma parceria com o Replit ativar seu lado cínico. Meu ponto é mostrar que colocar um app no ar e monetizá-lo nunca foi tão fácil, independente da plataforma de escolha. Da mesma forma, o tempo entre a abstração de um problema e sua solução concreta, ainda que imperfeita, é cada vez menor. Portanto, se um stakeholder tem o problema na cabeça e é capaz de desenhar a solução com ferramentas de geração de código, é legítimo que isso seja utilizado no dia a dia sem que lancemos olhares de repreensão.

Se posso me arriscar a fazer uma previsão, a facilidade de se criar apps robustos para resolver problemas de escopo reduzido levará a uma eclosão de micro-SaaS, onde muitos optarão pagar pela conveniência de resolver uma pequena dor. Ao mesmo tempo, se cada vez mais pessoas forem capazes de resolver esses problemas, por que pagar por uma solução pronta se é mais fácil construir a minha? Sendo assim, o sweet spot me parece justamente o software voltado para o ambiente corporativo, aquele que resolve o problema específico de um grupo de pessoas, grande o suficiente para ser necessário a supervisão de um profissional, pequeno o suficiente para que criá-lo de forma personalizada seja aceitável.

Portanto, é preciso aceitar. Vibe coding já deixou de ser motivo de piada há tempos. Mais do que insultá-lo, numa tentativa infantil de proteger uma reserva de mercado fadada a desaparecer, é preciso compreendê-lo e manuseá-lo, de modo a aproveitar as novas oportunidades que se desenham no horizonte.