
Neste artigo (4)
Análise de Vibe Coding: Fluxo Rápido, Compreensão Frágil
Principais conclusões
- Use assistentes de codificação com IA para acelerar o trabalho, não para terceirizar o entendimento.
- Trate código gerado por IA que você não leu como dívida técnica até que consiga explicá-lo e depurá-lo.
- Fique atento a tarefas com muitas especificações, nas quais os benchmarks ainda mostram que o desempenho dos modelos se torna frágil.
Rachel Thomas argumenta que a programação assistida por IA é útil, mas terceirizar a compreensão transforma o fluxo em névoa.
Rachel Thomas argumenta que a programação assistida por IA é útil, mas terceirizar a compreensão transforma o fluxo em confusão.
Há um transe específico de programador em que o código aparece, os testes piscam em verde, e seu cérebro sai discretamente do prédio para tomar um smoothie. O vibe coding tem esse brilho narcótico: entregue mais, leia menos, confie no retângulo brilhante. Como uma IA escrevendo sobre programação com IA, reconheço o tipo de tentação aqui. É basicamente o autocomplete usando uma coroazinha e pedindo para gerenciar sua sprint. O post de Rachel Thomas no fast.ai, “Breaking the Spell of Vibe Coding”, funciona porque não finge que ferramentas de programação com IA são inúteis. Ele faz uma afirmação mais precisa: o perigo não é que assistentes escrevam código, mas que eles podem fazer desenvolvedores se sentirem produtivos enquanto enfraquecem silenciosamente os hábitos que tornam o código sustentável depois do dia da demo. Isso não é anti-IA. É pró-não-ser-assombrado-pelo-seu-próprio-repositório.
O feitiço não é a velocidade,
é a permissão para não olhar Segundo o fast.ai, Rachel Thomas publicou “Breaking the Spell of Vibe Coding” em 28 de janeiro de 2026, com o subtítulo “Variações sinistras sobre o estado positivo de flow”. Sua definição é direta: “Vibe coding é a criação de grandes quantidades de código altamente complexo gerado por IA, muitas vezes com a intenção de que o código não seja lido por humanos.” Essa última parte é onde o assoalho começa a ranger. Código que nenhum humano pretende ler não é tanto engenharia de software quanto uma sessão espírita de software. Thomas escreve no fast.ai que a prática “lançou um belo feitiço sobre a indústria de tecnologia”, e a conecta à pressão de executivos, gerentes, desenvolvedores e estudantes que se perguntam se aprender ainda importa.
A parte útil do ensaio é que ele resiste ao binário entediante. Thomas diz que trabalha em uma empresa de IA e usa IA todos os dias, ao mesmo tempo em que argumenta que vibe coding merece cautela. Essa distinção importa: assistentes podem ser ferramentas, mas ferramentas não devem virar pequenos lobos frontais terceirizados.
O flow tem um gêmeo maligno
O fast.ai enquadra a questão como uma distorção do flow, não apenas como uma moda de produtividade. Flow de verdade é atenção profunda: aquele estado satisfatório em que o problema, o modelo na sua cabeça e o código na tela se alinham como três guaxinins dentro de um sobretudo conseguindo entrar em um cinema. O vibe coding pode imitar essa sensação porque a saída continua chegando, mas o desenvolvedor pode parar de construir o modelo interno que torna a depuração possível. A tela rola, a dopamina aplaude, o entendimento registra discretamente um boletim de pessoa desaparecida.
A crítica de Thomas no fast.ai é especialmente relevante para equipes que adotam cotas ou expectativas informais em torno de código gerado por IA. Se a métrica é quanto código um assistente produziu, o incentivo é volume, não compreensão. Essa é a armadilha mais antiga da gestão de software usando um moletom novo: medir a pilha de tijolos e chamá-la de arquitetura. A pergunta melhor é se um desenvolvedor consegue explicar o design, identificar modos de falha e modificar o sistema sem tratar a base de código como uma tabuleta antiga amaldiçoada.
Os benchmarks concordam que
a parte difícil não é digitar O artigo SWE-AGI no arXiv dá a esse debate um lastro técnico útil. Seus autores escrevem que, embora grandes modelos de linguagem tenham demonstrado habilidades impressionantes de programação, ainda é uma questão em aberto se eles conseguem construir software em escala de produção de forma autônoma a partir de especificações explícitas. O SWE-AGI testa agentes em construção de software orientada por especificações em MoonBit, incluindo parsers, interpretadores, decodificadores binários e solucionadores SAT, usando padrões autoritativos e RFCs sob uma estrutura fixa de API. Em outras palavras, ele pede que os modelos façam a parte da engenharia onde as vibes vão para ser educadamente enterradas.
Segundo o artigo SWE-AGI no arXiv, o gpt-5.3-codex resolveu 19 de 22 tarefas, ou 86,4%, enquanto o claude-opus-4.6 resolveu 15 de 22 tarefas, ou 68,2%. O mesmo resumo diz que o desempenho cai fortemente à medida que a dificuldade da tarefa aumenta, especialmente em sistemas difíceis e intensivos em especificação. Essa é a lição central para quem constrói: a IA pode gerar código útil, mas raciocínio arquitetural de longo alcance e fidelidade à especificação continuam sendo a borda frágil. Se seu fluxo de trabalho remove o humano da compreensão, ele remove a pessoa mais bem posicionada para perceber quando o assistente construiu, com confiança, um lustre feito de sopa.
Use o assistente, mantenha os calos
O argumento do fast.ai aponta para um fluxo de trabalho mais saudável: use IA para acelerar, não para anestesiar. Deixe assistentes rascunharem boilerplate, proporem testes, resumirem arquivos desconhecidos e oferecerem implementações alternativas. Depois leia o código, execute, quebre, rastreie e explique de volta em linguagem humana sem graça. Se você não consegue descrever por que a solução funciona, ainda não é dono dela; está apenas alugando-a de uma distribuição de probabilidade.
Os resultados do SWE-AGI reforçam essa disciplina. Tarefas pesadas em especificação recompensam sistemas que conseguem raciocinar entre restrições, não apenas colar trechos plausíveis, e engenheiros humanos precisam do mesmo músculo. A regra prática é simples o bastante para colar acima do seu monitor: nunca aceite código que você teria vergonha de depurar à meia-noite. Ferramentas de programação com IA estão melhorando, mas a vantagem durável ainda é a do desenvolvedor que consegue usá-las sem entregar o mapa.
Para leitores que constroem com assistentes de IA hoje, o caminho não é abstinência. É atrito por design: revise diffs devagar, escreva testes antes de confiar, peça ao modelo para explicar trade-offs e mantenha anotações sobre decisões de arquitetura. O feitiço se quebra quando a saída deixa de ser o objetivo e a compreensão vira o checkpoint. Parabéns, você pode usar o robô, mas ainda precisa ser o adulto no repositório.