O que é AI-DLC? O ciclo de desenvolvimento orientado por IA, visto de dentro de um rollout

No AI-DLC, a IA conduz e o humano decide. Todo o resto do método existe para manter honesta a segunda metade dessa frase.

AI-DLC, o AI-Driven Development Life Cycle, é um método de construir software em que um agente de IA planeja o trabalho, faz as perguntas e escreve todos os artefatos, dos requisitos ao código, enquanto pessoas aprovam ou rejeitam o resultado em gates entre uma etapa e outra. A AWS publicou o método em julho de 2025. Em setembro de 2026 saiu o AI-DLC 2, um motor de workflow instalável que roda dentro do Claude Code, do Kiro, do Codex, do Cursor, do opencode e do GitHub Copilot.

Essa é a definição. O resto deste guia é a parte que a documentação não conta.

Escrevo sobre Spec-Driven Development há um ano e construí uma fintech de 13 apps em 70 dias especificando antes de gerar. Nos últimos meses também estive dentro de uma grande organização de engenharia onde o AI-DLC saiu dos squads piloto e virou um programa de treinamento para as pessoas que vão espalhar o método por todos os times. Sentei nas sessões. Vi o que quebrou. Tudo o que vem a seguir sai do método público, da release atual e desse rollout, sem os nomes.

AI-DLC é um método, não uma ferramenta

Comece pelo que todo mundo erra primeiro. AI-DLC é um jeito de organizar o trabalho de software em volta de um agente de IA. A AWS descreve como metodologia, e as análises independentes concordam. O texto da TT PSC resumiu em uma linha: a contribuição do AI-DLC “não é a geração de código em si”, é “um modelo operacional controlado em que a IA participa de Inception, Construction e Operations, enquanto os humanos continuam responsáveis pelas decisões”.

A ferramenta veio depois. A primeira versão aberta, em novembro de 2025, era um conjunto de arquivos de regras para o Amazon Q e de steering files para o Kiro. O AI-DLC 2 transformou isso num motor com comando próprio, aidlc, que instala o workflow dentro do agente de código que você já usa. A AWS chama cada um desses agentes de harness: o Claude Code é um, o Cursor é outro. Dá para praticar o método sem o motor. Não dá para tirar valor do motor sem o método.

O AI-DLC 2 em números

5

fasesde Initialization a Operation

33

estágioscada um com um agente líder

14

agentes11 especialistas, 2 revisores, 1 composer

7

harnessesClaude Code, Kiro, Codex, Cursor e outros

A IA faz as perguntas e você decide

O coração do método é uma inversão. No desenvolvimento assistido por IA comum, quem começa a conversa é você. Você escreve o prompt, a IA ajuda numa tarefa, e o processo em volta continua o mesmo que o time já tinha. No AI-DLC quem começa é a IA. Você entrega uma intenção, e ela propõe o plano, pergunta o que precisa saber, rascunha o artefato e para esperando a sua aprovação antes de seguir.

O whitepaper usa um app de navegação para explicar. Você define o destino. O app dá as curvas. Você continua olhando a estrada e pode pegar outra rua, mas parou de ler o mapa.

Desenvolvimento assistido por IA

1. 01Você escreve o prompt e a IA responde
2. 02A IA ajuda numa tarefa por vez
3. 03O processo é o que foi feito para humanos
4. 04As decisões ficam no histórico do chat

AI-DLC

1. 01Você declara uma intenção e a IA faz as perguntas
2. 02A IA propõe o plano e a decomposição
3. 03O processo é refeito em volta da velocidade da IA
4. 04As decisões ficam em arquivos versionados no repo

Isso muda o que é trabalho bom para você. Você não ganha mais escrevendo o prompt perfeito. Ganha respondendo às perguntas certas com o contexto certo, e se recusando a aprovar o que você não consegue explicar.

Por que a AWS diz que não dá para parafusar IA no Scrum

O primeiro princípio do whitepaper é reimaginar em vez de adaptar. O argumento é simples e eu acho que está certo. O Scrum foi feito para um time de pessoas que precisa de duas semanas para entregar um incremento funcionando, então os rituais têm o tamanho desse ritmo: planning, daily, review, retro. Um agente entrega o mesmo incremento em horas. Mantenha os rituais de duas semanas e o agente passa a maior parte da vida esperando uma reunião.

O paper dá nome aos dois fracassos dos lados. O desenvolvimento assistido por IA mantém o processo antigo e acrescenta autocomplete, então nunca muda a estrutura do trabalho. O desenvolvimento autônomo deixa o agente construir sozinho, o que ainda não funciona, porque o contexto e as decisões críticas ainda dependem de uma pessoa. O AI-DLC fica no meio: a IA conduz, o humano aprova.

O vocabulário: Intent, Unit, Bolt

O AI-DLC renomeou as partes do trabalho de propósito. O sétimo princípio do whitepaper diz que um praticante deve conseguir começar em um dia, então cada termo novo corresponde a um antigo.

Palavras velhas, palavras novas

Bolt não é sprint com outro nome. É mais curto porque a IA comprime o tempo de produzir um artefato de dias para minutos.

Termo do AI-DLC	O que substitui	O que significa
Intent	Épico de negócio	A declaração do que precisa ser alcançado e por quê. O ponto de partida que a IA decompõe.
Unit	Épico técnico	Uma parte autocontida da solução que entrega valor mensurável e pode ser construída e implantada sozinha.
Bolt	Sprint	Uma fatia de entrega medida em horas ou dias, não em semanas. No AI-DLC 2, uma fatia planejada sobre uma ou mais Units dependentes.
Mob Elaboration	Planning e refinamento	O time e a IA numa sessão só: a IA propõe histórias e Units, o time corrige.
Mob Construction	Código, review, testes	A IA gera design, código e testes; os engenheiros aprovam ou pedem mudanças em cada passo.
Deployment Unit	Release candidate	Código, configuração e infraestrutura testados em função, segurança e requisitos não funcionais.

Dois desses merecem uma segunda olhada. A Intent é a única entrada que um humano precisa acertar, e o método quase não diz como acertar. A lacuna é grande o suficiente para ganhar um artigo só dela. E o Mob Elaboration é onde mora a maior parte do valor e da dor. É um ritual, com regras sobre quem senta na sala, e tem um guia próprio.

Cinco fases e 33 estágios no AI-DLC 2

A primeira versão do AI-DLC tinha três fases: Inception, Construction e Operations. O AI-DLC 2 tem cinco. Ganhou Initialization, que monta o workspace em menos de um segundo sem nenhuma pessoa envolvida, e Ideation, que transforma um pedido vago numa iniciativa aprovada antes de qualquer requisito ser escrito.

O ciclo de vida do AI-DLC 2

1. 0.1 a 0.3

   Initialization

   Monta o workspace, detecta o projeto, cria o estado. Automático.

   • Workspace Scaffold
   • Workspace Detection
   • State Initialization
   ↓→
2. 1.1 a 1.7

   Ideation

   Vale a pena construir isso, e o que exatamente é?

   • Intent Capture and Framing
   • Market Research
   • Feasibility
   • Scope Definition
   • Team Formation
   • Rough Mockups
   • Approval and Handoff

   ◆ Gate: Gate de verificação 1

   ↓→
3. 2.1 a 2.9

   Inception

   Requisitos, design e as Units de trabalho.

   • Reverse Engineering
   • Practices Discovery
   • Requirements Analysis
   • User Stories
   • Refined Mockups
   • Domain Design
   • Units Generation
   • Contract Design
   • Delivery Planning

   ◆ Gate: Gate de verificação 2

   ↓→
4. 3.1 a 3.7

   Construction

   Design, código e testes, uma Unit por vez.

   • Functional Design
   • NFR Requirements
   • NFR Design
   • Infrastructure Design
   • Code Generation
   • Build and Test
   • CI Pipeline

   ◆ Gate: Gate de verificação 3

   ↓→
5. 4.1 a 4.7

   Operation

   Deploy, observabilidade e o que se aprende volta para a Ideation.

   • Deployment Pipeline
   • Environment Provisioning
   • Deployment Execution
   • Observability Setup
   • Incident Response
   • Performance Validation
   • Feedback and Optimization

Dois tipos de checkpoint atravessam esse mapa, e a diferença importa. No fim de cada estágio existe um gate de aprovação: você responde Approve ou Request Changes, com as suas palavras, e nada anda até você responder. Entre as fases existe um gate de verificação: uma checagem automática de que cada requisito vira uma história, nada ficou órfão e os artefatos concordam entre si. O primeiro pega julgamento ruim. O segundo pega ligação quebrada.

Cada estágio tem um agente líder. A AWS entrega 14: 11 especialistas de domínio (produto, design, entrega, arquitetura, plataforma AWS, compliance, DevSecOps, desenvolvimento, qualidade, pipeline e deploy, operações), dois revisores que julgam requisitos e design técnico, e um composer que monta rotas sob medida. O princípio de design é “Small Mob, Broad Agents”: poucos agentes amplos em vez de dezenas de especialistas estreitos, porque uma cadeia de especialistas estreitos é só waterfall com marketing melhor.

A maioria dos estágios roda inline, na sua conversa com o agente. Quatro não. Reverse Engineering é um pipeline de dois passos (um agente de desenvolvimento varre o código, um agente de arquitetura escreve a síntese). Practices Discovery e Code Generation rodam como subagents despachados. User Stories roda como mob, com os agentes de design, desenvolvimento e qualidade escrevendo em paralelo. Tudo é gravado numa pasta por intent dentro do seu repo, com um arquivo de estado e um log de auditoria só de acréscimo que registra 108 tipos de evento.

A escolha de design mais importante do AI-DLC 2 não aparece nesse mapa. A rota é decidida por um motor determinístico, código comum, e não pelo modelo. O modelo pensa dentro de cada estágio. O motor decide qual estágio vem depois, uma Unit só conta como verificada por um comando de checagem que uma pessoa aprovou, os revisores são outros agentes, e as ferramentas do modelo não conseguem reescrever o estado do workflow. A versão 1 confiava que o agente seguiria regras escritas em prosa, e o slop nasce exatamente dessa confiança: um modelo que escolhe a própria rota e corrige a própria lição. A versão 2 tirou esses poderes dele.

Os detalhes do que mudou entre as versões, e de quais gambiarras caseiras o AI-DLC 2 tornou obsoletas, estão em AI-DLC 2: o que mudou.

Um bugfix não precisa de 33 estágios

O décimo princípio do whitepaper original é o que eu guardaria se só pudesse guardar um: nada de workflow engessado. Um bugfix não precisa de modelagem de domínio. Uma feature nova precisa. A IA propõe a profundidade, e o humano ajusta.

O AI-DLC 2 transformou esse princípio em 11 perfis de workflow. Você escolhe um pelo nome, ou descreve o trabalho e o motor sugere.

Perfis de workflow no AI-DLC 2

Para o que não cabe em nenhum, /aidlc compose pede ao agente composer uma rota sob medida e espera a sua aprovação.

Perfil	Estágios	Use para
Classic	18 / 33	A cerimônia da versão 1: Inception e Construction, uma aprovação por estágio. O padrão quando você não escolhe nada.
Express	10 / 33	Requisitos já claros. O caminho mais curto até código e testes.
Feature	33 / 33	Uma feature de produção pelo ciclo inteiro.
Enterprise	33 / 33	Trabalho regulado ou de alto risco. Profundidade máxima e as guardas mais rígidas.
MVP	23 / 33	Um primeiro incremento real, sem a fase de Operation.
Proof of concept	8 / 33	Isso funciona, afinal?
Bugfix	9 / 33	Um defeito conhecido, uma correção focada, um teste de regressão.
Refactor	10 / 33	Muda a estrutura, mantém o comportamento.
Infrastructure	13 / 33	Ambientes, IaC, pipelines, custo.
Security patch	10 / 33	Uma CVE ou uma vulnerabilidade pontual.
Workshop	26 / 33	Uma sessão de treinamento facilitada.

E existe uma décima segunda resposta que a tabela não lista: não usar AI-DLC. No rollout que acompanhei, um engenheiro rodou o ritual inteiro para mudar uma única linha de código. O playbook interno logo ganhou uma regra nova, escrita por alguém do piloto: se você já sabe exatamente o que digitar, digite. O AI-DLC se paga quando o trabalho pede decomposição e decisões de mais de uma pessoa. Abaixo disso, a cerimônia custa mais do que economiza.

Os gates são o método

Tire tudo do AI-DLC e sobra um loop. A IA produz um artefato. Uma pessoa confere. O próximo passo usa o artefato conferido como entrada. O whitepaper chama cada conferência humana de função de perda (loss function): ela pega a decisão errada onde voltar atrás é barato, antes que ela se multiplique por tudo o que vem depois.

Essa leitura está certa, e esconde o ponto mais fraco do método. O gate só é tão bom quanto a pessoa parada nele, e a IA produz artefatos mais rápido do que uma pessoa consegue ler com cuidado. O que eu vi quebrar, em ordem de frequência:

Como os gates falham na prática

• ✗Anti-pattern:
  O artefato parece completo e não diz nada.Um documento de requisitos bem formatado parece de verdade. Alguém de produto no rollout comparou com um e-mail falso do banco: o formato familiar desliga o ceticismo.
• ✗Anti-pattern:
  Quem revisa está cansado.Depois de uma hora lendo documentos gerados, as pessoas aprovam sem ler. Sessões com mais de uma hora viraram carimbo.
• ✗Anti-pattern:
  Quem revisa não conhece o domínio.Os seniores interrogavam cada afirmação e demoravam mais. Os juniores aceitavam a primeira saída. Quanto menos você sabe, mais você confia.
• ✗Anti-pattern:
  A décima aprovação do dia.A confiança se calibra pelo histórico. O agente acertou nove vezes, então a décima ganha uma olhada.

A correção é mais de ritmo do que de ferramenta. Sessões de uma hora. Pausa entre gates; o arquivo de estado faz a pausa custar zero. Manager presente nos primeiros mobs para segurar a pressa de aprovar. E uma regra para toda pessoa que revisa: antes de aprovar, diga numa frase o que o artefato faz e por que está certo. Se não consegue, você não terminou de ler. O argumento completo, com as contramedidas, está em gates são uma função de perda.

O AI-DLC precisa de Spec-Driven Development antes

Aqui está a minha principal discordância com o jeito como o AI-DLC costuma ser apresentado. Os times ouvem falar, se empolgam com os agentes e as fases, e tentam pular do autocomplete para um ciclo de 33 estágios. Não funciona, e o motivo não é a ferramenta.

O AI-DLC assume que o seu pessoal já sabe especificar. Cada gate pede para uma pessoa julgar uma spec: requisitos, histórias, design, o plano de cada Unit. Um time que nunca praticou escrever spec não consegue julgar uma. Então o agente produz artefatos plausíveis baseados nas próprias suposições, as pessoas aprovam porque parecem bons, e o código que sai do outro lado precisa ser consertado na mão. A execução que o agente deveria carregar volta para as pessoas. Isso é mais lento do que escrever o código você mesmo.

O modelo vai satisfazer qualquer especificação que você der, boa ou ruim. Estatisticamente ele cai em qualquer ponto entre a melhor e a pior versão do que você quis dizer. Especificar bem é a única alavanca que mexe nessa distribuição, e é por isso que eu vejo Spec-Driven Development como o degrau antes do AI-DLC, não como concorrente.

O caminho do copiloto ao AI-DLC

1. 1

   Scrum com copiloto

   "Autocomplete dentro do processo que você já tem."

   → Digita mais rápido. Mesma estrutura.

2. 2

   Scrum com SDD dentro da tarefa

   "Mantenha a sprint, mas especifique antes de deixar o agente construir."

   → O time aprende a escrever e a julgar spec.

3. 3

   SDD com agente supervisionado

   "O agente constrói a partir da spec; você verifica contra ela."

   → A spec vira contrato, não papelada.

4. 4

   Gestão e execução agênticas

   "O agente planeja e decompõe; as pessoas decidem nos gates."

   → É aqui que o AI-DLC começa a se pagar.

5. 5

   Full agêntico, em bolts

   "Horas por fatia, não pacotes de duas semanas."

   → A cadência para a qual o método foi desenhado.

A maioria dos times que eu encontro está no degrau um ou dois e acha que está perto do topo, porque já entrega mais rápido do que no ano passado. O argumento completo, e como saber em que degrau você está, está em AI-DLC vs Spec-Driven Development.

Não adote o AI-DLC em bloco

O AI-DLC é o framework público mais completo para construir com agentes. Mesmo assim eu não diria para um time adotar.

Adotar em bloco é anunciar “agora a gente faz AI-DLC”. As pessoas vão ler o paper e assistir às palestras, e tentam reproduzir um método desenhado por uma empresa com outra escala, outra cultura e outra stack. Estudam em vez de construir. E quando não encaixa, culpam a si mesmas ou o método.

Trate como gôndola de supermercado. Leve o que resolve um problema que você tem de verdade: artefatos que ficam no repo, gates entre as etapas, fatias medidas em horas, o hábito de deixar a IA perguntar. Deixe o resto. Escreva o que levou, o que deixou e por quê.

O AI-DLC 2 é a prova de que essa é a postura certa. Os times que adotaram a versão 1 construíram camadas por cima: arquivos de estado, retrospectivas, construção em paralelo, regras próprias. O AI-DLC 2 entregou a maior parte disso como recurso nativo. O encanamento caseiro ficou obsoleto numa release. O que sobreviveu foi o julgamento que esses times tinham codificado: as regras contra vibe coding, o ritual para moldar uma intenção, o senso de quando não usar o método. O argumento está em não adote o AI-DLC, roube dele.

O que acontece quando um time de verdade roda o método

A documentação descreve o método. O rollout acrescentou isto.

O throughput sobe desde o primeiro dia e o cycle time piora antes de melhorar. O agente produz código na hora, então as mudanças mergeadas por dev disparam. Mas ninguém redesenhou o code review para o volume novo, então as mudanças se acumulam esperando uma pessoa, e o tempo entre o primeiro commit e o deploy sobe antes de cair. Essa curva em J é a coisa mais previsível de um rollout de AI-DLC, e o motivo mais comum para um manager matar o rollout cedo demais. Mais em por que o AI-DLC te deixa mais lento primeiro.

A context window é restrição de design, não detalhe. Uma Inception num repositório real enche boa parte de uma janela de um milhão de tokens. Os times aprenderam a limpar o contexto em todo gate, nunca no meio de uma fase, e a retomar pelo arquivo de estado. A qualidade caía visivelmente quando a janela passava de três quartos. Código legado piora tudo, porque o agente precisa fazer engenharia reversa do que existe antes de propor qualquer coisa. Está tudo em AI-DLC em brownfield.

Produto não precisa ficar no mob inteiro. Depois da engenharia reversa o agente faz uma lista longa de perguntas, e a maioria é técnica. O padrão que funcionou: os engenheiros respondem as técnicas, e produto entra nas dúvidas de negócio. O guia de Mob Elaboration tem o resto do ritual.

As regras que seguraram a qualidade eram pequenas e específicas. Nunca edite código gerado na mão; volte para o design. Comece as perguntas exploratórias com “Do not update any documents.” Peça a crítica num contexto limpo, porque o agente defende o que escreveu. Estão reunidas em seis regras contra vibe coding dentro do AI-DLC.

E o trabalho muda. Os squads encolhem para pods de um engenheiro e um PM. Engenheiros de backend entregam front-end. O engenheiro continua dono do código em produção, porque quando quebra de madrugada não é o agente que recebe a ligação. Matrizes de competência que premiam escrever código começam a premiar a coisa errada. Isso é do squad ao pod, e o lado da medição está em depois dos story points.

Como começar sem jogar fora um trimestre

Uma primeira rodada de AI-DLC que te ensina alguma coisa

Entrada

Um time que já escreve spec e quer testar o AI-DLC

↓

1. REPODeixe o repositório legível para um agente

   Um AGENTS.md ou CLAUDE.md curto com a stack, os padrões, as bibliotecas proibidas e um exemplo de cada. Código legado sem isso produz chute.

   ↓
2. PICKEscolha uma feature real, não uma correção de uma linha

   Algo que peça decomposição e decisões de mais de uma pessoa. Pequeno o bastante para terminar numa semana.

   ↓
3. INSTALLInstale o motor no agente que você já usa

   aidlc config para o seu harness, depois aidlc doctor. O setup completo no Claude Code tem guia próprio.

   ↓
4. RUNRode o perfil Classic ou Feature

   O Classic é a cerimônia da versão 1 e o começo mais suave. Sessões de uma hora e contexto limpo nos gates.

   ↓
5. MEASURELeia o throughput ao lado do cycle time

   Espere a curva em J. Decida depois de umas quatro semanas se você está aprendendo ou travado.

↓

Saída

Uma feature entregue pelo método, e uma lista honesta do que manter, mudar ou largar.

O setup concreto, com os comandos, está em AI-DLC com Claude Code. Se o seu time ainda não especifica, comece um degrau antes com como escrever uma spec, ou com um kit mais leve como o pi-sdd-kit, e volte quando escrever e julgar spec parecer normal.

O que as análises independentes acrescentam

A AWS escreveu o método, então leia quem não escreveu. O guia de AIDLC da Augment Code mapeia os nomes concorrentes para a mesma mudança (o AI-DLC da AWS, o agentic software development da Forrester, o ADLC da Cycode) e coloca a escolha real como human in the loop contra human on the loop. A Wiz lê o método como problema de segurança: a velocidade é o ativo e o risco ao mesmo tempo, com cerca de um quinto dos pacotes sugeridos pela IA apontando para dependências que não existem. A Mission Cloud acrescenta a ideia de spec viva, mantida em sincronia com o código por um agente. O playbook de SDLC AI-native da Anthropic descreve a mesma cadeia de artefatos versionados vinda de outro fornecedor. Todos convergem no mesmo ponto que o rollout me ensinou: a IA não é a parte difícil. As pessoas nos gates são. A minha versão de campo do ciclo inteiro, escrita na ordem em que você adota, é o playbook de agentic SDLC.

Perguntas frequentes

O que significa AI-DLC?+

AI-Driven Development Life Cycle, o ciclo de vida de desenvolvimento orientado por IA. É um método de desenvolvimento de software publicado pela AWS em julho de 2025, em que um agente de IA planeja o trabalho e produz os artefatos enquanto as pessoas aprovam ou rejeitam nos gates. A implementação open source fica em github.com/awslabs/aidlc-workflows.

O AI-DLC é só para quem usa AWS?+

Não. O método não depende de fornecedor, e o AI-DLC 2 roda dentro do Claude Code, Kiro CLI, Kiro IDE, Codex CLI, Cursor, opencode e GitHub Copilot com o mesmo motor.

Ficam as digitais da AWS: um dos 14 agentes é especialista em plataforma AWS, e vêm junto servidores MCP opcionais da AWS. Em outra nuvem você ignora ou troca.

O AI-DLC substitui o Scrum ou o Agile?+

Substitui os rituais, não os valores. As sprints viram bolts medidos em horas, o planning vira Mob Elaboration e a daily encolhe para poucos minutos. Kanban encaixa melhor do que sprint.

Os times que tentaram manter sprints de duas semanas em volta de um agente viram o agente esperando o calendário.

Qual a diferença entre AI-DLC e Spec-Driven Development?+

Spec-Driven Development é uma prática: escreva a spec, deixe o agente construir a partir dela, verifique contra ela. O AI-DLC é um ciclo completo que assume que o seu time já faz isso, e acrescenta fases, gates, agentes e rituais de time em volta. SDD é o pré-requisito, não a alternativa.

O que é um Bolt no AI-DLC?+

Bolt é a fatia de entrega que substitui a sprint: trabalho medido em horas ou dias em vez de semanas. No AI-DLC 2 é uma fatia planejada sobre uma ou mais Units dependentes, e a ordem de construção segue o grafo de dependências entre as Units.

Preciso do Kiro para usar AI-DLC?+

Não. O Kiro foi a primeira casa dos steering files do AI-DLC, mas o AI-DLC 2 trata sete harnesses como primeira classe, incluindo Claude Code, Cursor e Codex.

O AI-DLC é gratuito?+

É. Os workflows são open source sob a licença MIT-0. Você paga pelo modelo que o seu agente usa, e uma rodada de AI-DLC lê e escreve muito contexto, então acompanhe a conta de tokens nas primeiras rodadas.

Quando não usar AI-DLC?+

Quando você já sabe exatamente o que mudar. Uma correção de uma linha, um typo, uma configuração. O método se paga quando o trabalho pede decomposição e decisões de mais de uma pessoa. Abaixo disso, use um perfil mais leve como Bugfix ou Express, ou simplesmente escreva o código.

Para onde ir agora

O AI-DLC é a resposta pública mais clara até agora para a pergunta que todo líder de engenharia está fazendo: como construir software com agentes sem perder o controle do que vai para produção. A resposta não são os agentes. São os gates, os artefatos e as pessoas capazes de julgá-los. Coloque o seu time para especificar primeiro, leve do método o que encaixa e meça com honestidade quando a curva afundar.