Há grande alarde ao redor de agentes baseados em grandes modelos de linguagem. Agentes nada mais são que um desdobramento da tecnologia. Boa parte dos programas de computador faz uso de uma interface textual, recebem texto como entrada (mais genericamente, qualquer tipo de sequência de bytes) e produzem texto como saída. Os agentes basicamente teriam autonomia para utilizar esses programas e, como sua saída é texto, poderiam eles próprios interpretar os resultados e continuar rodando mais programas. Foi proposto inclusive um novo protocolo para facilitar a comunicação de grandes modelos de linguagem com programas que originalmente não produziam ou consumiam texto, mas isso ficará para outra semana.
Podemos estar errados, mas pelas demonstrações que vimos de ferramentas como Replit, Cursor, Windsurf e tantas outras, ambientes de desenvolvimento “agentic”, a proposta de uso é completamente irreal. Apresentam essas ferramentas como grandes criadoras de aplicações para internet, com interface, banco de dados e tudo. Apesar de impressionante até certo ponto, é difícil entender porque isso seria superior aos casos de uso atuais, como sugestões de ajuste em tempo real no próprio ambiente de programação, e a famosa interface por conversa, popularizada pelo ChatGPT.
Essa criação de uma aplicação por essas ferramentas requer certa preparação. É preciso explicar em certo nível de detalhe as especificações desejadas, sob risco das tradicionais “alucinações” dos modelos de linguagem. No mais, o tempo de resposta é lento e requer que o usuário aprove passo a passo (é possível customizar isso, mas as implicações de segurança são meio catastróficas). Finalmente, o custo é alto porque esses agentes fazem inúmeras chamadas de inferência para chegarem ao resultado.
Dito isso, suponhamos que o produto final fosse gerado de forma mais ágil e a um custo menor, ainda vemos problemas nessa abordagem. A maioria do tempo de um engenheiro de software não é aplicada na criação de um projeto, mas em sua manutenção, muitas vezes ao longo de anos ou décadas. Essa manutenção se torna mais eficiente conforme se conhece a base de código e, portanto, pessoas que a criaram e a acompanham desde o início costumam ter proficiência em resolver os problemas do dia-a-dia. Além disso, passamos muito menos tempo escrevendo código, em comparação ao tempo que passamos lendo e interpretando, na busca de resolver problemas pontuais. Muitas vezes a solução é a alteração de algumas linhas de código.
Essas ferramentas iludem leigos e buscam atrair atenção para os provedores de grandes modelos de linguagem, que lutam para justificar o crescente capital investido na criação desses modelos. A solução mágica seria eliminar o trabalho de boa parte dos engenheiros de software e recuperar o investimento. Mas bem, vejamos que Elon Musk demitiu boa parte do quadro do antigo Twitter, antes da popularização dos assistentes de código, e manteve a empresa rodando. Não vamos aqui negar que há um excesso de programadores em certas empresas, formando uma certa casta burocrática, mas destacamos que agentes autônomos estão longe de poderem criar em manter sistemas robustos do zero.
Uma questão essencial nos perturba: criamos linguagens de programação para facilitar a interface homem-máquina, e agora criamos uma máquina que trabalha nessa mesma camada de abstração. Por que não ir direto para a geração de código de máquina?
Não há como negar os benefícios da dita “inteligência artificial”. São ferramentas de busca superiores às atualmente existentes e são capazes de nos livrar de boa parte do trabalho mecânico de tarefas envolvendo texto. Curiosamente, não vimos nenhum exemplo de um agente que, por exemplo, crie automaticamente testes unitários ou de integração, para que depois o engenheiro os verifique. Isso seria um ganho porque paralelizaria o trabalho do engenheiro e do agente, mas parece que nossos patrões querem nos pagar para confirmar o que os agentes sugerem. O pior é a pressão que há para usar essas ferramentas, mesmo quando seu uso é improdutivo.
Uma incompreensão dos gestores e executivos é a de que escrever código é muito trabalhoso. Não, a dificuldade está em entender e manter determinada base de código. Poucas vezes em nossa vida profissional temos a oportunidade de abrir um arquivo em branco e começar um projeto. Por isso é estranho que não se apresentem produtos que usem agentes para ajudar na manutenção e compreensão de projetos. Que não apareçam soluções para agilizar o treinamento de pessoas sobre como usar linguagens de programação ou, até mesmo, para a elaboração de novas linguagens que não sejam tão repetitivas e tediosas de se usar.
Além disso, quem disse que há um consenso sobre como se devem ser estruturados projetos de software? Para os modelos de linguagem pode haver um consenso, mas esse status quo é o que há de melhor? Deixo para os leitores que julguem as aplicações que usam diariamente e nos digam se estão satisfeitos ou não. Nosso receio é que essas ferramentas poderosas de produção de texto (e, consequentemente, código) em larga escala criem uma verdadeira favela digital de aplicações descartáveis de baixa qualidade. Esse é o grande problema da produção em larga escala: se o produto é consistentemente bom, o resultado é excelente; agora se for ruim, o que seria um problema simples de resolver, uma aplicação ruim, torna-se um problema gigantesco. Podemos argumentar que a produção em massa de software de baixa qualidade já é a regra, mas o problema tende certamente a se agravar.
É um problema crônico do capitalismo. O saldo de qualquer avanço tecnológico é sempre positivo, o problema está na sua aplicação.
