A história do software é uma história de entregar trabalho à máquina. Começamos perfurando instruções em cartões, depois deixamos os compiladores transformarem linguagens legíveis em código de máquina, depois deixamos as máquinas virtuais esquecerem em qual computador físico estávamos, depois deixamos a nuvem esquecer a máquina por completo. Cada passo parecia, na época, abrir mão do controle. Cada um era, na verdade, subir um nível: trocar uma camada de esforço por uma camada de alavancagem. O desenvolvimento agêntico é o próximo passo dessa mesma longa linha, e é maior do que a maioria.
A abstração sempre foi a história
Nenhuma das mudanças anteriores tornou os programadores obsoletos; elas mudaram no que um programador gastava o dia. O compilador não acabou com a programação, acabou com escrever assembly na mão. A nuvem não acabou com as operações, acabou com montar servidores em racks. Toda vez que a máquina absorveu a camada de baixo, o humano se moveu para a camada de cima: de gerenciar memória a gerenciar lógica, de gerenciar servidores a gerenciar sistemas.
O padrão é tão consistente que quase é uma lei: aquilo que fica barato de automatizar deixa de ser onde está o valor, e o valor se move para o que agora é a coisa mais escassa. Por muito tempo o escasso foi a implementação: transformar intenção em código que funciona. É exatamente essa a camada que os agentes estão absorvendo agora.
Um agente é um colega, não um autocompletar mais rápido
O erro tentador é arquivar os agentes de programação como "autocompletar melhor". Eles são outra categoria de coisa. O autocompletar termina a sua frase; um agente pega um objetivo e age sobre ele — decide, dentro das travas que você define, o que mudar e como, e então faz. É menos como um teclado mais esperto e mais como um colega que por acaso vive no repositório: você dá uma issue a ele, ele some, e volta com um merge request.
É essa a forma com que construímos o TaskGoblin. Não é um painel no seu editor. É um colega nas ferramentas que o seu time já usa — issues atribuídas, menções em threads, revisão de pull requests — que faz a implementação num sandbox e devolve um trabalho que você revisa. A unidade de interação não é uma tecla. É uma tarefa.
Como o dia começa a se parecer
Siga isso um passo à frente e o dia de trabalho muda de forma. As atualizações de dependência que ninguém quer fazer são feitas de madrugada. O teste instável é podado antes da daily. Uma funcionalidade bem especificada chega como um pull request em rascunho com scaffolding e testes já no lugar, esperando julgamento em vez de digitação. Um product manager move um ticket e a primeira versão da mudança está aberta quando alguém olha. A esteira do esforço — o trabalho necessário e sem glamour que enche tanto da semana de um engenheiro — enfim desacelera.
O que sobra é a parte que sempre foi o trabalho de verdade: decidir o que deve ser construído, perceber quando a implementação óbvia está sutilmente errada, sustentar o gosto e o contexto que nenhuma quantidade de capacidade bruta fornece. O engenheiro passa de autor a editor: de produzir cada linha a dirigir o que é produzido e julgar se está certo.
A pergunta muda de "conseguimos?" para "deveríamos?"
Quando a implementação é barata e rápida, a restrição que amarra deixa de ser se você consegue construir algo e passa a ser se vale a pena construir. Iterar fica barato o bastante para que as revisões de design fiquem exploratórias: teste três versões em vez de discutir sobre uma. Um time pequeno consegue operar com a produção de um muito maior, porque a alavancagem por pessoa subiu. E a vantagem competitiva se desloca de acordo: para longe de quem consegue executar, em direção a quem tem o gosto de saber o que executar, a empatia de entender para quem é, e a clareza de articular o problema bem o bastante para que um agente possa avançar sobre ele.
É esse o reenquadramento sob todo o barulho. "Agora somos todos gerentes de enxames de juniores" é a versão ansiosa; a versão mais verdadeira é que a alavancagem se moveu, e a habilidade escassa se moveu com ela: para cima, para o julgamento.
Onde o humano permanece
Uma versão honesta desse futuro não finge que o humano desaparece. É o oposto: à medida que a máquina absorve a implementação, as decisões humanas ficam mais consequentes, não menos, porque cada uma agora direciona muito mais produção. Por isso o TaskGoblin deliberadamente mantém uma pessoa no merge: o agente escreve o código e revisa a mudança, mas nunca aprova e nunca faz o merge. O julgamento sobre se algo está certo para este sistema, agora, é justamente a camada que não se automatiza, e é a camada para a qual todos nós estamos subindo.
A esteira está desacelerando. O que vai determinar quem molda a próxima era do software não será quem consegue implementar — a máquina está ficando com isso, como ficou com as camadas de baixo. Será a imaginação, o gosto e o julgamento de apontar toda essa capacidade para as coisas que de fato valem a pena construir.
