🎬 The 7 phases of AI-driven development

Duração: 08:26
Canal: Matt Pocock
Assistido em: August 24, 2026
Ferramenta usada por ele no vídeo: Claude Code
As fases valem para qualquer abordagem: Ralph loops, GSD, Spec Kit

Visão geral

1. IDEIA        ─── app inteiro, feature, bug fix ou refactor
2. PESQUISA     ─── só se houver dependência externa / explore difícil
3. PROTÓTIPO    ─── só se você precisa impor seu gosto
4. PRD          ─── descreve o destino (end state)
5. KANBAN       ─── PRD → tickets com relações de bloqueio
6. EXECUÇÃO     ─┐
7. QA           ─┘  loop 7 → 5 → 6 → 7 até o produto ficar bom

A tese central: a ideia vira um conjunto de tickets que um agente executa — seja vários agentes em paralelo, seja um agente sequencial percorrendo a lista. Tudo entre a fase 1 e a 5 existe para que esses tickets sejam bons o suficiente para rodar sem você olhando.

O loop: as três últimas fases (Kanban → Execução → QA) se repetem várias vezes. Cada rodada de QA gera novos tickets, que voltam para a execução.

---

Fase 1 — Ideia

Objetivo: definir o que provoca todo o processo.

Passo a passo

1. Escreva a ideia. Pode ser um app inteiro, uma feature, um bug fix ou um refactor — refactors contam.
2. Não se preocupe com o tamanho. O processo escala: aguenta ideias enormes e funciona também para coisas minúsculas e muito focadas.
3. Tenha em mente o destino desde já: essa ideia vai virar um conjunto de tickets. Isso já orienta o nível de detalhe que você precisa nas próximas fases.

✅ Saída da fase: a ideia escrita, com noção de escopo (app / feature / bug / refactor).

---

Fase 2 — Pesquisa (condicional)

Objetivo: cachear o conhecimento que é caro de descobrir, para o agente não precisar redescobrir a cada context window.

Quando fazer

Faça se a ideia envolve fase de explore difícil — tipicamente:

• integração com Stripe ou outro serviço externo;
• integração com uma API pouco comum;
• qualquer fonte de informação difícil de acessar de dentro do repositório.

Passo a passo

1. Rode uma fase de pesquisa explícita antes de qualquer código.
2. Crie um asset com o resultado — ele sugere um research.md.
3. Coloque esse asset dentro do repo (ou em algum lugar que o agente consiga acessar). O motivo é concreto: toda vez que o agente vai trabalhar, ele pode precisar explorar o repositório em uma context window nova. Se essa exploração for cara, você paga o custo de novo, toda vez.
4. Trate a pesquisa como descartável. Ela vive só pelo tempo de vida daquela sprint/ideia.

⚠️ Por que descartar: pesquisa desatualiza e apodrece. Uma pesquisa velha faz o agente tomar o caminho errado justamente onde ela não era mais necessária. Delete quando a ideia terminar.

✅ Saída da fase: research.md versionado no repo, com validade limitada a esta ideia.

---

Fase 3 — Protótipo (condicional)

Objetivo: impor o seu gosto no resultado, com feedback concreto.

Quando fazer

Faça quando você ainda não sabe o que está construindo — ou até por que está construindo. O gatilho é precisar impor taste:

• UI que precisa parecer de um jeito específico ou se comportar de um jeito específico;
• arquitetura de software — não é só para design;
• testar um serviço externo na prática.

Passo a passo

1. Peça ao LLM várias alternativas de uma vez, jogadas em uma rota descartável (throwaway route). É o modelo te mostrando todos os jeitos que ele consegue pensar em construir aquilo.
2. Itere em uma ou duas sessões com human-in-the-loop, até conseguir dizer: "ok, essa aqui é a melhor".
3. Commite o protótipo escolhido no code base. Esse é o passo que a maioria pula.
4. Deixe o protótipo disponível para o agente na hora da implementação — ele passa a ser referência concreta, não descrição.

Por que fazer isso cedo: quando você chega no PRD, tudo já ficou abstrato demais. Você precisa de feedback concreto antes.

✅ Saída da fase: protótipo escolhido, commitado e acessível ao agente.

---

Fase 4 — PRD

Objetivo: descrever o destino — o end state.

Você já tem mais informação: entende as APIs externas (fase 2) e já viu código de verdade no protótipo (fase 3). Agora dá para descrever o fim com confiança.

Passo a passo

1. Descreva o end state, não a implementação. Você não vai saber todas as decisões de implementação ainda — e tudo bem.
2. Foque no que o usuário vê e em como aquilo se comporta. É esse o nível.
3. Faça o agente te interrogar. Prompt o agente para te grelhar sem piedade, descendo por cada ramo da sua árvore de decisão. É aqui que o design é martelado até fechar.
4. Não se prenda ao nome. "PRD" é product requirements document, mas na prática é só um documento que descreve o end state. Chame do que quiser.

💡 Matt usa uma skill write a PRD dedicada a isso (linkada na descrição do vídeo dele).

✅ Saída da fase: documento do end state, com as ambiguidades já resolvidas na interrogação.

---

Fase 5 — Kanban board

Objetivo: transformar o PRD em um plano de implementação paralelizável.

Definição usada no vídeo: um Kanban board é só uma lista de tickets com relações de bloqueio entre eles. Nada além disso.

Passo a passo

1. Quebre o PRD em issues separadas. Ele usa uma skill separada só para essa conversão (PRD → issues).
2. Registre as relações de bloqueio. É isso que diferencia o Kanban de um plano sequencial.
3. Escolha a ferramenta:
   • ele usa GitHub Issues para o PRD e para o Kanban — é o que achou mais fácil;
   • ⚠️ GitHub ainda não tem jeito nativo de representar bloqueio entre tickets;
   • Linear tem — se o bloqueio importa para você, provavelmente é a melhor escolha.
4. Alternativa mais simples: você pode gerar um plano sequencial único que vira código direto. Funciona — só perde a paralelização.

O ganho do Kanban: você olha o board, acha todos os tickets que não estão bloqueados, sobe um agente para cada um e deixa resolverem em paralelo.

✅ Saída da fase: board com tickets e bloqueios explícitos.

---

Fase 6 — Execução

Objetivo: rodar os tickets do board.

Passo a passo

1. Rode um coding agent em loop executando os tickets do Kanban.
2. Comece sequencial. Na maior parte das vezes você não precisa paralelizar — um agente trabalhando ticket a ticket resolve.
3. Paralelize quando fizer sentido, usando os tickets não-bloqueados do board.
4. No caso dele: um Ralph loop, que funciona muito bem com esse setup.
5. Rode AFK. Com research + protótipo + PRD + Kanban dando suporte, dá para deixar o loop de execução rodando sozinho e o resultado sai bom. É exatamente para isso que as fases anteriores existem.

✅ Saída da fase: um asset completo, pronto para ser olhado por um humano.

---

Fase 7 — QA

Objetivo: validar o que foi produzido e realimentar o board.

Passo a passo

1. Peça ao agente um QA plan — um plano para o humano executar o QA do trabalho concluído.
2. Um humano executa o QA. Sim, humano. Ele bate nesta tecla explicitamente.
3. Leia o código produzido durante a execução. Isso faz parte do QA.
   • Pode não ser sempre necessário — ex.: se você usa uma arquitetura gray box (assunto de vídeos anteriores dele).
4. Transforme os achados em novos tickets no Kanban board.
5. Volte para a execução. Execução → QA → mais tickets → execução → QA…
6. Repita até convergir para o produto que você quer.

✅ Saída da fase: board atualizado com os novos tickets, ou o produto aprovado.

---

⚙️ O loop na prática

     ┌───────────────────────────────────┐
     ↓                                      │
5. KANBAN  →  6. EXECUÇÃO  →  7. QA  ───────┘
                              (gera novos tickets)

As três últimas fases se repetem várias vezes. Não espere acertar de primeira — a expectativa é iterar até o produto ficar bom.

---

✅ Um breve checklist de aplicação

Preparação

• Ideia escrita (app / feature / bug fix / refactor)
• Tem dependência externa ou explore difícil? → rodar pesquisa e salvar research.md no repo
• Marcar a pesquisa como descartável ao fim da sprint
• Preciso impor meu gosto (UI, arquitetura, serviço externo)? → prototipar
• Várias alternativas jogadas em uma rota descartável
• Protótipo escolhido commitado e acessível ao agente

Especificação

• PRD escrito descrevendo o end state (o que o usuário vê e como se comporta)
• Agente me grelhou em cada ramo da árvore de decisão
• PRD quebrado em issues
• Relações de bloqueio registradas (Linear, ou contornar a limitação do GitHub)

Loop

• Agente executando os tickets em loop (sequencial por padrão)
• Paralelizar só os tickets não-bloqueados, se valer a pena
• QA plan gerado pelo agente
• QA executado por um humano
• Código lido por um humano (salvo arquitetura gray box)
• Achados viraram tickets novos → voltar para execução

---

🕳️ Lacuna assumida pelo autor

Não há code review explícito nas 7 fases. Ele reconhece isso no fim do vídeo:

"Eu suponho que poderia fazer isso como parte do fluxo de execução. Suponho que talvez entre no QA — mas é definitivamente um passo essencial para produzir bom código."

Ele também diz esperar que a lista cresça para 8 ou 9 fases conforme for aprendendo. Trate as 7 fases como um esqueleto vivo, não como dogma.