# AI driven development: o workflow de 7 fases

> Published 2026-10-11T02:08:35.105Z on https://www.crazystack.com.br/pt/p/ai-driven-development-o-workflow-de-7-fases/
> Source video: https://www.youtube.com/watch?v=LmUsdFWuaGg

AI driven development funciona bem quando você segue sete fases: ideia, pesquisa, protótipo, spec, tickets pequenos, execução e revisão. Pular direto para pedir código ao agente é o caminho mais curto para soluções quase certas, mas não totalmente certas, que a maioria dos desenvolvedores reclama de receber.

## AI driven development: as sete fases que funcionam

AI driven development funciona em sete fases: ideia, pesquisa, protótipo, spec (ou PRD), tickets pequenos, execução e revisão. As três primeiras acontecem antes do ticket existirem, e a fase de spec é a única considerada imprescindível pelo próprio fluxo. Começar e terminar na execução é o erro que deixa você mais lento, não mais rápido.

Esse roteiro se inspira no vídeo do Matt Pocock sobre desenvolvimento com IA, mas aqui cada etapa vem acompanhada de embasamento: pesquisas da academia, boas práticas da indústria e dados das próprias empresas. O objetivo é resolver a frustração mais comum do desenvolvedor que usa agentes como o [Claude Code](https://docs.anthropic.com/en/docs/claude-code), ferramenta de codificação agêntica da [Anthropic](https://www.anthropic.com) que roda no terminal.

A regra de ouro que atravessa todas as fases é simples: não confie apenas no modelo interno de raciocínio da IA. Quanto mais ferramental você fornecer, documentação atualizada, esquema do banco de dados, exemplos, melhor o resultado. No vocabulário da ciência de dados, isso é evitar o garbage in, garbage out.

## Fases 1 a 3: ideia, pesquisa e protótipo antes do ticket

As três primeiras fases existem porque um input vago gera um output vago. Pedir 'construa um dashboard' garante que algum dashboard será feito, mas provavelmente não o que você precisa. Antes de abrir o terminal, você cristaliza a ideia respondendo a perguntas concretas.

## ### Fase 1: ideia cristalizada

Transforme 'construa um dashboard' em algo específico: ele é uma tab nova ou uma página principal? Mostra pedidos ou vendas, em gráfico de barra ou de linha? Para quem? Se o lojista só enxerga os próprios pedidos, você já identificou uma exigência de autenticação e uma restrição de dados. Defina também o objetivo, a métrica de sucesso e as boundaries: o dashboard altera o banco? Cria view nova? Os limites dizem onde o trabalho termina.

## ### Fase 2: pesquisa (interna ou externa)

Nem toda tarefa exige pesquisa, e pesquisa não significa apenas consultar a web. Descobrir de qual tabela puxar o pedido do mês passado é pesquisa interna, e faz diferença quando você não confia que a IA vai identificar o esquema corretamente. Você não precisa escrever isso tudo à mão: use o modo de plano (o /plan do Claude Code, recurso equivalente no [Codex](https://openai.com/codex), da OpenAI, e no [Cursor](https://cursor.com), editor com IA) para guiar o agente com prompts estruturados. O repositório de prompts do [Gemini CLI](https://github.com/google-gemini/gemini-cli), da Google, é uma referência popular para esse tipo de técnica.

## ### Fase 3: protótipo (opcional)

O protótipo não faz sentido em tarefas pequenas, mas vale a pena em dois cenários: quando você começa um projeto do zero e quer validar se as etapas do negócio funcionam, e em migrações grandes, como portar uma codebase inteira de Python para Go. A prototipagem é prática consolidada em engenharia de software há muito tempo, e estudos de especificação de requisitos, como os revisados na literatura de 2024, mostram que investir na especificação antes do código reduz retrabalho.

## Fase 4: spec e PRD, a etapa imprescindível

Quando você conversa com a IA existe muita ambiguidade, e a spec é onde ela aparece. Forçar o agente a escrever um PRD detalhado, de onde vem cada dado, como será exibido, qual biblioteca será usada, deixa explícita a distância entre o que você pensou e o que a IA entendeu. Como dono do código, você valida se aquilo faz sentido antes de uma linha ser gerada.

Das fases iniciais, esta é a primeira imprescindível. Uma spec cristalizada é o que transforma um pedido vago em um contrato verificável, e é ela que permite quebrar o trabalho em tickets com confiança. A partir daqui, é engenharia de software, na verdade, tudo desde a fase 1 já era.

## Fase 5: tickets de até 500 linhas de lógica

Cada ticket deve representar no máximo cerca de 500 linhas de lógica de código. Testes, documentação e arquivos de configuração não entram nessa conta. Janelas de contexto gigantes não se traduzem em qualidade proporcional: prefira vários pull requests pequenos a um único de 5.000 linhas, mesmo que algum produto de ponta consiga gerar algo assim, porque o custo e a dificuldade de revisão explodem.

Tarefas pequenas são melhores quando todo o resto se mantém constante: você estima melhor o esforço, revisa com mais facilidade, faz merge com menos risco e testa com mais precisão. Mesmo que você não leia o código da IA linha a linha, um colega consegue revisar um ticket pequeno sem perder o contexto. Se você estuda system design ou prepara entrevistas, essa disciplina de decomposição é a mesma ensinada em formações como o [Crazystack](https://crazystack.com.br) e o Bootcamp do Dev Doido, criadores como o Gustavo Dev Doido e o Augusto Galego repetem o princípio em contextos diferentes.

## Fase 6: execução com 2 a 5 tickets em paralelo

Se você respeitou a regra dos tickets pequenos, a execução é a parte mais fácil. Você orquestra manualmente, sem workflow maluco: três agentes em paralelo trabalhando em três tickets diferentes é um limite razoável para uma pessoa não perder o rastro do que está acontecendo.

Na prática, a margem fica entre dois e cinco tickets simultâneos, dependendo da complexidade. O autor do fluxo costuma trabalhar com dois ou três: quando as tarefas são rápidas, ele as faz em sequência, uma e revisão, uma e revisão; quando são complexas, distribui em paralelo.

## Fase 7: revisão, testes e o loop até a aprovação

A última fase é revisar o código, sozinho ou junto com agentes, verificar o que está certo e o que não está, e repetir o ciclo entre execução e revisão até a aprovação e o passe nas pipelines. Práticas como TDD aumentam a assertividade: os próprios agentes executam os testes, veem o output, criam testes que falham e corrigem o erro sozinhos.

Uma spec bem definida mais testes automatizados formam o fechamento do loop. É por isso que começar e terminar na execução é um erro: sem as etapas anteriores, o loop de revisão vira uma disputa de vaivém contra um agente que nunca soube exatamente o que você queria.

## Quando você pode pular etapas sem culpa

Nem toda tarefa precisa das sete fases. Um bug pequeno de produção, uma nota fiscal que deveria valer 30,00 e aparece como 29,99999999997 por causa de ponto flutuante, permite pular quase tudo: você descreve o sintoma ao agente, ele encontra a causa, escreve o fix, passa nos testes e na pipeline, e você manda bula direto.

Em tarefas complexas, em uma codebase complexa, o cálculo muda. Aí sim você volta às fases, cristaliza a ideia, pesquisa o contexto, escreve a spec, quebra em tickets e só então executa. O workflow é uma ferramenta, não um ritual, e o julgamento sobre quando aplicá-lo completo é parte do trabalho.

| Fase | O que você produz | Obrigatória? |
| --- | --- | --- |
| 1. Ideia | Objetivo, métrica de sucesso, boundaries | Sim, em qualquer escopo |
| 2. Pesquisa | Contexto interno, esquema, documentação | Depende da tarefa |
| 3. Protótipo | Validação de viabilidade | Não |
| 4. Spec/PRD | Contrato escrito do que será feito | Sim, a imprescindível |
| 5. Tickets | Tarefas de até 500 linhas de lógica | Sim |
| 6. Execução | Código + 2 a 5 agentes em paralelo | Sim |
| 7. Revisão | Loop até testes e pipeline passarem | Sim |

## FAQ sobre ai driven development

- **Preciso usar o Claude Code especificamente?** Não. O fluxo vale para qualquer agente de codificação, incluindo Codex e Cursor. O que muda de ferramenta para ferramenta é o comando do modo de plano e os detalhes de orquestração, não as sete fases.

- **Por que limitar tickets a 500 linhas de lógica?** Porque tarefas pequenas são mais fáceis de estimar, revisar, testar e mesclar quando todo o resto se mantém constante. Contexto gigante no modelo não garante qualidade proporcional, e pull requests gigantes custam caro e dificultam a revisão.

- **O protótipo é sempre necessário?** Não. Ele faz sentido ao iniciar um projeto do zero ou em migrações grandes, como trocar a linguagem de uma codebase inteira. Em tarefas pequenas, prototipar é perda de tempo.

- **Quantos agentes posso rodar em paralelo?** Entre dois e cinco, dependendo da complexidade dos tickets. O limite prático é você conseguir manter o contexto do que cada agente está fazendo sem perder o controle da integração.

- **A IA fica mais lenta em algumas tarefas?** Isso depende da tarefa e do contexto. Observações da indústria mostram aceleração em alguns tipos de trabalho e desaceleração em outros, e a pesquisa da Stack Overflow de 2025 registrou 66% de desenvolvedores frustrados com soluções quase certas. O workflow completo é justamente a resposta a esse dado.

## Do vídeo ao artigo: transforme seu conteúdo em referência

Este artigo nasceu de um vídeo de 11 minutos sobre as sete fases do desenvolvimento com IA, e é exatamente esse tipo de transformação que o [Skala Blog](https://skalablog.com) faz. Se você explica processos, compara ferramentas ou ensina boas práticas em vídeos no YouTube, esse conhecimento pode virar um artigo estruturado, com títulos pesquisáveis, FAQ e respostas diretas, pronto para ser encontrado por quem procura o assunto. Você cola o link do vídeo, o conteúdo é transcrito e um artigo como este é gerado para você revisar e publicar.

[Source video](https://www.youtube.com/watch?v=LmUsdFWuaGg)