No último ano, a conversa sobre engenharia agentiva migrou para arreios e loops, frotas e fábricas de software. Minha opinião é que os engenheiros precisam assumir o controle do loop externo — a responsabilidade por esses sistemas. Isso só se torna mais verdadeiro à medida que modelos poderosos como Fable e GPT-5.6 se tornam disponíveis.
Agentes têm alavancagem, e alavancagem cria obrigações. Alguém precisa ser capaz de explicar exatamente o que mudou, por que era seguro e o que acontecerá se estiver errado. Caso contrário, suas ações não podem ser justificadas. O que torna improvável que sua organização as solicite em primeiro lugar.
E então quero falar sobre três termos. O primeiro, Qualidade, refere-se a todas as verificações que instalamos antes de liberar o sistema. Essas verificações produzem evidências, e a partir dessas evidências derivamos um Veredito.
O segundo, Veredito, refere-se à decisão final que tomamos antes de o trabalho entrar em nosso sistema dependente: sou o produtor da linha deste conteúdo. Eu comando a equipe cujo trabalho é enviado sob meu nome. O modelo pode escrever a linha, mas o Veredito é meu. O trabalho da minha equipe não entrará em nossos sistemas dependentes sem minha decisão. Um Veredito é a decisão de produção: devemos enviar, bloquear, redirecionar, restringir a resposta, adicionar uma salvaguarda ou rejeitar completamente?
O terceiro, Responsabilidade Explicativa, refere-se à garantia de que, se alguém perguntar, posso explicar o porquê.
Para dizer de outra forma: nosso agente (que defino como um modelo mais um arreio de arquivos, ferramentas, memória, habilidades, sandboxes, permissões, observabilidade e recuperação) é o que executa nosso loop (que defino como investigação, implementação, verificação e repetição). E é o que cria nossa fábrica de software.
O modelo é apenas o motor. O arreio — ferramentas, memória, permissões, sandboxes, testes — é o carro que você constrói ao redor dele para que ele possa fazer trabalho real com segurança.
Envolva esse arreio em um ciclo repetível: investigue, implemente, verifique, repita. O loop é como uma boa execução se torna um processo em que você pode confiar para repetir. Envolva esse arreio em um ciclo repetível — investigue, implemente, verifique, repita — onde uma verificação independente, e não a própria palavra do modelo, decide quando o trabalho está concluído.
Agora execute muitos loops de uma só vez. Uma fábrica são loops em escala — os agentes enviam o trabalho internamente, enquanto os humanos tomam as decisões na fronteira.
E no coração dessa fábrica está uma fronteira cuidadosa entre o que está dentro do sistema e o que está fora dele. Dentro do sistema: coletamos entradas (da intenção da equipe de produto, ou do conhecimento de trabalhos já enviados, ou de incidentes recentes, ou de feedback específico de usuários). O loop do agente investiga a tarefa, implementa um plano e verifica o resultado. Então, as evidências cruzam essa fronteira. Um humano, que é dono do sistema dependente, vê as evidências e decide se deve prosseguir.
E essa, amigos, é a mudança que estamos tentando fazer. Antes, nossos agentes estavam fazendo o loop interno do loop de execução. Agora eles executam o loop de execução interno. Engenheiros assumem o controle do loop externo.
Dentro do sistema, há realmente apenas um tipo de coisa que nossos agentes estão fazendo: capacidade. A capacidade de investigar tarefas, implementar planos, testar seus resultados e relatar. Essa é a capacidade de um modelo. E, como dissemos, esse futuro já está aqui.
Fora do sistema, há um único tipo de coisa: agência. A agência para decidir, verificar, aprovar e assumir a responsabilidade.
Ainda estamos falando de código, veja bem. Ele só precisa viver em um lugar e ser executado por pessoas que sabem o que estão fazendo.
O potencial para código de IA não é mais marginal. Em uma pesquisa da Sonar de 2026, perguntamos às equipes sobre a parcela de seus commits que eram assistidos por IA. Era pequena, mas não trivial. E vários dos entrevistados disseram que esperam que a parcela de commits assistidos por IA cresça substancialmente. O Relatório State of Code 2026 da Sonar descobriu que 42% do código commitado foi gerado por IA ou significativamente assistido por IA, com expectativas de que essa parcela continue crescendo, em vez de se estabilizar.
Criação, em outras palavras, está ficando mais barata. Recursos mais escassos são revisão, validação, compreensão e manutenção.
Aceleramos a velocidade de geração mais do que a velocidade de controle. E, portanto, temos uma lacuna de confiança-verificação. Muitas pessoas com quem conversamos ainda expressam algum grau de desconfiança em relação ao código de IA. No entanto, menos delas parecem construir consistentemente essa desconfiança em seus processos de verificação.
E esse é um lugar perigoso para se estar. Vamos precisar de maneiras mais baratas e claras de verificar a confiabilidade do código de IA.
Se você olhar o relatório de junho de 2026 do GitLab, verá que as questões de governança mudaram. A pesquisa de responsabilidade de IA de junho de 2026 do GitLab mostra que revisão e validação são os gargalos atuais ao usar IA e, mais preocupante, que a governança geralmente acontece após a criação do código, depois que aceitamos o risco e perdemos o controle sobre a propriedade. Hoje, não se trata apenas de controle. Trata-se de quais restrições definimos no sistema. Trata-se de como verificaremos o trabalho com evidências e como responsabilizaremos as equipes. Trata-se de quem será o dono de qual parte do ciclo de vida da IA.
Portanto, a distinção final nesta série é entre processo e qualidade. Qualidade é o conceito de contrapressão. Queremos dizer isso literalmente. Não queremos conceder aos nossos agentes tanta autonomia quanto eles possam exercer. Queremos conceder a eles autonomia suficiente para que tenhamos contrapressão suficiente para detê-los, regulá-los, verificar seu trabalho e garantir nossa humanidade.
A engenharia comum sustenta muitos sinais que indicam que o trabalho que está sendo feito está fazendo a coisa certa. Verificações de tipo, testes, hooks, limites de sandbox, logs de auditoria, monitores. Nossos sistemas de engenharia estão cheios desses tipos de sinais, e eles são projetados para fornecer contrapressão suficiente para manter o sistema honesto.
E, portanto, enquanto nossos agentes estiverem emitindo esses mesmos sinais, podemos confiar que nossa engenharia comum fornecerá a contrapressão apropriada.
Confiar em nossos sistemas não significa que não queremos um humano no loop. Significa apenas que o humano não precisa estar no loop interno. Queremos que eles estejam no loop de restrições (quais entradas, arquiteturas, instruções ou invariantes devemos definir?), no loop de amostragem (quanta saída devemos amostrar e revisar?), no loop de auditoria (quais evidências devemos manter e como garantir que nosso log de auditoria seja eficaz?), e no loop de propriedade (qual parte da fronteira de produção devemos possuir).
Mas o humano não precisa estar no loop interno.
O agente pode enviar mais do que você pode revisar.
E o recurso escasso é o seu próprio julgamento humano central, informado por sinais de qualidade como logs ou testes.
O relatório de IA de junho de 2026 mostra que, no ambiente experimental, a delegação agentiva em horizontes de tempo de horas já é essencialmente uma realidade. O trabalho da OpenAI este ano sobre agentes e o futuro do trabalho foi uma grande fonte para essas ideias. Portanto, precisamos começar a pensar em como estabelecer essa fronteira de propriedade, à medida que nossos sistemas começam a enviar mais do que podemos revisar.
E é aí que entra a responsabilidade explicativa.
Porque com agentes de longo horizonte, as decisões tomadas em escalas de tempo de horas são exatamente isso — decisões. E nem todas as decisões serão registradas. Você não pode rastrear todas elas até os tokens de entrada. Se tudo o que você está fazendo é confiar que a saída que você obtém é a escolha correta para o problema em questão, as centenas ou mesmo milhares de horas de trabalho humano que você precisará para reconstruir a cadeia de decisões que a levaram se tornam impossíveis. E, portanto, novamente, a responsabilidade explicativa se torna algo que deve estar no centro do design do nosso sistema.
Três custos ocultos
E há três custos ocultos:
Rendição cognitiva ~ aceitar cegamente o que a IA lhe dá. Quando você delega trabalho a um agente, o trabalho em si pode parecer ser o trabalho do agente. Mas é, na verdade, seu trabalho. É sua reputação. É sua responsabilidade. E é o seu software que sofreu os defeitos na saída. E é o seu software que precisa ser alterado para refletir essa saída. Portanto, a saída do agente se torna sua resposta. E com ela vem toda a responsabilidade. O estudo da Wharton que reuniu isso é reconfortante quando a IA está certa. Mas quando está errada, a notícia não é boa. Quando a IA estava errada, quase três quartos das pessoas a aceitaram mesmo assim e se sentiram mais confiantes do que se sentiriam sem a IA.
Dívida cognitiva ~ erosão da sua compreensão e memória de como resolver problemas. Quando você delega trabalho a um agente, está transferindo todo o trabalho de pensamento para o agente. E enquanto pensar tudo sozinho leva tempo e energia, pensar em uma base de código massiva consome recursos que não estão disponíveis quando você está tentando subir na curva de aprendizado. Portanto, a saída que você obtém é muitas vezes inatingível por você. E quanto maior o horizonte de tempo do planejamento agentivo, maior se torna a lacuna entre o código que o agente produz e sua compreensão dele. A lacuna se acumula. A dívida se acumula. E o custo de subir na curva de aprendizado cresce quase exponencialmente. Há um ensaio clínico randomizado da Anthropic analisando se engenheiros que dependem de IA para escrever código o entendem tão bem quanto engenheiros que o escrevem sozinhos. A conclusão foi sombria: em um teste de compreensão, os engenheiros que trabalharam com IA pontuaram dezessete pontos percentuais a menos do que aqueles que não usaram, 50% contra 67%.
E então há o imposto de orquestração ~ é fácil criar muitos agentes agora, mas sua largura de banda cognitiva não paraleliza da mesma forma. Orientar seu agente para longe dos piores comportamentos, classificar o trabalho que o agente produz para identificar aqueles que precisam de sua atenção, direcioná-lo para focar primeiro no trabalho que você considera importante, verificar suas restrições mais importantes e suas suposições mais perigosas antes de deixá-lo executar…
Tudo isso dá trabalho e não pode ser automatizado.
Não há substituto para o julgamento humano.
Sistemas brownfield são especialmente perigosos aqui, porque o comportamento do sistema que você precisa auditar não vive no código. Vive nas cicatrizes.
Soluções? Torne a atenção a prioridade em suas decisões arquiteturais. Use worktrees, escopos e evidências para reduzir o acoplamento entre seu plano inicial e o trabalho que emerge dele. Defina um limite de tempo para resolver etapas não acionáveis. E torne a mudança no seu software estritamente uma permissão opt-in.
Alfa, decadência e bom gosto: esses são os três padrões centrais que moldam carreiras e performances em todos os domínios.
Alfa é a parte de liderança assumida pelo maior realizador na competição, quando você está jogando seu movimento de maior valor. Decadências são padrões estabelecidos que todos aprendem através da repetição e observação dos outros (platôs, se preferir). Bom gosto é o mais cedo que podemos sentir a liderança em um alfa ou a mudança em uma decadência. É nosso julgamento do que está por vir antes de termos qualquer evidência de que algo está acontecendo. O ponto de Paul Graham é que quando qualquer um pode fazer qualquer coisa, escolher o que fazer importa mais, e a definição de Mitchell Hashimoto é a operacional: fazer julgamentos qualitativos de alta qualidade onde nenhuma métrica objetiva existe ainda. De agora em diante, o bom gosto impulsiona tudo: mudanças alfa são mudanças de bom gosto. E as decadências desaparecem porque começamos a sentir algo diferente.
Próximo passo? Operacionalize seu bom gosto. Como? Dê a ele um nome que reflita o que você está tentando mover do límbico para o consciente. Pratique-o na crítica e em exemplos. Torne sua lógica explícita.
E continue fazendo o movimento que oferece a vantagem competitiva mais durável em sua indústria. O que é isso? Continue movendo a fronteira para cima, de apenas fazer a tarefa para ensiná-la, sistematizá-la, decidir quando ela deve ser feita e assumir a responsabilidade pelo resultado.
Todos são desenvolvedores, mas nem todos são engenheiros. Engenharia é o que um desenvolvedor se torna quando abraça uma disciplina de trabalho mais rigorosa: raciocínio completo e logicamente sólido, consideração de restrições e trade-offs, reconhecimento de risco e exposição, e responsabilidade prática.
No futuro, as pessoas deixarão o trabalho administrativo da engenharia e abraçarão novos papéis que surgem à medida que a engenharia se torna mais exigente. Papéis que são desagregados do espírito do ofício, mas que deixam claro o que cada pessoa faz. Haverá aqueles que prototipam. Aqueles que constroem. Aqueles que varrem. Aqueles que fazem crescer. Aqueles que mantêm.
Os humanos seguram a fronteira do sistema na outra direção também. Aumentando o alfa na outra direção: escolher o que vale a pena fazer, definir as restrições dentro das quais deve ser feito, decidir se as evidências são suficientes para prosseguir e cuidar do resultado. Seja uma única equipe ou cem equipes, esta é a fronteira que apenas os humanos podem segurar.
A responsabilidade escalará a fábrica. Como atenção e bom gosto, a responsabilidade também é uma das três dualidades que fazem tudo funcionar. Sem responsabilidade, não há regras. Sem discussão com questionadores. Sem trade-offs. Sem riscos. Sem redes de segurança. Se ninguém for dono da consequência de uma decisão, então a alta agência só pode trazer caos.
A meia-vida de uma fronteira é um lançamento, mas a meia-vida de uma assinatura é uma carreira. Uma assinatura é seu nome no trabalho, de modo que você sinta que pode defender o que foi enviado. Habilidades lhe dão alavancagem; responsabilidade transforma alavancagem em confiança.
Apenas pessoas podem escolher. Apenas pessoas herdam consequências. Agentes podem ser solicitados a escolher, rotear, mesclar e escalar com segurança dentro de uma política, mas não podem herdar as consequências.
Talvez toda base de código deva vir com algum tipo de contrato de responsabilidade que declare explicitamente a lista de verificação que foi compreendida quando a mudança foi aceita, as evidências que entraram na decisão, quem era responsável pela mudança e o status do sistema após a mudança ser bloqueada. Assim como:
- Sua atenção e bom gosto
- Suas evidências, veredito e propriedade
- Seu alfa, decadência e bom gosto
Alta agência
Em um fluxo de trabalho agentivo típico, alta agência é a arte de saber quando delegar, quando inspecionar, quando parar e quando assumir a responsabilidade pelo resultado de um processo. A escada da agência vai de baixa a alta: sinalizar um problema potencial, investigá-lo, executar contra ele, diagnosticá-lo, propor soluções, recomendar correções e resolver o problema. Um degrau alto na escada da agência é discernimento: encontrei, não vale a pena consertar, seguindo em frente.
Os doze pilares que sustentam a fábrica de software
Brownfield é a fronteira para fábricas que esperam escalar. Todas aquelas pequenas inovações inteligentes podem não parecer muito ainda, mas o ambiente de produção é muito. Ao construir um sistema totalmente novo, é muito mais fácil planejar e implementar mecanismos de contrapressão suficientes porque você tem controle total. No entanto, ao adicionar agentes inteligentes a um sistema legado, é uma questão completamente diferente.
Sistemas legados incluem a totalidade do comportamento de produção, expectativas futuras dos clientes, históricos de migração, durações de ciclos de lançamento e orçamento, suposições não ditas, casos extremos, estranhezas de dados, procedimentos de runbook e todas as cicatrizes que se acumularam sem a vontade de cuidar do sistema.
Ser um administrador de brownfield requer uma forma de engenharia durável. O trabalho precisa ser feito para transformar conhecimento implícito em restrições explícitas, mantê-lo coerente entre equipes e através de gerações, formalizar esse conhecimento em procedimentos de teste e especificações funcionais, e amarrar esse conhecimento a evidências objetivas. Tudo isso enquanto se transforma falhas em mais aprendizado. Porque se o sistema não receber o cuidado que sempre recebeu, tudo desabará.
Novo Trabalho é Trabalho Real
O trabalho se tornará mais interessante à medida que você escala. Porque quando tudo o mais estiver construído, as pessoas vão querer construir coisas novas. Elas vão querer empregar o alfa e o bom gosto que desenvolveram através de seu ofício para projetar novos loops que possam ser enxertados na fábrica de software. Ou vão querer construir sistemas greenfield que empreguem todo o conhecimento da fábrica de software em um esforço elegante, bem-intencionado e baseado em princípios. Elas vão querer projetar e implementar novas formas de evidência que se elevem ao nível de verificação para os novos sistemas. Elas vão querer cuidar de sistemas brownfield que agora são tão complexos que precisam de atenção dedicada. Elas vão querer projetar e gerenciar novos mecanismos de contrapressão. Elas vão querer projetar novos agentes. E elas vão querer construir agência.
E, ao fazerem isso, elas perceberão que tudo isso é trabalho real. Isso é uma coisa boa.
A automação cria gargalos. Gargalos na produção que valem a pena possuir. Porque a automação nos dá controle sobre a escala industrial. Mas também surgem novos gargalos da escala industrial. O gargalo muda de "podemos construir isso?" para "isso deveria existir, podemos responder por isso?"
O que estou sugerindo é um modelo operacional prático para escalar a engenharia agentiva. Existem loops internos e externos. O loop interno é onde o trabalho é feito. Os loops são projetados para serem tão independentes quanto possível. Coloque todas as garantias de qualidade e verificação dentro do loop. Uma vez que você tenha projetado e validado o próprio loop, a única coisa que resta a fazer é conceder autonomia colocando em prática um mecanismo de contrapressão que atue para controlar a taxa na qual o loop é executado e seu escopo de operação. E coloque os humanos em seu devido lugar, nas decisões certas. Não trate a compreensão como uma transferência ou um portão de liberação, mas sim como um ponto de decisão onde os humanos são preparados para fornecer sua percepção. E então, para cada artefato que existe e é realimentado na produção e em novas equipes e engenheiros, deixe artefatos melhores para trás.
Construa a fábrica; mantenha as luzes acesas; torne o trabalho legível, verificável e de propriedade definida.
Um agente pode escrever. Mas antes que chegue aos usuários, alguém deve explicar por que deveria existir, por que é seguro o suficiente para fazer parte da produção e o que fará quando estiver errado.
Isso é engenharia agentiva no loop externo — esse é o trabalho agora.
Pangram classificou este artigo como 100% escrito por humanos: https://www.pangram.com/history/ae6caccc-b70f-4336-a019-5c3411516871
