Construir com IA

Os agentes de código reduzem o custo de transformar instruções em software. Essa vantagem muda o gargalo. O problema já não é apenas se uma capacidade pode ser construída, mas se ela merece existir, se resolve o problema certo e se preserva a compreensão da pessoa.

A IA deve absorver complexidade, não produzi-la.

Um agente pode implementar com grande velocidade uma especificação fraca, reproduzir padrões convencionais que não se encaixam no contexto e acrescentar opções plausíveis que ninguém pediu. Por isso o desenvolvimento assistido por IA precisa de uma camada explícita de intenção, limites e verificação.

Seis diretrizes para times e agentes

Diretriz	Exigência	Limite
D01 Fundamento antes da implementação	Compreender a definição de produto, sua autoridade, seu escopo e a evidência que a sustenta antes de propor componentes ou código. Quando existirem Job Stories, conservar sua circunstância, motivação e resultado.	Não começar a construir se uma ambiguidade material puder alterar a solução, o escopo ou uma regra.
D02 Especificação suficiente antes da geração	Definir estados, decisões, restrições e critérios de aceitação no nível necessário para o risco.	Não converter um prompt vago em uma implementação extensa e depois usar o código para descobrir o problema.
D03 Simplicidade deliberada	Preferir a solução que exige da pessoa menos conceitos, decisões e esforço de memória quando ambas alcançam o mesmo resultado.	Menos código não é a medida; menos carga desnecessária, sim.
D04 Determinismo onde importa	Implementar regras críticas, permissões, cálculos, estados e validações como lógica verificável.	Não delegar certeza, conformidade ou segurança ao comportamento variável de um modelo.
D05 Verificação antes da aceitação	Avaliar o fluxo, os estados extremos, a acessibilidade, o desempenho e o resultado real.	Código gerado e testes unitários aprovados não equivalem a produto concluído.
D06 IA subordinada à pessoa	Usar IA para propor, explicar e executar sob limites claros, mantendo revisão e reversibilidade proporcionais ao impacto.	A fluência de uma resposta nunca substitui evidência nem autorização.

A segunda pergunta reitora

Agora que podemos construir quase qualquer coisa com mais facilidade, o que merece ser construído e o que devemos deixar deliberadamente de fora?

Esta pergunta introduz uma obrigação que antes podia ficar oculta pelo custo técnico. Deve ser formulada durante a definição de produto e ao avaliar alternativas, e não utilizada durante a implementação para recortar unilateralmente um escopo aprovado. Cada capacidade deve justificar sua existência em relação a uma alternativa mais simples, inclusive a alternativa de não construí-la; uma vez autorizada, qualquer exclusão exige uma decisão rastreável de produto.

Determinismo e geração

A escolha não é entre um produto determinista ou um produto com IA. Um sistema confiável combina ambos conforme a natureza de cada decisão.

Tipo de comportamento	Tratamento preferido	Exemplos
Deve produzir sempre o mesmo resultado sob as mesmas condições	Regra determinista e teste automatizado	Permissões, preços, limites, cálculos, transição de estados
Admite várias respostas úteis e exige interpretação	IA com contexto, limites e avaliação	Explicar, resumir, propor alternativas, classificar texto
Pode afetar dinheiro, reputação, segurança ou direitos	A IA propõe; uma regra ou uma pessoa autoriza	Publicar, comprar, apagar, enviar, alterar acesso
A incerteza faz parte da saída	A IA declara suposições e nível de confiança	Recomendações, estimativas, informação incompleta

O fluxo evita que a geração de código se torne o primeiro ato de design. Não pretende criar uma fase carregada de documentação nem impor uma estrutura ao PRD. Busca compreender o fundamento recebido, produzir a clareza necessária para planejar e manter cobertura até a aceitação.

Passo	Decisão	Trabalho	Evidência mínima
F01	Compreender o fundamento	Reconhecer as fontes, a autoridade, o escopo, a estrutura utilizada e os resultados esperados.	Mapa fiel da definição de produto, sem reformulá-la por conveniência técnica.
F02	Estabelecer cobertura	Inventariar histórias, capacidades, regras, estados, jornadas, critérios e relações aplicáveis.	Cobertura completa, com lacunas ou contradições visíveis.
F03	Planejar a implementação	Resolver dependências, bloqueios, ordem, paralelismo, integração e testes sem modificar o escopo.	Plano coerente que contempla toda a definição aprovada.
F04	Concretizar o progresso	Usar as Job Stories existentes ou formular uma visão derivada quando acrescentar clareza e estiver identificada como tal.	Circunstâncias, motivações e resultados preservados quando couber.
F05	Estabelecer o contrato de experiência	Descrever o que a pessoa deve compreender, decidir e sentir nos momentos críticos.	Caminho principal, estados e promessa de interação.
F06	Modelar regras e riscos	Separar lógica determinista, comportamento generativo, permissões e ações irreversíveis.	Mapa de decisões e limites.
F07	Explorar e prototipar	Comparar alternativas e testar compreensão, hierarquia e recuperação antes de otimizar código.	Razão da alternativa escolhida e evidência do percurso.
F08	Construir, integrar e verificar	Implementar o plano, manter rastreabilidade e reconciliar resultados com o escopo completo.	Código, testes e evidência de cobertura; pendências e exceções explícitas.

Cada artefato existe para responder a uma pergunta, não para satisfazer um modelo. Pode ser uma seção do PRD, uma visão derivada, uma tabela, um teste ou um documento separado. Se a informação já existe, deve ser referenciada e não duplicada. A profundidade depende da extensão, da complexidade, da incerteza e do risco; se um artefato não muda uma decisão nem ajuda a verificá-la, deve ser simplificado ou eliminado.

Artefato	Pergunta	Conteúdo mínimo
A01 Mapa do fundamento	O que deve ser construído, por quê e com que autoridade?	Fontes; escopo; resultados; regras; limites; evidência; não objetivos
A02 Mapa de cobertura	Como todo o escopo será contemplado?	Elementos obrigatórios; relações; dependências; implementação; testes; estado; exceções
A03 Ficha de Job Story quando couber	Quando surge a necessidade e que mudança a pessoa busca?	Circunstância; motivação; resultado; comportamento atual; ansiedade; evidência; suposições
A04 Contrato de experiência	O que a pessoa deve compreender e conseguir fazer?	Caminho principal; linguagem; decisões; feedback; controle; recuperação
A05 Modelo de estados	O que pode acontecer e que transições são válidas?	Estados; eventos; regras; erros; permissões; persistência
A06 Orçamento de complexidade	Que carga estamos acrescentando?	Conceitos novos; decisões; passos; exceções; opções visíveis
A07 Plano de aceitação	Que evidência autoriza declarar o desenvolvimento concluído?	Resultados; regras; Job Stories quando se aplicam; acessibilidade; desempenho; estados extremos; métricas
A08 Registro de decisões	Por que escolhemos esta alternativa?	Alternativas; trade-offs; suposições; decisão; data; evidência pendente

O agente não deveria começar uma implementação se não conseguir responder com precisão às perguntas a seguir, no nível exigido pelo risco e pela complexidade:

• Qual é a definição de produto autorizada e que escopo ela estabelece?

• Que elementos do fundamento justificam o desenvolvimento e que evidência os sustenta?

• O planejamento contempla todas as histórias, capacidades, regras, estados e critérios obrigatórios?

• Quando existem Job Stories, a circunstância, a motivação e o resultado estão separados da solução?

• Qual é o caminho principal e que estados alternativos importam?

• Que decisões a pessoa deve tomar e quais o sistema pode resolver?

• Que comportamento precisa de certeza determinista?

• O que não faz parte do escopo e quem estabeleceu essa exclusão?

• Que evidência demonstrará que o desenvolvimento está concluído?

Se faltar uma resposta capaz de mudar materialmente a solução, o escopo, uma regra ou um direito, o agente deve parar e solicitá-la. Se a incerteza for menor, reversível e estiver dentro da sua autoridade, ele pode declarar uma suposição e avançar sem reduzir silenciosamente a cobertura assumida.

O contrato a seguir pode ser incorporado às instruções de um repositório, a um PRD ou ao prompt de um agente de código. Deve vir acompanhado do contexto específico do produto e não substitui a definição do problema.

CR01 Propósito. Construa a solução mais simples que permita à pessoa alcançar o resultado definido, preservando clareza, controle e capacidade de recuperação.

CR02 Antes de programar. Identifique as fontes autorizadas, explique o fundamento de produto e confirme o escopo completo. Reconheça a estrutura utilizada pela definição; quando contiver Job Stories, conserve sua circunstância, motivação e resultado. Separe evidência de suposições e identifique qualquer ambiguidade capaz de mudar materialmente a solução.

CR03 Ao planejar. Contemple todos os elementos obrigatórios e estabeleça suas dependências, bloqueios, ordem, integração e testes. Não selecione, omita nem adie partes do escopo por iniciativa própria. Se as restrições impedirem cobri-lo, solicite uma decisão à autoridade de produto.

CR04 Ao propor. Apresente a alternativa recomendada, uma alternativa mais simples e a opção de não construir, quando a decisão ainda pertencer a produto. Explique como cada uma responde ao fundamento, que carga introduz e que trade-offs exige.

CR05 Ao projetar. Não exponha estruturas internas. Use a linguagem da pessoa, convenções conhecidas, hierarquia clara, profundidade progressiva, valores padrão editáveis e feedback imediato.

CR06 Ao usar IA. Reserve as regras críticas para lógica verificável. Declare incerteza. Não execute ações de alto impacto sem autorização proporcional. Mantenha rastreabilidade, revisão e reversibilidade.

CR07 Ao implementar. Respeite o escopo acordado e conserve rastreabilidade com seu fundamento. Não acrescente funcionalidades, modos, configurações nem abstrações não solicitadas. Cubra estados vazios, de carregamento, erro, sucesso e recuperação, e integre as partes relacionadas.

CR08 Antes de declarar o trabalho concluído. Reconcilie a implementação com a definição completa de produto. Verifique resultados, regras, critérios e, quando couber, as Job Stories em suas circunstâncias. Verifique também acessibilidade, desempenho percebido, erros, persistência do trabalho e controle da pessoa. Apresente as evidências, as pendências e as exceções aprovadas.

Formato de entrega esperado do agente

1. O01 Fontes autorizadas e fundamento de produto que justificam o desenvolvimento.

2. O02 Inventário de escopo e cobertura de histórias, capacidades, regras, estados e critérios aplicáveis.

3. O03 Jobs to Be Done e Job Stories quando fazem parte da definição ou acrescentam uma visão derivada útil.

4. O04 Evidência disponível, suposições e critérios de resultado.

5. O05 Alternativa escolhida e razão do descarte de opções mais complexas.

6. O06 Arquivos ou componentes modificados e limites da mudança.

7. O07 Estados e casos extremos cobertos.

8. O08 Testes executados e evidência de resultado.

9. O09 Riscos, incertezas, pendências, exceções e decisões que ainda exigem julgamento humano.

Prompt breve para iniciar uma tarefa

Antes de escrever código, identifique a definição de produto autorizada, explique seu fundamento e confirme o escopo completo. Reconheça todas as histórias, capacidades, regras e critérios aplicáveis; quando existirem Job Stories, conserve sua circunstância, motivação e resultado. Distinga evidência de suposições. Planeje dependências e cobertura sem omitir nem adiar escopo por iniciativa própria. Implemente a solução mais simples que cumpra o aprovado e verifique resultados, integração, erros e recuperação.