Desacelere, essa é a resposta para a era do agente

Título Original: Reflexões sobre a Importância de Desacelerar
Autor Original: Mario Zechner
Tradução: Peggy, BlockBeats

Nota do Editor: À medida que a IA generativa avança na engenharia de software, o sentimento da indústria está mudando de "admiração pela capacidade" para "ansiedade pela eficiência." Não escrever rápido o suficiente, não usar o suficiente, não automatizar de forma abrangente — tudo isso parece criar uma pressão de obsolescência. No entanto, à medida que os agentes de codificação realmente entram no ambiente de produção, algumas questões mais práticas começam a surgir: os erros são amplificados, a complexidade sai do controle, os sistemas se tornam cada vez mais opacos e os ganhos de eficiência não se traduzem proporcionalmente em melhorias de qualidade.

Com base na prática de linha de frente, este artigo oferece uma reflexão sóbria sobre a atual tendência de "codificação agente." O autor aponta que os agentes não aprendem com os erros como os humanos; na ausência de gargalos e mecanismos de feedback, pequenos problemas são rapidamente amplificados. Dentro de bases de código complexas, sua perspectiva local e capacidade de memória limitada agravam ainda mais a desordem da estrutura do sistema. A essência desses problemas não reside na tecnologia em si, mas na entrega prematura do julgamento e controle pelos humanos sob a pressão da ansiedade.

Portanto, em vez de cair na ansiedade de "se devemos abraçar totalmente a IA," é melhor recalibrar a relação entre humanos e ferramentas: deixar os agentes assumirem tarefas locais e controláveis, enquanto mantemos o design do sistema, a garantia de qualidade e as decisões-chave firmemente em nossas mãos. Nesse processo, "desacelerar" torna-se uma capacidade; significa que você ainda entende o sistema, pode fazer compensações e manter um senso de controle sobre seu trabalho.

Em uma era de ferramentas em evolução, o que pode ser verdadeiramente escasso pode não ser capacidades gerativas mais rápidas, mas o julgamento da complexidade e a firmeza para fazer escolhas entre eficiência e qualidade.

Abaixo está o texto original:

A expressão no rosto da tartaruga é como eu olho para esta indústria

Cerca de um ano atrás, um verdadeiro agente de codificação que poderia ajudá-lo a "completar um projeto inteiro do início ao fim" começou a surgir. Havia ferramentas anteriores como Aider e o Cursor inicial, mas elas eram mais como assistentes do que "agentes". A nova geração de ferramentas é muito atraente, e muitas pessoas têm passado muito do seu tempo livre realizando todos os projetos que sempre quiseram fazer, mas nunca tiveram tempo.

Não acho que isso seja um problema em si. É inerentemente alegre fazer algo no seu tempo livre, e na maioria das vezes, você realmente não precisa se preocupar com a qualidade do código e a manutenibilidade. Isso também lhe dá um caminho para aprender uma nova pilha de tecnologia.

Durante a temporada de festas de Natal, a Anthropic e a OpenAI também lançaram alguns "créditos gratuitos", atraindo as pessoas como uma máquina caça-níqueis. Para muitos, essa foi a primeira verdadeira experiência da mágica da "codificação com Agente." A participação está crescendo.

Hoje em dia, codificar com um Agente também está começando a fazer parte de bases de código em produção. Doze meses se passaram, e estamos começando a ver as consequências desse "progresso." Aqui estão meus pensamentos atuais.

Tudo Está Desmoronando

Embora a maior parte disso seja anedótica, o software atual realmente dá uma sensação de estar "prestes a quebrar" a qualquer momento. 98% de tempo de atividade está se tornando a norma, mesmo para grandes serviços. A interface do usuário está cheia de todo tipo de bugs absurdos que deveriam ter sido detectados à primeira vista pela equipe de QA.

Admito que essa situação existia antes do Agente aparecer. Mas agora, o problema está claramente acelerando.

Não podemos ver o verdadeiro estado dentro das empresas, mas há vazamentos ocasionais de informações, como a suposta "queda da AWS induzida por IA." A Amazon Web Services prontamente "corrigiu" a declaração, mas logo lançou um plano de reorganização interna de 90 dias.

Satya Nadella (CEO da Microsoft) também tem enfatizado recentemente que cada vez mais do código na empresa é escrito por IA. Embora não haja evidências diretas, há de fato uma sensação: a qualidade do Windows está em declínio. Até mesmo em alguns blogs divulgados pela própria Microsoft, parece que eles tacitamente reconheceram isso.

Empresas que afirmam que "100% do produto é gerado por IA" quase sempre acabam produzindo os piores produtos que você pode imaginar. Sem querer apontar dedos, mas coisas como vazamentos de memória por gigabyte, caos na interface, recursos ausentes, travamentos frequentes... nada disso é o que eles consideravam como um "endosse de qualidade," muito menos uma demonstração positiva de "deixe o Agente fazer tudo por você."

Privadamente, você ouvirá cada vez mais, tanto de grandes empresas quanto de pequenas equipes, dizendo uma coisa: elas foram empurradas para um canto pelo "código do Agente." Sem revisões de código, entregando decisões de design ao Agente e, em seguida, acumulando um monte de recursos desnecessários—obviamente, isso não vai acabar bem.

Por que não devemos usar o Agente dessa maneira

Quase abandonamos toda a disciplina de engenharia e julgamento subjetivo, caindo em uma maneira de trabalhar "viciada": há apenas um objetivo—gerar o máximo de código no menor tempo possível, sem absolutamente nenhuma consideração pelas consequências.

Você está construindo uma camada de andaime para comandar um exército de Agentes automatizados. Você instalou o Beads, mas está completamente alheio ao fato de que é essencialmente um "malware" desinstalável. Você está fazendo isso apenas porque fontes online dizem que "todo mundo está fazendo isso." Se você não fizer isso dessa maneira, você está "ngmi" (não vai conseguir).

Você está continuamente se consumindo em um "loop estilo boneca russa."

Veja—Anthropic criou um compilador C usando um grupo de Agentes, embora ainda tenha problemas agora, o modelo de próxima geração certamente será capaz de consertá-lo, certo?

Agora veja—Cursor construiu um navegador usando um grande grupo de Agentes, embora seja basicamente inutilizável agora e ainda precise de intervenção manual ocasional, o modelo de próxima geração certamente será capaz de lidar com isso, certo?

"Distribuído," "Dividir e Conquistar," "Sistemas Autônomos," "Fábrica de Luz Negra," "Seis Meses para Resolver um Problema de Software," "SaaS está morto, minha avó acabou de montar uma loja Shopify usando Claw"...

Essas narrativas soam empolgantes.

Claro, essa abordagem pode realmente "ainda funcionar" para o seu projeto paralelo quase não utilizado (incluindo por você mesmo). Talvez exista realmente um gênio que possa usar esse método para criar um produto de software não lixo, verdadeiramente utilizável. Se você é essa pessoa, então eu realmente admiro você.

No entanto, pelo menos nos meus círculos de desenvolvedores, ainda não vi um caso verdadeiramente eficaz desse método. Claro, talvez todos nós sejamos apenas inexperientes demais.

A acumulação de erros em nenhum aprendizado, sem gargalos e explosões atrasadas

O problema com os Agentes é: eles cometem erros. Isso não é um grande problema em si; os humanos também cometem erros. Pode ser apenas alguns erros de correção, fáceis de identificar e corrigir, e adicionar um teste de regressão torna tudo ainda mais estável. Pode também haver alguns cheiros de código que os linters não conseguem detectar: um método não utilizado aqui, um tipo irrazoável ali, algum código duplicado, e assim por diante. Individualmente, esses não são um grande problema, e os desenvolvedores humanos também cometem esse tipo de pequenos erros.

Mas "máquinas" não são humanos. Após repetir o mesmo erro várias vezes, os humanos geralmente aprendem a não repeti-lo—ou são repreendidos por alguém, ou mudam em um genuíno processo de aprendizado.

Os Agentes não têm essa capacidade de aprendizado, pelo menos não por padrão. Eles irão repetir o mesmo erro repetidamente, e podem até "criar" combinações maravilhosas de diferentes erros com base nos dados de treinamento.

Claro, você pode tentar "treiná-los": escrever regras em AGENTS.md para que eles não repitam tais erros; projetar um sistema de memória complexo para que eles consultem erros históricos e melhores práticas. Isso é de fato eficaz em certos tipos de problemas. Mas a premissa é—você deve primeiro observar que ele cometeu esse erro.

A chave da diferença é esta: Os humanos são o gargalo; os Agentes não são.

Um humano não consegue vomitar vinte mil linhas de código em poucas horas. Mesmo com uma taxa de erro não tão baixa, apenas um número finito de erros pode ser introduzido em um dia, com sua acumulação sendo lenta. Normalmente, quando a "dor dos erros" atinge um certo nível, os humanos (por aversão instintiva à dor) param para corrigir as coisas. Ou eles são substituídos, e outra pessoa os corrige. De qualquer forma, o problema é resolvido.

No entanto, quando você implanta um verdadeiro exército de Agentes bem orquestrados, não há gargalo e nenhuma "sensação de dor." Esses pequenos erros inicialmente inconsequentes se acumulam a uma taxa insustentável. Você foi retirado do circuito, sem saber que esses glitches aparentemente inofensivos se tornaram um monstro. Quando você realmente sente a dor, geralmente é tarde demais.

É somente quando um dia você tenta adicionar um novo recurso e descobre que a arquitetura atual do sistema (essencialmente uma pilha de erros) não pode acomodar a mudança, ou os usuários começam a reclamar furiosamente porque a última versão tem problemas, ou pior, dados perdidos.

É nesse ponto que você percebe: Você não pode mais confiar nesta base de código.

Pior ainda, os milhares e milhares de testes unitários, testes de snapshot, testes de ponta a ponta gerados pelos Agentes são igualmente não confiáveis. A única maneira de avaliar se o "sistema está funcionando corretamente" é através de testes manuais.

Parabéns, você se colocou (e sua empresa) em uma situação complicada.

O Mercador da Complexidade

Você perdeu completamente a noção do que está acontecendo no sistema porque entregou o controle aos Agentes. E, fundamentalmente, os Agentes estão no negócio de "vender complexidade." Eles viram muitas decisões arquitetônicas terríveis em seus dados de treinamento e reforçaram continuamente esses padrões no processo de aprendizado por reforço. Você os deixou projetar o sistema, e o resultado é o que você esperava.

O que você acaba tendo é um sistema altamente convoluto, misturando várias imitações ruins das "melhores práticas do setor", e você não impôs nenhuma restrição antes que os problemas saíssem do controle.

Mas os problemas não param por aí. Seus Agentes não compartilham processos de execução entre si, não conseguem ver todo o código-fonte e não têm conhecimento das decisões que você ou outros Agentes tomaram anteriormente. Portanto, suas decisões são sempre "locais."

Isso leva diretamente aos problemas mencionados anteriormente: código duplicado em abundância, estruturas excessivamente abstratas em nome da abstração, todo tipo de inconsistências. Esses problemas se acumulam, resultando, em última análise, em um sistema irremediavelmente complexo.

Isso é na verdade bastante semelhante a um código-fonte de nível empresarial escrito por humanos. A única diferença é que esse tipo de complexidade geralmente é o resultado de anos de acúmulo: a dor é espalhada por um grande número de pessoas, cada uma das quais não atingiu o limite de "precisa consertar", a organização em si tem uma alta tolerância, então a complexidade e a organização "co-evoluem."

No entanto, no caso de uma combinação humano + Agente, esse processo será acelerado consideravelmente. Duas pessoas, mais um monte de Agentes, podem alcançar esse nível de complexidade em questão de semanas.

A Taxa de Recordação da Busca Agente é Baixa

Você pode esperar que os Agentes "limpem a bagunça" para você, ajudem a refatorar, otimizar e tornar o sistema mais limpo. Mas o problema é: eles não conseguem mais fazer isso.

Porque o código-fonte é muito grande e a complexidade é muito alta, e eles só conseguem ver uma parte dele. Isso não é apenas uma questão de a janela de contexto não ser grande o suficiente, ou o mecanismo de longo contexto falhar diante de milhões de linhas de código. O problema é mais insidioso.

Antes que um Agente tente consertar o sistema, ele deve primeiro encontrar todo o código que precisa ser modificado, bem como implementações existentes que podem ser reutilizadas. Essa etapa, chamamos de busca agente.

Como um Agente faz isso depende das ferramentas que você lhe dá: pode ser Bash + ripgrep, pode ser um índice de código pesquisável, serviço LSP, banco de dados vetorial...

Mas não importa quais ferramentas sejam usadas, a essência é a mesma: quanto maior o código-fonte, menor a taxa de recordação. E uma baixa taxa de recall significa: o Agente não consegue encontrar todo o código relevante e, naturalmente, não consegue fazer as modificações corretas.

É também por isso que inicialmente aparecem esses pequenos erros de "cheiro de código"; ele não encontrou uma implementação existente, então reinventa a roda, introduzindo inconsistência. Eventualmente, esses problemas continuarão a se espalhar, sobrepor e crescer em uma "flor podre" extremamente complexa.

Então, como podemos evitar tudo isso?

Como Devemos Colaborar com Agentes (pelo Menos por Enquanto)

Programar com Agentes é como lidar com um monstro marinho, com sua velocidade de geração de código extremamente rápida e aquele tipo de inteligência "intermitente, mas ocasionalmente impressionante" que te atrai. Eles frequentemente conseguem completar tarefas simples a uma velocidade e qualidade surpreendentes. O verdadeiro problema começa quando você tem a ideia - "Essa coisa é poderosa demais, computador, faça o trabalho por mim!"

Delegar tarefas ao próprio Agente não é, claro, um problema. Boas tarefas para o Agente geralmente têm várias características: o escopo pode ser bem definido, não há necessidade de entender todo o sistema; a tarefa é de ciclo fechado, o que significa que o Agente pode avaliar os resultados por conta própria; a saída não está no caminho crítico, apenas algumas ferramentas ou softwares temporários para uso interno, não afetará usuários reais ou receita; ou você só precisa de um "pato de borracha" para ajudar a pensar - essencialmente pegando suas ideias e tendo uma colisão com conhecimento comprimido da internet e dados sintéticos.

Se essas condições forem atendidas, então essa é uma tarefa adequada para ser delegada ao Agente, desde que você, como humano, ainda permaneça o controle de qualidade final.

Por exemplo, usar o método de auto-pesquisa de Andrej Karpathy para otimizar o tempo de inicialização de aplicativos? Ótimo. Mas é essencial que você entenda que o código que ele gera não está de forma alguma pronto para produção. A auto-pesquisa é eficaz porque você deu a ele uma função de aptidão para otimizar em torno de uma métrica específica (como tempo de inicialização ou perda). No entanto, essa função de aptidão cobre apenas uma dimensão muito estreita. O Agente ignorará audaciosamente todas as métricas não incluídas na função de aptidão, como qualidade do código, complexidade do sistema e, em alguns casos, até mesmo correção - se a sua função de aptidão em si estiver com falhas.

A ideia central é na verdade bastante simples: deixe o Agente fazer as tarefas chatas e não educativas, ou o trabalho exploratório que você nunca teve tempo para tentar. Então, avalie os resultados, selecione as partes verdadeiramente razoáveis e corretas e complete a implementação final. Claro, você também pode usar o Agente para ajudar com este passo final.

Mas o que eu realmente quero enfatizar é: realmente, desacelere um pouco.

Dê a si mesmo tempo para pensar sobre o que você está fazendo e por que está fazendo isso. Dê a si mesmo a chance de dizer "não, não precisamos disso." Defina um limite claro para o Agente: quanto código ele pode gerar por dia, uma quantidade que deve corresponder à sua capacidade real de revisão. Todas as partes que determinam a "forma geral" do sistema, como arquitetura e APIs, devem ser escritas por você. Você pode usar a autocompletação para ter uma noção de "escrever código à mão," ou fazer programação em par com o Agente, mas a chave é: você deve estar no código.

Porque escrever código você mesmo, ou assistir à sua construção passo a passo, traz uma espécie de "fricção." É essa fricção que torna você mais claro sobre o que deseja fazer, como o sistema funciona e qual é a "sensação" geral. É aqui que a experiência e o "sabor" entram em jogo, e isso é precisamente o que os modelos mais avançados ainda não conseguem substituir. Desacelere, suporte alguma fricção – é assim que você aprende e cresce.

No final, o que você terá ainda será um sistema mantível—pelo menos não pior do que antes do surgimento do Agente. Sim, sistemas anteriores também não eram perfeitos. Mas seus usuários vão agradecer porque seu produto é "usável," não um monte de lixo jogado juntos às pressas.

Você terá menos recursos, mas eles serão mais corretos. Aprender a dizer "não" é, em si, uma habilidade. Você também pode dormir tranquilo porque ainda sabe o que está acontecendo no sistema, você ainda tem controle. É essa compreensão que permite que você aborde a questão da recuperação da busca agente, tornando a saída do Agente mais confiável e exigindo menos correções.

Quando o sistema dá errado, você pode colocar a mão na massa para consertá-lo; quando o design foi falho desde o início, você pode entender o problema e refatorá-lo para uma forma melhor. Se há um Agente ou não, na verdade, não é tão importante.

Tudo isso requer disciplina. Tudo isso é inseparável dos humanos.

[Artigo Original]