Vibe coding: passado, presente e futuro

Há um ano, “vibe coding” ainda parecia uma piada. Você abria uma ferramenta como Cursor, descrevia mais ou menos o que queria, aceitava o código gerado, rodava, quebrava, pedia correção e seguia nesse ciclo até algo funcionar.

O resultado era mágico o suficiente para impressionar e bagunçado o suficiente para assustar.

O curioso é que, em apenas um ano, essa prática mudou muito. O que era basicamente autocomplete com marketing virou uma discussão mais séria sobre agentes, contexto, ferramentas, testes, risco e supervisão humana.

Ou seja: quanto melhor o “vibe coding” fica, mais ele se parece com engenharia.

O passado: autocomplete com ego

No começo, IA para programação era principalmente autocomplete. O modelo sugeria linhas, funções, regexes, testes simples, pequenos blocos de código. O humano ainda era claramente o programador. A IA era só uma mão extra.

Depois vieram as ferramentas mais integradas. Claude Code virou símbolo dessa fase. A IA lia arquivos, editava múltiplos pontos do projeto e começava a entender um pouco melhor a codebase.

Mesmo assim, o fluxo ainda era muito supervisionado. O desenvolvedor apontava, a IA executava. O desenvolvedor revisava, a IA corrigia. A responsabilidade continuava com o humano.

A fase “vibe coding” nasce quando essa supervisão começa a relaxar. A pessoa descreve uma tela, aceita o código, testa visualmente, pede ajuste, aceita de novo. Para protótipos, isso é incrível. Para software que alguém vai ter que manter, é terrivel.

E aqui aparece o primeiro problema: código ficou barato demais.

O problema do código barato

Existe uma velha ideia do Bill Gates. Quando ainda era CEO da Microsoft, ele preferia colocar uma pessoa preguiçosa para resolver uma tarefa difícil, porque ela encontraria o jeito mais simples de fazer.

O livro Programming Perl também dedica um capitulo inteiro à essa tradição ao tratar a preguiça como uma virtude do programador. Não a preguiça de fazer mal feito, mas a preguiça nobre: aquela aversão saudável complexidade desnecessária e manutenção futura.

Todo programador experiente aprende isso em algum momento. Escrever código é fácil. Difícil é manter. Mais difícil ainda é deletar. E deletar código costuma ser muito mais valioso do que adicionar codigo em projetos longevos.

A IA não tem essa preguiça.

Ela não sofre mantendo o sistema seis meses depois. Não recebe ligação de madrugada. Não precisa explicar para o time por que existem três abstrações quase iguais. Não sente vergonha de criar cinco arquivos onde bastava uma função. O modelo é feliz cuspindo tokens. Pior. Ao que tudo indica, o modelo é incentivado a cuspir o máximo de tokens.

Esse é o problema central do código barato. Quando escrever fica quase de graça, a tendência é escrever demais.

E software nenhum morre por falta de código. Software morre por excesso de código ruim.

O presente: agentes e contexto

A conversa saiu de “qual modelo gera código melhor?” para “como criamos o ambiente certo para o agente trabalhar?”.

Agente bom não é apenas modelo bom. É modelo mais ferramentas, contexto, permissões, feedback e restrições.

É decidir o que o modelo deve ver, quando deve ver e em qual formato. Convenções de código, arquitetura, decisões de produto, design system, padrões de teste, regras de negócio, exemplos e restrições não podem mais ficar só na cabeça dos seniors. Antes, isso era conhecimento tácito do time. Agora precisa virar contexto explícito para o agente.

E é aqui que a piada fica boa. Para fazer vibe coding direito, você precisa escrever requisitos, documentar arquitetura, definir padrões, criar testes, automatizar validações e explicar o que “pronto” significa. Ou seja, reinventanos 50 anos de engenharia de software em um arquivo markdown.

O desenvolvedor era o harness

Harness, nesse contexto, é tudo que cerca o modelo para aumentar a chance de ele acertar e reduzir a necessidade de supervisão humana. Antes, o harness era o próprio desenvolvedor.

Era o humano que sabia rodar teste, interpretar erro, perceber uma abstração ruim, lembrar uma regra arquitetural, revisar comportamento, desconfiar de uma mudança perigosa e dizer: “isso aqui está ficando idiota”.

Agora estamos tentando transformar parte disso em infraestrutura. Testes automatizados. Linters. Formatadores. Análise estática. Mutation testing. Language servers. Fitness de arquitetura. Agentes revisores.

A ideia é simples. Se você quer dar autonomia para o agente, precisa aumentar a confiança no resultado. E confiança não vem de fé. Vem de feedback rápido. Um agente que altera código e imediatamente vê erro de compilação, teste quebrado, queda de cobertura ou violação de arquitetura pode se autocorrigir.

Essa talvez seja a mudança mais importante. O trabalho do engenheiro passa a ser menos “digitar código” e mais “construir o ambiente onde código ruim tem dificuldade de sobreviver”.

O problema ainda aberto

O problema mais difícil continua sendo comportamento.

Muita gente hoje escreve duas páginas de especificação em markdown, manda o agente implementar e recebe de volta dez mil linhas de código. Depois pede para o mesmo agente gerar os testes. A suíte fica verde. Pronto: parece engenharia.

Mas existe uma pegadinha enorme aí.

Duas páginas de markdown não especificam dez mil linhas de comportamento. Elas descrevem o fluxo principal, algumas regras óbvias, talvez meia dúzia de exceções. Só que software real não vive no fluxo principal. Vive nos detalhes. E o diabo mora nos detalhes...

O que acontece quando o usuário clica duas vezes? Quando a API demora? Quando o dado vem nulo? Quando a permissão mudou no meio da operação? Quando o timezone quebra uma data? Quando dois eventos chegam fora de ordem? Quando o estado local discorda do servidor? Quando o botão deveria estar desabilitado, mas não está? Quando o erro precisa ser reversível?

A especificação nunca cobre tudo isso. Então o agente preenche os buracos. E ele preenche com algo plausível. Não necessariamente correto.

Esse é o perigo.

O modelo não implementa apenas a especificação. Ele inventa o resto da aplicação entre uma frase e outra. E, quando também escreve os testes, muitas vezes testa justamente o comportamento que ele mesmo inventou. A suíte vai passar e ainda assim o produto estar errado.

Os testes vão provar que o código faz o que o código faz, não que ele faz o que deveria fazer.

Esse problema não é novo. Humanos também interpretam mal requisitos. Humanos também esquecem casos de borda. Humanos também escrevem testes ruins.

A diferença é a escala. Um humano transforma duas páginas de especificação em mil linhas de código ao longo de dias. Um agente transforma duzentas linhas de markdown em dez mil linhas de C em minutos.

A velocidade muda completamente a natureza do risco.

Quando soltar o agente e quando segurar

Nem toda tarefa tem o mesmo risco.

Gerar uma tela descartável para validar uma ideia não é o mesmo que mexer em autorização. Refatorar CSS não é igual a alterar uma regra fiscal. Criar um protótipo não é igual a mudar um fluxo crítico em produção.

Uma boa forma de pensar é risco = probabilidade + impacto + detectabilidade.

1. Qual a chance da IA errar?

2. Qual o estrago se ela errar?

3. Quão fácil é perceber que ela errou?

Se a chance de erro é baixa, o impacto é pequeno e a falha é fácil de detectar, dá para deixar o agente correr solto. Se a chance de erro é alta, o impacto é grande e a falha é sutil, supervisão humana próxima é indispensável.

A pergunta não é “IA escreve código bom ou ruim?”.

A pergunta é “para essa tarefa, com esse harness, nesse contexto, quanto posso confiar?”

O futuro: programadores mais preguiçosos que as máquinas

A próxima fase não será simplesmente “todo mundo programando pela vibe”. Vai ser algo mais interessante. Ferramentas, APIs, documentações e ambientes feitos para agentes.

Mas o ponto principal continua humano. Como código ficou barato, o bom engenheiro precisa ser ainda mais preguiçoso. Preguiçoso no melhor sentido possível.

Preguiçoso para não aceitar cinco camadas onde uma função resolve. Preguiçoso para não manter código desnecessário. Preguiçoso para deletar sem dó. Preguiçoso para impedir que a máquina transforme uma tarefa simples em um pequeno framework interno.

A IA é trabalhadora demais. Ela escreve feliz. Refatora feliz. Duplica feliz. Gera teste feliz. Cria arquivo feliz. Instala dependência feliz.

O engenheiro precisa ser o freio.

Não porque IA seja inútil. Pelo contrário. Ela é útil demais para ser usada sem disciplina.

Conclusão

Vibe coding começou como improviso. Um jeito rápido, meio irresponsável e meio genial de transformar linguagem natural em software funcionando.

Um ano depois, a conversa mudou. Agora falamos de agentes, contexto, skills, harness, risco, testes, feedback, supervisão e qualidade.

No fundo, a indústria está redescobrindo uma verdade antiga. Gerar código nunca foi a parte difícil da engenharia de software.

A parte difícil é controlar complexidade. E essa ficou ainda mais difícil...