O melhor IDE para IA agente pode não ser um IDE

Considere um desenvolvedor que pede a um agente para corrigir um bug, a outro para investigar um problema de desempenho e a um terceiro para atualizar uma dependência. Enquanto os agentes trabalham, ela pode fazer outra coisa, o que torna o desenvolvimento orientado pelo LLM tão atraente – pelo menos até o retorno dos agentes.

Nenhum desses agentes funciona totalmente isolado do resto do sistema. Pense nisso: a correção do bug muda o comportamento do qual alguém pode depender. OK… podemos resolver isso! Mas espere, agora temos a investigação de desempenho oferecendo três opções, cada uma com custos diferentes. Hum. Espere um minuto enquanto eu resolvo isso… exceto que a atualização da dependência não está esperando. Ele passa nos testes, mas o agente também reescreveu um arquivo de configuração. Melhor verificar isso!

Como mostra este exemplo simples, antes que o desenvolvedor possa avançar em qualquer decisão, ele primeiro precisa recuperar o que pediu, o que o agente descobriu e o que permanece incerto. E não, adicionar mais agentes não resolve o problema. Em vez disso, poderia agravar o problema.

Os agentes podem ter economizado horas. Viva! Mas uma lista de sessões concluídas não informa ao desenvolvedor por onde começar. O resultado de um teste verde também não responde à questão de saber se a alteração pertence à aplicação.

É por isso que o número de agentes em execução nos diz tão pouco, mesmo que isso nos faça sentir bem. Quero dizer, o que esses agentes estão fazendo, afinal? Os comentaristas de Yegge fornecem algumas pistas. Por exemplo, Anton descreve o uso de 30 guias de terminal com um agente ativo por projeto, para evitar sobreposição de trabalho. Jerry Combs diz que geralmente não mantém mais do que três conversas, com os agentes gerenciando seus próprios subagentes conforme necessário. Mesmo essas três conversas são bastante difíceis de acompanhar.

Ambas as abordagens podem fazer sentido. As exigências dependem da independência com que o trabalho pode prosseguir e de quanto julgamento humano é necessário ao longo do caminho. Um desenvolvedor com 20 agentes pode ter menos decisões a tomar do que alguém com três.

Gergely Orosz listou recentemente várias observações que valem a pena considerar em conjunto: os desenvolvedores gastam menos tempo em IDEs, as revisões de código se tornam um teatro e as pessoas trabalham mais, apesar das promessas de produtividade da IA. Suas observações não estabelecem que as ferramentas dos agentes causem excesso de trabalho ou revisão superficial. Eles fazem valer a pena perguntar se estamos transferindo esforços para lugares que nossas histórias de produtividade negligenciam. Observar um agente produzir uma mudança é satisfatório, mas passar a tarde reconstruindo por que seis mudanças foram feitas é menos satisfatório.

Mas esse trabalho, por mais insatisfatório que seja, é necessário para que essas mudanças sejam compreendidas e mantidas.

Alguns dos encanamentos já existem para aliviar esses problemas. Por exemplo, o Herdr rastreia os agentes como trabalhando, bloqueados ou ociosos e carrega esses estados em suas guias e áreas de trabalho; cmux oferece notificações e um atalho para a área de trabalho com a notificação não lida mais recente. Estes são começos úteis, mas realçam o quanto ainda falta fazer. Afinal, a notificação mais recente pode dizer respeito à tarefa menos importante, e um agente que faz uma pergunta pode ser perfeitamente capaz de esperar enquanto o desenvolvedor termina outra coisa.

A próxima melhoria deverá ajudar os desenvolvedores a fazer essas distinções. Uma tarefa deve manter o seu propósito original, as decisões relevantes e as evidências que apoiam o seu resultado. Quando precisa de uma pessoa, deve explicar a decisão necessária e o que acontece se essa decisão esperar. Um resumo pode ajudar, mas deve levar de volta às mudanças reais e aos resultados dos testes. Caso contrário, facilitamos a aprovação de trabalhos sem entendê-los.

Novamente, as melhores ferramentas para IA de agência serão aquelas que trazem o ser humano de volta ao circuito e fornecem as informações necessárias para a tomada de decisões.

Gostaria de uma ferramenta que pudesse me dizer que uma tarefa está pronta para revisão porque o comportamento solicitado foi demonstrado, mantendo uma questão separada e menos urgente fora do meu caminho. Também gostaria de lembrar que rejeitei uma abordagem ontem, para não precisar descobri-la novamente na correção proposta hoje. Se essa ferramenta se autodenomina IDE parece secundário. O Google introduziu o Antigravity 2.0 como um aplicativo de agente independente sem um IDE, ao mesmo tempo em que recomenda que os desenvolvedores o usem junto com o IDE de sua escolha. Em outras palavras, o editor ainda tem um trabalho, mesmo quando não é mais onde começa toda tarefa.

Em 2022, escrevi sobre a conveniência da nuvem e a tendência de entender mal o que os desenvolvedores desejam de suas ferramentas. Eles têm trabalho a fazer e querem menos obstáculos para fazê-lo. Deveríamos aplicar esse mesmo padrão ao desenvolvimento de agentes em toda a tarefa, incluindo o esforço de regressar a ela.

Não que possamos colocar todo o ônus sobre a IA e suas ferramentas. As equipes têm um papel a desempenhar aqui. Se cada tarefa for urgente, a ferramenta não terá nada de útil para priorizar. Se ninguém definir o que conta como concluído, a ferramenta só poderá informar que um agente parou. Concordar sobre essas coisas e limitar o trabalho que requer decisões humanas simultâneas fará mais do que adicionar outro distintivo de status.

Os leitores de Yegge já estão construindo peças desse futuro, um atalho e um espaço de trabalho caseiro de cada vez. A oportunidade do fornecedor é disponibilizar essa conveniência sem exigir que todos mantenham um projeto paralelo. Dê aos desenvolvedores mais trabalho que eles possam deixar para trás com segurança e menos conversas que eles precisem manter vivas em suas cabeças.