Os agentes de codificação em segundo plano e de longa duração atingiram um novo limite. Quando um agente funciona por horas, gerencia seu próprio loop de iteração e envia uma solicitação pull sem ajuda, ele deixa de ser uma ferramenta que você invoca e passa a ser mais como um trabalhador ao qual você atribui tarefas. Como qualquer trabalhador, a questão não é até que ponto você os supervisiona. É o trabalho que você atribui a eles em primeiro lugar.
Estamos todos descobrindo isso em tempo real e vejo muitas equipes cometendo um erro compreensível, mas crítico. Eles ajustam o dial de autonomia, adicionando mais pontos de verificação de revisão ou removendo-os, quando a variável real que importa é quais categorias de trabalho os agentes devem possuir versus quais categorias os desenvolvedores devem possuir. Essa distinção não tem a ver com tolerância ao risco. Trata-se de limites de capacidade.
Escrever código e engenharia de software não são o mesmo trabalho
Escrever código é reconhecer padrões. Pegue o que foi feito antes, aplique-o a um novo contexto e desenvolva-o. Grandes modelos de linguagem são excepcionais nisso porque é exatamente isso que fazem: reconhecer e reproduzir padrões de grandes corpora de trabalhos anteriores.
Engenharia de software é outra coisa. São compensações. Restrições. Decisões que exigem contexto ao qual nenhum modelo tem acesso: seu domínio de negócios, sua estratégia de produto, seus clientes, sua dívida técnica, a conversa que sua equipe teve na semana passada sobre por que você escolheu uma abordagem em vez de outra.
A maioria das equipes se divide quanto à importância ou tolerância ao risco. A verdadeira divisão está entre o trabalho que pode ser fundamentado a partir de padrões anteriores e o trabalho que requer contexto, estratégia e julgamento que vive fora da base de código.
O que os desenvolvedores realmente possuem
O trabalho que realmente exige desenvolvedores é mais específico do que “qualquer coisa importante”, mas não se reduz a uma lista organizada de tipos de tarefas. Ele atravessa todas as partes do processo de engenharia.
“Os agentes podem ler o código. Eles não podem ler a sala.”
Os desenvolvedores são os donos do trabalho onde a resposta certa depende do contexto que não existe na base de código. Estratégia de produto, restrições de negócios, dinâmica de equipe, conversas em threads do Slack e revisões de arquitetura fazem parte da história de por que um sistema é construído do jeito que é. Os agentes podem ler o código. Eles não podem ler a sala.
Os desenvolvedores são donos do trabalho onde o perfil de risco é ambíguo ou os modos de falha são difíceis de prever. Algumas mudanças ocorrem em cascata de maneiras que dependem dos limites organizacionais, do tempo de implantação ou dos contratos de dados incorporados a um sistema ao longo de anos de iteração. Avaliar a correção nesses casos requer um julgamento que nenhum modelo pode conduzir apenas com base no código. Quanto maior a incerteza, mais você precisa de alguém que entenda não apenas o que o código faz, mas por que foi escrito dessa forma.
Os desenvolvedores são donos do trabalho onde o resultado é uma decisão, não um artefato: o que construir, o que cortar e quais apostas técnicas fazer daqui a seis meses. Os agentes podem gerar opções. Eles não podem dizer qual opção é a certa para a sua situação porque “certa” depende de fatores que residem nas cabeças humanas e nos contextos organizacionais, e não nos dados de treinamento.
E tudo isso ainda está evoluindo. À medida que as equipes investem em tornar o contexto mais explícito por meio de melhor documentação, contratos mais claros e registros de decisões mais estruturados, os limites mudam. O trabalho que antes exigia o conhecimento institucional de um desenvolvedor torna-se acessível a um agente. Mas a fronteira do trabalho não estruturado e de alto julgamento também continua se movendo, e é aí que o tempo do desenvolvedor é mais valioso.
Em sistemas distribuídos, esse problema piora. Quanto mais serviços você distribui por diversas equipes e bases de código, mais esse contexto crítico fica fora de qualquer base de código única. Uma mudança no esquema de eventos de um serviço pode quebrar os consumidores downstream de uma forma que nenhum teste no próprio conjunto desse serviço conseguirá detectar.
Além disso: o agente não sabe o que não sabe. O desenvolvedor dessa equipe faz isso – não porque escreveu o código – mas porque estava na reunião em que o esquema foi acordado. Para equipes nativas da nuvem, isso não é muito escalonável: quanto mais serviços, mais contratos implícitos e mais contexto que apenas as pessoas carregam.
Onde os agentes entregam mais valor
Há uma montanha de trabalho em cada base de código que é um desperdício de capacidade intelectual humana. Boilerplate, scaffolding, refatoradores repetitivos, geração de testes unitários, modelos de configuração e formatação de dados. Este trabalho é mecânico, mecânico e pode ser fundamentado inteiramente a partir de padrões anteriores. Os agentes deveriam possuí-lo.
Depois que um desenvolvedor especifica a interface, o contrato e o comportamento esperado, um agente pode implementar de forma mais rápida e consistente do que um desenvolvedor. A implementação é a parte repetível. O raciocínio que o precede não é.
“Os desenvolvedores que prosperarem neste modelo não serão aqueles que escreverão a maior parte do código. Serão aqueles que tomarão as melhores decisões.”
A velocidade da iteração também é importante aqui. Gerar múltiplas implementações, executar suítes de testes, verificar a conformidade do contrato: os agentes fazem isso em um ritmo que nenhum desenvolvedor consegue igualar. Relatório sobre o estado da entrega de software da Circle CI descobriram que os gargalos de rendimento aparecem mais comumente no ciclo de feedback e validação, não na fase de escrita do código. Os agentes compactam esse ciclo significativamente quando os critérios de aceitação são claros e eles têm acesso ao ambiente de tempo de execução e às ferramentas necessárias para validar seu trabalho.
Os desenvolvedores que prosperarem nesse modelo não serão os que escreverão mais código. Serão eles que tomarão as melhores decisões sobre o que construir e como arquitetá-lo e, em seguida, entregarão a execução a agentes que podem se mover mais rápido do que qualquer ser humano.
Um modelo de três níveis para dividir o trabalho
Em nossa equipe, achamos útil implementar uma estrutura aproximada para agrupar categorias de trabalho de engenharia para tomar decisões sobre como ele é distribuído entre agentes e desenvolvedores.
Camada 1: liderada pelo agente e revisada pelo desenvolvedor
Tarefas em que a execução do agente é de alta confiança e a saída é autoverificável. Geração padrão, modelos de configuração, adição de endpoints dentro de padrões estabelecidos, execução e relatórios sobre suítes de testes e estruturação de novos serviços ou módulos a partir de convenções existentes. O desenvolvedor analisa a saída, mas o agente é o dono do trabalho.
Encaminhar isso para desenvolvedores desperdiça seu recurso mais caro. Esta categoria deve se expandir à medida que as equipes melhoram em tornar seus padrões explícitos e testáveis.
Nível 2: assistido por agente e guiado pelo desenvolvedor
Tarefas que requerem contexto além da base de código para serem validadas. O agente implementa, mas o desenvolvedor define o escopo, as restrições e os critérios de sucesso. O trabalho de recursos dentro de um domínio bem compreendido, a refatoração dentro dos limites estabelecidos e a implementação de testes para estratégias definidas pelo desenvolvedor se enquadram aqui.
O desenvolvedor fornece o julgamento de engenharia. O agente fornece o rendimento da implementação. A maior parte do trabalho de recursos, em qualquer arquitetura, se enquadra nesse nível.
Nível 3: liderado pelo desenvolvedor e apoiado pelo agente
Tarefas em que o trabalho principal é o julgamento e não a implementação. Decisões arquitetônicas, alterações contratuais transfronteiriças, depuração de falhas emergentes e definição do que construir em seguida. Os agentes podem ajudar nas subtarefas: elaboração de propostas, análise de logs e geração de implementações candidatas para avaliação. Mas um desenvolvedor deve conduzir porque o trabalho em si é raciocínio, não execução de padrões.
A distinção do Nível 2 é que o desenvolvedor não está apenas validando a saída. Eles estão fazendo um trabalho intelectual que nenhuma quantidade de dados de treinamento pode substituir.
O custo de errar na divisão
A maioria das equipes com quem converso está subalocando ou superalocando trabalho aos agentes. Ambos são erros caros.
A superalocação é a falha mais visível. Empurre os agentes para o trabalho de Nível 3 e eles produzirão resultados que exigirão retrabalho significativo porque o contexto necessário não estava disponível para eles. O custo de retrabalho é real, mas o custo de oportunidade é pior: os desenvolvedores que deveriam estar fazendo trabalho de Nível 3 estão revisando e corrigindo a produção do agente que não deveria ter sido delegada em primeiro lugar.
A subalocação é mais silenciosa, mas igualmente prejudicial. As equipes que adotam como padrão o trabalho de propriedade do desenvolvedor porque o resultado do agente parece incerto estão pagando taxas de desenvolvedor pelas tarefas de Nível 1. O tempo do desenvolvedor é o recurso de maior custo na equipe. Queimá-lo no trabalho de execução de padrões que os agentes poderiam realizar é um lento obstáculo à velocidade que aumenta ao longo dos meses.
É por isso que muitas equipes que adotam fluxos de trabalho de agentes veem ganhos limitados ou até mesmo pequenas reduções no rendimento do código mesclado. Eles não resolveram o problema de alocação. Eles adicionaram uma nova ferramenta sem alterar a forma como o trabalho é distribuído.
Audite o trabalho, não apenas os agentes
A questão não é se os agentes substituem os desenvolvedores. É assim que se parece o modelo de engenharia certo quando os agentes cuidam do trabalho mecânico e os humanos se concentram no trabalho estratégico.
As equipes que navegam bem nisso não auditam apenas seus agentes. Eles auditam seu trabalho. Eles perguntam quais tarefas poderiam ser lideradas pelos agentes se os limites fossem explicitados e, em seguida, investem em tornar esses limites explícitos. Esse investimento devolve o tempo do desenvolvedor ao trabalho de alto julgamento e dependente do contexto que os agentes não dominarão tão cedo.
A resposta não virá dos laboratórios de IA. Virá de equipes de engenharia que realmente constroem software dessa maneira todos os dias, descobrindo onde está o limite por meio da prática e aprendendo o que sua base de código, equipe e domínio específicos exigem em cada lado da divisão.
YOUTUBE.COM/THENEWSTACK
A tecnologia avança rápido, não perca um episódio. Inscreva-se em nosso canal no YouTube para transmitir todos os nossos podcasts, entrevistas, demonstrações e muito mais.
ASSINAR
Deseja saber mais sobre Programação e Desenvolvimento Clique Aqui!
signadot,pós-contribuição