- Com a recente disseminação dos agentes de IA para programação, a velocidade de desenvolvimento aumentou, mas a queda na qualidade do software e a instabilidade também se agravaram
- Os agentes acumulam os mesmos erros sem capacidade de aprendizado iterativo, e em bases de código grandes surgem queda de recall na busca e explosão de complexidade
- Entregar o sistema inteiro sem controle humano leva a código duplicado, padrões de projeto incorretos e bases de código impossíveis de manter
- No momento, os agentes devem ser usados de forma limitada em tarefas não centrais ou áreas experimentais, e os humanos devem continuar como o gate final de qualidade
- Desacelerar e recuperar a autonomia humana é essencial para o aprendizado, o crescimento e um ecossistema de software sustentável
Tudo está quebrado
- No último ano, os agentes de programação evoluíram a ponto de concluir projetos reais, mas o resultado tem sido uma queda visível na qualidade do software
- Até em grandes serviços, 98% de uptime está se tornando comum, e bugs de UI aparecem com frequência
- São mencionados casos como incidentes ligados a IA na AWS e declarações da Microsoft sobre o aumento da proporção de código gerado por IA
- Algumas empresas afirmam que 100% do código do produto é escrito por IA, mas o resultado tem baixa qualidade, com vazamentos de memória, erros de UI e instabilidade funcional
- Vários desenvolvedores relatam que, com o desenvolvimento centrado em agentes, acabaram em bases de código impossíveis de manter por falta de code review, ausência de design e excesso de funcionalidades desnecessárias
Formas de não trabalhar com agentes
- Os desenvolvedores ficaram viciados em velocidade e volume de código e acabaram abrindo mão da qualidade e do controle
- Sob o lema de “distribuído, autônomo, automatizado”, tentam uma orquestração em larga escala de agentes, mas na prática só produzem resultados instáveis
- Alguns projetos mal conseguem funcionar e, sem intervenção humana, não se mantêm
- Isso pode funcionar no nível de projeto pessoal, mas em produtos com base real de usuários, a maioria dos casos termina em fracasso
-
Acúmulo de erros e ausência de aprendizado, sem gargalo, dor adiada
- Os agentes não têm capacidade de aprendizado iterativo, então continuam cometendo os mesmos erros
- Humanos aprendem com erros, mas agentes repetem os mesmos equívocos infinitamente
- Humanos têm limite na velocidade de escrita de código, então o acúmulo de erros é mais lento; já um exército de agentes, sem gargalo, acumula erros de forma explosiva
- Como resultado, a base de código se torna não confiável, e até os testes automatizados deixam de ser confiáveis
- No fim, só o teste manual resta como meio de validação, e a equipe de desenvolvimento cai na própria armadilha
-
Mercadores que aprenderam a complexidade
- Os agentes tomam apenas decisões locais, sem enxergar o contexto do sistema como um todo
- Como consequência, código duplicado, abstrações desnecessárias e confusão estrutural se acumulam rapidamente
- Em organizações humanas, essa complexidade costuma se acumular lentamente ao longo de anos; em equipes baseadas em agentes, o mesmo nível de caos surge em poucas semanas
- Os agentes reproduzem padrões incorretos de projeto aprendidos nos dados de treinamento e, sem controle humano, criam uma complexidade irrecuperável
-
Baixo recall na busca feita por agentes
- Quando agentes tentam modificar ou refatorar código, não conseguem encontrar todo o código necessário
- Quanto maior a base de código, mais o recall da busca cai drasticamente, gerando duplicação e inconsistência
- Mesmo usando várias ferramentas, como Bash, LSP e bancos de dados vetoriais, ainda existem limites em bases de código grandes
- Isso agrava ainda mais os code smells e a complexidade desnecessária
Como trabalhar com agentes (por enquanto)
- Os agentes são atraentes por sua geração rápida de código e alta qualidade inicial, mas entregar o sistema inteiro a eles leva ao colapso
- Casos de uso adequados são tarefas não centrais de pequeno escopo, tarefas com loop de autoavaliação possível e tarefas em que falhar não é crítico
- Por exemplo, ferramentas internas, experimentos de ideias e pesquisa automatizada baseada em medição de desempenho (auto-research) são usos apropriados
- Os humanos devem permanecer obrigatoriamente como o gate final de qualidade e precisam revisar, corrigir e integrar os resultados dos agentes
- Se a função de avaliação refletir apenas métricas estreitas, os agentes podem ignorar qualidade do código, complexidade e precisão
- Desacelerar é o ponto central
- É preciso garantir tempo para pensar o que está sendo construído e por quê, e rejeitar com firmeza funcionalidades desnecessárias
- Limitar a quantidade de código que um agente pode gerar por dia a um nível que possa ser revisado
- Arquitetura, APIs e outras formas essenciais do sistema devem ser escritas diretamente por pessoas
- Fazer pair programming com agentes, garantindo atrito e oportunidade de compreensão durante a escrita do código
- Essa abordagem cria uma base de código sustentável, aumenta a satisfação dos usuários e ajuda a focar em funcionalidades centrais em vez de recursos desnecessários
- Quando a compreensão humana permanece, o problema de recall na busca dos agentes também é mitigado, e quando surgem problemas, eles podem ser corrigidos diretamente
- Mesmo que o design inicial esteja errado, mantém-se a capacidade de entender o motivo e melhorar
- No fim, o que se exige é disciplina e autonomia humana
- A qualidade e a sustentabilidade do sistema dependem da intervenção e do julgamento humanos
- “Ir devagar” é, no fim das contas, o único caminho para preservar aprendizado e crescimento e também um ecossistema de software saudável
2 comentários
Pi – harness conciso de programação no terminal
Então foi essa pessoa que criou isso.
Comentários do Hacker News
Sempre que leio esse tipo de texto mais contemplativo hoje em dia, sinto que eu também cheguei num ponto de exaustão
No fim, o que importa é “o que estamos construindo” e “essa ferramenta ajuda de fato”
Repetimos os mesmos erros nas eras de Ruby, PHP, Lotus Notes e Visual BASIC
É preciso usar as ferramentas com sabedoria e trabalhar num ritmo que permita entender a realidade complexa do que a equipe está realmente construindo
Não é sobre Agile ou Waterfall, Docker ou Podman
Hoje vivemos numa época em que um LLM apaga o banco de dados de produção e ainda desenha ilustrações para o postmortem no blog, mas não sei se isso é engenharia de verdade
Talvez desenvolvimento de software nunca tenha sido, para começo de conversa, uma disciplina de engenharia
Nos últimos 10 anos, a indústria de software esteve cheia de trabalho meta — novos frameworks, ferramentas, camadas de virtualização, estruturas organizacionais e assim por diante
Mas o “para quê” estamos construindo isso ficou pouco claro
Dá uma sensação de estrutura piramidal, como se estivéssemos criando novos empregos para sustentar a própria indústria
Ainda assim, engenharia de verdade existe — quando formulamos perguntas de forma científica e tomamos decisões com base nas respostas
Em contrapartida, trabalhar no “feeling” e apenas seguir o que o CEO diz não é engenharia
Antigamente havia muitas equipes sem nenhum controle de versão e, mesmo quando havia, era péssimo
Se você olhar o Joel Test do Joel Spolsky, a maioria das empresas daquela época responderia “não” para quase tudo
Uma ponte calcula com precisão carga, materiais, vida útil etc., mas num site é difícil prever até o tráfego
Não existe um critério quantitativo para lidar com os limites de um servidor ou framework
Talvez um dia software vire engenharia de verdade, mas ainda falta muito
Acho que colaram a palavra “engenheiro” nisso só para pagar mais
Engenheiros de verdade valorizam prova e validação, enquanto nós gostamos de novos padrões e experimentos
Por isso, a palavra “engenheiro” às vezes até incomoda
Ele criticava isso como “uma metodologia para pessoas que não sabem programar tentarem programar”, e parece que continua sendo verdade até hoje
Hoje o processo de desenvolvimento baseado em IA está se consolidando em torno das grandes empresas e a dependência de fornecedor está ficando mais forte
Se a base de código passar a ser centrada em agentes, no fim só esses agentes vão entender o código
Quando isso acontecer, os preços vão subir e pode virar uma transição de mão única, na qual será difícil até voltar a depender de desenvolvedores humanos
Os otimistas dizem que “tecnologia sempre fica mais barata e melhor”, mas também pode acabar virando um mercado como o do petróleo
Como na transição de DVD para streaming, é como se estivéssemos comprando o mesmo filme duas vezes
Modelos como o Claude Opus 4.6 já ficaram caros, em torno de 1 dólar por minuto, e engenharia de prompt não consegue mais compensar isso
No fim, os serviços de IA também estão se dividindo em camadas de baixo custo–intermediário–premium
Engenharia de prompt agora é tratada quase como um tipo de jailbreaking engenhoso
É arriscado “alugar” sua capacidade de trabalho intelectual para empresas de IA
Quando alguém diz “os custos não vão mais subir”, a conversa já acabou — eles já lançaram os dados
As grandes empresas de IA vão seguir pelo mesmo caminho
No fim, talvez fiquemos presos num mercado de viciados em tokens
A mão invisível do open source vai acabar tornando tudo gratuito
Conforme hardware e software evoluem, o custo unitário de computação cai de forma constante
Como no boom do blockchain, tecnologias sem uso real desaparecem, mas a IA tem usuários reais
Serviços como o Uber, que no começo também eram muito criticados, acabaram se firmando como negócios sustentáveis
Diferente do petróleo, computação fica mais barata e mais rápida a cada ano
O autor deste texto é a pessoa que criou o framework open source de agente de programação chamado Pi
Ele também é usado no OpenClaw
Vale a pena ver também o post dele no blog sobre o Pi
Ele é alguém que provavelmente mexeu com LLMs e agentes mais a fundo do que quase qualquer um
Quanto mais uma empresa afirma que “a IA escreve 100% do código”, maior a chance de entregar um produto bagunçado
Na época do DOS ou do MacOS, esse tipo de código derrubava o sistema inteiro, então qualidade importava mais
Hoje o sistema operacional é mais tolerante, então código malfeito sobrevive
Graças a atualizações OTA, ficou fácil lançar produtos inacabados e tentar chegar ao mercado antes dos concorrentes
Só que o que lembramos é de uma pequena minoria de produtos bem feitos
Hoje, se houver conexão de rede, até o sistema operacional é atualizado facilmente como se fosse um jogo
Agentes de programação são como “sereias sedutoras”
No começo parecem rápidos e inteligentes, mas no momento em que você pensa “computador, faça meu trabalho por mim”, tudo desmorona
Mas isso é temporário — a IA já superou humanos em áreas mensuráveis
O verdadeiro problema é HCI (interação humano–computador)
Projetar interfaces alinhadas com os valores humanos será a tarefa central daqui para frente
Estamos no pico do superaquecimento da IA
Como na época em que MongoDB e NoSQL gritavam “SQL morreu”, no fim as pessoas vão voltar a um ponto de equilíbrio mais realista
NoSQL não desapareceu, mas agora é usado só onde realmente faz sentido
Concordo com a ideia de que “o software de hoje é um caos frágil”, mas na verdade o software em si não mudou
No passado havia menos confiança, então as pessoas verificavam tudo manualmente, e essa lentidão acabava reduzindo problemas
O núcleo de DevOps é andar rápido com base em confiança, mas mantendo a qualidade
Como no código Andon da Toyota, se surgir um problema, é preciso parar imediatamente e resolver a causa raiz
Isso não é um problema técnico, e sim um problema de cultura e processo
É necessário encontrar cedo interfaces erradas ou desalinhamentos com o contexto de negócio
Como todo mundo usa GitHub, AWS e Cloudflare, se um deles para, o mundo inteiro para junto
Se um bug é encontrado pouco antes do tape-out, a resposta não é culpar o mensageiro, e sim avaliar com cuidado
O resultado da programação não é só o código, mas também o próprio programador
Os modelos mentais e a memória muscular acumulados ao escrever código são o verdadeiro patrimônio
Se a IA substituir esse processo, no fim o crescimento do programador desaparece
O “Preventing the Collapse of Civilization”, de Jonathan Blow, trata do mesmo problema
Veja “Programming as Theory Building”
Ontem conversei com um colega sobre algo parecido
Vi uma demonstração em que a IA lia logs, corrigia bugs e até escrevia o postmortem,
mas o problema é que os humanos não têm tempo de internalizar esse processo
Como no ditado de que “um carro só consegue andar rápido porque tem freios”,
é preciso manter um certo atrito de aprendizado numa velocidade que os humanos consigam acompanhar
Se um agente conseguisse reconhecer isso sozinho e se recuperar, haveria mesmo necessidade de o humano aprender?
Claro, ele poderia deixar passar a causa raiz, mas se o sistema de autorrecuperação fosse robusto o bastante, isso ainda seria um problema?
Do ponto de vista de design de produto, sinto um problema parecido
A velocidade de desenvolvimento está tão alta que não há tempo para usar diretamente e validar
Se você continua empilhando funcionalidades sobre um design errado, fica difícil voltar atrás
No fim, o importante não é velocidade, mas o equilíbrio entre qualidade e aprendizado
Esse processo inevitavelmente precisa de tempo