Título original: Pensamentos sobre desacelerar
Autor original: Mario Zechner
Compilado por: Peggy, BlockBeats

Nota do editor: Com a aceleração da IA generativa na engenharia de software, o sentimento da indústria está passando de “admiração pela capacidade” para “ansiedade pela eficiência”. Escrever mais devagar, usar menos, não automatizar o suficiente, parece criar uma pressão de ser descartado. Mas quando os Agentes de codificação realmente entram no ambiente de produção, algumas questões mais realistas começam a surgir: os erros são amplificados, a complexidade sai do controle, os sistemas tornam-se progressivamente incompreensíveis, e o aumento da eficiência não se traduz, proporcionalmente, em uma melhoria da qualidade.

Este artigo, baseado em práticas de primeira linha, reflete friamente sobre esta onda de “codificação agencial”. O autor aponta que os Agentes não aprendem com os erros como os humanos, e na falta de gargalos e mecanismos de feedback, pequenos problemas são rapidamente amplificados; enquanto isso, em bibliotecas de código complexas, sua perspectiva local e capacidade de recordação limitada exacerbam ainda mais a confusão estrutural do sistema. A essência desses problemas não reside na tecnologia em si, mas no fato de que os humanos, impulsionados pela ansiedade, entregam o julgamento e o controle cedo demais.

Portanto, em vez de cair na ansiedade de “se é necessário abraçar totalmente a IA”, é melhor recalibrar a relação entre humanos e ferramentas: deixar que os Agentes assumam tarefas locais e controláveis, enquanto mantém firmemente o design do sistema, a garantia de qualidade e as decisões críticas em suas próprias mãos. Nesse processo, “desacelerar” torna-se uma habilidade, significando que você ainda entende o sistema, é capaz de fazer escolhas e ainda mantém uma sensação de controle sobre o trabalho.

Na era da evolução constante das ferramentas, o que realmente falta pode não ser a capacidade de gerar mais rapidamente, mas o julgamento sobre a complexidade e a firmeza em fazer escolhas entre eficiência e qualidade.

Abaixo está o texto original:

A cara da tartaruga é a expressão que eu tenho ao olhar para esta indústria.

Cerca de um ano atrás, os Agentes de codificação que realmente podem te ajudar a “fazer um projeto completo do início ao fim” começaram a surgir. Antes disso, já existiam ferramentas como Aider e Cursor, mas elas eram mais como assistentes do que “agentes”. A nova geração de ferramentas é extremamente atraente, e muitas pessoas também passaram muito tempo livre completando projetos que sempre quiseram fazer, mas não tinham tempo.

Não vejo problema nisso. Fazer coisas no tempo livre é, por si só, muito prazeroso, e na maioria das vezes você não precisa se preocupar muito com a qualidade e a manutenção do código. Isso também oferece um caminho para aprender novas pilhas de tecnologia.

Durante as férias de Natal, a Anthropic e a OpenAI também ofereceram um pouco de “créditos gratuitos”, atraindo as pessoas como uma máquina caça-níqueis. Para muitos, esta foi a primeira experiência verdadeira da “magia de um Agente escrevendo código”. O número de participantes está crescendo.

Hoje, os Agentes de codificação também estão começando a entrar em bibliotecas de código de produção. Doze meses se passaram e começamos a ver as consequências desse “avanço”. Abaixo estão minhas opiniões atuais.

Tudo deu errado

Embora a maioria disso seja apenas experiência pessoal, o software atual realmente dá a impressão de que “pode quebrar a qualquer momento”. 98% de disponibilidade está se tornando a norma, mesmo em grandes serviços. A interface do usuário está cheia de bugs absurdos que deveriam ser facilmente detectados pela equipe de QA.

Eu admito que essa situação já existia antes do surgimento dos Agentes. Mas agora, o problema claramente está acelerando.

Não vemos a verdadeira situação dentro das empresas, mas ocasionalmente algumas informações vazam, como na vez em que houve rumores de que “IA causou a queda da AWS”. A Amazon Web Services rapidamente “corrigiu” a declaração, mas logo iniciou internamente um plano de reestruturação de 90 dias.

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

As empresas que afirmam que “100% do código do produto é gerado por IA” praticamente sempre produzem os piores produtos que você pode imaginar. Não é direcionado a ninguém, mas vazamentos de memória com GB, confusão na UI, funcionalidades ausentes, falhas frequentes… nada disso é o “endosse de qualidade” que eles pensam, muito menos uma demonstração positiva de “deixe o Agente fazer tudo por você”.

Nos bastidores, você ouvirá cada vez mais que, tanto grandes empresas quanto pequenas equipes, estão dizendo uma coisa: foram empurrados para um beco sem saída pela “codificação agencial”. Sem revisão de código, entregando decisões de design a um Agente e acumulando uma montanha de funcionalidades que ninguém precisa - o resultado, naturalmente, não será bom.

Por que não devemos usar os Agentes dessa forma

Praticamente abandonamos toda a disciplina de engenharia e julgamento subjetivo, caindo em um modo de trabalho “viciado”: o único objetivo é gerar o máximo de código no menor tempo possível, sem pensar nas consequências.

Você está construindo uma camada de orquestração, para comandar um exército de Agentes automatizados. Você instalou Beads, mas não faz ideia de que, na essência, é quase um “malware” que não pode ser removido. Apenas porque todo mundo na internet diz “todos estão fazendo isso”. Se você não fizer, “você vai se dar mal” (ngmi).

Você está se consumindo em um ciclo “de boneca dentro de boneca”.

Veja - a Anthropic usou um grupo de Agentes para criar um compilador C; embora ainda tenha problemas, o próximo modelo certamente vai consertar, certo?

E veja - a Cursor usou um grande número de Agentes para criar um navegador, embora atualmente seja praticamente inutilizável e exija intervenção manual ocasional, o próximo modelo certamente vai resolver, certo?

“Distribuído”, “dividir para conquistar”, “sistemas autônomos”, “fábrica sem luz”, “resolver problemas de software em seis meses”, “SaaS está morto, minha avó acabou de usar o Claw para montar um Shopify”…

Essas narrativas soam agradáveis.

Claro, essa abordagem pode funcionar para aquele seu projeto secundário que quase ninguém usa (incluindo você). Talvez haja realmente algum gênio que consiga criar um produto de software que não seja lixo e que seja realmente utilizado. Se você é essa pessoa, eu realmente admiro.

Mas pelo menos no círculo de desenvolvedores ao meu redor, ainda não vi casos em que essa abordagem realmente funcione. Claro, talvez só sejamos todos muito inexperientes.

Os erros se acumulam sem aprendizado, gargalos ou explosões tardias

O problema com os Agentes é que: eles cometem erros. Isso em si não é um problema, os humanos também cometem erros. Podem ser apenas alguns erros de correção que são fáceis de identificar e corrigir; e um teste de regressão adicional tornaria tudo mais seguro. Também podem ser alguns “cheiros de código” que os linters não conseguem detectar: um método inútil aqui, um tipo irracional ali, e código duplicado. Cada um desses erros, visto isoladamente, não é grave, e os desenvolvedores humanos também cometem esses pequenos erros.

Mas “máquinas” não são humanas. Depois de cometer os mesmos erros algumas vezes, os humanos normalmente aprendem a não cometê-los novamente - seja porque foram corrigidos ou porque mudaram durante um verdadeiro processo de aprendizado.

Os Agentes, no entanto, não têm essa capacidade de aprendizado; pelo menos, presumidamente não têm. Eles repetem os mesmos erros vez após vez, e podem até “criar” combinações de erros diferentes baseadas nos dados de treinamento.

Você pode, é claro, tentar “treiná-los”: escrevendo regras em AGENTS.md para que não cometam mais esses erros; projetando um sistema de memória complexo para que eles consultem erros históricos e melhores práticas. Isso pode funcionar para alguns tipos específicos de problemas. Mas a condição é - você deve primeiro notar que eles cometeram esse erro.

A diferença mais crucial é: os humanos são o gargalo, enquanto os Agentes não são.

Os humanos não conseguem gerar 20.000 linhas de código em poucas horas. Mesmo que a frequência de erros não seja baixa, em um dia só pode introduzir um número limitado de erros, e a acumulação desses erros é lenta. Normalmente, quando a “dor causada pelos erros” acumula até um certo ponto, os humanos (por instinto de aversão à dor) param para corrigir. Ou a pessoa é substituída, e alguém mais corrige. De qualquer forma, o problema será tratado.

Mas quando você usa um exército de Agentes totalmente orquestrado, não há gargalos e não há “sensação de dor”. Esses pequenos erros, que antes eram insignificantes, se acumulam a uma velocidade insustentável. Você foi removido do ciclo e não percebeu que esses pequenos problemas, que pareciam inofensivos, cresceram em um monstro. Quando você realmente sente a dor, muitas vezes já é tarde demais.

Até que um dia, você queira adicionar uma nova funcionalidade e descubra que a arquitetura atual do sistema (que já é, essencialmente, um acúmulo de erros) não pode suportar a modificação; ou os usuários começam a reclamar freneticamente porque a última versão apresentou problemas, e até perderam dados.

Só então você percebe: você já não pode confiar nesse código.

Pior ainda, os milhares de testes unitários, testes de instantâneas e testes de ponta a ponta gerados pelo Agente também se tornam não confiáveis. A única maneira de determinar se “o sistema está funcionando corretamente” é através de testes manuais.

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

Os vendedores da complexidade

Você já não sabe o que está acontecendo no sistema, porque entregou o controle aos Agentes. E os Agentes, em essência, estão “vendendo complexidade”. Eles viram um grande número de decisões arquitetônicas ruins nos dados de treinamento e continuam a reforçar esses padrões durante o aprendizado por reforço. Você os coloca para projetar o sistema e o resultado é previsível.

Você acaba obtendo: um sistema extremamente complexo, misturado com várias imitações ruins de “melhores práticas da indústria”, e você não impôs restrições antes que os problemas saíssem do controle.

Mas o problema não para por aí. Seus Agentes não compartilham o processo de execução entre si, não veem o repositório de código completo e não entendem as decisões feitas por você ou outros Agentes anteriormente. Portanto, suas decisões são sempre “locais”.

Isso leva diretamente aos problemas mencionados anteriormente: uma grande quantidade de código duplicado, estruturas que abstraem por abstrair e várias inconsistências. Esses problemas se acumulam continuamente, formando um sistema complexo irreversível.

Isso é muito parecido com bibliotecas de código de nível empresarial escritas por humanos. Apenas essa complexidade é geralmente o resultado de anos de acúmulo: a dor é dispersa por uma grande quantidade de pessoas, cada uma não atingindo o “ponto crítico” de “precisar corrigir”, e a tolerância da organização em si é alta, de modo que a complexidade “co-evolui” com a organização.

Mas na combinação de humanos + Agentes, esse processo é acelerado enormemente. Duas pessoas, mais um monte de Agentes, podem alcançar essa complexidade em algumas semanas.

A taxa de recall da busca agencial é muito baixa

Você pode esperar que os Agentes “resolvam a situação”, ajudando a refatorar, otimizar e deixar o sistema mais limpo. Mas o problema é: eles já não conseguem fazer isso.

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

Antes que os Agentes tentem corrigir o sistema, eles precisam encontrar todo o código que precisa ser modificado e as implementações existentes que podem ser reutilizadas. Essa etapa chamamos de busca agencial (agentic search).

Como os Agentes fazem isso depende das ferramentas que você lhes fornece: pode ser Bash + ripgrep, um índice de código pesquisável, serviços LSP, banco de dados de vetores…

Mas independentemente da ferramenta usada, a essência é a mesma: quanto maior o repositório de código, menor a taxa de recall. E uma baixa taxa de recall significa que os Agentes não conseguem encontrar todo o código relevante, e, portanto, não conseguem fazer as correções corretas.

É também por isso que, inicialmente, aqueles pequenos erros de “cheiro de código” aparecem; eles não encontraram implementações existentes e, portanto, reinventam a roda, introduzindo inconsistências. No final, esses problemas se espalham e se acumulam, formando uma “flor podre” extremamente complexa.

Então, como podemos evitar tudo isso?

Como devemos colaborar com os Agentes (pelo menos por agora)

Os Agentes de codificação são como sereias, atraindo você com uma velocidade de geração de código extremamente rápida e uma inteligência que “é intermitente, mas às vezes surpreendente”. Eles costumam ser capazes de completar algumas tarefas simples de forma rápida e de alta qualidade. O verdadeiro problema começa quando você começa a ter a ideia de - “isso é tão poderoso, computador, faça o trabalho para mim!”

Entregar as tarefas aos Agentes em si não é um problema. Tarefas boas para Agentes geralmente possuem algumas características: o escopo pode ser bem definido, não precisa 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 é crítica, é apenas uma ferramenta temporária ou software de uso interno, que não afetará usuários reais ou receita; ou você só precisa de um “pato de borracha” para auxiliar no pensamento - essencialmente, levando suas ideias para uma rodada de colisão com o conhecimento comprimido da internet e dados sintetizados.

Se essas condições forem atendidas, então essa é uma tarefa adequada para um Agente, desde que você, como humano, ainda seja o guardião final da qualidade.

Por exemplo, usar o método de auto-pesquisa proposto por Andrej Karpathy para otimizar o tempo de inicialização de um aplicativo? Ótimo. Mas a condição é que você esteja ciente de que o código que ele gera definitivamente não possui viabilidade para produção. A auto-pesquisa é eficaz porque você lhe deu uma função de avaliação, permitindo que ela otimize em torno de um determinado indicador (como tempo de inicialização ou perda). Mas essa função de avaliação cobre apenas uma dimensão muito estreita. O Agente ignorará todos os indicadores que não estão na função de avaliação, como qualidade do código, complexidade do sistema e, em alguns casos, até mesmo a correção - se a sua função de avaliação em si tiver problemas.

A ideia central é bastante simples: deixe os Agentes fazerem aquelas tarefas monótonas, que não lhe ensinarão nada novo, ou aquelas que você não tem tempo para tentar explorar. Então, você avalia os resultados, escolhe as partes que são realmente razoáveis e corretas, e completa a implementação final. Claro, você também pode usar os Agentes para ajudar nessa etapa final.

Mas eu quero enfatizar mais uma vez: realmente, é hora de desacelerar um pouco.

Dê a si mesmo tempo para pensar sobre o que você está realmente fazendo e por que está fazendo. Dê a si mesmo a oportunidade de dizer “não” - “não, isso não precisamos”. Defina um limite claro para os Agentes: quanto código eles podem gerar por dia, e essa quantidade deve corresponder à sua capacidade real de revisão. Todas as partes que decidem a “forma geral” do sistema, como arquitetura, API, etc., devem ser escritas por você pessoalmente. Você pode usar o autocompletar para ter um pouco da “sensação de escrever código à mão”, ou pode programar em par com o Agente, mas o ponto chave é: você deve estar no código.

Porque escrever código pessoalmente ou ver o código sendo construído passo a passo traz uma sensação de “fricção”. É essa fricção que o ajuda a entender melhor o que você realmente deseja fazer, como o sistema funciona e como é a “sensação” geral. Esse é o ponto onde a experiência e o “sabor” desempenham um papel, e isso é algo que os modelos mais avançados atuais ainda não podem substituir. Desacelerar e suportar um pouco de fricção é, na verdade, a sua forma de aprender e crescer.

No final, você terá um sistema que ainda é mantível - pelo menos não será pior do que antes do surgimento dos Agentes. Sim, os sistemas passados também não eram perfeitos. Mas seus usuários agradecerão, porque seu produto será “funcional”, em vez de ser um monte de lixo improvisado.

Você fará menos funcionalidades, mas elas serão mais corretas. Aprender a dizer “não” é, em si, uma habilidade. Você também poderá dormir mais tranquilo, porque pelo menos sabe o que está acontecendo no sistema, ainda mantém o controle. É essa compreensão que permite compensar o problema de recall da busca agencial, tornando as saídas dos Agentes mais confiáveis e exigindo menos correções.

Quando o sistema apresenta problemas, você pode intervir pessoalmente; quando o design já é irracional desde o início, você também conseguirá entender onde está o problema e reestruturá-lo em uma forma melhor. A questão de ter ou não um Agente, na verdade, não é tão importante.

Tudo isso requer disciplina. Tudo isso depende dos humanos.

[Link original]

Clique para saber mais sobre as vagas disponíveis na BlockBeats

Bem-vindo ao grupo oficial da BlockBeats:

Grupo de assinatura do Telegram: https://t.me/theblockbeats

Grupo de discussão do Telegram: https://t.me/BlockBeats_App

Conta oficial do Twitter: https://twitter.com/BlockBeatsAsia