O gargalo mudou de lugar
Antes da IA, a capacidade de implementação era escassa: um requisito mal escrito desperdiçava o tempo de alguns engenheiros. Com a IA agêntica, essa capacidade explode — e um requisito ruim agora pode gerar centenas de mudanças erradas, muito baratas. O gargalo, portanto, migra para a montante: definição de problema, contexto, restrições, decisões e validação.
A tese central do artigo de Mike Huls é direta: “se a direção está errada, toda essa velocidade extra só leva você ao lugar errado dez vezes mais rápido.” Resolver o problema certo deixou de ser um detalhe de gestão e virou a principal competência técnica da era agêntica.
O Project Preparation Framework em 6 passos
A proposta é um framework que reduz a incerteza antes de acelerar a implementação. Cada passo produz um documento curto que torna as decisões explícitas e utilizáveis tanto por humanos quanto por agentes de IA. O princípio regente: quanto mais cara for uma decisão de reverter, mais incerteza você deve eliminar antes de tomá-la.
| Passo | Documento | Propósito |
|---|---|---|
| 1. Pré-requisitos de negócio | PID.md | Alinhar problema, escopo e metas |
| 2. Pré-requisitos de TI | discovery-report.md | Entender dados, sistemas e restrições |
| 3. Requisitos funcionais | functional-requirements.md | Definir o que a solução deve fazer |
| 4. Requisitos técnicos | technical-requirements.md | Definir como a solução vai funcionar |
| 5. Governança | governance.md | Definir quem decide e quem responde |
| 6. Planejamento | roadmap.md | Definir quando, em que ordem e por quem |
Quando o framework vale a pena
Nem toda mudança exige seis documentos. Um bug fix, um script interno ou um protótipo descartável não justificam esse nível de preparação. O framework se paga quando o custo de errar a direção é alto — por exemplo, quando há múltiplos stakeholders, quando o problema é ambíguo, quando decisões de arquitetura ou dados serão caras de reverter, ou quando vários agentes vão trabalhar em paralelo.
Ele também não substitui experimentação: quando uma hipótese é incerta, um protótipo ou spike costuma ser o jeito mais rápido de reduzir a incerteza — e o resultado deve realimentar o passo correspondente, não mudar a direção do projeto em silêncio.
“War stories” que explicam cada passo
- O webhook que era uma API: a equipe entregou uma solução técnica impecável para um problema que não existia. Lição: o cliente é dono do problema; você é dono da solução.
- O dashboard em tempo real: semanas construindo processamento em tempo real para uma fonte que só entregava lotes a cada 12 horas. Lição: falhe cedo sobre o que o ambiente atual suporta.
- A automação de 10 minutos: mais de 100 horas automatizando um processo manual que levava 10 minutos por mês. Lição: antes de abrir a IDE, entenda quem usa, como e com que frequência.
- A cirurgia de PostgreSQL: a migração foi difícil não porque o banco era ruim, mas porque a decisão de arquitetura foi tomada antes de entender o domínio. Lição: a ferramenta certa é a que se encaixa no problema, não a que você já conhece.
Por que isso importa agora
Com agentes de código multiplicando a velocidade de implementação, errar a direção ficou exponencialmente mais caro — um único pressuposto errado deixa de ficar em um arquivo e passa a ser copiado em cada mudança gerada por agente antes de qualquer humano revisar. O framework não elimina a incerteza; ele ajuda a equipe a encontrar a incerteza que importa e a tratá-la enquanto ainda é barato. Na era agêntica, boa engenharia deixou de ser escrever mais código e virou tomar boas decisões sob restrição.
Descubra mais sobre noticiAI
Assine para receber nossas notícias mais recentes por e-mail.
