O ponto cego do AI-DLC: de onde vem a Intent

O AI-DLC transforma uma intent em software com disciplina de verdade. Nada nele confere se a intent valia a pena ser construída.

Todo workflow de AI-DLC começa com uma Intent: a declaração do que precisa ser alcançado e por quê. O método, do jeito que a AWS o apresentou, define isso numa frase. O agente decompõe a intent em Units, as partes independentes em que o trabalho é dividido, as Units viram código, e uma dúzia de gates humanos confere cada passo pelo caminho. É uma máquina cuidadosa. Também é uma máquina que assume que a primeira entrada estava certa.

Essa suposição é a origem da maior parte da dor que eu vi. No rollout que acompanhei dentro de uma grande organização de engenharia, os times que sofreram com o AI-DLC quase nunca sofreram com o agente. Sofreram porque o que entrou lá em cima era vago, desatualizado ou mirava o resultado errado, e o método processou isso fielmente até o fim.

O whitepaper é honesto sobre a divisão do trabalho. As pessoas definem o destino. A IA dá as direções. O que ele não diz é como um time chega a um destino que vale a viagem. Essa é a lacuna do upstream, e este artigo é sobre o ritual que a fecha.

Erros na intent se multiplicam

Num workflow de AI-DLC, cada fase lê a saída da anterior como contexto. Os requisitos são construídos a partir da intent. As histórias, a partir dos requisitos. As Units, a partir das histórias. O código, a partir das Units. Essa cadeia é o que torna o método rastreável. Também é o que torna caro um começo ruim.

Uma intent vaga não produz código vago. Produz código confiante. O agente preenche cada lacuna que encontra com a resposta estatisticamente mais provável, e cada fase seguinte trata essa resposta como fato decidido. Quando o erro aparece num code review, ele já foi codificado em requisitos, histórias, um modelo de domínio e alguns milhares de linhas de implementação.

O whitepaper chama cada conferência humana de função de perda (loss function): um ponto onde uma decisão errada é podada antes de crescer. Leve essa lógica até o fim e a intent é a função de perda mais valiosa do ciclo inteiro, porque é a que tem mais trabalho pendurado depois dela. Uma decisão errada na intent sai mais barata de corrigir na própria intent. Cada gate seguinte cobra mais caro pela mesma correção.

O AI-DLC 2 acrescentou a Ideation, e a maioria das rodadas pula

A AWS viu a lacuna com clareza. O AI-DLC 2 acrescentou uma fase inteira antes da Inception (a fase em que requisitos e design são decididos), chamada Ideation, com sete estágios: Intent Capture and Framing, Market Research, Feasibility and Constraints, Scope Definition, Team Formation, Rough Mockups e Approval and Handoff.

O Intent Capture é bem desenhado. O agente de produto pergunta sobre o problema de negócio, o cliente, as métricas de sucesso, o gatilho da iniciativa e quem tem autoridade de decisão. Cada linha relevante da declaração de intent resultante carrega uma tag que diz de onde veio: a sua descrição original, uma resposta específica que você deu, uma regra guardada do time ou uma suposição. As suposições precisam ser confirmadas explicitamente, e confirmar uma mantém o rótulo. Isso não promove um palpite a fato. É exatamente a disciplina de que o upstream precisa.

Agora veja quais workflows rodam isso de verdade.

Quais perfis do AI-DLC 2 rodam a Ideation

O Classic é o perfil que o motor usa quando você não escolhe nenhum. Numa rodada padrão, a intent é o que você digitou depois de /aidlc.

Perfil de workflow	Ideation
Feature, Enterprise	Os sete estágios
MVP	Uma versão leve: intent, viabilidade, escopo, mockups
Proof of concept	Só uma captura mínima de intent
Classic, Express, Bugfix, Refactor, Infrastructure, Security patch, Workshop	Pulada inteira

Isso faz sentido para um bugfix, em que o problema é o bug. Faz menos sentido para os muitos times que começam pelo Classic porque é o padrão e parece a versão 1. Nessas rodadas, a intent é a frase que você digitou depois de /aidlc, mais o que o agente deduzir do seu repositório.

E nem a fase completa de Ideation consegue fazer a parte mais difícil. Ela estrutura o que alguém na sala sabe. Não descobre o que ninguém sabe. Se o PM não tem certeza de que o problema vale a pena ser resolvido, sete estágios bem desenhados vão produzir uma intent lindamente tagueada para um problema incerto.

Cinco perguntas antes do primeiro prompt

Os times que foram bem tinham uma coisa pronta antes de o AI-DLC começar: um documento de entrada. Alguns chamavam de six-pager, por causa do hábito da Amazon de memorandos narrativos. O nome não importa. As perguntas importam.

A intent precisa responder cinco perguntas

• ✓Obrigatório:
  Qual é o problema?Escrito como algo que dói hoje, não como uma feature a construir.
• ✓Obrigatório:
  Para quem?Um usuário ou grupo de clientes real. 'Usuários' não é resposta.
• ✓Obrigatório:
  Que resultado esperamos?O que vai estar diferente quando isso for para produção.
• ✓Obrigatório:
  Quais são as restrições?Prazos, regulação, sistemas em que não se pode mexer, orçamento e o que está explicitamente fora do escopo.
• ✓Obrigatório:
  Como vamos saber que funcionou?Uma métrica que se mexe, não um entregável que passa a existir. Mais sobre isso abaixo.

Nada disso é novo. É pensamento de produto, e gente boa de produto sempre fez isso. O que mudou é o custo de pular. Quando um time de pessoas construía a partir de um ticket vago, a vagueza era resolvida devagar, em cem conversas pequenas. Quando um agente constrói a partir de uma intent vaga, ele resolve a vagueza na hora, sozinho, e anota o resultado como se alguém tivesse decidido.

É também aqui que Spec-Driven Development ganha o seu lugar como o degrau antes do AI-DLC. Um time que praticou escrever spec, com o porquê, o quê e o escopo negativo explícito, já sabe responder essas cinco perguntas. Um time que não praticou vai achar as perguntas mais difíceis que o código.

Deixe o tamanho do problema decidir quanto a IA faz

Uma das melhores ideias que eu vi no rollout veio de quem usava as ferramentas de upstream, não de quem as construía. Uma pessoa de produto e uma de design, que testaram cedo, pediram um passo de triagem antes de qualquer coisa: classificar o problema primeiro e depois decidir quanto o agente pode fazer.

A triagem não muda quantas perguntas o agente faz. Muda o que o agente tem permissão de gerar sozinho.

Triagem de complexidade antes da intent

A classificação é um gate, não um veredito. Se o agente diz baixa e o problema atravessa três times, corrija antes de continuar.

Complexidade	O que o agente faz	O que a pessoa faz
Baixa	Roda a descoberta de ponta a ponta e entrega um rascunho de intent.	Lê e aprova ou corrige.
Média	Conduz seção por seção, com uma conferência depois de cada uma.	Responde e aprova cada seção antes da próxima.
Alta, muitos stakeholders	Só facilita. Organiza a conversa e nunca gera estrutura por conta própria.	É dona de cada decisão. O agente toma notas.

O anti-pattern aqui é o atalho na direção contrária. O agente classifica o problema como de alta complexidade, alguém força a classificação para conseguir um rascunho autônomo completo mais rápido, e o rascunho sai com buracos do tamanho dos stakeholders que ninguém consultou. Esses buracos entram no ciclo como uma intent vaga, e você já sabe o que acontece depois.

Dê ao agente um índice curado, não a wiki inteira

Toda empresa tem uma wiki cheia de documentos. Alguns estão atualizados. Muitos não. Um agente com acesso a tudo não consegue diferenciar, e vai construir a sua intent sem a menor cerimônia em cima de uma decisão que a empresa reverteu dois anos atrás.

Eu vi isso acontecer ao vivo. Durante uma demo de um agente de descoberta de upstream, ele puxou um documento de 2022 para o contexto de um projeto atual. A pessoa de produto que conduzia a demo conhecia o domínio, percebeu e corrigiu. Alguém com menos contexto teria aprovado, porque parecia exatamente um documento relevante.

A solução que o time usou é sem glamour e funciona: um índice curado por área da wiki, mantido na mão, listando as fontes que o agente pode tratar como confiáveis. O agente lê o índice primeiro e só segue links a partir dele. Montar o índice é trabalho chato. Também é a pré-condição para confiar em qualquer coisa que o agente escreva no upstream, pelo mesmo motivo que um bom AGENTS.md importa no downstream: o agente só é tão bom quanto o contexto que você escolhe dar a ele.

Um critério de sucesso é um resultado, nunca um artefato

Esse foi o erro mais comum que eu vi o agente cometer, e o que tem mais chance de passar por quem revisa cansado.

Numa sessão ao vivo, uma pessoa de produto estava moldando a intent de um backoffice interno que ia substituir uma ferramenta paga de um fornecedor. O agente rascunhou os critérios de sucesso e escreveu, em essência, que sucesso era a documentação estar completa. A pessoa parou e contestou. A documentação era o entregável desta etapa. O sucesso da feature era cortar o custo do fornecedor e responder a um movimento que um concorrente tinha feito. Um documento existir não é resultado de negócio.

A pessoa estava certa, e o agente aceitou a correção. Mas repare como a versão errada era plausível. “Documentação completa” e “épico criado” são coisas que um time produz, então parecem progresso. Elas medem atividade. Uma intent cujo critério de sucesso é um artefato vai produzir um ciclo otimizado para produzir esse artefato.

Critérios de artefato (rejeite)

1. 01A documentação está completa
2. 02O épico foi criado no tracker
3. 03A API está em produção
4. 04As telas batem com os mockups

Critérios de resultado (peça estes)

1. 01O contrato com o fornecedor pode ser cancelado
2. 02O abandono do checkout cai no mobile
3. 03Os tickets de suporte sobre reembolso diminuem
4. 04O onboarding leva um dia em vez de cinco

A mesma sessão mostrou duas lições menores. Primeiro, o agente deduz trabalho a partir de palavras-chave. O concorrente tinha sido mencionado de passagem, então o agente começou um benchmark competitivo que ninguém tinha pedido. Diga explicitamente o que está fora do escopo, ou o agente vai inventar escopo a partir do seu vocabulário. Segundo, quando essa busca de benchmark falhou por um erro de rede, o agente disse que não ia inventar dados. Isso é um bom sinal. Se o seu inventa uma análise de mercado quando uma fonte está fora do ar, você tem um problema maior do que a intent.

Completude vale mais que formato

As ferramentas de upstream costumam produzir um documento-resumo arrumado, e a suposição natural é que o resumo é a entrada do downstream. Um time aprendeu o contrário. O resumo que o processo de upstream deles gerou tinha cortado contexto que o ticket original tinha, e eles gastaram um tempo considerável recolocando esse contexto durante a Inception.

A lição que eles anotaram: o AI-DLC não precisa de um formato específico como entrada. Precisa da informação mais completa disponível. Se o ticket original tem mais detalhe que o resumo, entregue o ticket. Entregue os dois. Registre quais documentos você passou, para a próxima pessoa saber o que o agente sabia. Um resumo é escrito para comunicar uma decisão a pessoas. Não é escrito para preservar cada restrição de que um agente vai precisar.

Convincente não é o mesmo que correto

Alguém de produto no rollout explicou o risco da descoberta gerada por IA com uma analogia que eu vivo repetindo. Quando chega um e-mail do seu banco, você olha com cuidado. O link está certo? O logo está torto? Um six-pager gerado é o caso oposto. Parece tanto com um de verdade que você para de tomar cuidado. E aí você lê de fato e percebe que não tem nada ali.

Quanto melhor o formato, menos as pessoas leem. É por isso que a intent precisa da assinatura de uma pessoa nomeada, com conhecimento do domínio, antes de qualquer coisa começar no downstream. Nas sessões que eu vi, as pessoas mais seniores interrogavam cada afirmação do agente e demoravam mais. As menos experientes aceitavam o primeiro rascunho e seguiam. Para um time sem essa experiência, forme duplas: uma pessoa conduz a sessão, outra que conhece o domínio aprova o resultado.

O ritual de upstream antes de o AI-DLC começar

Entrada

Um problema que alguém acha que vale a pena resolver

↓

1. TRIAGEClassifique o problema

   Complexidade baixa, média ou alta decide quanto o agente pode gerar sozinho.

   ↓
2. SOURCESAponte o agente para fontes curadas

   Um índice de documentos confiáveis, não a wiki inteira. Anexe o material mais completo que você tiver.

   ↓
3. FIVEResponda as cinco perguntas

   Problema, para quem, resultado esperado, restrições com o fora de escopo explícito e uma métrica de resultado.

   ↓
4. SIGNUma pessoa dona do domínio assina a intent

   Alguém que pegaria uma regra desatualizada ou um artefato disfarçado de critério de sucesso.

↓

Saída

Uma intent que vale a pena decompor. Agora a Inception tem algo real com que trabalhar.

A intent é a primeira metade de uma spec

Se você já leu outras coisas que eu escrevo, dá para ver aonde isso vai. A intent é a camada de cima de uma spec: o porquê e o quê, antes do como. No workflow de Spec-Driven Development que eu uso, essa camada é o documento de requisitos de produto, e ele é aprovado antes de qualquer decisão de design. Como escrever uma spec cobre o formato em detalhe.

O AI-DLC 2 chega mais perto disso com a Ideation, e as tags de origem em cada afirmação são uma boa ideia. Mas uma fase que pode ser pulada não é um hábito, e o workflow padrão pula. O hábito tem que viver no time. Se o seu pessoal não consegue responder as cinco perguntas sozinho, o método vai responder por você, e vai responder com a média de tudo o que já leu.

Perguntas frequentes

O que é uma Intent no AI-DLC?+

Uma Intent é a entrada inicial de um workflow de AI-DLC: uma declaração de alto nível do que precisa ser alcançado e por quê, seja um objetivo de negócio, uma feature ou um resultado técnico. A IA a decompõe em Units de trabalho. No AI-DLC 2, cada Intent também ganha a própria pasta no repositório, onde ficam todos os artefatos, decisões e registros de auditoria daquele trabalho.

Qual a diferença entre uma Intent e uma Unit?+

A Intent é o porquê: uma declaração de propósito. Uma Unit é um pedaço do como: uma parte autocontida da solução, derivada da Intent, que pode ser construída e implantada sozinha. Uma Intent normalmente gera várias Units.

O AI-DLC precisa de um PRD ou de um six-pager?+

O método não exige um documento específico. Precisa da informação mais completa disponível sobre o problema, no formato que o seu time usar.

Na prática, os times que chegavam com um documento de entrada estruturado, respondendo problema, usuários, resultado, restrições e métrica de sucesso, tiveram muito menos retrabalho do que os times que digitavam uma frase depois do comando.

A fase de Ideation roda em todo workflow do AI-DLC 2?+

Não. Feature e Enterprise rodam os sete estágios de Ideation, o MVP roda uma versão leve e o Proof of concept roda uma captura mínima de intent. O Classic, que é o padrão quando você não escolhe um perfil, pula a Ideation inteira, assim como Express, Bugfix, Refactor, Infrastructure, Security patch e Workshop.

Qual deve ser o tamanho de uma intent?+

O necessário para responder as cinco perguntas com honestidade. Para uma tarefa pequena, um parágrafo. Para uma iniciativa entre times, algumas páginas. O tamanho não é o teste. O teste é se alguém sem contexto consegue dizer que problema você está resolvendo, para quem e como vai saber que funcionou.

Qual é o erro mais comum numa intent gerada por IA?+

Um critério de sucesso que é um artefato em vez de um resultado: 'documentação completa' ou 'épico criado' em vez de uma métrica de negócio que se mexe. O segundo mais comum é informação desatualizada puxada de uma wiki sem curadoria.

Para onde ir agora

O AI-DLC é excelente para transformar uma boa intent em bom software, e indiferente a se a intent era boa. Essa parte continua sendo sua. Faça a triagem do problema, cuide das fontes, responda as cinco perguntas e coloque alguém que conhece o domínio para assinar antes de a máquina começar.