Capítulo 3 — A nova unidade de trabalho: mudança limitada, não prompt

O erro de medir trabalho em prompts

Quando ferramentas de IA entram no fluxo de desenvolvimento, é tentador tratar o prompt como a unidade de trabalho.

Essa visão é confortável porque o prompt é visível. Ele parece ter começo e fim. Pode ser copiado, refinado, comparado e reutilizado.

Mas software não é entregue em prompts.

Software é alterado por mudanças que atravessam arquivos, dependências, testes, decisões, commits, revisão e, em muitos casos, produção.

Um prompt pode iniciar uma mudança. Ele não define sozinho onde a mudança termina, qual superfície ela toca, como será verificada nem o que deve acontecer quando alguma hipótese estiver errada.

Por isso, neste livro, a unidade operacional será outra:

uma mudança limitada com intenção, escopo, evidência e desfecho observáveis.

É a mesma lógica que sustenta o nosso Change Episode.

Pequeno não significa trivial

Martin Fowler descreve o ritmo seguro de refactoring como uma alternância disciplinada entre teste e pequenas mudanças. O valor não está em tornar o trabalho superficial. Está em encurtar a distância entre uma decisão e o feedback que revela se ela preservou o comportamento esperado. ¹

Kent Beck leva a mesma ideia para TDD. O ambiente deve responder rapidamente a pequenas mudanças, e o ciclo Red → Green → Refactor mantém o trabalho dentro de uma sequência curta de hipótese, implementação e ajuste. ²

A lição para agentes não é simplesmente “faça tarefas pequenas”.

É mais precisa:

mantenha cada mudança pequena o suficiente para continuar compreensível, verificável e reversível.

Uma mudança pode ser tecnicamente complexa e ainda assim ser limitada. Ela pode tocar dezenas de linhas críticas, exigir raciocínio arquitetural e demandar vários testes. O que importa é que tenha uma fronteira clara.

Agent-sized change

Chamaremos essa unidade de agent-sized change.

Não é uma medida fixa em linhas de código.

É uma mudança cujo envelope permite responder, sem ambiguidade excessiva:

qual resultado queremos;
quais arquivos ou componentes podem mudar;
o que está fora do escopo;
quais invariantes não podem ser violados;
quais evidências devem existir;
quem pode aprovar;
como desfazer;
quando a tarefa deve escalar.

Uma tarefa grande demais tende a empilhar incertezas. O agente precisa carregar mais contexto, o diff cresce, as hipóteses se acumulam e a revisão fica mais cara.

Uma tarefa pequena demais também pode ser ruim. Fragmentação excessiva cria handoffs artificiais, repete contexto e pode destruir uma fronteira conceitual que deveria permanecer coesa.

A meta não é minimizar tamanho por princípio.

A meta é encontrar o menor lote que preserve significado suficiente para ser implementado e verificado de ponta a ponta.

Delegação incremental

Tantithamthavorn propõe começar a delegação com tarefas menores e bem delimitadas e ampliar o envelope conforme evidência específica daquele codebase aumenta a confiança no agente. ³

Isso evita um erro comum: transformar confiança em uma propriedade global.

Um agente pode demonstrar bom desempenho em testes utilitários e ainda não ter evidência suficiente para receber autonomia sobre autenticação, migrações ou produção.

A fronteira da tarefa, portanto, também é uma fronteira de confiança.

Quando o agente trabalha em um lote limitado, conseguimos calibrar autonomia com base no tipo de mudança, no histórico e na capacidade de recuperação.

Diff revisável é parte do contrato

Pequenos lotes só ajudam se continuarem legíveis depois da geração.

Tantithamthavorn também recomenda granularidade de commit que preserve diffs revisáveis, justamente para evitar mudanças geradas por IA grandes demais para verificação prática. ⁴

Isso cria uma conexão importante:

o tamanho da tarefa e o tamanho do diff não são detalhes de Git; são propriedades de verificabilidade.

Uma mudança que cabe em um prompt, mas explode em milhares de linhas, falhou como unidade de engenharia.

O problema não é estético.

Quando o diff fica grande demais:

relações causais ficam mais difíceis de reconstruir;
regressões se escondem entre alterações legítimas;
revisão vira amostragem;
rollback pode remover mudanças boas junto com ruins;
o custo de entender a intenção cresce.

Por isso, o commit não é apenas registro histórico. Ele ajuda a manter o lote de mudança auditável.

O loop local da mudança limitada

Este não é um segundo lifecycle do livro. É um loop local para executar um único lote dentro do lifecycle canônico:

Intent — definir o resultado.
Boundary — limitar escopo e superfície.
Evidence first — definir como saberemos que funcionou.
Agent Work — delegar a implementação dentro do envelope.
Mechanical checks — testar propriedades verificáveis.
Review — avaliar decisões que ainda exigem julgamento.
Commit — registrar uma unidade legível e reversível.
Learning — atualizar contexto, testes ou regras quando algo novo for descoberto.

O ponto central é que o agente não recebe “faça tudo”.

Ele recebe uma mudança cuja conclusão pode ser demonstrada.

Quando dividir

Uma tarefa deve ser candidata à divisão quando pelo menos uma destas condições aparece:

há mais de um resultado independente;
partes diferentes exigem contextos diferentes;
o diff previsto ultrapassa a capacidade de revisão prática;
riscos diferentes pedem gates diferentes;
uma parte pode ser entregue e verificada antes da outra;
há uma fronteira arquitetural ou de domínio natural;
rollback de uma parte deveria ser independente.

Esses sinais não são fórmula matemática. São heurísticas de engenharia.

O capítulo 7 aprofundará decomposição como decisão arquitetural. Aqui, interessa apenas o princípio operacional: não deixe uma tarefa crescer até que a verificação se torne qualitativamente diferente.

Quando não dividir

Também existem sinais de fragmentação ruim.

Não vale separar quando:

duas alterações só fazem sentido juntas;
a divisão duplica contexto sem reduzir risco;
cria estados intermediários inválidos;
exige coordenação maior que o trabalho economizado;
transforma uma única decisão de domínio em várias interpretações parciais.

Small-batch engineering não é microtasking compulsivo.

É controle de superfície.

Uma mudança deve caber na cabeça de alguém

Agentes ampliam a capacidade de produzir alterações em paralelo, mas isso não elimina a necessidade de alguém compreender o que está sendo aceito.

Se nenhuma pessoa consegue explicar o objetivo, o diff, os principais riscos e a evidência, a unidade de trabalho está grande demais para o sistema de controle existente.

Isso pode ser resolvido de duas formas:

reduzir a mudança;
aumentar a capacidade de verificação.

Na prática, fazer as duas coisas costuma ser mais seguro.

Métricas que importam

No estudo longitudinal, small-batch engineering pode ser observado por sinais concretos:

tamanho do diff;
número de arquivos alterados;
duração do episódio;
número de tentativas;
rework antes do merge;
tempo de revisão;
falhas encontradas antes e depois do merge;
rollback necessário;
quantidade de contexto carregado;
número de gates executados.

Nem todo episódio terá todas essas métricas.

A regra é registrar apenas o que foi realmente medido.

O objetivo não é provar antecipadamente que lotes menores são sempre melhores. É construir evidência sobre quando eles reduzem custo de revisão, risco e retrabalho — e quando a fragmentação começa a gerar overhead.

Do prompt para o Change Episode

O prompt continua existindo, mas muda de papel.

Ele deixa de ser o contêiner da mudança e passa a ser um dos artefatos usados dentro dela.

O Change Episode é mais amplo:

Intent → Domain → Architecture → Spec → Context → Agent Work → Evidence → Review → Delivery → Operations → Learning

Essa unidade permite comparar episódios ao longo do tempo, observar falhas reais e relacionar autonomia ao resultado.

Também permite que o livro mostre algo que um catálogo de prompts não consegue mostrar: a cadeia entre decisão e consequência.

Próximo passo: domínio

Se a mudança precisa ser limitada, surge uma pergunta anterior:

limitada em torno de quê?

Arquivos não são uma resposta suficiente.

Módulos também não.

Para limitar corretamente uma mudança, precisamos compreender o domínio, a linguagem e as invariantes que dão significado ao sistema.

Por isso, o próximo capítulo sobe um nível: Domínio antes do prompt.

Fronteira de confiança

A confiança não é concedida ao agente de forma global. Ela é delimitada por tarefa, tipo de mudança, risco e evidência acumulada. A unidade pequena ajuda a tornar essa fronteira explícita. ³

Evidência exigida

Para uma mudança limitada, o pacote mínimo deve tornar observáveis:

outcome;
escopo;
acceptance criteria;
diff;
testes/checks;
decisão de revisão;
commit/revision;
rollback quando aplicável.

Rollback e recuperação

Lotes menores tendem a permitir reversão mais localizada, mas isso não é automático. O gate deve verificar se a mudança é realmente separável e se o rollback preserva invariantes do sistema.

Proveniência das fontes

Rastreabilidade deste capítulo:

CLM-003 — Fowler, ritmo test → small change → test;
CLM-020 — Beck, feedback rápido e pequenos passos em TDD;
CLM-021 — Tantithamthavorn, incremental delegation;
CLM-022 — Tantithamthavorn, commit granularity e diff revisável.

Fontes de acesso limitado não foram usadas como autoridade factual neste capítulo.

Recursos complementares

Recursos relacionados:

Change Episode;
Evidence Explorer;
futura visualização de tamanho de diff × rework × tempo de revisão;
futura ferramenta Agent Task Decomposer.

Martin Fowler, Refactoring (1999), Final Thoughts, pp. 43–45. Rastreabilidade interna: CLM-003. ↩
Kent Beck, Test-Driven Development: By Example (2002), Preface, pp. 6–7. Rastreabilidade interna: CLM-020. ↩
Kla Tantithamthavorn, Agentic Software Engineering (2026), Chapter 6: Agentic Software Engineering: A New Paradigm, p. 103. Rastreabilidade interna: CLM-021. ↩ ↩²
Kla Tantithamthavorn, Agentic Software Engineering (2026), Chapter 6: Agentic Software Engineering: A New Paradigm, p. 103. Rastreabilidade interna: CLM-022. ↩