Depois que o Agente assume a tarefa, a primeira coisa a apertar é a unidade de trabalho.

Tenho lido muitas discussões sobre Agente recentemente e no final sempre volto à mesma pergunta: Para quem deve dar um trabalho, como deve ser embalado antes de entregá-lo e como será aceito após ser devolvido. Uma vez que esse problema ocorre em um projeto, a primeira coisa que aumenta muitas vezes não é o custo do modelo, mas sim a complexidade da unidade de trabalho. Se a tarefa for muito grande, o modelo aparecerá “como se pudesse ser feito”; os verdadeiros problemas geralmente residem na reversão, reprodução e aceitação.

A unidade de trabalho deve primeiro poder ser aceita

Nos últimos dias, depois de reunir as notas fragmentadas de Martin Fowler e várias discussões no retiro sobre o futuro do desenvolvimento de software da Thoughtworks, a sensação mais óbvia é que a conversa na reunião foi superficialmente dispersa, mas no fundo ela girava em torno de apenas uma coisa - entregar uma grande parte do trabalho ao agente.

A finalização de Kief Morris é a mais direta. Diferentes sessões discutiram revisão de código, acidentes de produção, divisão de trabalho da equipe e roteamento de modelo. Pareciam estar falando de coisas diferentes, mas a conclusão acabou sendo a mesma: as pessoas têm ajustado o tamanho da “unidade de trabalho”. Quanto maior for o aparelho, mais fácil será entregá-lo; quanto maior for a unidade, mais difícil será aceitá-la depois que ela voltar. Não é que o modelo não possa fazer isso, é que o link de confirmação subsequente não pode ser sustentado primeiro.

É por isso que o arnês é mencionado repetidamente. Gerenciamento de contexto, sensores computacionais, testes baseados em propriedades, métodos formais, essas coisas parecem ferramentas adicionais, mas na verdade coletam unidades de trabalho. Algumas pessoas controlam o agents.md para menos de 200 linhas, não para buscar limpeza na forma, mas para forçar o sistema a receber apenas a parte da informação que é realmente útil e pode realmente ser verificada. O contexto é muito vago, é claro que o Agente pode ser executado; mas depois de correr, ninguém sabe qual camada de restrições ele engoliu.

A auto-hospedagem aumenta a superfície de controle

As discussões sobre modelos auto-hospedados também apontam para a mesma coisa. Depois que os tokens ficarem mais caros, os requisitos de conformidade se tornarem mais rígidos e os dados não puderem ser vazados, os modelos de código aberto e os modelos locais se tornarão naturalmente mais atraentes. Mas depois de carregar o modelo sozinho, você também terá problemas: GPU, sala de inferência, roteamento, reversão, ajuste fino e seleção de modelo. Estas não são as capacidades do modelo em si, mas determinarão se o sistema será estável em última análise.

Tais custos são frequentemente subestimados. Muitas equipes inicialmente se concentraram em “se o modelo é mais forte”, mas depois descobriram que o que realmente consome tempo é a transferência estável de unidades de trabalho entre vários modelos. Quando usar um modelo grande, quando usar um modelo leve e quando simplesmente usar um modelo local, isso depende não da preferência verbal, mas de uma camada de superfície de controle que pode ser usada para desvio e encobrimento. Sem essa camada de coisas, a auto-hospedagem passará de “tomar a iniciativa” para “assumir você mesmo a complexidade da operação e manutenção”.

Simon Willison mencionou deixar modelos mais fortes escolherem modelos menores para fazer o trabalho. Essa ideia também é muito semelhante ao que o plano de controle está fazendo. O modelo em si não conhece necessariamente os limites de custos da equipe, mas o sistema conhece. Tratar o modelo como um intermediário e utilizá-lo para alocar tarefas está mais próximo da entrega real do que perseguir cegamente um modelo único para entrega com tudo incluído.

Aceitação e metas não podem ser terceirizadas

“Bring me a Rock” de Sam Ruby trouxe outra questão à luz. Entregar o trabalho ao modelo equivale a adicionar um executor; a responsabilidade não desaparece. Os gerentes podem usar o LLM para exploração e podem deixar que ele apresente um monte de soluções candidatas primeiro, mas os critérios finais de aceitação ainda terão que cair em mãos humanas. Os objetivos ocultos são os mais problemáticos. Permissões, privacidade, ações destrutivas e vazamento de contexto muitas vezes não estão incluídos nos requisitos originais.

Portanto, os testes de conformidade costumam ser mais úteis do que as especificações. As especificações são boas para descrever “o que é necessário” e os testes são melhores para expor “o que não pode acontecer”. Isto é especialmente verdadeiro em sistemas Agentes. O modelo pode compensar muito bem os objetivos explícitos, mas os limites implícitos precisam ser verificados por meio de uma verificação mais rigorosa. Enquanto as condições de aceitação permanecerem em descrições vagas, quanto mais o Agente fizer, mais parecerá que o sistema está apostando na probabilidade.

Portanto, a revisão de código, o tratamento de incidentes e a atribuição de tarefas, que costumavam ser tarefas muito humanas, estão agora começando a assumir outras formas. Os gerentes usam o modelo diretamente. Superficialmente, parece estar a melhorar a eficiência, mas, no nível mais básico, estão na verdade a mudar um método de gestão: de métodos de gestão para gestão de objectivos. Se o objetivo estiver claramente escrito, o modelo terá chance de funcionar; se o objetivo não for claro, o modelo apenas ampliará a ambiguidade para outros.

A experiência e as habilidades de leitura ainda estão melhorando

A experiência interacional e a experiência contributiva mencionadas por Dan Davies também são muito relevantes para esta mudança. O modelo pode ler muitos materiais e fazer um julgamento decente, mas para que o sistema seja estável, ainda é necessário que haja alguém que possa ler as especificações, ver os resultados e saber o que está errado. A chave aqui não é que as pessoas devam competir com o modelo para ver quem é mais inteligente, mas que as pessoas devam continuar numa posição que defina os limites.

Esse assunto é mais direto quando se trata de entrega de software. Depois que o Agente assumir o controle, o trabalho humano recairá menos na execução manual e mais na segmentação de tarefas, definição de limites, design de aceitação e tratamento de exceções. Se as tarefas podem ser entregues determina claramente se vale a pena fazer o gerenciamento de contexto subsequente, o roteamento de modelo e a orquestração de ferramentas. Se a unidade não estiver clara, não importa quantas camadas existam, isso apenas atrasará o problema.

Depois de ler esses fragmentos nos últimos dias, o que permanece em minha mente não é um nome de modelo específico, nem uma nova estrutura, mas um julgamento mais simples: a primeira coisa que o sistema Agente precisa reforçar não é a capacidade do modelo, mas a unidade de trabalho. Se a unidade for menor, a aceitação for mais rigorosa e as permissões mais restritas, o sistema terá a oportunidade de manter a complexidade dentro de uma faixa controlável.