Agentic SDLC: o build encolheu, agora arrume os dois lados

Durante décadas o ciclo de desenvolvimento de software foi montado em volta de uma etapa lenta e cara. Os agentes deixaram essa etapa barata. Tudo o que se apoiava nela caiu.

O build encolheu. O que um time levava semanas escrevendo, um agente escreve em horas. Passo meus dias de trabalho com times de engenharia atravessando essa mudança, e a primeira coisa que todo mundo espera acaba se mostrando errada. Nada chega em produção dez vezes mais rápido. O build ficou barato, e os dois lados dele quebraram.

Este playbook é sobre esses dois lados. Ele está escrito na ordem em que você adota, então quem lê de cima a baixo já sai com a sequência: o que arrumar primeiro, como cada passo fica no repositório, como saber onde você está e até onde vale subir. Funciona com qualquer harness.

O build encolheu. O calendário quase não percebeu

Guarde uma pergunta no bolso durante o artigo inteiro: se o agente escreve o código dez vezes mais rápido, por que a feature não chega em produção dez vezes mais rápido?

Esta é a medição que me fez levar a pergunta a sério. Uma feature de um time com quem eu trabalho: dez tasks, treze merge requests, seis repositórios, cinco linguagens, com teste e documentação. Antes dos agentes, o time estimava 10 a 15 dias úteis com cinco devs em tempo integral. Com agentes, levou três dias úteis e seis horas e meia de trabalho humano, somando todo mundo, mais US$ 67 de token.

Uma feature, antes e depois dos agentes

Esforço humano÷ 60 ou mais: Sem agentes (estimativa do time): 5 devs em tempo integral por 10 a 15 dias úteis
Com agentes (medido): 6,5 horas, somando todo mundo
Tempo de calendário÷ 4: Sem agentes (estimativa do time): 10 a 15 dias úteis
Com agentes (medido): 3 dias úteis

Uma feature, medida uma vez e depois do fato, num trabalho escolhido por encaixar bem no agente. As barras usam o limite baixo da estimativa do time.

O esforço humano caiu umas 60 vezes. O calendário caiu umas 4. Mesma feature, mesmo time. É uma medição só, feita de forma retroativa, numa feature escolhida por caber bem no agente, então leia como ordem de grandeza e nada mais fino que isso. Mas o formato conta a história inteira. O trabalho deixou de ser o que tomava o tempo.

Pense numa linha de produção montada em volta de uma prensa lenta. Cada estação está ajustada ao ritmo dela. Quem alimenta a prensa tem tempo de preparar o próximo lote. Quem vem depois inspeciona uma peça a cada poucos minutos. O operador fica do lado da prensa enquanto ela trabalha e vai pensando no próximo serviço. Agora troque por uma prensa dez vezes mais rápida. Quem alimenta não dá conta, a inspeção afoga, e o operador, que descansava enquanto a máquina trabalhava, passa o dia inteiro em pé do lado dela. A produção quase não sai do lugar. A linha nunca foi limitada só pela prensa. Ela estava ajustada em volta dela.

É assim que fica um time de software depois dos agentes.

O build lento fazia três trabalhos que ninguém escreveu

Antes dos agentes, o build era a etapa cara, então tudo em volta existia para protegê-lo. Requisito, refinamento, estimativa, sprint, review: tudo estava organizado para que as semanas de gente escrevendo código corressem do jeito mais liso possível. O gargalo era o build, e o build pagava por três coisas que nunca entraram em documento de processo nenhum.

Ele dava tempo para o upstream se preparar. Enquanto a engenharia passava duas semanas construindo, produto tinha duas semanas para descobrir a próxima coisa. O requisito vago se resolvia numa conversa de corredor no meio da sprint, antes de alguém precisar dele.

Ele entregava ao downstream um fluxo que dava para absorver. Review, QA e deploy foram dimensionados para a quantidade de código que gente produz. Dava para revisar cada linha porque uma pessoa tinha digitado cada linha.

Ele dava tempo para o dev pensar. Digitar era tempo de raciocinar. Enquanto você escrevia o código e participava das reuniões, ia montando o contexto na cabeça. Devs experientes num rollout me contaram que agora terminam o dia mais cansados do que antes de usar IA. O contexto chega pronto, é muita coisa para filtrar, e a parte lenta em que eles pensavam sumiu.

Quando o build achatou, os três trabalhos sumiram ao mesmo tempo. Os dois lados quebraram.

O que o build lento te dava de graça

O resto deste playbook é como construir a coluna da direita, em ordem.
O build lento te dava	Quando ele encolheu	O que agora você constrói de propósito
Tempo para o upstream se preparar	A spec chega vaga ou atrasada, e o agente preenche cada lacuna com um chute confiante	Contexto escrito antes da task: o problema, o escopo, o critério de aceite
Um fluxo que o downstream conseguia absorver	Fila de review, merge request grande demais para ler, approve que não significa nada	Unidades pequenas, verificação determinística e review de intenção e risco
Tempo para o dev pensar	O contexto chega pronto, as pessoas terminam o dia esgotadas, e o que aprenderam morre junto com a janela do chat	Tempo de spec antes da execução, sessões com limite e work logs que guardam o que foi aprendido

O resto deste playbook é como construir a coluna da direita, em ordem.

Então o gargalo mudou de lugar. Antes era o build. Agora ele está dos dois lados: contexto na esquerda, verificação na direita. Na esquerda, a pergunta é se o agente sabe o que construir e com quais regras. Na direita, é se alguém consegue dizer que o que voltou está certo. Cada passo abaixo ataca um dos dois.

O que é, de fato, um agentic SDLC

Agentic SDLC é um ciclo de desenvolvimento em que cada etapa deixa um artefato versionado que a etapa seguinte consegue ler, seja quem for o próximo leitor: uma pessoa ou um agente. A task alimenta o plano. O plano alimenta o código. As verificações julgam o código. O que o ciclo ensinou volta para o repositório, e o próximo ciclo já começa sabendo mais.

Três coisas mudam em relação ao ciclo que você conhece. As pessoas param de revisar linha e passam a revisar intenção e evidência. Regra que máquina consegue verificar passa a ser verificada por máquina, sempre. E o repositório vira o lugar onde todo mundo se encontra: produto, design e engenharia escrevem nele, cada um na sua linguagem, e o agente lê tudo.

O agentic SDLC como uma cadeia de artefatos

01
Upstream
O que construir, e por quê.
- Um problema escrito por trás do épico
- Uma task com critério de aceite
- Escopo visto pela engenharia
Gate: Uma pessoa aceita a spec
↓→
02
Build
O agente escreve; o repositório impõe os limites.
- AGENTS.md na raiz
- Um plano com unidades do tamanho de um review
- Código e teste
Gate: O comando único passa
↓→
03
Verificação
A máquina confere o que ninguém lê mais.
- Regras de lint e de tipo
- Teste que bloqueia o merge
- Review de intenção e risco
Gate: Um dono nomeado aprova
↓→
04
Entrega
Sobe pequeno, observa, desfaz rápido.
- Canary com abort
- Rollback que já foi executado
- Registro do que o agente fez
Gate: Release autorizado
↓→
05
Aprendizado
O que o ciclo ensinou volta para dentro.
- Work logs
- Achado repetido no review vira regra
- Incidente vira caso de eval
Gate: Alguém faz a curadoria antes de virar verdade

A última fase é a que os times pulam, e é ela que deixa o próximo ciclo mais barato.

Os sete passos a seguir constroem essa cadeia, na ordem que se sustenta na prática.

1. Prepare o repositório para receber trabalho

Comece pelo build, não pela spec. Essa é a decisão que mais pesa, e o instinto natural vai para o lado contrário.

Alguns grupos perto do meu começaram pelo upstream. Um deles automatizou primeiro o caminho do PRD até a spec técnica, com a ideia de resolver o resto depois. Eu não acredito nessa ordem. Uma spec perfeita entregue a um repositório sem arquivo de contexto, sem um comando único que prove que o trabalho terminou e sem teste que bloqueie o merge continua gerando código ruim. O agente chuta. O dev vira babá do agente, promptando e colando. O time conclui que a ferramenta não funciona, e a spec bonita leva a culpa.

Do jeito que eu falei para uma liderança de engenharia: se o build não estiver pronto quando o upstream acelerar, você ganha uma avalanche de devs estressados e frustrados que não escrevem mais código. Eles ficam de babá.

Tem um segundo motivo, e ele é sobre confiança. Quando o build está endurecido, as pessoas passam a confiar no que o agente entrega, porque sabem o quanto um merge request apanhou antes de sair. Essa confiança não vem de prompt melhor.

Antes de qualquer outra coisa, o repositório precisa de duas: um arquivo de contexto que o agente lê sempre, e um comando que diz a ele que o trabalho terminou.

# AGENTS.md

## Done means

Run `make check` and paste the output. It runs lint, types, unit and
integration tests, and exits non-zero on any failure. Fix the code, not
the test.

## Conventions the linter does not cover

- Money is integer cents, never floats.
- Every new endpoint gets an integration test in tests/integration/.

## Where the why lives

- Specs and decisions: docs/specs/ and docs/adr/
- Work logs: docs/worklogs/ (unofficial notes; verify before trusting)

## Mistakes we have seen twice

- The billing client retries on 409. Stub it in tests.

Mantenha o AGENTS.md como fonte única e faça cada arquivo específico de ferramenta apontar para ele. No Claude Code, um CLAUDE.md com a única linha @AGENTS.md importa o conteúdo. Time troca de harness. As suas convenções não deveriam ter que mudar de casa junto.

2. Transforme toda regra verificável em verificação que falha

Uma linha no AGENTS.md é um pedido. O modelo lê, e dependendo de quanta coisa está empilhada no contexto dele, pula. Modelo é uma máquina estatística. Determinístico é tudo o que não é estatístico, e é ali que as suas regras devem morar sempre que der.

Então, quando um achado de review aparece duas vezes, ele não deveria virar mais uma linha de Markdown. Se uma máquina consegue verificar, vira regra de lint, tipo ou teste, e a mensagem de erro aponta onde está escrito como corrigir.

// eslint.config.js
export default [
  {
    rules: {
      "no-restricted-imports": [
        "error",
        {
          paths: [
            {
              name: "moment",
              message: "Use date-fns. Why and how: docs/conventions.md#dates",
            },
          ],
        },
      ],
    },
  },
];

Essa regra era uma frase que o agente seguia na maior parte das vezes. Agora ela vale em toda execução, e o agente só precisa saber uma coisa: rodar a verificação, ler o erro, e o erro diz onde está a resposta. Você tira do modelo a responsabilidade de julgar, e ele fica melhor no trabalho que sobrou para ele.

Um arquivo de contexto saudável encolhe com o tempo. Toda regra que dá para verificar desce uma camada, para o linter, os tipos ou os testes, e o que fica no Markdown é julgamento. O pipeline garante o resto: teste vermelho e segredo exposto não entram, não importa quem ou o que abriu o merge request.

3. Pare de jogar contexto fora

Toda vez que alguém fecha a janela do chat, a organização perde o que aquela sessão aprendeu. A regra que o dev teve que explicar na mão, o beco sem saída que ele encontrou, o motivo de quebrar a migration em outro merge request: estava tudo na sessão, e a sessão acabou. Foi embora o token, o tempo e o raciocínio de quem fez.

Contexto é o novo gargalo, e ele é caro de três jeitos. Precisa ser capturado, porque a maior parte mora na cabeça das pessoas. Precisa ser curado, porque o que vai para o papel muitas vezes está errado ou se contradiz. E precisa ser conectado, porque uma base de conhecimento ótima que um time guarda só para si não rende juros.

A captura começa com um work log. No fim de uma unidade de trabalho, antes de limpar a sessão, peça ao agente para extrair o que ele precisou e não encontrou, e grave num arquivo Markdown.

# Work log: invoice retry, 2026-09-18

## Context I had to add by hand

- Invoices to public-sector customers must not retry on weekends.
  The rule is not written anywhere; finance confirmed it in chat.
- The email provider returns 202 before validating the address.

## Decisions taken in the session

- Moved the migration to its own merge request to keep review small.

## Promote?

- [ ] Weekend rule to docs/specs/invoicing.md (ask finance to sign off)
- [ ] Provider behavior to AGENTS.md, under mistakes seen twice

Work log não é documentação. É matéria-prima. A curadoria decide o que sobe para a spec, para o arquivo de contexto ou para uma verificação, e é trabalho de formiguinha: classifique o que você sabe em verde, amarelo ou vermelho conforme o quanto confia, e nunca deixe uma nota vermelha virar a verdade em que um agente vai se apoiar.

O que está em jogo é maior do que parece. Num rollout, metade de uma regra de negócio morava na cabeça de uma pessoa de produto e a outra metade na cabeça de uma pessoa de engenharia, e não estava escrita em lugar nenhum. Em sistemas mais antigos eu escuto sempre a mesma reclamação: ninguém tem coragem de mexer numa regra, porque um dia alguém teve um motivo para ela e ninguém sabe onde esse motivo está hoje. Dívida técnica muitas vezes é exatamente isso, uma decisão cujo porquê nunca foi escrito. A wiki, quando existe, conta talvez um décimo de como a história aconteceu de verdade.

Cada ciclo que alimenta o repositório deixa o próximo mais barato. Essa é a parte que rende juros num agentic SDLC, e é a parte que o build lento nunca obrigou ninguém a construir.

4. Traga a spec para antes da execução

Acompanhei um dev fazendo o que a maioria faz nos primeiros meses com agente. Leu o PRD, leu a task do Jira e começou a promptar, completando os detalhes que faltavam conforme o agente perguntava ou errava. Isso é especificar em tempo de execução. Parece produtividade. É o sinal mais claro de um time travado entre o nível 2 e o nível 3.

O agente mudou a economia de uma task vaga. O dev com uma task vaga trava, levanta e vai perguntar, e aquela pergunta era revisão de spec de graça que ninguém nunca contou. O agente nunca trava. Ele preenche a lacuna com uma suposição e entrega tão rápido que ninguém vê a suposição até ela aparecer dentro de um diff grande demais para ler. O modelo satisfaz qualquer spec, boa ou ruim.

Isso não pede formato novo. Uma task com problema, escopo e critério de aceite já é o artefato que o agente precisa ler. O que muda é o leitor: agora você escreve para a máquina também.

# Show why an invoice failed to send

## Problem

Customers open support tickets to ask why an invoice never arrived.
Written problem: docs/problems/invoice-visibility.md

## Scope

- Billing page, read-only. Out of scope: resending.

## Acceptance criteria

- An invoice that failed shows the reason and the last attempt time.
- An invoice that was delivered shows no badge.
- `make check` passes, with one integration test per criterion.

## Context

- Failure reasons: docs/specs/invoicing.md#failures
- Design: link to the approved mock

Duas coisas precisam ser verdade antes de uma task dessas existir. O épico aponta para um problema escrito: o que é, quem é afetado e como saber que funcionou. E a engenharia viu o escopo antes de a task ser escrita, porque é ali que as perguntas baratas acontecem.

O fluxo também anda para trás. Se você não pega o que o build aprendeu e não leva isso para o próximo requisito, empurra o problema para a esquerda, e o próximo PRD sai quebrado. Os work logs do passo 3 são o jeito de o build conversar de volta com o upstream.

5. Mude o que chega no review

De volta à pergunta do começo. O tempo que o agente economizou não sumiu. A maior parte foi parar no review. É a primeira reclamação dos devs nos times que adotam agente: a quantidade de merge request para revisar só cresce, e a fila virou a etapa mais lenta.

Revisar mais rápido não resolve. Approve obrigatório por merge request, com review prometido para o mesmo dia, foi dimensionado para a quantidade de código que gente produz. Multiplique os merge requests e ou a promessa quebra ou o approve deixa de significar alguma coisa. Ler cada linha fazia sentido quando uma pessoa escrevia cada linha. Não acompanha um agente.

Arrume o que chega. Limite o tamanho de cada unidade de trabalho na aprovação do plano, antes de o código existir, para que alguém consiga revisar o resultado de uma vez só: quebre por endpoint, dê à migration de banco o próprio merge request. Depois mude o que o revisor olha. O passo 2 já barra os problemas mecânicos, então o review pode ser sobre intenção e risco: isso faz o que a task queria dizer, e o que quebra se estiver errado. Marque cada comentário com o peso dele, blocking, major ou minor, para quem escreveu saber quais seguram o merge. Contei como um time saiu desse congestionamento de review em por que o AI-DLC te deixa mais lento primeiro.

O revisor é a peça mais escassa do sistema, e a mais frágil. Num rollout que eu acompanhei, as pessoas aprovavam documento depois de sessões longas, sem capacidade sobrando para ler de verdade, e cerca de uma hora por sessão acabou sendo o limite prático. A falha oposta é mais silenciosa. O décimo artefato que o agente produziu é aprovado com menos cuidado que o primeiro, porque os nove primeiros pareciam bons, e o revisor só aperta o botão. Gate aprovado por gente cansada ou confiante demais vira carimbo. Gates são uma função de perda mostra as quatro formas como isso acontece.

6. Ponha o gate humano onde o trabalho está

Existem dois tipos de gate humano. O gate de review vem depois do trabalho: ficou pronto, uma pessoa valida antes do merge. O gate de início vem antes: nada começa porque a única pessoa que poderia revisar está ocupada. O segundo é circular. Nada começa porque não tem revisor, e não tem nada para revisar porque nada começou.

Participei de uma reunião sobre um time que tinha o PRD escrito, um trabalho autocontido e um repositório com os contratos mapeados, e nada andava, porque o engenheiro que ia revisar estava alocado em outra frente. Alguém na sala resumiu: a gente montou o carro e continua indo a pé.

O agente trabalha de forma assíncrona. Deixe o gate humano viajar junto com o trabalho em vez de ficar parado na frente dele. Um time com quem eu trabalho desenhou o quadro assim.

Um quadro em que a pessoa aparece duas vezes

Entrada

Um problema escrito, com escopo

pessoaSpec
Um dev valida a task e o critério de aceite antes de qualquer agente rodar.
filaPronto para o agente
Qualquer pessoa arrasta o card para cá. O agente lê a coluna e a task.
agenteEm andamento
O agente planeja, implementa e roda o comando único até passar.
pessoaReview
Um dono nomeado revisa intenção e risco. Comentário na task volta para o agente.
aprendizadoFeito
Mergeado, e o work log vai para a curadoria.

Saída

O trabalho do agente e o das pessoas correm em paralelo, e não em fila

A sprint carrega o mesmo pressuposto escondido do gate de início. Duas semanas faziam sentido quando a entrega era limitada pela velocidade de digitar: você junta o trabalho num pacote coeso. Quando o código leva horas, esperar duas semanas para começar algo novo custa mais do que fazer. Encurtar a sprint não resolve, porque a duração nunca foi o problema. Enfiar o agente nas cerimônias que você já tem também não. Isso automatiza a fábrica em vez de redesenhar a fábrica, e automatizar um fluxo que ainda não funciona só acelera o gargalo.

7. Conquiste o loop

O último trecho é a entrega e o loop fechado, e ele vem por último por um motivo: todos os passos anteriores são o que o deixa seguro.

A entrega precisa ser chata antes de um agente chegar perto dela. Qualquer pessoa do time sobe o mesmo ambiente com um comando. Toda mudança sai atrás de um canary com abort. E o rollback já foi executado de verdade, recentemente, por alguém do time. Sem isso, toda mudança autônoma é tudo ou nada em produção.

Depois o agente passa a ser avaliado como um funcionário que nunca para de aprender: por uma suíte. Junte vinte ou mais tarefas reais do seu próprio histórico, cada uma com o resultado que vocês aceitaram, e rode no CI sempre que mudar um prompt, uma skill ou o modelo. Todo incidente vira um caso novo. Sem eval, “autônomo” significa “não verificado”, e o projeto fica no nível 3 por melhor que seja o modelo.

Rode o agente em sandbox com credencial escopada, guarde o registro dos comandos que ele executou e dê a cada time um orçamento de token visível. Sem sandbox, um erro vira incidente. Sem registro e sem orçamento, a falha é silenciosa e a conta é surpresa.

Só então feche o loop. Um script determinístico observa a produção. Quando uma métrica sai da faixa normal, ele chama o agente, o agente diagnostica e escreve a próxima task, e uma pessoa faz a triagem. A detecção continua determinística e o modelo faz a parte que precisa de modelo, a mesma divisão que atravessa o playbook inteiro. É também a divisão que faz o AI-DLC 2 funcionar: a engine roteia, o modelo executa.

A escada não tem atalho

Esses sete passos se encaixam numa escada de autonomia. Ela define cada nível pelo que o agente assume, pelo que fica com a pessoa e por quem faz a verificação. A minha é adaptada de um framework interno, e os níveis vão parecer familiares para quem já viu alguma das versões públicas.

A escada agêntica

L1
Assistido
"O agente rascunha e completa. O dev escreve e decide tudo."
Verificado por olhos humanos
L2
Supervisionado
"O agente muda arquivos quando pedem. Uma pessoa revisa cada diff."
Verificado por olhos humanos, apoiados por teste
L3
Pull request
"O agente pega uma task inteira, edita vários arquivos e abre o pull request. Uma pessoa revisa o pull request."
Verificado por teste em camadas e CI
L4
Autônomo
"O agente planeja, implementa, se avalia e entrega atrás de um gate de aprovação. Uma pessoa aprova no gate."
Verificado por um gate de eval
L5
Totalmente agêntico
"Da spec à produção, reentrando no loop sozinho. A pessoa define a intenção e fica de on-call."
Verificado por evals autônomos

O salto que importa é do L2 para o L4. É ali que o trabalho sai de operar e vai para julgar, sai de mover mão de obra e vai para declarar intenção. No L2 o agente é um autocomplete melhor. No L3 você entrega uma task para ele do jeito que entregaria para um colega. Modelo melhor não produz esse salto.

Não dá para pular degrau. Um time no L2 que força a subida para o L5 sem teste em camadas, sem contexto no repositório e sem escrever spec tem uma chance perto de cem por cento de dar muito errado, porque o que ele está fazendo de verdade é vibe coding em escala. Um nível só se sustenta quando a automação é confiável o bastante para assumir a supervisão que a pessoa parou de fazer. Subir sem isso é ausência de controle.

Fique de olho no platô também. Time que ainda está promptando está entre o L2 e o L3, e o risco é se acostumar ali. Promptar dá sensação de avanço. É o degrau antes do degrau.

Mais duas coisas sobre a escada. A nota descreve prontidão, não prática: um repositório no L3 está preparado para receber trabalho agêntico, o que não quer dizer que o time já trabalhe assim. E a escada tem três trilhas. Repositório é infraestrutura, time de desenvolvimento é o downstream, time de negócio é o upstream, e cada um tem o seu próprio L1 a L5.

Seu teto é a sua linha mais fraca

Para saber onde um projeto está, pontue. Estas são as onze linhas que eu peço para os times pontuarem, cada uma ligada ao nível que destrava. Cada linha recebe de 0 a 3: 0 ausente, 1 ad hoc, 2 estabelecido, 3 automatizado e obrigatório. Faça com o time inteiro, numa retro, e repita a cada ciclo. Boa parte dá para ler direto do repositório; eu entrego para os times uma skill que lê o repo e propõe a nota, e o time corrige.

Onze linhas para pontuar, de 0 a 3

Pontue o projeto, não o time: um serviço no caminho crítico e um experimento descartável são dois projetos com duas notas.
Linha (nível que destrava)	Como é um 2
AGENTS.md na raiz do repo (L2)	Nos repos principais, com comandos e convenções, mexido neste ciclo, apontando para a spec quando ela mora em outro lugar
Um comando que roda tudo (L2)	Um lugar que o agente lê declara tudo o que precisa passar antes do merge, e cada verificação sai com código diferente de zero quando falha
Critério de aceite na task (L3)	A task sai com um critério verificável antes de alguém acionar o agente
Teste automatizado (L3)	Unitário, integração e e2e, com o pipeline bloqueando merge por teste vermelho ou segredo exposto
Setup do agente versionado (L3)	Skills, hooks e o ponto em que o agente para e pede aprovação moram no repo, e rodam igual em qualquer harness
Acoplamento de deploy (L3)	Dá para fazer merge e deploy de uma parte sem subir outra junto, e o contrato entre elas é versionado
Disciplina de review (L3)	O review usa prefixo de peso e olha intenção e risco, não formatação
Ambiente e entrega (L4)	Qualquer pessoa sobe o mesmo ambiente, o canary tem abort e o rollback já foi executado de verdade
Eval harness (L4)	Uma suíte de 20+ tarefas reais roda no CI com resultado esperado versionado
Sandbox e registro (L4)	O agente roda em sandbox, com secret scanning, custo visível por time e registro dos comandos que executou
Convenção no linter (L4)	As convenções que mais aparecem em review viraram regra de lint, e a mensagem de erro diz onde está escrito como corrigir

Pontue o projeto, não o time: um serviço no caminho crítico e um experimento descartável são dois projetos com duas notas.

Depois aplique a regra que muda a conversa.

Um barril feito de ripas de madeira segura água até a altura da ripa mais curta. Aumente as outras ripas e você construiu um barril mais alto que segura exatamente a mesma água.

Num projeto ilustrativo, três serviços e sete pessoas, no formato dos que eu encontro: teste tira 3, com unitário, integração e e2e bloqueando o merge. Entrega tira 3, com canary por padrão e rollback executado no último incidente. O time se enxerga no L3. O teto é L1, decidido por uma linha só: o AGENTS.md existe em um dos três repositórios, com o último commit de cinco meses atrás. Sem contexto no repositório, o agente trabalha por suposição, e cobertura boa não compensa isso.

A percepção segue a melhor ferramenta. O teto segue a que está travada. Os números que mais chamam atenção nessa pontuação são os zeros do gate do L4, três degraus acima. A tarefa que resolve é a mais barata: um arquivo de contexto em três repositórios, que sozinho leva o projeto do L1 para o L2.

Suba só até onde o seu custo de erro pede

A régua é a mesma para todo mundo. O que muda é até onde vale subir, e quem decide é o custo de um erro. Todo projeto é uma balança entre contexto de um lado e velocidade, segurança e confiabilidade do outro.

Nível-alvo pelo custo do erro

O que protege o transatlântico afunda o jet ski.
Perfil	O que é	Um erro custa	Alvo
Plataforma core	Caminho crítico, profundidade técnica, muitos consumidores	Um incidente em produção	L5
Produto base	Voltado a cliente e parceiro, sólido, menos profundo que uma plataforma	Uma regressão recuperável	L3
Experimento	Uma ou duas pessoas, muita incerteza, hipótese descartável	Jogar fora e refazer	L2

O que protege o transatlântico afunda o jet ski.

O valor de um experimento é velocidade, então ele pode errar mais do que uma plataforma. Mas tamanho não faz de um projeto um experimento. Raio de dano faz. Duas pessoas mexendo com dinheiro, dado pessoal ou o caminho do checkout não são um experimento, por menor que seja o time.

Cruze o teto com o alvo. Abaixo do alvo, a lacuna é o seu roadmap. No alvo, pare de investir em harness ali e coloque o esforço na entrega. Acima do alvo, você construiu o que não precisava, o que normalmente quer dizer que o perfil estava errado. Invista na linha mais fraca abaixo do alvo, e só nela. Um experimento travado no L1 não precisa de eval harness. Precisa de um arquivo de contexto.

O repositório vira a sala de reunião

A maior mudança que eu tenho visto não está no código. Quando gerar código custa quase nada, a disciplina de onde você veio deixa de ser o que organiza o trabalho. A entrega comum é sempre um repositório, e agora todo mundo escreve nele na sua própria linguagem: produto escreve o problema, design escreve o mock e as regras por trás dele, engenharia escreve a arquitetura e as verificações. O agente lê tudo. Organizações montadas em caixinhas de especialistas vão ter que assumir trabalho multidisciplinar, planejando isso ou não.

O trabalho de engenharia sobe um nível de abstração, do mesmo jeito que subiu quando paramos de gerenciar registrador na mão. Menos digitação, mais contexto, desenho de arquitetura, integração de sistemas e decisão sobre o que vale a pena construir. Meio brincando, eu digo para os devs que o futuro da programação é escrever arquivo Markdown. É só meio brincadeira.

Essa mudança tem custo, e alguém precisa cuidar dele. O tempo de pensar que o build lento dava ao dev agora precisa ser agendado de propósito, como tempo de spec antes da execução. Sessão precisa de limite. O que funcionou no rollout que eu acompanhei foi um manager que participou das primeiras sessões, calibrou o ritmo e impediu que a aprovação virasse automática. Sem alguém perto cuidando disso, todo gate vira formalidade.

E nem toda tarefa deve ir para o agente. Quando o gargalo é conhecimento que já está na cabeça de quem executa, não existe nada para o agente destravar, e descrever a solução custa mais do que escrever o código. Um estudo randomizado da METR encontrou devs experientes mais lentos com IA em código que conheciam bem, enquanto acreditavam estar mais rápidos. O investimento é contexto e verificação. Esperar que o próximo modelo resolva não é.

Meça o que encolheu e o que não encolheu

O custo da IA se mede sozinho. A conta de token chega todo mês sem ninguém pedir. O retorno, não. Quando um lado da conta se preenche sozinho e o outro depende de alguém preencher, toda discussão de orçamento acontece com metade dos números.

Meça o custo de entregar uma feature contra o que o time gastaria sem o agente. É a medição do começo deste playbook, e é daqui que sai cada número.

Como reproduzir a medição de uma feature

O número	Quem responde	De onde sai
Tamanho da feature, na escala do próprio time	Tech Lead, manager ou o time numa retro. Nunca o agente	O seu Jira
Pessoas e tempo que o time levaria sem o agente	Derivado do histórico; o time confirma ou corrige	Épicos fechados antes de o agente chegar
Tempo de calendário até o merge	Ninguém	Jira e o host do git
Horas humanas, por pessoa	Quem fez o trabalho	Só perguntando
Custo de token	Ninguém	O export de uso do seu provedor

Nunca deixe o agente estimar o próprio trabalho. Numa feature, o agente pontuou mais do que o dobro do que o responsável pelo projeto achava que ela valia. Tire o contrafactual do histórico: quantos pontos o time gasta em cada tipo de trabalho já está nos épicos fechados. Use uma janela anterior ao agente, ou a base vem deflacionada e o ganho parece menor do que é.

Uma linha resiste à automação. Hora humana não se deduz do calendário. Na medição acima, a dedução deu dois devs em tempo parcial por três dias, contra seis horas e meia trabalhadas de fato: fator de oito, direto no denominador. Pergunte às pessoas, no dia em que o épico fecha, enquanto elas ainda lembram.

Linha de código, commit e merge request eram proxies razoáveis enquanto escrever código dominava o custo do ciclo. Com agente, crescem sem mudança nenhuma correspondente no resultado. O guia de métricas do AI-DLC tem as quatro que eu colocaria no dashboard no lugar delas.

Todo processo novo precisa de data de remoção

Pontue antes de prescrever. Quadro, papel ou etapa nova é prescrição, e prescrição vem depois do diagnóstico. Processo criado para descobrir onde o trabalho trava é instrumento, e instrumento tem data de remoção. Processo criado para ficar, num projeto cujo teto ainda é L1 ou L2, vira o próprio teto: o que não pode ser automatizado acaba definindo até onde o time sobe.

Escreva a data de remoção do lado do processo no dia em que criar. “Revisamos toda spec em mob até o critério de aceite parar de voltar errado” é instrumento. “Revisamos toda spec em mob” é cerimônia, e cerimônia sobrevive ao problema para o qual foi criada.

O playbook em uma página

O agentic SDLC, na ordem em que você adota

Obrigatório:
Dê a cada repositório um AGENTS.md e um comando que prova que terminou.Os arquivos de cada ferramenta apontam para ele. Só isso já sobe a maioria dos projetos um nível inteiro.
Obrigatório:
Leve toda regra que máquina consegue verificar para uma verificação que falha.Lint, tipos, testes. Teste vermelho e segredo exposto nunca entram. O arquivo de contexto encolhe.
Obrigatório:
Mantenha um work log por unidade de trabalho, e faça curadoria.Capture o que a sessão aprendeu antes de limpar. Promova o que você confia.
Obrigatório:
Escreva a spec antes de o agente rodar, não durante.Um problema escrito por trás do épico, critério de aceite na task, engenharia no escopo.
Obrigatório:
Dimensione as unidades para o review no plano, e revise intenção e risco.Limite as sessões, marque o peso dos comentários, desconfie da décima aprovação fácil.
Obrigatório:
Deixe o gate humano viajar junto com o trabalho.Pessoas na spec e no review. O agente trabalha no meio, em paralelo.
Obrigatório:
Conquiste o loop: entrega chata, evals, sandbox, registro.Depois deixe a detecção determinística chamar o agente, e uma pessoa fazer a triagem.
Obrigatório:
Pontue as onze linhas a cada ciclo e ataque a mais fraca abaixo do alvo.O gate mais fraco é o teto. O alvo vem do custo de um erro.
Anti-pattern:
Empurrar a spec para o agente e pular a régua.É assim que um time acaba especificando em tempo de execução e culpando a ferramenta.

O build encolheu. Essa parte está feita, e era a parte fácil. O agente deixou o código barato. Não deixou o julgamento barato, e não deixou o contexto barato. Construa esses dois de propósito, nesta ordem, e o calendário começa a andar também.

FAQ

O que é agentic SDLC?

É o ciclo de desenvolvimento de software refeito para um mundo em que agentes de IA escrevem a maior parte do código. Cada etapa deixa um artefato versionado que a seguinte consegue ler, as pessoas revisam intenção e evidência em vez de cada linha, regra que máquina consegue verificar é verificada por máquina, e o que cada ciclo aprende volta para o repositório. Você também vai ver o nome AI-native SDLC ou AI SDLC.

Se nossos agentes escrevem código mais rápido, por que o lead time não caiu?

Porque o build era só uma parte do lead time, e o resto do ciclo estava ajustado em volta de ele ser lento. Quando o build encolheu, o trabalho foi para os dois lados: contexto na esquerda, review e verificação na direita. Enquanto você não reconstrói esses dois lados, o calendário quase não se mexe.

Por onde um time deve começar?

Pelo repositório, não pelo PRD. Um AGENTS.md na raiz e um comando que roda tudo o que precisa passar antes do merge. Spec melhor só se paga depois que o repositório aguenta receber trabalho; antes disso ela produz código errado com muita confiança e devs frustrados.

Qual a relação do agentic SDLC com AI-DLC e Spec-Driven Development?

O AI-DLC é o método da AWS para a mesma mudança, com vocabulário próprio e uma engine que roda o método. Spec-Driven Development é a prática de escrever a spec antes de o agente rodar, que é o passo 4 aqui. Este playbook é a ordem e o teto que valem para qualquer um deles.

Todo time precisa chegar à autonomia total?

Não. Defina o alvo pelo custo de um erro. Um experimento descartável para no L2, um produto voltado a cliente no L3, uma plataforma core no caminho crítico mira o L5. Investir em harness acima do alvo não compra nada.

Como medir o ROI de agentes de IA para código?

Meça o custo de entregar uma feature contra o que o time gastaria sem o agente. Tire o contrafactual de épicos fechados antes do agente, pergunte às pessoas as horas reais no fechamento do épico e some a conta de token. A resposta é uma ordem de grandeza, que é o que uma decisão de orçamento precisa.

A newsletter

Don’t Code, Specify. Toda semana, agentes de IA em produção de verdade. Sem hype: o que funcionou e o que quebrou.

Assinar no Substack