Fluxo de 4 portas: reduzir a incerteza antes de programar com agentes

O custo de descobrir uma premissa tarde

Os agentes podem produzir mudanças em várias camadas com rapidez. Se uma premissa equivocada está na definição do problema, implementá-la primeiro no banco de dados, nos serviços e na UI multiplica o custo de corrigi-la. O trabalho prévio busca tornar visíveis as decisões com maior raio de impacto antes de gerar muito código.

As quatro portas propostas pelo material de partida são um padrão de planejamento, não um padrão formal. Podem ser adaptadas ao tamanho e ao risco da tarefa; uma mudança trivial não exige a mesma cerimônia que uma modificação com impacto em dados, permissões ou deploys.

As quatro portas de decisão

Cada checkpoint produz uma resposta que pode ser revisada. Se uma decisão-chave continuar aberta, o próximo passo deve reduzir essa incerteza e não escondê-la sob mais implementação.

1. Produto: quem tem o problema, que resultado busca e como o sucesso será reconhecido.
2. Arquitetura: quais sistemas, interfaces, dados, permissões e limites são afetados.
3. Projeto do programa: quais módulos, contratos, arquivos e testes compõem a mudança.
4. Slices verticais: qual é o percurso mínimo que atravessa UI, lógica e dados para testar a hipótese.

Separar pesquisa de solução: uma sequência QRDSPI

O documento do NotebookLM chama de “QRSPI” uma sequência, embora enumere seis fases. Para não ocultar essa discrepância, aqui as seis iniciais são escritas como QRDSPI: Questions, Research, Design, Structure, Plan e Implement. É um rótulo editorial para explicar o fluxo do artigo, não uma metodologia certificada nem um framework universal.

Primeiro, são formuladas perguntas neutras sobre o código e o problema; depois, o repositório é pesquisado sem pressupor a solução. Com essa evidência, projeta-se o comportamento, define-se a estrutura, planejam-se testes e slices e, por fim, implementa-se em partes revisáveis.

1. Questions: transformar o ticket em perguntas verificáveis.
2. Research: buscar respostas e restrições no sistema existente.
3. Design: acordar experiência, comportamento e critérios de aceitação.
4. Structure: definir limites, contratos e responsabilidades dos componentes.
5. Plan: ordenar testes e slices verticais pequenos.
6. Implement: executar um slice, validá-lo e seguir para o próximo.

Tornar as portas proporcionais ao risco

Use checkpoints mais leves para mudanças reversíveis e amplie a revisão quando uma tarefa toca dados sensíveis, pagamentos, acesso, migrações ou produção. Um plano útil registra decisões pendentes e critérios de saída; não tenta adivinhar todos os detalhes antes de aprender algo com o primeiro slice.

A aprovação pertence às pessoas responsáveis pelo produto e pelo sistema. O agente pode preparar alternativas, testes e documentação, mas não transforma suas próprias propostas em decisões aprovadas.