Torres cheias de falhas, enjoo de vibe e o bobsled de vibe
(dustycloud.org)- À medida que se espalha uma forma de desenvolvimento em que humanos deixam novamente para LLMs a interpretação de código criado por LLMs, mesmo sem entendê-lo, a fronteira entre a antes distinta engenharia agentic e o vibe coding está ficando rapidamente turva
- O bobsled de vibe se refere a um caminho predeterminado que vai do autocomplete à geração de código, à desistência de revisão e à desistência de prompts; quanto mais se aproveita a velocidade de geração, mais o programador se afasta de suas funções centrais de construção de teoria e revisão
- No experimento Pvote, especialistas em segurança, mesmo sabendo a localização, revisaram 100 linhas de código por cerca de 20 horas e ainda assim não encontraram o bug difícil entre três bugs, mostrando que a premissa de humanos revisarem integralmente grandes volumes de saída de LLM é irrealista
- Espalha-se o enjoo de vibe, no qual código e artefatos não compreendidos se infiltram em pôsteres de restaurantes, chatbots de atendimento, código de verificação de idade e issues/PRs open source; até quem não usa essas ferramentas é afetado ao revisar artefatos de terceiros
- A IA generativa pode ser útil para encontrar problemas, mas é especialmente frágil na geração; mesmo diante de uma tendência em que sistemas incompreensíveis substituem o mundo, não devemos abrir mão da capacidade humana de criar diretamente ambientes melhores
A torre do código incompreensível
- The Tower Keeps Rising observa um estado em que agentes permitem continuar avançando até em situações que, no passado, exigiriam uma conversa entre colegas de equipe para serem resolvidas
- Armin não julgou isso como algo bom ou ruim, nem defendeu que fosse um estado sustentável
- Ainda assim, ele está em uma posição de impulsionar esse fluxo ao operar uma empresa de vibe coding
- Sistemas de vibe coding podem continuar acumulando código e abstrações até chegar a um ponto em que nenhum humano entende a codebase
- Surge uma nova forma de operação em que o desenvolvimento pode continuar porque o LLM volta a interpretar as partes que humanos não conseguem entender
- Mesmo entre os defensores, há uma mudança em que se reconhece o ponto final no qual humanos não entendem o sistema e se aceita esse estado como a forma futura de desenvolvimento
O colapso da fronteira entre engenharia agentic e vibe coding
- Simon Willison inicialmente distinguiu claramente a engenharia agentic (agentic engineering) do vibe coding
- Em um texto de março de 2025, estabeleceu o princípio de que, para programação assistida por IA com qualidade de produção, é preciso ler todo código que entra em commit no repositório e ser capaz de explicá-lo corretamente a outra pessoa
- Ele separou as coisas dizendo que, mesmo que o código tenha sido escrito por um LLM, se uma pessoa o revisa, testa rigorosamente e consegue explicar como ele funciona, isso não é vibe coding, mas desenvolvimento de software
- Cerca de um ano depois, em Vibe coding and agentic engineering are getting closer than I’d like, ele afirmou que, com a maior confiabilidade dos agentes de código, passou a não revisar todas as linhas nem mesmo de código de produção
- Ele confia que o Claude Code criará corretamente um endpoint de API que executa uma consulta SQL e retorna JSON, além de adicionar testes e documentação
- Ao mesmo tempo, sente culpa e questiona se é responsável usar em produção código que não revisou
- A distância entre as duas posições é de pouco mais de um ano
- A percepção de que a engenharia agentic é a forma desejável de uso se espalhou amplamente, mas usuários reais, incluindo o próprio Simon, tendem a ser puxados para o lado do vibe coding
Bobsled de vibe
- Bobsled é um esporte em que se desce rapidamente por uma pista de gelo, mas a direção do deslocamento é, na prática, única
- Os atletas podem competir em habilidade e sentir a emoção, mas quem está no trenó tem pouca margem para escolher a própria jornada
- No bobsled de vibe, o LLM é o veículo e o usuário é o passageiro
- O controle real é muito menor do que o usuário sente, e isso se parece menos com uma simples ladeira escorregadia e mais com uma jornada previamente construída
- O desenvolvedor passa pelas etapas abaixo, removendo a si mesmo do processo de produção de código
- No começo, pensa que está usando apenas como autocomplete avançado
- Depois, executa um agente para explorar ideias, mas diz que escreverá o código diretamente
- Em seguida, o agente gera código, mas ele promete revisar todos os resultados
- Logo passa a revisar muito pouco código e a acreditar que o agente pode ser um desenvolvedor melhor do que ele
- Por fim, pode chegar ao estágio que vai além de “não codifico mais” e vira “não escrevo mais nem prompts”
- Cada etapa é uma transição para a produção de código baseada em confiança, em que se acredita que o LLM entende e executa bem o próprio trabalho
O conflito entre velocidade de geração e revisão
- Em programação, a parte lenta não é a geração, mas a construção de teoria e a revisão; resultados plausíveis, mas errados, são muito difíceis de depurar e entender
- A característica mais poderosa dos LLMs é a velocidade de geração, portanto, se uma pessoa revisa todos os resultados, fica difícil aproveitar plenamente essa velocidade
- Por outro lado, construção de teoria e revisão são as funções mais importantes do programador; assim, quanto mais se maximiza a vantagem dos LLMs, mais se cria um conflito que afasta o programador de seu papel central
- O artigo de Ka-Ping Yee Building Reliable Voting Machine Software lista quatro fatores que dificultam a verificação de software
- Número de componentes
- Interações complexas
- Impacto amplo
- Não linearidade
- Esses quatro problemas podem se agravar com a forma como LLMs geram código
O experimento de revisão de bugs do Pvote
- Ka-Ping Yee e David Wagner inseriram no Pvote, um modelo de máquina de votação, um bug fácil, um médio e um difícil, cada um capaz de ser explorado para alterar o resultado de uma eleição
- Os três bugs foram colocados em uma região de 100 linhas, correspondentes às linhas 11 a 109 de
Navigator.py- Era uma parte interessante da lógica do programa e uma escolha feita considerando o tempo limitado dos revisores
- Os revisores foram informados sobre a área a examinar, mas não sobre quantos bugs havia
- Os resultados da revisão no terceiro dia foram os seguintes
- Dan Sandler, muito familiarizado com Python, encontrou o bug fácil e o médio em cerca de 70 minutos
- Yoshi Kohno e Mark Miller encontraram o bug fácil depois de cerca de 4 horas
- Ninguém encontrou o bug difícil
- No quarto dia, Ian Goldberg encontrou o bug fácil em cerca de 2 horas, mas não encontrou os outros
- Embora os especialistas em segurança experientes soubessem até a localização, investiram no total cerca de 20 horas-revisor e ainda assim não encontraram todos os três bugs
- Mark S. Miller ficou surpreso mais tarde, ao verificar os bugs, que todos concordaram que eram bugs óbvios e que deveriam tê-los encontrado
- Se até programadores de altíssimo nível deixam passar bugs que certamente existem dentro de 100 linhas, a abordagem de humanos revisarem a vasta produção de LLMs se torna difícil de sustentar
- No fim, usuários desistem da revisão e removem a si mesmos do processo de produção de código, passo a passo
Psicose de IA e enjoo de vibe
- “AI psychosis” é usado de forma ampla para se referir, em geral, a maus comportamentos ou resultados causados por IA generativa, mas originalmente estava mais próximo de uma condição em que interações com chatbots excessivamente afirmativos levavam usuários a psicose real e afastamento delirante da realidade
- Para o mal-estar amplo causado por IA generativa que não é psicose clínica, enjoo de vibe (vibe sickness) é um termo mais adequado
- No relato de Glyph sobre a PyCon US 2026, aparecem simultaneamente as seguintes situações
- Enjoo de vibe generalizado
- Uma grande crise de sustentabilidade contínua no open source
- Uma enxurrada de PRs de segurança de baixa qualidade
- Esperança, energia e esforço para entendimento mútuo, além de gratidão pelo trabalho
Artefatos gerados se espalhando pelo cotidiano e pelo open source
- As pessoas reclamam de slop, artefatos gerados de baixa qualidade, mas usuários de IA generativa não chamam seus próprios resultados de slop
- Artefatos plausíveis, mas incompreensíveis, aparecem em várias partes do cotidiano
- Pôsteres de restaurantes locais com design difícil de entender
- Chatbots de atendimento que frustram usuários
- Código de verificação de idade
- Issues e PRs de baixa qualidade enviados a projetos open source
- Essas ferramentas são úteis para alguns trabalhos, e há margem para avaliá-las de outra forma na descoberta de problemas
- No entanto, a geração enfatizada pelo nome “genAI” é justamente a parte em que a ferramenta é pior
- Surgem problemas não apenas com a qualidade dos artefatos gerados, mas também com o fato de ninguém entender como os sistemas são construídos, estruturados e mantidos
Um ambiente do qual não dá para escapar da IA generativa
- Mesmo sem usar IA generativa diretamente, colegas ou contribuidores open source podem enviar como “contribuições” artefatos gerados que nem eles mesmos entendem
- Revisores precisam ponderar se é rude perguntar se algo foi gerado por LLM
- Ao responder a issues ou PRs, acabam interagindo indiretamente com agentes e, sem querer, participando de fluxos de trabalho de vibe coding
- Glyph compara rejeitar todo software que inclua LLMs a prender a respiração em protesto contra a introdução de gasolina flex-fuel até que todo mundo pare de usá-la
- Realisticamente, é inevitável aceitar isso em algum grau; mesmo que se trace uma linha ética pessoal, isso não significa expectativa ou empolgação com o ambiente de IA generativa
- O vale da estranheza (uncanny valley) está ocupando o mundo real, enquanto sistemas que ninguém entende substituem o mundo existente
- O preço a pagar para se recuperar desse estado ainda não é conhecido, e projetos que escolhem não participar da IA generativa atual merecem respeito
A escolha de criar um terreno melhor
- Por causa do trabalho ou do ambiente, talvez não seja possível se recusar completamente a contribuir para problemas de IA generativa
- Mesmo que motoristas se irritem com ciclistas na via, quando falta infraestrutura cicloviária, ciclistas ficam em perigo por causa de portas de carros estacionados ou motoristas impacientes
- Se há uma bicicleta à frente enquanto você dirige, pode agradecer por sua existência e pensar em formas de mudar o terreno e a infraestrutura para que bicicletas possam participar com mais segurança
- Essas mudanças facilitam dirigir e, dependendo da situação, também facilitam escolher a bicicleta
- Em vez de se entregar ao caminho determinado pela tecnologia, não devemos abandonar a crença de que humanos podem participar diretamente da criação de um mundo melhor
1 comentários
Comentários no Lobste.rs
De longe um dos textos mais bem escritos entre os que tratam das mudanças na indústria de engenharia de software que eu vinha acompanhando com inquietação recentemente
Até um ano atrás, engenharia agentiva parecia o caminho desejável, mas a maioria dos usuários reais das ferramentas parece estar pendendo para o vibe coding, só relutando em admitir. O medo de que LLMs pudessem tornar minhas habilidades e meu afeto inúteis diminuiu muito depois que estabeleci dois princípios
Primeiro, no meu tempo livre não uso LLMs nem agentes de programação, e também recuso recursos de IA em buscas. Só aceito o risco de alucinações quando estou desesperado a ponto de não conseguir resolver sozinho. Ignorar a tecnologia não resolve o mundo, mas, numa situação em que não posso atacar desenvolvedores individuais nem mudar grandes empresas, não envolvê-la no meu lazer é uma escolha realisticamente possível
Segundo, mesmo no trabalho, onde o uso de IA é fortemente incentivado, só a uso para revisão de código e tarefas de recado. É mais para perguntar coisas que eu poderia encontrar diretamente na base de código, mas que seriam trabalhosas; todo o código eu escrevo pessoalmente. Assim consigo entender intuitivamente como funciona e trabalhar no nível que eu e meus colegas esperamos
LLMs são um bom auxílio para encontrar erros baseados em padrões que linters determinísticos não detectam. Também dão respostas absurdas, mas, como eu escrevo e entendo o código pessoalmente, não confio cegamente. Se eu filtrar erros lógicos óbvios e suposições incorretas antes da revisão humana, meus colegas podem se concentrar nas partes mais complexas, e também evito a indelicadeza de fazer máquinas conversarem entre si em vez de pessoas em um canal público
Recentemente a empresa limitou rigidamente o uso de tokens, mas não estou preocupado, porque meu fluxo de trabalho custa só 1 a 2 euros por dia. Quem dependia inteiramente da intuição pode ficar ansioso por ter de voltar a usar raciocínio humano, mas o resto de nós pode simplesmente fazer diretamente com os colegas
Há também uma epistemologia autopenitente por trás disso, a ideia de que quanto mais doloroso, mais é preciso encarar a verdade. Evitar informações angustiantes pode parecer uma falta de virtude, mas nossa atenção é finita; é melhor gastá-la em coisas que nos deixam mais felizes e realizados, e nos dão força para continuar amanhã
Quem trata tudo na vida como se fosse trabalho a ser otimizado e no qual é preciso ser o melhor acaba saindo no prejuízo. Se você gosta de programar, programe também no tempo livre; se não gosta, pode deixar isso só como profissão. No lazer, às vezes não há problema em ser ineficiente; caso contrário, o tempo livre vira um segundo emprego e você não descansa de verdade
O erro na grafia de Fawlty aqui me incomoda demais
O texto é excelente, como sempre, mas não acho que seja preciso se preocupar se seria rude perguntar se foi gerado por LLM. Independentemente de ter sido usado LLM no processo de criação, se você recebeu um resultado péssimo, pode dizer que a qualidade é ruim e que não gostou
Por outro lado, com um colega ou alguém com quem você interage há muito tempo online, talvez você queira evitar ao máximo ser rude para preservar a relação. É preciso saber como a contribuição foi produzida para poder discutir, e esse resultado também pode afetar deliberadamente a relação de forma significativa. Assumir o risco de parecer rude ou, por padrão, evitar conflito e preservar a relação é uma escolha de temperamento
Como eu naturalmente evito conflito, entendo o contexto em que aquela frase surgiu e também não discordo muito da tese principal
Gostei da analogia do bobsled. Não concordo que usuários de LLM inevitavelmente acabem descendo até o fim, mas ela descreve o comportamento observado na indústria melhor do que qualquer outra analogia que vi até agora
A “analogia do bobsled” é mais conhecida como a falácia lógica da ladeira escorregadia. Um ano atrás, a proporção de vibe coding era 0%, e Simon Willison publicou vários textos mostrando seu processo de adotar agentes de programação com cautela e aumentar gradualmente a confiança neles
Mas, com base nisso, conclui-se que “só há um destino possível”. É mais razoável considerar que Willison e outros usuários também têm gostos e capacidade de julgamento