7 pontos por GN⁺ 3 시간 전 | Ainda não há comentários. | Compartilhar no WhatsApp
  • Mesmo que os agentes assumam o loop interno de execução — repetindo investigação, implementação e verificação — os engenheiros devem assumir o loop externo, decidindo se algo será implantado e se responsabilizando pelo resultado
  • Sistemas de agentes operam com base em Qualidade (Quality), que significa verificações prévias; Veredito (Verdict), que decide se algo entra em produção; e Responsabilidade de explicação (Answerability), que permite explicar por que a decisão foi tomada
  • A pesquisa da Sonar de 2026 mostrou que 42% do código comitado foi gerado por IA ou recebeu assistência substancial de IA, e, à medida que a velocidade de geração ultrapassa a velocidade de controle, revisão, verificação, compreensão e manutenção tornam-se recursos escassos
  • O uso de IA traz rendição cognitiva, que é aceitar respostas erradas sem questionar; dívida cognitiva, que enfraquece a compreensão do código; e o custo de orquestração de ter de gerenciar vários agentes com atenção humana limitada
  • Uma fábrica de software escalável não dá aos agentes autonomia máxima, mas sim autonomia que pode ser interrompida, regulada e verificada, e só funciona quando humanos assumem restrições, revisão por amostragem, auditoria, propriedade e o resultado final

O loop externo da engenharia agentiva

  • A discussão sobre engenharia agentiva está migrando para harnesses de agentes e loops, frotas e fábricas de software
  • Quanto mais surgem modelos poderosos como Fable e GPT-5.6, mais os engenheiros precisam assumir diretamente o loop externo, isto é, a responsabilidade sobre o sistema
  • A alta alavancagem dos agentes cria obrigações proporcionais
    • É preciso conseguir explicar com precisão o que mudou
    • É preciso explicar por que essa mudança foi segura
    • É preciso saber o que acontece se o julgamento estiver errado
  • Sem cumprir essas condições, não é possível justificar o comportamento do agente, e a organização também terá dificuldade para usar esse tipo de sistema

Qualidade, veredito e responsabilidade de explicação

  • Qualidade (Quality) significa todas as verificações instaladas antes de soltar o sistema, e as evidências obtidas aí formam a base do veredito
  • Veredito (Verdict) é a decisão final de produção tomada por uma pessoa antes que o trabalho entre em um sistema dependente
    • Mesmo que o modelo escreva o código, a responsabilidade pelo veredito é de quem implanta o trabalho em seu próprio nome
    • A decisão pode ser implantar, bloquear, redirecionar, reduzir o escopo da resposta, adicionar guardrails ou rejeitar completamente
  • Responsabilidade de explicação (Answerability) é a garantia de que, se alguém perguntar o motivo, esse julgamento poderá ser explicado
  • O modelo pode escrever uma linha de código, mas não substitui a responsabilidade de decidir se aquilo deve ou não seguir para um sistema dependente

Modelo, harness, loop e fábrica

  • Um agente não é só um modelo, mas também o harness que combina arquivos, ferramentas, memória, habilidade, sandbox, permissões, observabilidade e capacidades de recuperação
  • Se o modelo é o motor, o harness é o carro construído ao redor dele para que o trabalho real seja feito com segurança
    • Ferramentas e memória fornecem capacidade de execução
    • Permissões e sandbox limitam o escopo de execução
    • Testes e observabilidade permitem verificar o resultado do trabalho
  • O loop de execução do agente é composto de investigar → implementar → verificar → repetir
    • Um ciclo repetível transforma um sucesso isolado em um processo confiável
    • A conclusão da tarefa deve ser determinada por verificações independentes, não pelo julgamento do próprio modelo
  • Quando vários loops operam ao mesmo tempo, isso vira uma fábrica de software
    • No interior, os agentes produzem trabalho
    • Na fronteira, os humanos assumem a decisão de produção

A fronteira que separa o dentro e o fora do sistema

  • No centro da fábrica de software existe uma fronteira que separa o interior e o exterior do sistema
  • O sistema interno coleta como entradas a intenção da equipe de produto, conhecimento sobre implantações passadas, incidentes recentes e feedback específico de usuários
  • O loop do agente investiga o trabalho, implementa o plano e depois verifica o resultado
  • Quando a evidência gerada pela verificação cruza a fronteira do sistema, o humano dono do sistema dependente decide se aquilo deve prosseguir
  • Antes, os agentes executavam apenas parte do processo; agora assumem todo o loop interno de execução, enquanto o engenheiro cuida do loop externo
  • O que o agente oferece dentro da fronteira é capacidade (capability)
    • Investigar o trabalho
    • Implementar o plano
    • Testar o resultado
    • Relatar o resultado
  • O que o humano exerce fora da fronteira é agência (agency)
    • Decidir
    • Verificar
    • Aprovar
    • Assumir a propriedade

A lacuna de confiança e verificação criada pelo código de IA

  • A participação do código de IA já não é mais periférica
  • Segundo o relatório 2026 State of Code da Sonar, 42% do código comitado foi gerado por IA ou recebeu assistência substancial de IA, e os respondentes esperam que essa participação continue crescendo
  • À medida que o custo de gerar código cai, revisão, verificação, compreensão e manutenção tornam-se recursos mais escassos
  • Como a velocidade de geração cresce mais rápido do que a velocidade de controle, surge uma lacuna de confiança e verificação
    • Muita gente desconfia do código de IA
    • Menos gente traduz essa desconfiança em procedimentos consistentes de verificação
  • É preciso uma forma mais barata e clara de confirmar a confiabilidade do código de IA

Os limites da governança posterior

  • Segundo a pesquisa de responsabilidade em IA de junho de 2026 da GitLab, o gargalo atual do uso de IA é revisão e verificação
  • A governança costuma ser aplicada principalmente depois que o código já foi criado
    • Nesse ponto, a organização já aceitou o risco
    • O controle sobre a propriedade do trabalho também já enfraqueceu
  • A governança de IA deve ir além do simples controle do sistema e definir
    • Que restrições serão impostas ao sistema
    • Com que evidências o trabalho será inspecionado
    • Como a equipe será responsabilizada
    • Quem será dono de cada parte do ciclo de vida da IA

A contrapressão que produz qualidade

  • Qualidade pode ser entendida como a contrapressão (back pressure) aplicada ao sistema
  • O objetivo não é dar aos agentes a maior autonomia possível
  • É preciso dar aos agentes apenas autonomia suficiente para poder interrompê-los, regulá-los, inspecionar o trabalho e preservar o papel humano
  • A engenharia tradicional já possui sinais que mostram se o trabalho está indo na direção correta
    • Verificação de tipos
    • Testes
    • Hooks
    • Limites de sandbox
    • Logs de auditoria
    • Monitores
  • Se os agentes emitirem os mesmos sinais, os sistemas de engenharia existentes poderão aplicar a contrapressão adequada

Quatro loops em que humanos precisam estar

  • Confiar no sistema não significa tirar os humanos do loop
  • Em vez do loop interno de execução, os humanos precisam estar nestes quatro loops externos de controle
    • Loop de restrições: decide quais entradas, arquiteturas, instruções e condições invariáveis serão definidas
    • Loop de revisão por amostragem: define quanto das saídas será extraído para revisão
    • Loop de auditoria: decide quais evidências serão preservadas e como garantir a validade dos logs de auditoria
    • Loop de propriedade: deixa claro quem é dono de qual parte da fronteira de produção
  • Os agentes podem gerar mais trabalho do que os humanos conseguem revisar
  • Por isso, o recurso escasso é o julgamento humano essencial, exercido com base em sinais de qualidade como logs e testes
  • O estudo da OpenAI sobre agentes e o futuro do trabalho mostra que, em ambientes experimentais, a delegação agentiva em escalas de horas já se tornou viável
  • É preciso estabelecer fronteiras de propriedade antes que o sistema produza mais trabalho do que a capacidade de revisão

Agentes de longa duração e responsabilidade de explicação

  • Todas as escolhas feitas por agentes de longa duração que operam por horas são decisões
  • Nem todas essas decisões ficam registradas, e não é possível rastrear cada uma delas até os tokens de entrada
  • Se apenas acreditarmos que o resultado foi a escolha certa para o problema, reconstruir a cadeia de decisões que levou até ele pode exigir centenas ou milhares de horas de trabalho humano
  • Como essa cadeia de decisões é, na prática, difícil de reconstruir, a responsabilidade de explicação precisa estar no centro do design do sistema

Os três custos ocultos da delegação à IA

  • Rendição cognitiva

    • Rendição cognitiva (cognitive surrender) é o fenômeno de aceitar cegamente o resultado produzido pela IA
    • Mesmo quando a tarefa é delegada ao agente, o resultado continua ligado ao trabalho, à reputação e à responsabilidade do usuário
    • O defeito continua no software do usuário
    • O software que precisa ser alterado para se adequar à saída também é o do usuário
    • A resposta do agente acaba se tornando a resposta do usuário, junto com a responsabilidade por ela
    • Em um estudo da Wharton, quase três quartos dos participantes aceitaram a resposta da IA mesmo quando ela estava errada, e demonstraram mais confiança do que quando julgaram sem IA
  • Dívida cognitiva

    • Dívida cognitiva (cognitive debt) é o enfraquecimento da compreensão e da memória sobre como resolver o problema
    • Ao delegar trabalho ao agente, o processo de pensamento também é externalizado
    • O tempo e a energia necessários para compreender por conta própria uma base de código grande podem ser difíceis de assegurar durante o processo de aprendizagem
    • Como resultado, o artefato produzido pelo agente pode atingir um nível que ultrapassa a capacidade atual do usuário
    • Quanto mais longo for o tempo de planejamento do agente, maior fica a distância entre o código gerado e a compreensão humana
    • Essa distância se acumula, e o custo de voltar a subir a curva de aprendizagem cresce quase exponencialmente
    • Em um ensaio clínico randomizado da Anthropic, engenheiros que escreveram código com IA tiveram 50% de acerto em um teste de compreensão, 17 pontos percentuais abaixo dos 67% do grupo que escreveu diretamente
  • Custo de orquestração

    • Custo de orquestração (orchestration tax) surge porque, embora muitos agentes possam ser executados ao mesmo tempo, a largura de banda cognitiva humana não se paraleliza da mesma forma
    • Os humanos ainda precisam executar diretamente as seguintes tarefas
      • Ajustar os agentes para evitar os piores comportamentos
      • Identificar, entre os artefatos gerados, o que exige atenção
      • Instruir os agentes a priorizar o que é importante
      • Verificar restrições essenciais e premissas arriscadas antes da execução
    • Esse trabalho não pode ser automatizado e não substitui o julgamento humano

Como proteger a atenção em brownfields

  • Sistemas brownfield são especialmente arriscados porque o comportamento que precisa ser auditado não existe só no código, mas também nas cicatrizes e na história acumuladas
  • Em decisões de arquitetura, a atenção humana deve ser priorizada
  • Usar worktree, escopo e evidência ajuda a reduzir o acoplamento entre o plano inicial e o trabalho que aparece durante a execução
  • Tentativas de resolver etapas que não podem ser executadas devem ter limite de tempo
  • A permissão para alterar software deve ser concedida por um modelo estrito de opt-in

Alpha, decay e taste

  • Três padrões fundamentais que moldam carreiras e desempenho em várias áreas são alpha, decay e taste
  • Alpha é a zona de liderança ocupada por quem obtém o melhor desempenho em uma competição, ou o estado de fazer o lance de maior valor
  • Decay é o padrão estabelecido que todos acabam aprendendo por repetição e observação, uma espécie de zona de estagnação
  • Taste é o julgamento que detecta a liderança do alpha ou a mudança do decay antes que a evidência apareça
  • A discussão de Paul Graham é que, quando qualquer pessoa pode construir qualquer coisa, torna-se mais importante escolher o que construir
  • Na definição de Mitchell Hashimoto, taste é um julgamento qualitativo de alta qualidade feito quando ainda não existe um critério objetivo de medição
  • O deslocamento do alpha ocorre por mudanças em taste, e o decay desaparece quando as pessoas começam a preferir outra coisa

Tornando taste uma capacidade operacional

  • Para tirar o taste do campo da intuição e levá-lo a uma capacidade consciente, primeiro é preciso dar nome a ele
  • Esse julgamento deve ser praticado por meio de crítica e de casos concretos
  • Também é necessário expressar explicitamente a base desse julgamento
  • Para aumentar a vantagem competitiva sustentável, é preciso mover continuamente a fronteira do papel para cima
    • Executar o trabalho diretamente
    • Ensinar o trabalho a outras pessoas ou sistemas
    • Sistematizar o trabalho
    • Decidir quando executá-lo
    • Assumir o resultado

A diferença entre desenvolvedor e engenheiro

  • Qualquer pessoa pode ser desenvolvedora, mas nem todo mundo é engenheiro
  • O desenvolvedor se torna engenheiro quando aceita uma disciplina de trabalho mais rigorosa
    • Raciocínio minucioso e logicamente válido
    • Consideração de restrições e trade-offs
    • Consciência de riscos e exposição
    • Responsabilidade concreta
  • Quando a engenharia fica mais exigente, as pessoas se afastam de tarefas administráveis e separam papéis antes ligados ao artesanato, tornando suas funções mais claras
    • Quem faz protótipos
    • Quem constrói
    • Quem organiza
    • Quem escala
    • Quem mantém

A fronteira do sistema que só humanos podem proteger

  • Os humanos também assumem, na fronteira oposta do sistema, o papel de elevar o alpha
    • Escolhem o que vale a pena fazer
    • Definem sob quais restrições isso será feito
    • Julgam se há evidência suficiente para avançar
    • Cuidam do resultado
  • Seja em uma equipe ou em cem, essa fronteira só pode ser possuída por humanos
  • Atenção, taste e responsabilidade são os elementos centrais que fazem a fábrica de software funcionar
  • Sem responsabilidade, não há regras, resposta a perguntas, trade-offs, riscos nem redes de segurança
  • Se não houver alguém para assumir as consequências das decisões, uma agência elevada leva ao caos

A assinatura que dura mais do que a tecnologia

  • A meia-vida de uma vantagem técnica pode ser de um único release, mas a meia-vida da assinatura (signature) deixada no trabalho pode durar toda a carreira
  • Assinatura significa poder colocar o próprio nome no resultado implantado e sustentá-lo
  • A tecnologia cria alavancagem, e a responsabilidade transforma essa alavancagem em confiança
  • Só pessoas podem escolher e herdar as consequências
  • Agentes podem escolher, rotear, fazer merge e escalar dentro de uma política, mas não podem herdar o resultado

O contrato de responsabilidade da base de código

  • Cada base de código pode precisar de um contrato de responsabilidade que explicite as condições para aceitar mudanças
    • Uma checklist do que foi compreendido no momento da aprovação
    • A evidência usada no julgamento
    • Quem se responsabiliza pela mudança
    • O estado do sistema depois que a mudança for bloqueada
  • O contrato deve tratar explicitamente das conexões entre atenção e taste, evidência, veredito e propriedade, e alpha, decay e taste

A escada da alta agência

  • Em workflows agentivos, alta agência é a capacidade de saber quando delegar, inspecionar, interromper e assumir o resultado
  • A escada da agência vai dos níveis mais baixos aos mais altos
    1. Sinalizar problemas em potencial
    2. Investigar o problema
    3. Executar o trabalho de resposta
    4. Diagnosticar a causa
    5. Propor uma solução
    6. Recomendar uma correção
    7. Resolver o problema
  • Os níveis mais altos também incluem o discernimento de notar um problema, julgar que ele não vale a pena ser corrigido e seguir adiante

Por que brownfield é a linha de frente da fábrica de software

  • Brownfield é a linha de frente que uma fábrica de software voltada a escala inevitavelmente encontra
  • Sistemas greenfield permitem controlar o todo, então é relativamente mais fácil planejar e implementar mecanismos suficientes de contrapressão
  • Ao adicionar agentes inteligentes a sistemas legados, é preciso lidar até com a complexidade que existe fora do código
    • Todo o comportamento de produção
    • As expectativas futuras dos clientes
    • O histórico de migrações
    • Ciclos de release e orçamento
    • Suposições implícitas
    • Exceções
    • Particularidades dos dados
    • Procedimentos de runbook
    • Cicatrizes acumuladas sem gestão
  • Cuidar de brownfields exige engenharia sustentável
    • Transformar conhecimento tácito em restrições explícitas
    • Manter o conhecimento consistente entre equipes e gerações
    • Formalizar esse conhecimento em procedimentos de teste e especificações funcionais
    • Conectar esse conhecimento a evidências objetivas
    • Acumular falhas como aprendizado adicional
  • Se o nível anterior de gestão desaparecer, o sistema inteiro pode ruir

O novo trabalho que surge com a escala

  • Quando componentes existentes são automatizados, as pessoas passam a usar o alpha e o taste vindos de sua experiência artesanal para projetar novos trabalhos
    • Projetar novos loops para incorporar à fábrica de software
    • Usar o conhecimento obtido na fábrica para construir sistemas greenfield baseados em princípios
    • Criar novos formatos de evidência capazes de validar novos sistemas
    • Cuidar de sistemas brownfield que se tornaram complexos o bastante para exigir gestão dedicada
    • Projetar e gerenciar novos mecanismos de contrapressão
    • Projetar novos agentes
    • Construir novos sistemas de agência
  • Tudo isso também é trabalho real de engenharia, e se torna um problema ainda mais interessante à medida que a escala aumenta

O gargalo que a automação desloca

  • A automação dá controle em escala industrial, mas também cria novos gargalos
  • Se antes o gargalo era “dá para construir isso?”, daqui para frente ele se desloca para “isso deve existir, e é possível explicar e assumir a responsabilidade pelo resultado?”
  • O novo gargalo que surge em produção é valioso o suficiente para ser assumido diretamente por humanos

O modelo operacional da engenharia agentiva

  • O loop interno é onde o trabalho real acontece, e cada loop deve ser projetado para ser o mais independente possível
  • Toda a garantia de qualidade e verificação deve ser colocada no loop interno
  • Depois de projetar e validar o próprio loop, deve-se conceder autonomia instalando mecanismos de contrapressão que controlem velocidade de execução e escopo do trabalho
  • Em vez de intervir em todas as etapas internas, os humanos devem ser colocados nos pontos corretos de decisão
  • Compreensão não deve ser tratada como simples handoff ou gate de release, mas como um ponto de decisão em que humanos estão prontos para oferecer insight
  • Sempre que o artefato voltar a abastecer produção ou novas equipes e engenheiros, ele deve deixar artefatos e evidências melhores do que antes
  • Construa e mantenha a fábrica de software, mas mantenha o trabalho em um estado legível, verificável e com dono
  • Mesmo que agentes escrevam o código, antes de ele chegar ao usuário alguém precisa responder às seguintes perguntas
    • Por que esse código deve existir?
    • Por que ele é seguro o bastante para estar em produção?
    • O que será feito se estiver errado?
  • Realizar esse julgamento e assumir essa responsabilidade é o loop externo da engenharia agentiva

Ainda não há comentários.

Ainda não há comentários.