AI SDLC: um compêndio de boas práticas para desenvolver com IA

Há muito hype em torno do desenvolvimento assistido por IA. Claude, Copilot, Cursor… a lista cresce toda semana. E sim, essas ferramentas são poderosas. A IA é excelente para um PoC, mas colocar em produção é outra história.

O que é o AI SDLC?

O AI SDLC é a integração de ferramentas e sistemas de IA em cada fase do ciclo de desenvolvimento de software tradicional — planning, analysis, design, coding, testing, deployment e maintenance — para potencializar o desenvolvedor humano e melhorar velocidade, qualidade e tomada de decisões. Como resume a IBM neste artigo, a ideia não é substituir o dev, e sim acrescentar uma camada inteligente ao longo de todo o processo. E eles alertam para algo fundamental: o código gerado por IA «may look correct, but can contain subtle problems» — pode parecer correto e esconder problemas sutis. Por isso a abordagem human-in-the-loop é quase obrigatória em qualquer projeto sério.

Este post não pretende cobrir as sete fases. É um compêndio de boas práticas durante o AI SDLC, focado na parte em que o dev está mais no loop: design, construção e revisão. Não é a verdade absoluta; você vai encontrar muitas outras práticas e padrões à medida que se aprofundar. É o que funciona para mim.

A IA é ótima para um PoC — mas um PoC não está pronto para produção

As AI dev tools são fantásticas para começar do zero e ter algo funcionando rápido. Você diz o que quer, deixa rodar e, em minutos, tem um PoC. O problema é que esse código não necessariamente segue boas práticas de design, arquitetura ou coding. Na maioria dos casos, o que sai não é um produto pronto para produção.

E aqui vem a parte incômoda: você precisa entender o código. O vibe coding serve para um mockup, mas não para algo prod-grade. E isso continua valendo mesmo com o modelo mais recente e as melhores ferramentas.

Os cenários: onde a IA brilha e onde se complica

Criar um PoC totalmente funcional do zero — muito bem. É o terreno onde ela mais brilha.
Adicionar features simples a um codebase — bem. Em geral não exige muito mais ajuda.
Adicionar features complexas a um codebase complexo — mais ou menos. Aqui já precisa de bem mais guidance do dev.
Modificar features existentes em um codebase simples — bem. Em geral, menos guidance.
Modificar uma feature existente em um codebase grande — bem. Continua sem exigir muita orientação.
Implementar uma feature complexa em um codebase grande — aqui fica difícil. Não importa quanto contexto, skills ou hooks você tenha, nem quão bom seja o seu prompt: aqui você precisa de um bom plano. É muito fácil o agente gerar código não ideal — provavelmente código que funciona, mas não escalável, propenso a erros, pouco legível etc.
Codebases grandes em geral, e migrações de código — a coisa fica realmente delicada.

A conclusão: quanto maior e mais complexo o codebase, e quanto mais complexa a feature, mais cai a utilidade da IA deixada sozinha — e mais sobe a importância do dev no loop.

Quando você vai colocar em produção: meu fluxo de AI SDLC

Quando você quer levar algo para produção, o vibe coding não é a resposta — pelo menos não se você espera que o agente faça tudo. Estas são as boas práticas que aplico, com base na minha experiência pessoal:

1. Projete antes de escrever prompts

Antes de escrever um único prompt, é você quem decide a arquitetura, o design e a linguagem. Você pode fazer brainstorming com a IA, mas deveria ter projetado de antemão cada aspecto da aplicação e da infra.

2. Peça um plano detalhado

Use esse design e peça à IA que gere um plano detalhado, com suas instruções e decisões já tomadas como input.

3. Revise o plano!

Com cuidado. Peça as modificações necessárias. Eu normalmente peço que ela crie um arquivo .md que tanto a IA quanto eu possamos modificar e revisar — não deixo só no prompt.

4. Divida e avance

Quando o plano estiver OK, quebre as tarefas maiores em tarefas pequenas e comece.

5. Nunca deixe que ela faça tudo sem perguntar

Revise cada mudança. Complete um commit. Nesta etapa, gosto de revisar as mudanças do commit mais uma vez. O código gerado por IA parece bom, e é fácil deixar passar problemas numa única passada. Quando estiver satisfeito com esse commit, siga para o próximo passo.

6. Revisão final, em triplicata

Quando estiver tudo pronto, peça à IA que revise mais uma vez para encontrar possíveis problemas. E faça você mesmo uma inspeção manual rápida do seu código novo. Essa é a terceira revisão.

Mais práticas que vale a pena considerar

Testes como guardrail

Peça à IA que escreva testes, mas com olhar crítico. Às vezes ela gera testes que passam de forma trivial, ou que testam a implementação em vez do comportamento real. Os testes são sua rede de segurança quando você deixa o agente modificar código, mas é preciso revisá-los com a mesma desconfiança que o resto. Um teste que nunca falha não protege você de nada.

Segurança: nunca confie cegamente

A IA facilmente coloca secrets hardcoded, dependências inseguras, validações faltando ou vulnerabilidades de injeção. Funciona, mas deixa a porta aberta. Revise sempre o código gerado pelo ângulo da segurança: que dados ele toca, o que valida, o que expõe.

Ferramentas determinísticas no loop

Nem tudo precisa passar pelo seu critério ou pelo do modelo. Linters, type checkers, formatters e CI pegam automaticamente um monte de coisas que nem você nem o agente deveriam revisar à mão. Deixe as ferramentas determinísticas fazerem o trabalho delas e reserve sua atenção para o que realmente exige julgamento.

Cuidado com o scope creep

O agente tende a «melhorar» coisas que você não pediu, ou a mexer em arquivos fora do escopo da tarefa. De repente, uma mudança simples veio com três refactors surpresa. Mantenha-o focado no que você pediu; as mudanças fora do escopo são uma das formas mais fáceis de introduzir bugs que ninguém esperava.

Saiba quando escrever você mesmo

Às vezes, explicar à IA como fazer algo custa mais do que fazer à mão. Reconhecer esse ponto é uma skill por si só. A IA é uma ferramenta, não uma obrigação: se você vai levar menos tempo escrevendo o código você mesmo, escreva.

Escolha o modelo e o effort certos para cada tarefa

Nem tudo merece o modelo mais potente no effort máximo. Para tarefas simples — renomear, refactors mecânicos, boilerplate — um modelo mais leve basta e sobra. Reserve os modelos grandes e o reasoning alto para o que realmente precisa: arquitetura, features complexas, debugging difícil. Economizar custos e tokens não é só uma questão de dinheiro: ajustar o modelo e o effort à complexidade real da tarefa dá melhores resultados e menos ruído.

Algumas regras importantes

Garanta que seus skills, hooks, commands, rules e o code styling estejam configurados no contexto do agente, prontos antes de começar.
Aproveite as rules para fixar comportamentos inegociáveis do agente: «nunca presuma nada», «sempre consulte ou pergunte se algo não estiver totalmente claro», «não mexa em arquivos fora do escopo da tarefa», «não invente APIs nem bibliotecas». Uma boa rule poupa você de repetir a mesma coisa em cada prompt.
Faça adversarial reviews do seu projeto.
Em geral, as soluções simples são as melhores. Desconfie das soluções complexas que a IA gera — muitas vezes existe um caminho mais direto que o modelo não escolheu.
Se não tiver certeza de qual é a melhor forma de implementar algo, volte à fonte: documentação oficial, specs, o código original. Não fique com a primeira resposta do agente.
Não coloque em produção nada que você não entenda.