Por muito tempo a pergunta sobre agentes de programação foi se eles conseguiam de fato fazer o trabalho. Essa pergunta está se fechando sem alarde. Em tarefas bem delimitadas, com o repositório à frente e a capacidade de rodar os testes, bons agentes entregam mudanças reais que passam na revisão. E no momento em que você confia nisso, esbarra num problema do qual ninguém te avisou: você não consegue pensar em trabalho rápido o bastante para mantê-los ocupados.
A execução deixou de ser a restrição
Sempre há trabalho infinito a fazer num produto de software. O backlog nunca está vazio; a lista de coisas que poderiam estar melhores é interminável. Por isso soa estranho dizer que um time poderia ficar sem trabalho para um agente. Mas "existe trabalho infinito" e "existe trabalho numa forma que um agente consegue pegar e terminar" são duas afirmações muito diferentes, e é na lacuna entre elas que os times travam.
Um agente executa uma tarefa clara em minutos. Escrever essa tarefa clara — a que tem contexto suficiente, o escopo certo e uma definição de pronto — ainda custa a uma pessoa os mesmos vinte minutos de sempre. Quando a parte lenta era a execução, tudo bem; a especificação era cinco por cento do esforço e o trabalho eram os outros noventa e cinco. Empurre o custo de execução para perto de zero e a proporção se inverte. Agora a especificação é a metade cara, e um time que conseguia alimentar um agente descobre que não consegue alimentar três.
O gargalo subiu, na sua direção
Este é o problema do suprimento de tarefas: a restrição do desenvolvimento com agentes não é mais a capacidade do agente de fazer coisas, é a capacidade da organização de produzir coisas bem formadas para fazer. E essa restrição recai sobre as pessoas mais escassas que você tem: as que têm contexto suficiente para dizer o que deve acontecer em seguida e por quê.
Você sente isso como uma pressão estranha. O agente é rápido e confiável, então a fila esvazia mais rápido do que você consegue reabastecer, e reabastecer é a parte que precisa de julgamento, senso de produto e conhecimento de para onde o sistema está indo. O gargalo não desapareceu. Ele se moveu do teclado para a cabeça da pessoa que sabe o que o teclado deveria estar fazendo.
O agente tem que ajudar a suprir o trabalho
A única forma de superar um problema de suprimento é aumentar o suprimento, e a pessoa que define tarefas não escala. Então o agente que executa o trabalho tem que começar a ajudar a gerá-lo — não inventando tarefa de encher linguiça, mas transformando os sinais que já circulam pelos seus sistemas em tarefas concretas e prontas para rodar.
O TaskGoblin faz uma versão disso hoje, em dois lugares que talvez você não tenha pensado como "geração de tarefas":
- Apontamentos de revisão viram trabalho. Todo merge request que o agente revisa produz apontamentos específicos e localizados: esta função tem um bug de correção, este caminho não tem cobertura, isto cheira a problema de segurança. Cada um é, na prática, uma tarefa pré-escrita com uma definição de pronto. Responda
@taskgoblin fixe o apontamento vira uma mudança. Ninguém precisou sentar e escrever aquele ticket; a revisão o supriu. - Ciclos permanentes viram trabalho. Um loop é um gerador de tarefas que roda no relógio: "todo dia útil, encontre trabalho que entrou cujas issues ainda estão abertas e feche-as", "vigie um CI vermelho por tempo demais". A instrução é escrita uma vez e segue produzindo trabalho concreto — ou corretamente produzindo nada quando não há nada a fazer — sem ninguém reabastecer a fila à mão.
Nos dois casos o agente não espera que digam o que fazer. Ele lê o estado do sistema e propõe a próxima coisa concreta e terminável.
Por que o contexto é o jogo inteiro
A razão de o trabalho proposto por um agente ser em geral de baixo valor não é o modelo não ser esperto o bastante. É que o agente não sabe o que importa para você. Cego à intenção do produto, um agente sugere com prazer os vinte refactors que enxerga e nenhum da única mudança que de fato move o negócio — porque o código diz a ele o que é possível, não o que é importante.
Por isso as superfícies úteis de geração de tarefas são as ancoradas na intenção real. Um apontamento de revisão importa porque está sobre uma mudança que alguém escolheu fazer. Um ciclo agendado importa porque um humano decidiu que manter issues e merges em sincronia vale a pena todo dia. O contexto que faz uma tarefa proposta valer a pena não está só no código; está nas issues, nas discussões e nas decisões ao redor do código — e um agente que vive nesses sistemas, como o nosso, pode ler essa intenção em vez de adivinhá-la.
Onde está o valor agora
Vale ser claro sobre onde isso deixa a vantagem. À medida que os modelos convergem para conseguir executar quase tudo, o valor desproporcional deixa de se acumular em quem tem o agente mais esperto e passa a se acumular em quem consegue manter bons agentes supridos com trabalho que importa. A jogada vencedora não é um modelo mais engenhoso. É fechar o ciclo entre a intenção espalhada pelas suas ferramentas e o agente que pode agir sobre ela, para que "o que fazemos em seguida" deixe de ser um gargalo que é você em pessoa.
É esse o problema contra o qual estamos de fato construindo. Fazer o agente conseguir programar era a primeira metade. Garantir que ele sempre saiba o que vale a pena fazer — e consiga transformar o seu contexto na próxima tarefa concreta sem esperar por você — é a metade que decide quanto valia a primeira.
