Fase 5 — Desenvolvimento assistido (S)

A Fase 5 é onde a IA se torna mais visível no dia a dia. Setup automatizado, code generation contextual, review com checagem de conformidade. Mantém-se uma regra inegociável: nenhum código entra em main sem revisão humana do Tech Lead, conforme o princípio de Supervisão humana obrigatória.

Etapa 5.1 · Preparação automática para desenvolvimento

Acionamento: Fase 4 encerrada (arquitetura aprovada).

O que a IA faz antes do dev começar:

Gera templates de código (boilerplate) alinhados aos padrões da organização.
Configura CI/CD pipeline (GitHub Actions, GitLab CI, etc.) com gates pré-aprovados.
Cria stubs de API a partir do OpenAPI Spec gerado na Fase 3.
Gera testes unitários base que o dev expandirá depois.
Configura linters, formatters e hooks de pre-commit.
Prepara o ambiente em Docker/Compose ou dev container.

Saída: o desenvolvedor faz git clone → cria branch → começa a codificar — sem perder 1–2 dias em setup.

Validação humana obrigatória: o Tech Lead revisa o boilerplate e o pipeline antes de liberar para o time; templates errados se propagam silenciosamente.

Ganho típico: 1–2 dias por desenvolvedor em setup; padrões já incorporados desde o primeiro commit.

Etapa 5.2 · Assistência durante o desenvolvimento

Ferramenta sugerida: IDE com IA integrada (Cursor, GitHub Copilot, Claude Code, etc.).

Como o desenvolvedor usa a IA:

Uso	Para que serve
Chat com IA	”Como faço autenticação 2FA em FastAPI seguindo nossos padrões?”
Code completion	Sugestões inline durante a codificação
Geração de testes	”Crie testes para essa função, cobrindo retry e auditoria”
Refactoring	”Deixe esse código mais testável e remova esse acoplamento”
Explicação de código	”Por que essa função está lenta? Quais alternativas?”

Regra inegociável: o output da IA é sempre revisado pelo Tech Lead antes de merge.

Exemplo de iteração com revisão

Dev: “Preciso de uma função que envie email com retry exponencial e auditoria.”

IA gera: função send_approval_email com max_retries, exponential backoff, logging estruturado e tratamento de erro.

Tech Lead revisa: “Lógica correta. Mas falta teste de retry com falha permanente, e o email contém o nome completo do aprovador (LGPD). Use ‘Aprovador’ em vez de nome.”

IA ajusta com base no feedback; novo PR é aberto.

Validação humana obrigatória: o Tech Lead aprova cada PR; questões de conformidade (LGPD, sensibilidade) exigem visto adicional do Encarregado de Dados; questões de arquitetura (mudança de padrão, novo componente) exigem visto do Arquiteto.

Ganho típico: 1–2 horas por função em codificação; código segue padrões; testes já incluídos; segurança considerada.

Etapa 5.3 · Code review com IA em tempo real

Acionamento: o desenvolvedor abre um PR.

O CI/CD automático executa:

Build.
Testes unitários e de integração.
SAST (SonarQube, CodeQL ou similar).
Análise por IA focada em três dimensões:
- mapeamento PR → requisito (PR cobre o critério BDD declarado?);
- detecção de anti-patterns e violações dos padrões internos;
- checagem de conformidade (LGPD em strings, tokens em logs, dados pessoais expostos, falta de auditoria, etc.).

Saída esperada do code review da IA

Sessão	Conteúdo
Conformidade com requisito	Lista de critérios BDD cobertos / não cobertos pelo PR
Padrões seguidos	Async/await, retry com backoff, logging estruturado, type hints, etc.
Alertas	LGPD, falta de auditoria, timeouts longos, código bloqueante, segredos hardcoded
Cobertura	Coverage atingido, gaps de teste, sugestões de casos de borda
Segurança	SAST + checagens específicas (rate limit, validação de input, sanitização)
Recomendação final	”Aprovar com ajustes / Solicitar revisão / Bloquear”

Validação humana obrigatória: o Tech Lead aprova manualmente mesmo quando a IA recomenda aprovar. A IA bloqueia merge quando detecta violação crítica (segredo hardcoded, ausência de auditoria em endpoint regulado, etc.) — desbloqueio só com decisão explícita do Tech Lead e registro do motivo no PR.

Ganho típico: 30–45 min de code review por PR; nenhum bug de conformidade passa silenciosamente.

Etapa 5.4 · Sprint reviews com IA documentando

Quando: ao fim de cada sprint (tipicamente 2 semanas).

O que a IA faz:

Transcreve a Sprint Review.
Detecta histórias prontas vs. adiadas.
Calcula velocidade real e tendência.
Sugere ajustes para a próxima sprint (agrupamento, dependências, riscos).
Documenta decisões tomadas durante a review.
Atualiza o roadmap automaticamente (drafts).

Validação humana obrigatória: o PO/Scrum Master valida o roadmap atualizado e fecha a próxima sprint; nada vai para o backlog sem revisão.

Ganho típico: 1–2 horas por sprint em atas e planejamento.

Encerramento de cada sprint da Fase 5

Item	Critério
PRs aprovados	Cada PR tem revisão humana registrada (não só “IA aprovou”)
Cobertura	Cobertura geral acima da meta acordada (ex.: ≥ 80%) e cobertura por requisito atendida
Conformidade	Zero violações críticas em aberto
Documentação	ADRs novos publicados; SRS atualizado se houve mudança
Sprint review	Ata aprovada e roadmap atualizado
Riscos	Riscos novos registrados e classificados

Sprints encerradas dessa forma deixam a Fase 6 (Qualidade) operando em paralelo desde o início, conforme o princípio de Validação em múltiplas camadas.

Anterior: 6 · Fase 4 — Arquitetura com IA · Próximo: 8 · Fases 6–7 — Qualidade e homologação