A torre continua ficando mais alta

• O software feito com vibe coding, que muda de forma aleatória e inesperada, lembra a Torre de Babel, cuja construção parou quando a linguagem comum se perdeu, mas na era da IA a diferença é que a construção continua mesmo depois do colapso do entendimento
• O limite do software em grande escala não depende apenas da velocidade individual de produção de código, mas de quão bem se coordena o entendimento compartilhado sobre conceitos, limites, invariantes, propriedade e os motivos do design
• A fricção que surgia na exploração de código, perguntas, revisões e alinhamentos entre equipes era desperdício, mas também era o processo de sincronizar o entendimento mútuo e confirmar o consenso sobre o sistema
• Os agentes executam em paralelo tarefas como adicionar OAuth, cachear e reconstruir o banco de dados sem conversa, e mesmo que cada mudança seja razoável e passe nos testes, o modelo comum humano pode enfraquecer
• Na engenharia assistida por IA, os agentes interpretam e modificam cada área e mantêm a construção avançando sem falhas imediatas, então fica difícil perceber a perda da linguagem arquitetural com a qual os humanos raciocinavam juntos sobre o sistema

---

A força da Torre de Babel estava mais na coordenação do que na tecnologia

• O modo como alguns softwares de vibe coding mudam de maneiras um tanto aleatórias e inesperadas lembra The Tower of Babel de Bruegel
• A história da Torre de Babel costuma ser interpretada como uma história sobre arrogância, ambição e sobre por que as pessoas passaram a falar línguas diferentes, mas ao mesmo tempo mostra a unidade que torna o avanço tecnológico possível
• Em Gênesis 11:3–6 (KJV), as pessoas alcançam um avanço técnico ao usar tijolos cozidos em vez de pedra e betume em vez de argamassa, e tentam construir uma cidade e uma torre que alcance o céu
• O que Deus viu como problema não eram os tijolos nem o conhecimento de fabricação, mas o fato de as pessoas serem um só povo e compartilharem uma só língua, sem restrições para o que poderiam fazer
• Quando o trabalho de cada um pode ser combinado por meio de uma linguagem comum, torna-se possível construir algo que ninguém conseguiria fazer sozinho
• Quando desapareceu não o tijolo nem o método de fabricação, mas a capacidade de se entenderem, a coordenação se tornou impossível e a construção parou

A torre continua subindo mesmo depois que os agentes de IA removem a fricção

• A programação assistida por IA dá ferramentas mais poderosas aos indivíduos, e os desenvolvedores que usam agentes podem alterar um codebase em uma escala muito maior
• Porém, o limite de projetos grandes depende não apenas da velocidade com que um indivíduo produz código, mas também de quão bem as pessoas coordenam seu entendimento sobre o sistema que está sendo alterado
• A linguagem comum de um projeto de software não é o inglês nem o próprio Python, mas sim o entendimento compartilhado sobre os seguintes elementos
  • o que cada conceito significa
  • onde estão os limites do sistema
  • quais invariantes são importantes
  • quem é responsável por quê
  • por que o sistema acabou tendo sua estrutura atual
• Esse entendimento nunca fica totalmente registrado em um só lugar; ele se acumula não apenas em documentos e código, mas também em code reviews, conversas, debates e na experiência de explicar mudanças para outras pessoas
• Antes dos agentes, para alterar a camada de armazenamento de outra pessoa, muitas vezes era preciso ler o código, fazer perguntas e negociar com outra equipe que operava serviços dependentes
  • Havia desperdício nesse processo, mas ele também servia para transferir o entendimento de uma pessoa para outra e verificar se ambos ainda estavam de acordo sobre como o sistema funcionava
  • Essa fricção sincronizava o entendimento das pessoas
• Os agentes reduzem bastante essa fricção e permitem que várias pessoas peçam mudanças diferentes sem conversar entre si
  • Uma pessoa pode adicionar OAuth, outra inserir cache, e outra reconstruir o banco de dados do zero e deixar a UI rosa
  • Cada mudança pode ser razoável de forma independente, e o código pode compilar, passar nos testes e até gerar explicações quando necessário
  • Ninguém precisa conversar com os outros nem adquirir partes do modelo compartilhado que, no passado, aprenderia durante o processo de mudança
• Os agentes não sentem dor, apenas os humanos sentem, e eles permitem alterar até áreas do sistema e do codebase que antes exigiam a ajuda de outras pessoas
• Projetos de vibe coding em maior escala se tornam codebases parecidos com a Torre de Babel não porque não conseguem se comunicar, mas porque já não precisam se comunicar
  • Cada desenvolvedor tem um tradutor incansável que explica uma área específica da torre e executa a mudança local desejada
  • As mudanças continuam sendo aplicadas, mas a linguagem arquitetural que permitia aos humanos raciocinar juntos sobre o sistema pode desaparecer
• Na Torre de Babel bíblica, a perda da linguagem comum interrompeu a obra, mas na engenharia assistida por IA a construção pode continuar mesmo depois que o entendimento compartilhado entra em colapso
• Como a torre não desmorona nem ocorre uma falha imediata, fica difícil perceber o que foi perdido, e a torre continua ficando mais alta

[GN⁺]

Comentários do Hacker News

• Há muito tempo penso que a componibilidade do software deveria funcionar como no Tetris, em que as linhas precisam ser eliminadas. Agentes usados de forma imatura ou engenheiros com pouca experiência tendem a deixar essa organização de lado e apenas continuar empilhando a torre
  É possível fazer com que agentes integrem repetidamente elementos existentes em abstrações melhores, mas nem mesmo Fable ou 5.6 Sol chegam perto da capacidade humana de prever a evolução sutil do software com um senso arquitetural de alto nível. Os sistemas atuais parecem ainda não conseguir manter, de forma suficiente, modelos de mundo esparsos, de alta qualidade e escaláveis, como os humanos fazem; ainda assim, é animador que a diferença já tenha se estreitado até esse nível de sutileza

  • Não consigo provar, mas acredito fortemente que a lógica e a intuição necessárias para abstrações que levem em conta mudanças futuras não podem ser implementadas apenas como uma sequência de tokens previstos. Falta alguma coisa que não é mensurável
  • No passado, a capacidade da mente humana era o limite superior da complexidade dos programas, mas o vibe coding pode romper essa barreira. Não porque o problema seja realmente tão complexo assim, mas porque o processo de desenvolvimento não converge para abstrações concisas
    Esta é uma versão em IA do problema de escala tratado por Brooks em The Mythical Man-Month: conforme a escala aumenta, a explosão combinatória piora e surgem duplicações de código por todo o projeto, implementando na prática a mesma funcionalidade. Precisamos de uma forma de fazer a codificação com IA buscar a concisão
  • A janela de contexto humana pode ser muito menor do que a dos LLMs atuais. Essa limitação tem a vantagem de nos forçar a modularizar e abstrair para conseguir manter o trabalho na cabeça; como LLMs conseguem abarcar muito mais coisa de uma vez, eles não têm o mesmo incentivo, e isso faz agentes produzirem código espaguete desorganizado
  • No fim, é só uma questão de tempo. gpt2 e llama2 eram chocantemente ruins em comparação com os modelos atuais, e na época também eram praticamente inúteis, mas mesmo assim ficamos impressionados
    GPT3.5 e gpt4, que antes causavam entusiasmo, agora ficam muito atrás de qwen27b e gemma31b. Com tempo suficiente e o aprendizado por reforço (RL) adequado, os modelos também passarão a construir na “cabeça” excelentes modelos de sistemas de software
  • Será que isso não é resultado de os LLMs terem sido treinados com aprendizado por reforço para resolver tarefas de horizonte curto? Diferentemente de tarefas de passar em testes, esforços que duram anos, arquitetura limpa e bom senso não são coisas fáceis de maximizar em benchmarks

• O argumento central deste texto lembra a Lisp Curse e o Bipolar Lisp Programmer. A ideia era que Lisp permite que indivíduos construam com facilidade o que quiserem, o que reduz o incentivo para programadores colaborarem na construção de resultados genéricos e complexos, deixando o ecossistema de software aberto mais pobre do que em linguagens que exigem esforço considerável
  Armin também parece estar fazendo um argumento muito parecido sobre programação com IA: Lisp Curse, Bipolar Lisp Programmer

  • Programadores de Assembly também faziam o mesmo argumento. É um lugar-comum que se repete sempre que a engenharia de software passa por uma mudança de paradigma, e há quem tenha mais dificuldade do que outros para atravessar essa mudança
  • Fico em dúvida se é realmente o mesmo argumento. Hoje já há muita gente que acha que, sem precisar se reunir para colaborar, basta mobilizar uma horda de agentes para construir qualquer software complexo que se consiga imaginar
  • Na verdade, se TypeScript e Rust não tivessem dominado o mercado, este teria sido um ótimo momento para virar um condutor de LLMs para Lisp. Os agentes de hoje conseguem explicar a maior parte das coisas quase sem alucinações; se houver disposição para entender, a barreira de compreensão praticamente desaparece, e esse também é o ponto central do texto
  • Não está claro o pressuposto de que outras linguagens exigem “muito mais esforço” para chegar ao mesmo resultado. Muitos desenvolvedores que não usam Lisp dão importância à sintaxe, enquanto desenvolvedores Lisp não dão, e há muitos que, mesmo depois de experimentar a expansão do pensamento proporcionada por Lisp, continuam sem preferi-lo
    Pode haver modos diferentes de processamento cognitivo entre os dois grupos. Para que Lisp seja tão produtivo quanto outras linguagens, é preciso explorar ativamente a homoiconicidade, e o resultado costuma ser que programas Lisp sérios se tornam conjuntos de linguagens específicas de domínio (DSLs) que só uma ou duas pessoas conseguem entender

• O limite de grandes projetos de software não está em quão rápido indivíduos conseguem produzir código, mas em quão bem as pessoas que mudam o sistema conseguem alinhar uma compreensão comum sobre ele. É correto dizer que tudo ficou mais complexo depois de 30 de novembro de 2022

  • O software ficou excessivamente complexo, empilhando camada sobre camada, e estamos usando ferramentas que criam ainda mais complexidade para lidar com isso. Nos anos 1990 e no começo dos 2000, era possível criar aplicações poderosas com Visual Basic ou PHP sem educação formal, mas hoje o desenvolvimento web ou desktop é esmagadoramente complexo, e até para usar React direito há coisas demais que você precisa saber
    Introduzir IA nisso chega perto de ser o erro de colocar outra camada de complexidade em cima da complexidade existente. Na melhor das hipóteses, é um enorme desperdício de hardware; na pior, agentes criam tantos bugs quanto corrigem, aumenta a quantidade de software lixo vulnerável e, ao mesmo tempo, as pessoas deixam de aprender habilidades, enfraquecendo a capacidade da humanidade como um todo. O software não precisa ser inerentemente tão complexo assim, e para resolver isso é preciso valorizar o artesanato
  • O fato de que é preciso entender um sistema antes de mudá-lo não é novidade. Programming as Theory Building, de Peter Naur, já existia nos anos 1980 e, mesmo sem tê-lo lido, entre desenvolvedores experientes era senso comum que entender o sistema era indispensável
  • Nem tudo ficou mais complexo. Os principais bancos de dados passaram a incluir ferramentas práticas de alta disponibilidade, os microsserviços estão perdendo força, e bancos de dados estruturados estão voltando no lugar de NoSQL
    HTML e pré-renderização também voltaram com HTMx e LiveView, e o CSS se livrou das gambiarras bizarras do passado. Quando você explica a um colega mais jovem como era depurar páginas web no IE6, dá para sentir a passagem do tempo. Algumas coisas ficaram mais complexas, mas outras amadureceram o suficiente para ficar mais simples
  • Não é “depois de 30 de novembro de 2022”, e sim depois de 2022 a.C. que tudo ficou mais complexo. O aumento da complexidade é praticamente a própria história da civilização humana
    Uma pessoa de 20 mil a.C. buscava comida e evitava o frio e predadores, mas uma pessoa de 5 mil a.C. cultivava a terra, se preocupava com chuva e doenças e criava sistemas para administrar comunidade e território. Hoje, a maioria não cultiva a própria comida e administra a complexidade de uma sociedade gigantesca. Para um desenvolvedor dos anos 1970–80, até o software anterior aos LLMs já pareceria imensamente complexo, e agora quase ninguém mais programa hardware diretamente sem camadas de abstração. Até criptografia é ensinada com bibliotecas escondendo a complexidade e o conselho de “não implemente você mesmo”. Agora a pergunta central é com que rapidez os LLMs conseguem alinhar a compreensão sobre o sistema que será modificado

• A linguagem compartilhada de um projeto de software não é inglês nem Python, mas uma compreensão comum sobre o significado dos conceitos, limites, invariantes, propriedade e os motivos de o sistema ter se tornado o que é hoje. Pattern Language, de Christopher Alexander, trata exatamente desse problema, e sua recomendação de criar uma linguagem de padrões adequada a cada domínio levou aos famosos GoF Design Patterns
  Estou experimentando uma funcionalidade em que a IA mantém três linguagens de padrões para cada projeto: negócio, produto e domínio técnico, e isso está funcionando muito bem. Ao consultar isso no planejamento e organizá-lo durante implementação e revisão, até projetos codificados 100% por IA ficaram mais sistemáticos, bem alinhados entre domínios e mais fáceis de lidar

  • Fiquei curioso sobre um exemplo real. Já ouvi várias vezes a ideia de que o processo de maturação do código se parece com o crescimento natural de uma cidade, mas nunca vi resultados concretos
  • Gostaria de saber se existe algum exemplo público no GitHub

• Na Torre de Babel, a construção para quando se perde a linguagem comum, mas no desenvolvimento assistido por IA, a construção continua mesmo depois que a compreensão compartilhada desmorona. O autor não disse explicitamente se isso é bom ou ruim, mas claramente vê isso como algo ruim
  Se saber que tomate é fruta é inteligência, e não colocá-lo em salada de frutas é sabedoria, então a IA é a forma definitiva de inteligência sem sabedoria alguma, e na prática está mais perto de uma ilusão de inteligência. Se não houver ninguém que entenda o que a IA está fazendo, então é hora de parar e reconhecer que nos falta a sabedoria para controlar o que estamos criando

  • Gostei que, em vez de pregar, o autor deixou a própria imagem transmitir o significado. A história nunca se repete exatamente, mas sempre rima
  • Clichês infantis como “saber que tomate é fruta é inteligência” deveriam ser evitados a menos que o objetivo seja induzir ao erro. Só entender classificação e relações de dependência já é um problema suficientemente difícil e, no supermercado ou no critério tributário de Nix v. Hedden, tomate é legume

• Eu também penso em Babel e no quadro de Bruegel, mas de forma muito menos otimista. Pequenos agentes míopes desenvolvem suas respectivas áreas de um todo grande demais para ser compreendido, com 50 ameias de um lado, uma estranha torre saliente do outro e, sem saber por quê, um telhado de adobe sobre o pátio interno e, ao lado, uma torre com telhado de palha sobre o patamar da escada
  No nível de cada projeto individual isso faz sentido, mas sem políticas e julgamentos em vários níveis para integrar o empreendimento como um todo, isso vira um monstro gigantesco de projeto. O fato de que, para criar e manter uma linguagem comum em uma organização grande o bastante, é preciso disciplina aparece também na terminologia peculiar de empresas bem-sucedidas e forças armadas. Os “Gastown Mayors”, os “polecats” abaixo deles e até os golens ainda mais abaixo acham que falam a mesma língua, mas, quando tudo estiver concluído, descobrirão que a compreensão que acreditavam ter sido perfeitamente transmitida a partir do trono na verdade não era compartilhada

• Anakin: “Desenvolvedores que usam agentes vão aumentar dramaticamente sua capacidade de mudar a base de código”
  Padmé: “Na direção certa, né?”
  Anakin: silêncio
  Padmé: “Na direção certa, né?”

• Parece que o motivo de o vibe coding dizer para você não ler o código gerado é que, depois de ver uma vez o horror à espreita dentro de um arquivo Python, é impossível esquecer. Em sentido amplo, ele funciona como foi pedido, mas, sempre que precisa escolher um meio para atingir o objetivo, toma decisões inconsistentes
  Aplica validações estranhas só a algumas entradas de usuário, ordena repetidamente os dados em três etapas ou converte tudo para minúsculas sem motivo, e até codifica como strings os nomes das colunas da primeira linha do CSV de entrada. Metade cria funções globais que recebem dataclasses e o restante implementa tudo como classes. Quando você pensa que um dia terá de atualizar e manter isso com as próprias mãos, é difícil não corrigir, mas, ao fazer essas mudanças, boa parte do tempo economizado desaparece

• Programação baseada em agentes é muito mais próxima de trabalho de gestão do que de programação de fato. Um gestor acompanha o que os contribuintes individuais fazem apenas em alto nível e, muitas vezes, não tem tempo, capacidade cognitiva ou mesmo competência para entender todos os detalhes
  Quanto mais software for escrito por agentes, mais o papel do engenheiro de software vai se aproximar de um cargo de gestão do que de um cargo técnico

  • O mesmo vale para programadores. A maioria dos contribuintes individuais não sabe o que acontece abaixo da camada em que trabalha e não entende a implementação interna de bibliotecas, frameworks, APIs remotas ou chamadas de sistema
    Como não há tempo nem fôlego para entender tudo, eles apenas executam o trabalho necessário em sua própria camada de abstração
  • Dá a sensação de passar o dia todo revisando o código de um desenvolvedor júnior, então quase não uso, e principalmente só uso para encontrar partes que deixei passar

• No passado, grandes refatorações exigiam muito esforço, então era preciso haver uma boa justificativa. Agora, se o prompt estiver só um pouco ambíguo e você não revisar o resultado direito, o agente pode reescrever metade do código, então a alma do programa pode mudar drasticamente todos os dias. É algo excelente e, ao mesmo tempo, nem um pouco

  • A maior barreira para grandes refatorações nunca foi a carga de trabalho em si, mas sim minimizar o risco de bugs, preservar funcionalidades e garantir compatibilidade com o ecossistema existente. Se isso ficou mais fácil na era da IA, é porque deixamos de nos importar com essas coisas