O Handoff É a Unidade de Design: Delegando para Agentes Sem Perder o Sistema

Quando escrevi sobre Zero Token Architecture, a pergunta era se valia a pena chamar inferência: toda chamada de IA é uma decisão arquitetural, e a maior parte do custo fica fora do medidor de tokens. Este post é sobre o que acontece depois que a resposta é sim. Porque, quando agentes escrevem uma parcela significativa do código, minha descrição de cargo muda silenciosamente — e vi essa mudança acontecer na minha própria mesa. O output do meu dia de trabalho não é mais código digitado. É um fluxo de decisões de delegação: o que entregar, quanto disso, com quais restrições, e como vou saber que voltou correto.

Isso é trabalho de arquiteto, esteja ou não escrito no título. E, como qualquer arquitetura, pode ser feito deliberadamente ou por acidente. A versão acidental já é familiar: um prompt de um parágrafo descrevendo uma feature, vinte minutos de geração, um diff de duas mil linhas e um desenvolvedor rolando a tela naquele estado que chamei de "admirar" no post anterior — impressionado, concordando com a cabeça, sem verificar. A versão deliberada é uma disciplina, e essa disciplina tem uma ideia que sustenta todo o resto: o handoff, não a feature, é a unidade de design.

Bainbridge descreveu essa cadeira em 1983

Nada disso é tão novo quanto o tooling faz parecer. Em 1983, a psicóloga cognitiva Lisanne Bainbridge publicou "Ironies of Automation", cinco páginas na Automatica sobre controle de processos industriais que hoje se leem como uma resenha do meu setup de terminal. A ironia central dela: quanto mais você automatiza, mais o papel do humano migra de fazer o trabalho para supervisionar o trabalho — e supervisão é um papel no qual humanos estão predispostos a falhar, justamente porque a automação tirou deles a prática que mantinha suas habilidades afiadas. Sobram duas funções para o operador: monitorar, o que corrói a vigilância, e a rara intervenção difícil, que agora exige o pico de habilidade de alguém que não a exercita diariamente.

Troque "operador" por "desenvolvedor" e "malha de controle" por "agente de código" e as duas ironias continuam de pé. Se agentes cuidam de toda mudança rotineira, a fluência de que preciso para os 10% difíceis — a race condition cabeluda, a migração que toca tudo — é exatamente a fluência que atrofia. E o problema do monitoramento é pior em software do que em uma sala de controle, porque uma suíte de testes verde tem exatamente a mesma aparência esteja a mudança por baixo correta ou sutilmente errada.

Há também um dado desconfortável sobre o custo da supervisão não estruturada. O ensaio randomizado da METR, de meados de 2025, colocou 16 mantenedores open source experientes diante de 246 issues reais em seus próprios repositórios — bases de código nas quais trabalhavam havia anos, com mais de um milhão de linhas em média. Com ferramentas de IA liberadas, eles concluíram as tarefas 19% mais devagar. Depois, estimaram que as ferramentas os tinham deixado 20% mais rápidos. Mantenho essa lacuna de 39 pontos entre percepção e medição fixada ao lado da questão verificar-versus-admirar do post anterior, porque é a mesma constatação vestida de jaleco: a sensação de que a delegação está funcionando não é evidência de que está.

Atualizado em agosto de 2026: o número de manchete mudou desde então, e este post seria desonesto se não dissesse isso. O follow-up de fevereiro de 2026 da METR repetiu o desenho com 57 desenvolvedores em 143 repositórios e mais de 800 tarefas, e obteve o sinal oposto — uma estimativa de 18% de ganho de velocidade entre os desenvolvedores da coorte original que retornaram, 4% entre os novos recrutas, ambos com intervalos de confiança largos o bastante para cruzar o zero. A própria METR relativiza seu resultado, e a razão em si merece atenção: hoje tantos desenvolvedores se recusam a trabalhar sem IA que o experimento sistematicamente deixa de fora as pessoas e as tarefas com mais a ganhar. Ou seja, a lentidão não é o achado duradouro. A lacuna entre o que aqueles desenvolvedores mediram e o que acreditaram, essa sim é — e nenhuma revisão a tocou. A disciplina descrita abaixo é minha tentativa de conquistar um ganho de velocidade em vez de apenas senti-lo.

O handoff é a unidade de design

Um handoff grande falha duas vezes, uma em cada ponta do loop.

Falha do lado do agente porque especificações vagas e espalhadas degradam a qualidade do output de formas que se acumulam. Os textos de prática que mais valorizo neste ano convergem para o mesmo formato por caminhos diferentes. O ensaio de março de Addy Osmani sobre codificação multi-agente defende tarefas atômicas e delimitadas, com critérios explícitos de aprovado/reprovado, aprovação do plano antes de qualquer implementação e critérios de encerramento para trabalho travado — sua frase de que "o gargalo não é mais a geração. É a verificação" resume toda a economia deste post em uma frase. Calvin French-Owen, descrevendo seu próprio fluxo em fevereiro, chega a planos externalizados e divididos em estágios numerados precisamente porque agentes degradam quando um problema ultrapassa a janela de contexto — e porque um plano que vive em um arquivo sobrevive à sessão que o escreveu.

Falha do meu lado por uma razão que antecede os agentes em décadas. O maior estudo de code review que conheço — o da SmartBear, com um time da Cisco Systems — descobriu que a descoberta de defeitos se sustenta quando os reviews ficam na faixa de 200 a 400 linhas, a menos de 500 linhas por hora, em sessões limitadas a cerca de uma hora; passe disso e a detecção despenca. Esses números descrevem atenção humana revisando código humano, e aplicá-los a output de agente é uma extrapolação — sinalizo isso como tal. Mas a restrição de fundo — minha atenção — não mudou quando o autor mudou. No máximo, os números favorecem o caso do agente, porque código de agente chega sem o contexto compartilhado que a mudança de um colega carrega.

Os dados da indústria dizem que esse orçamento já está sob pressão pelo outro lado. Conforme a adoção de IA cresce, pull requests estão cerca de 18% maiores, enquanto incidentes por PR subiram cerca de 24% e as taxas de falha de mudança cerca de 30% — mais linhas chegando por review, com o mesmo par de olhos. Os mantenedores do OCaml tornaram público o formato disso quando recusaram um pull request de 13 mil linhas gerado por IA, não porque o código estivesse necessariamente errado, mas porque ninguém tinha banda para descobrir.

Junte os dois modos de falha e você chega à lei de dimensionamento contra a qual hoje desenho meus handoffs: dimensione a tarefa no começo ao review que você consegue pagar no fim. Não "quanto o agente consegue gerar" — geração é praticamente de graça. A pergunta é quanto eu consigo verificar com atenção plena em uma sentada, e a resposta honesta tem um teto de algumas centenas de linhas. Um handoff dimensionado além do meu orçamento de verificação não delega o trabalho; delega a responsabilidade, e silenciosamente. No momento em que o diff excede o que de fato vou ler, eu deixo de ser o orquestrador. Viro um espectador com direito a commit.

O briefing que eu realmente entrego

Dimensionar é necessário, mas não suficiente; uma tarefa pequena e vaga continua vaga. O que fez a delegação começar a funcionar para mim foi tratar o próprio documento de handoff como o artefato de engenharia — a coisa que eu construo com o cuidado que antes gastava no código. Minha prática, refinada ao longo de meses de uso diário, é um formato plan-first: um plano mestre que captura a intenção e o sequenciamento, dividido em tarefas-filhas pequenas e numeradas com dependências explícitas, cada filha carregando seu próprio status de pendente a em andamento até concluída ou bloqueada. Nada executa até que eu tenha revisado o plano em si. Esse review — cinco minutos de leitura antes de qualquer código existir — é onde pego os erros arquiteturais, enquanto ainda custam zero para corrigir.

Cada tarefa-filha é um briefing com o mesmo esqueleto:

## Task 03 — Extract retry policy into RetryPolicy type

**Depends on:** 01 (interfaces defined) · **Blocks:** 04, 05

**Scope**
Move the inline retry/backoff logic from `HttpSyncClient` into a
`RetryPolicy` value type. Touch only `sync/` — the callers in
`ingest/` are task 04, not this one.

**Constraints**
- No new dependencies.
- Public API of `HttpSyncClient` unchanged; this is internal.
- Follow the error taxonomy in `docs/errors.md` — do not invent
  retryable/non-retryable classifications.

**Done means**
- `./gradlew :sync:test` passes, including the three new cases
  named below.
- Diff stays under ~300 lines. If it will not, stop and report
  why instead of continuing.

**Verify with**
- New tests: exhausted-budget path, jitter bounds, non-retryable
  short-circuit.
- I will read the full diff before merge.

**Escalate when**
Blocked, or after 3 failed attempts at a passing build — do not
keep iterating past that.

Cada campo justifica sua presença respondendo a uma falha específica que já enfrentei. O limite de escopo nomeia o que não tocar, porque agentes são afoitos e é por arquivos adjacentes que uma tarefa de 300 linhas vira um diff de 1.400. As restrições carregam as decisões que me recuso a delegar — escolhas de dependência, contratos públicos, taxonomias — a camada de "ideias, arquitetura e sequenciamento do projeto" que French-Owen identifica como a parte que continua humana. Os critérios de conclusão são aprovado/reprovado, nunca "melhorar" ou "limpar", e incluem o próprio orçamento de diff como regra de parada. A cláusula de escalonamento codifica o critério de encerramento de Osmani: um agente que falhou três vezes está gerando entropia, não progresso, e o briefing diz isso de antemão, de modo que parar vira cumprimento de regra em vez de julgamento.

O loop abaixo é o sistema inteiro, e o que vale notar é onde ficam os dois gates laranja — ambos do meu lado da mesa, ambos antes de qualquer coisa irreversível.

​

Continuar conectado sem dirigir cada linha

A parte dessa disciplina que nenhum tooling resolve é justamente a que a pergunta nas minhas anotações fica rodeando: como permanecer conectado a um sistema no qual não estou mais digitando. A resposta de Bainbridge para salas de controle era prática deliberada e estruturada para os operadores. A minha, traduzida para uma base de código, são quatro hábitos.

O review do plano é onde mora o controle, não o code review. Quando um diff existe, as decisões caras — fronteiras, sequenciamento, o que depende do quê — já foram tomadas. Ler um resumo de plano de cinco linhas com atenção plena vence passar os olhos por um diff de 900 linhas com a ilusão de atenção. Quando discordo do trabalho de um agente, quase sempre é do plano que eu deveria ter discordado.

Leio todo diff que faço merge, e dimensiono o trabalho para que isso continue verdadeiro. É a lei de dimensionamento imposta socialmente, não tecnicamente. O dia em que eu fizer merge de algo que não li é o dia em que o modelo mental começa a se descolar do código, e o descolamento se acumula em silêncio até que um incidente faça a auditoria por mim. French-Owen, de quem peguei emprestada a disciplina de planos, seguiu o caminho oposto — ele faz verificações por amostragem, mantém a arquitetura na cabeça e se apoia no Bugbot do Cursor e no review do Codex para pegar o que já não lê linha a linha. É uma troca defensável e não é a minha, porque a leitura cumpre para mim uma segunda função que um bot de review não cumpre: é o que mantém meu modelo do sistema atualizado.

O mapa do sistema vive em um artefato que tanto o agente quanto eu lemos. Mantenho no repositório uma descrição de arquitetura — fronteiras de componentes, dependências permitidas, o raciocínio —, verificável por máquina sempre que possível. Ela cumpre dupla função: o agente planeja contra ela em vez de adivinhar a estrutura pelos nomes de pacote, e escrevê-la mantém o mapa atualizado na minha cabeça. Meu setup com Structurizr e ArchUnit, do começo deste ano, acabou sendo menos sobre diagramas e mais sobre isso: uma fonte de verdade compartilhada sobre o que o sistema é, que o CI defende enquanto estou olhando para outro lado.

Uma tarefa por semana, eu mesmo digito. Deliberadamente, em geral algo rotineiro que eu delegaria. Essa é a prescrição de prática de Bainbridge aplicada às minhas próprias mãos — o trabalho rotineiro é exatamente o que preserva a fluência que a rara intervenção difícil vai exigir. Custa talvez duas horas por semana. Penso nisso como pagar a previdência do meu próprio julgamento.

Quando delegar é a ferramenta errada

A disciplina tem limites honestos, e o primeiro é o piso de coordenação. Mesmo nos números revisados da METR os intervalos de confiança cruzam o zero, que é o jeito estatístico de dizer que, em algumas tarefas, o overhead ainda come o ganho — e um briefing é overhead. Não escrevo briefings para correções de um arquivo que consigo segurar inteiras na cabeça; no tempo de escrever o briefing, a mudança já estaria digitada. O custo do handoff é real, e fingir o contrário é o jeito mais rápido de transformar orquestração em cerimônia.

Trabalho de design em que escrever é pensar também continua do meu lado. Quando ainda não sei o que quero — um novo bounded context, um protocolo desconhecido, qualquer coisa em que a primeira tentativa existe para ser jogada fora —, delegar a exploração significa delegar o aprendizado, e o aprendizado é o entregável. O agente recebe a tarefa depois que o formato está claro, não antes.

E há um limite de tamanho de frota que respeito mesmo que o tooling já não o imponha. Cada agente em paralelo multiplica a superfície de review, e meu orçamento de verificação é fixo. Duas, ocasionalmente três tarefas simultâneas é onde eu paro; além disso, os gates formam fila e a pressão para ler por cima vira estrutural. A restrição nunca foi quantos agentes consigo rodar. Sempre foi quanto trabalho pronto consigo receber com a atenção intacta.

Pontos principais

• O handoff é a unidade de design. Dimensione cada tarefa delegada ao review que você consegue pagar depois — algumas centenas de linhas, uma sentada — e não ao que o agente consegue gerar.
• Escreva o briefing como o artefato de engenharia: escopo com uma fronteira de "não toque", critérios de conclusão aprovado/reprovado, um orçamento de diff como regra de parada e uma cláusula de escalonamento que torne desistir após três tentativas falhas o comportamento correto.
• Revise o plano antes de qualquer código existir; é ali que as decisões que você não pode delegar — dependências, contratos, sequenciamento — realmente são tomadas.
• Mantenha o mapa do sistema em um artefato compartilhado contra o qual o agente planeja e que o CI garante, e leia todo diff que você faz merge.
• Digite algo rotineiro você mesmo, com regularidade. Supervisão sem prática é o jeito silencioso de perder a habilidade de que você vai precisar na intervenção difícil.

Recorra a essa disciplina quando o trabalho se decompõe em passos delimitados e verificáveis dentro de um sistema cujo mapa você já domina. Pule-a — e simplesmente escreva o código — quando a tarefa cabe na sua cabeça, quando escrever é pensar, ou quando o briefing pesaria mais que a mudança. O post anterior argumentava que toda chamada de inferência é uma decisão arquitetural. Este é a continuação: todo handoff também é, e o arquiteto que para de revisar o prédio enquanto ele sobe manteve o título abrindo mão do trabalho.