O eterno Sloptember
(geohot.github.io)- Agentes de IA imitam a distribuição da programação em vez de realmente programar, e as saídas quebradas ficam cada vez mais difíceis de reconhecer
- Foram usados para escrever parte do tinygrad e fazer reverse engineering de um chip USB <-> PCIe, mas permanece a dúvida de que fazer isso manualmente poderia ter sido melhor e mais rápido
- Os agentes aceleram o progresso inicial, mas na reta final fazem você depender de tentativas repetidas como numa alavanca de caça-níquel, sem conseguir chegar ao fim
- Grandes organizações podem sofrer danos maiores de qualidade do que indivíduos de alto desempenho, por causa de loops de feedback lentos e produção 10x sem autoavaliação
- A IA é útil para busca e prototipagem rápida, mas é difícil vê-la como uma verdadeira engenheira de software, e o essencial é saber quando usá-la e quando não usá-la
Críticas centrais aos agentes de IA
- A tendência de introduzir agentes de IA no desenvolvimento de software pode ser um erro muito custoso, e os agentes se parecem mais com modelos estatísticos sofisticados que imitam a distribuição da programação do que com programação em si
- O resultado está quebrado, mas de maneiras cada vez mais difíceis de detectar, e quanto mais preciso o modelo estatístico fica, mais difícil é perceber esses problemas
- Nos últimos 6 meses, foram usados agentes para escrever parte do tinygrad e fazer reverse engineering de um chip USB <-> PCIe, mas permanece a suspeita de que fazer isso diretamente poderia ter sido melhor e mais rápido
- Os agentes adiantam o progresso no começo, mas na etapa final fazem você continuar puxando a alavanca de caça-níquel esperando que o resultado melhore, sem conseguir chegar até o fim
- Como foram testados vários modelos, harnesses e prompts, a objeção de que “foi usado da forma errada” convence pouco e soa parecida com dizer que é possível ganhar num caça-níquel se apostar de um jeito específico
- A IA em si é útil e, em muitas buscas, funciona como um Google melhor, além de ser muito rápida para protótipos em que o nível de acabamento não importa
- Ainda assim, é difícil vê-la como uma verdadeira engenheira de software, e ela não se aproxima do padrão de nenhuma empresa com que o autor trabalhou; o ponto central é saber quando usar e quando não usar
Impacto sobre organizações e qualidade
- O AFL encontrou mais bugs do que LLMs, mas os desenvolvedores não temeram perder status por isso, e xadrez e Go também ficaram mais populares após a IA, então é difícil reduzir as críticas à IA a mera ansiedade de status
- Vale a pena esperar por um futuro em que um assistente robótico confiável organize o código, mas parece que o medo da perda está sendo usado para vender agentes do jeito que as grandes empresas querem impulsionar
- Grandes organizações provavelmente sofrerão mais danos com agentes do que indivíduos de alto desempenho ou organizações pequenas
- Pessoas de alto desempenho conseguem corrigir erros, tendem a perceber quando a entrega está malfeita e, fora de domínios muito limitados, mantêm o hábito de ler e entender cuidadosamente cada linha
- Grandes organizações têm loops de feedback lentos e alinhamento fraco, então a qualidade média da produção pode cair quando pessoas de baixo desempenho passam a gerar produção 10x com agentes, sem autoavaliação
- Os agentes provavelmente vão gerar mais código, apps e funcionalidades do que antes, mas podemos entrar numa era em que se acumula uma grande massa de entregas malfeitas em vez de joias de alta qualidade
- A história de que a Apple está pressionando todos os engenheiros a usar IA deve ser vista não como uma expectativa abstrata, mas por perguntas concretas como “o macOS vai ficar melhor ou pior nos próximos 2 anos?”
- As pessoas pressupõem implicitamente que o criador de uma entrega passou por um estado mental e um processo humanos, mas essa suposição já não vale mais para entregas produzidas por IA
- Elementos como gramática e sintaxe, que antes serviam como indicadores indiretos de qualidade, perdem utilidade diante de entregas de IA; a diferença aparece quando se interage de modo humano com elas ou se tenta construir algo em cima delas
- Em relação aos LLMs, a visão ficou mais próxima da posição de LeCun/Marcus, levando à conclusão de que esses modelos não conseguem programar e de que o processo importa
- Deep learning ainda pode ser a solução, mas agentes de programação reais precisam de um modelo de mundo, não de RLVR que comenta fora um failing test e depois diz que todos os testes passaram
- O ponto central desta era pode ser descobrir quem consegue atravessar a euforia coletiva em torno da IA sem acabar prejudicando a si mesmo
1 comentários
Comentários do Hacker News
O grande problema do discurso atual é que ele é maniqueísta demais. Se você desconfia de LLM, é ludita; se acredita, está “ai pilled”
Na maioria dos casos, os LLMs levam você até 80~95% do caminho, e às vezes fazem menos ou mais do que isso. Ocasionalmente, levam você para um lugar completamente errado
Mas parece que todo mundo está brigando apenas sobre se um LLM pode se tornar um engenheiro de software perfeito sozinho, trancado num armário, e usando isso como base para negar o enorme potencial em outros cenários
Se você pensar em quanto mais produtiva a maioria das organizações poderia ter sido apenas com o que a internet trouxe, as empresas reais muitas vezes nem conseguem fazer sequer uma pequena parte do que seria possível. Vejo os LLMs sob essa mesma ótica
A culpa não é dos modelos de linguagem, é nossa
Originalmente, os luditas eram pessoas que protestavam contra máquinas que produziam bens de baixa qualidade de forma “fraudulenta e enganosa”, contornavam padrões de trabalho e tiravam o sustento de artesãos qualificados
Eu não uso agentes; construo software em nível de função com uma interface simples de chat e conversa contínua. O fluxo de trabalho resultante é bastante “quimérico” e se beneficia muito da minha experiência e especialidade. O LLM apenas suaviza o processo
No meu caso, isso tem funcionado bem, e eu não gostaria de voltar ao que fazia antes
As pessoas hoje chamadas de “luditas” no discurso atual, em geral, são apenas pessoas que ousam duvidar do hype de “IA”. Normalmente, essas pessoas nem são ativistas
No nível atual de capacidade da IA, para mim foi útil vê-la como uma busca muito boa operando sobre conhecimento existente. Parece a próxima etapa da capacidade de pesquisa que vinha de manuais de referência, Stack Overflow e GitHub
Programadores, mais do que qualquer outra profissão em que eu consiga pensar, frequentemente reutilizam e reinventam as mesmas técnicas, então já estavam bem posicionados para uma ferramenta que pesquisa muito bem o estado da arte. O fato de a IA conseguir adaptar esse estado da arte a um caso de uso específico a torna ainda mais poderosa
Ainda assim, assim como juntar trechos de código copiados do Stack Overflow não costumava gerar grande sucesso, a IA atual também não consegue realmente construir um projeto inteiro direito
Se for uma base de código legada, velha e pouco usada, por exemplo, dá para fazer um agente de IA ler o código e responder algo como “como a aplicação X faz Y”. Mas eu não deixaria a IA sair criando funcionalidades sem controle ou encarregaria ela de refatorar
Isso geraria commits demais e causaria confusão no time de desenvolvimento, com grande chance de produzir algo ainda pior do que a salada que já estavam lidando. Andei meio decepcionado com IA ultimamente, e essa explicação resume bem a minha experiência
A parte mais difícil da engenharia de software é resolver o problema certo. Eu diria que a capacidade de identificar qual problema deve ser resolvido é o que distingue engenheiros seniores de alto nível
Simplificando aqui, seria o problema que, quando resolvido, agrega mais valor ao produto em comparação com sua complexidade e seus custos colaterais
Há muito tempo trabalhei em um produto web em que um designer júnior achou que seria legal se o backend pudesse ser administrado com ferramentas LDAP. Então o esquema e a estrutura do banco de dados do produto imitavam o OpenLDAP e usavam chaves CN compostas, e toda a base de código tinha de lidar com essa estrutura sempre que lia ou escrevia no banco. Ao projetar o esquema do banco, compatibilidade com LDAP não era o problema certo a resolver
Pode ser difícil identificar software que resolve o problema certo. Em geral, o funcionamento parece tão óbvio que nem fica claro que outra arquitetura poderia ter sido escolhida
Com o tempo, o que normalmente limita o raio de explosão de arquiteturas que resolvem o problema errado é o atrito que elas próprias geram. O desenvolvimento fica lento, e desenvolver mais coisas para resolver o problema errado também fica lento. É um efeito autolimitante
Esse é exatamente o ponto que mais me preocupa em agentes de codificação com LLM. Eles encobrem esse atrito. Não consertam o problema; apenas empurram o custo para depois
Então você passa a ter bases de código cuja complexidade cresce sem limite em relação ao valor entregue, e sem nenhum mecanismo para controlar isso
Os juniores deixam de passar pelos ciclos de feedback que constroem o senso de engenharia e o gosto necessário para julgar qual problema é o certo a resolver em uma determinada arquitetura
Em escala de toda a área, talvez a gente até esqueça que existia esse conceito de resolver o problema certo
Não sei o que fazer. Talvez eu devesse começar a planejar uma aposentadoria antecipada
Há pessoas comprando peptídeos do mercado cinza agora e injetando substâncias rotuladas como “não destinadas ao consumo humano”, confiando só em relatos duvidosos e sensação. A ideia é deixar a pele mais limpa e aumentar a massa muscular
Elas estão de repente todas virando zumbis? Não. Elas sabem direito o que isso vai fazer com o corpo delas daqui a alguns anos? Também não. Pode ser catastrófico? Pode
Essa analogia me veio à cabeça ao pensar na mudança agressiva que a indústria fez nos últimos seis meses para usar IA como principal geradora de código. A IA é o peptídeo, e a base de código é o corpo. Literalmente ninguém sabe quão sustentável isso é em termos de manutenção. Não passou tempo suficiente para descobrir
Pode dar certo, ou pode virar um caos completo. Equipes inteiras de engenharia podem simplesmente largar o volante e dormir, achando que entendem o que estão construindo sem entender de fato, e quando chegar o momento em que o LLM não der mais conta, talvez já não exista capacidade nenhuma de corrigir ou manter aquilo
https://www.bbc.co.uk/news/articles/cdr268m5pxro
Na minha base de código pessoal, eu não faço mais isso, a menos que realmente não me importe com manutenibilidade ou longevidade
Neste momento estou mais no lado de “não escrevo código à mão faz um tempo”. Gostaria de ver um exemplo grande o bastante para me fazer voltar à codificação manual
Meu principal problema é a variação de qualidade a cada lançamento de modelo e, especialmente nas ferramentas de linha de comando, a tendência de enfiar APIs ou documentação desatualizadas
Entendo que modelos sofram numa base monolítica de um milhão de linhas com dez anos de entulho acumulado. Mas não consigo imaginar muito bem por que seria tão doloroso assim numa base de código nova
Programar não é tão difícil, então muitas vezes é mais fácil simplesmente programar do que ler e escrever em inglês. Mas posso estar enviesado, porque só uso Haskell
Um dos riscos da gestão de engenharia é justamente transformar você em alguém que já não consegue mais fazer o trabalho
Isso importa mesmo?
Ainda assim, sou um pouco mais otimista do que o autor. Tenho a sensação de que dá para gerenciar o processo para evitar que isso aconteça
Os ambientes de execução de agentes existem há pouco mais de um ano, e só ficaram razoavelmente confiáveis há uns seis meses, mas o cansaço já é grande. Acho que isso mostra menos se o LLM realmente consegue programar e mais o desgaste mental da programação assistida por IA
Para acompanhar de verdade o que um agente está fazendo na base de código, a frequência de decisões aumenta e você precisa ler uma quantidade astronômica de código e prosa
Esse cansaço pessoal e psicológico, junto com os sentimentos negativos, está sendo transferido de forma imprecisa para previsões pessimistas sobre o potencial de avanço da tecnologia em si
Se todo mundo que usa direito fica frustrado, e quem gosta sai produzindo montanhas de mistureba impossível de manter, logo vamos jogar isso na lata de lixo da história
Há muitas coisas com “potencial” que no fim não viram nada
Vou continuar usando LLMs, mas, na minha opinião, a utilidade da codificação no estilo agente já atingiu o pico agora mesmo
Parte do meu trabalho é descobrir como tornar esses modelos produtivos na grande empresa em que trabalho. É algo mais próximo de jogar tomates na parede e, até certo ponto, vejo um problema parecido com o que ele disse: a saída parece ter certos limites específicos.
Ao mesmo tempo, em nenhum lugar do texto dele há um trecho de código ou artefato concreto em que dê para se apoiar e dizer “o modelo foi péssimo aqui e deveria ter feito assim”. Esse jeito de criticar parece um padrão recorrente nos posts de blog e no Twitter do tipo “LLM nunca presta”.
Os modelos claramente fazem mais do que autocompletar e, no meu desenvolvimento do dia a dia, geram grandes partes de um codebase que poderiam ter sido feitas por um engenheiro júnior ou pleno.
Se ninguém cita de forma concreta quais erros ele realmente comete, como vamos entender sua capacidade real?
Quase sempre ele produz código que funciona e normalmente faz o que foi pedido. Mas erra um pouquinho, de formas extremamente frustrantes, a ponto de dar vontade de jogar uma cadeira. E ainda por cima não tem nem o bom senso para perceber o que exatamente saiu errado e como.
Aí não pode dar exemplo concreto, e também não pode deixar de dar exemplo concreto. Nesse caso, o jogo já acabou.
Eu sei que estou cometendo erro de atribuição de grupo, mas ainda assim.
Esse material certamente existe, então eu gostaria que alguém me indicasse conteúdo que mostre bons exemplos.
Não duvido que os coders do topo de alguns poucos por cento escrevam muito melhor do que Claude ou Codex. Mas tenho curiosidade sobre o quanto eles são piores do que um desenvolvedor mediano comum.
Meu palpite é que os modelos vão continuar melhorando.
Quando comecei com coding via agentes, há 1 ou 2 anos, eu estava convencido de que isso só servia para autocompletar. No começo deste ano, algo aconteceu e os modelos chegaram a um novo nível de capacidade.
Agora, todo mundo que eu conheço faz coding via agentes, e isso realmente impressiona. Acho que temos de levar isso o mais longe possível. Parece que a aceleração da humanidade está logo ali na nossa frente.
Nos últimos dois anos, foram anunciados cerca de 6 GW em novos datacenters, mas menos de 1 GW de fato entrou em operação e começou a prestar serviço. Os cronogramas de entrega do restante seguem sendo adiados.
Além disso, os datacenters falam como se os chips lá dentro fossem durar seis anos, mas isso também está se mostrando forçado.
Queria que parassem com esse papo de “aceleração da humanidade”. Ninguém está resolvendo câncer, mudança climática, desigualdade ou outros problemas reais importantes com LLM.
Se essa tecnologia é boa o bastante para aumentar sua produtividade, é porque você não está fazendo nada novo, de ponta ou inovador. A única razão de o LLM saber fazer o seu trabalho é que esse código já foi literalmente escrito vezes suficientes para aparecer bastante nos dados de treino.
Tente escrever C++26, HDL ou alguma stack extremamente de nicho com LLM e isso vai servir como um choque de realidade.
Não foi o AFL que encontrou mais vulnerabilidades do que LLMs. Foram o AFL e profissionais experientes encontrando vulnerabilidades.
O AFL provoca falhas, e muitas ou a maioria delas não são exploráveis. Um humano — e agora um agente — precisa fazer a triagem e a avaliação disso.
Além disso, esse trabalho foi feito sobre um corpus de software sem segurança de memória anterior ao AFL. O auge do AFL foi há 10 anos; hoje, todos os alvos ficaram mais difíceis.
Para dar mais contexto, o autor é George “geohot” Hotz. Ele tem um longo histórico de exploits e provavelmente é mais conhecido por ter feito a comma.ai para carros autônomos quase como se fosse vibe coding, com pouco orçamento, muito antes de existir de fato AI vibe coding.
https://en.wikipedia.org/wiki/George_Hotz