AI driven development: o workflow de 7 fases

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, ferramenta de codificação agêntica da Anthropic 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, da OpenAI, e no Cursor, editor com IA) para guiar o agente com prompts estruturados. O repositório de prompts do 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 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 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