Briefing
Não é nome do projeto. É clareza sobre problema, público, escopo e porquê. Sem briefing, todo o resto é chute disfarçado de execução.
INPUTclareza
Puxadinho atrás de puxadinho
Antes de explicar as etapas, preciso te mostrar o erro que TODO mundo está cometendo agora: inclusive eu, depois de seis meses dentro da AIOX. A maioria das pessoas começa a dar comando pra IA sem todas as especificações. Sem briefing, sem detalhamento, sem quebra em tarefas. Aí vira o quê? Puxadinho atrás de puxadinho. Aquela mansãozinha bonita que você ia construir vira um Frankenstein com varanda enferrujada do lado, garagem improvisada na frente, banheiro no quintal. As coisas até continuam funcionando, esse é o pior. Continua funcionando, e você se acostuma com a porcaria. Quando o Pedro me apresentou o que ele estava fazendo, eu já tinha estudado um pouco de metodologia ágil. Eu já tinha algumas práticas. Mas o nível de detalhamento entre as etapas que ele fazia não tinha comparação. Não tinha comparação. E eu descobri hoje, depois de seis meses de AIOX, que tinha umas etapas que eu mesmo não tava fazendo direito. Eu. Que estou aqui ensinando vocês. Se eu não tava fazendo, imagina o tamanho do puxadinho que tá no projeto de quem ainda nem instalou direito. Por isso essa aula é literal sobre isso: as etapas que separam um app de verdade de uma mansão com sete puxadinhos. E pra deixar claro, isso aqui não é firula. É a fundação que vai impedir que tu fique consertando coisa quebrada o resto do ano.
3etapas canônicas
6movimentos no tema de casa
1erro barato antes da execução séria
Mapa da aula
Use este mapa para entender a sequência da aula antes de entrar nos detalhes.
Legenda de coresO que cada cor sinaliza nesta aula
Sintoma de puxadinhoexecutar sem especificar gera Frankenstein que funciona meia-boca
Etapa canônicauma das três camadas de especificação do AIOX
Detalhamentosub-etapas que pouca gente faz e onde mora o resultado
Diagnósticovoltar para a etapa que ficou fraca antes de remendar
Movimento de práticacomeçar a usar, errar barato, compartilhar com o grupo
Como ler esta aula
1. O sintoma: puxadinhoConstruir sem especificar vira Frankenstein que 'funciona': e você se acostuma com a porcaria.
2. Três etapas canônicasBriefing → PRD → Stories. Cada uma trava o erro mais cedo e mais barato.
3. Detalhamento é a fundaçãoNão é firula, é o que impede você de consertar coisa quebrada o ano inteiro.
4. Tema de casaVocê sai com uma rotina pequena para aplicar antes da próxima execução séria.
DiagnósticoPuxadinho não nasce porque a IA é ruim. Nasce porque você começou a construir antes de especificar.
como uma ideia vira puxadinho
1
Ideia solta
Parece clara na cabeça, mas não foi escrita com escopo e restrição.
2
Comando cedo
A IA começa a executar antes de entender o projeto.
3
Correção em cima
Cada ajuste vira remendo porque a base não foi decidida.
4
Puxadinho
O produto funciona, mas ninguém confia, ninguém escala e todo mundo tem medo de mexer.
As três etapas: Briefing, PRD, Stories
Existem três etapas principais no desenvolvimento AIOX. Pouca gente faz. E dentro de cada uma, tem sub-etapas que ninguém faz, e é aí que o jogo vira.
Eu separei isso aqui em três etapas principais. Briefing, onde você entende o que quer fazer. PRD, que é o detalhamento operacional: separar isso por etapas, deixar tudo escrito antes de uma linha de código sair. E Stories, a quebra em tarefas executáveis. Só ter essas três já te coloca à frente de noventa por cento das pessoas que usam IA pra construir coisa. Mas o pulo do gato não está em ter as três. O pulo do gato é que dentro de cada uma existem sub-etapas essenciais. É no detalhe que mora o resultado. Quando você pula a sub-etapa de validação do briefing, o PRD nasce torto. Quando o PRD nasce torto, a Story nasce torta. Quando a Story nasce torta, o Claude Code constrói uma coisa torta, e ele constrói rápido, então você acaba com várias coisas tortas, rápido. Velocidade sem fundação é o que a gente chama de puxadinho industrializado.
PRD
Separar trabalho por etapas, escrever objetivos, stack, decisões e trade-offs. O PRD dita tudo. Pular essa etapa é construir sem planta.
PLANdecisoes
Stories
Cada Story é unidade executável com critério de aceite. É o que o Claude Code mastiga sem inventar moda. Sem Story, vira improvisação.
EXECaceite
As três etapas que estruturam todo desenvolvimento AIOX
1. BriefingEntender o que você quer fazer. Não é nome do projeto. É clareza sobre o problema, o público, o escopo e o porquê. Sem briefing, todo o resto é chute.
2. PRD (Detalhamento Operacional)Separar o trabalho por etapas, escrever objetivos, stack, entregáveis. O PRD vai ditar tudo que vai ser desenvolvido. Pular essa etapa é construir sem planta.
3. Stories (Quebra em Tarefas)Cada Story é uma unidade executável com critério de aceitação. É o que o Claude Code consegue mastigar sem inventar moda. Sem Story, vira improvisação.
Construir puxadinho
- Pular briefing porque a ideia parece óbvia.
- Pedir PRD genérico sem restrição, público ou critério.
- Mandar Claude Code construir uma Story grande demais.
- Corrigir com remendo depois que a base já nasceu torta.
Construir mansão
- Escrever briefing curto, mas concreto.
- Converter briefing em PRD com etapas e decisões explícitas.
- Quebrar em Stories pequenas com aceite claro.
- Executar com gate: PO, Dev, QA e DevOps quando fizer sentido.
A Fran pediu pro porta-aviões fazer aviãozinho de papel
Caso que aconteceu hoje, dentro do grupo. A Fran descobriu errando, e o erro dela vale ouro pra você.
Vou contar o que aconteceu hoje. A Fran pediu pro Squad Creator pra criar uma apresentação. Pra quem ainda não viu, o Squad Creator é um porta-aviões. Ele é uma das peças mais complexas, mais densas, mais caras de operar da AIOX. Ele é literalmente um projeto dentro do projeto. E ela pediu pra ele fazer um aviãozinho de papel. Apresentação de slide. Coisa que tem squads específicos pra isso, mais leves, mais diretos, mais rápidos. A reação típica seria: "Fran, errado, não era pra usar esse." Mas é exatamente o contrário. Ela TESTOU. E ao testar, descobriu que existem squads mais simples pra isso. Descobriu na mão, no impacto, lendo a documentação depois que percebeu que tinha exagerado. Esse é o ponto. Testem. Vocês têm que usar pra poder ver o que não estavam usando do jeito certo. Não esperem descobrir tudo o que vão aprender aqui pra só depois começar: porque vocês vão cometer um erro muito grande. Comecem agora. Nem que vocês deletem e refaçam tudo do zero três vezes esta semana. O erro barato no ambiente local é o melhor professor que existe. Quem erra mais e mais rápido aprende mais do que quem tenta fazer perfeito da primeira vez.
Fran e o porta-aviões
Ela usou uma ferramenta grande demais para uma tarefa simples, e isso virou aprendizado útil para o cohort inteiro.
Começou comoPedido de apresentação feito para o Squad Creator.
VirouClareza sobre roteamento: ferramenta precisa combinar com tamanho da tarefa.
ProvaO erro revelou a existência de squads mais adequados antes de virar processo caro.
LiçãoErro barato em Local é dado de aprendizagem, não vergonha.
1TentouChamou uma peça pesada para uma tarefa pequena.
2Sentiu atritoPercebeu que a ferramenta parecia pesada para o objetivo.
3AprendeuConverteu o erro em critério de escolha de squad.
- O erro revelou a existência de squads mais adequados antes de virar processo caro.
- Erro barato em Local é dado de aprendizagem, não vergonha.
- Compartilhar erro acelera o aprendizado coletivo.
- Tentou: Chamou uma peça pesada para uma tarefa pequena.
- Sentiu atrito: Percebeu que a ferramenta parecia pesada para o objetivo.
- Aprendeu: Converteu o erro em critério de escolha de squad.
o erro da Fran como método de aprendizagem
1
Tarefa simples
Criar apresentação.
2
Ferramenta grande
Usou Squad Creator, um porta-aviões para um aviãozinho de papel.
3
Atrito visível
Percebeu que o sistema tinha peças mais adequadas.
4
Aprendizado real
O erro barato ensinou roteamento melhor do que uma explicação abstrata.
Por que este caso importaO objetivo não é nunca errar. O objetivo é errar cedo, em Local, com custo baixo, e converter o erro em regra de roteamento.
Confusão é o primeiro estágio do conhecimento
Se você está confuso agora, parabéns. É sinal de que está avançando.
Eu sei o que tá batendo em vocês agora. Briefing, PRD, Story, Epic, core-config, CLAUDE.md, DevOps, ambiente local, staging, produção. É muita sigla. É muita ferramenta. É muita coisa nova de uma vez. Calma. Respira. Eu vou repetir uma coisa que vocês precisam tatuar no avesso da mente. O primeiro estágio da compreensão é a confusão. Se tu tá confuso, parabéns. Tu tá no estágio que tá avançando. Se tu NÃO tá confuso, é porque tu nem sabia que existia Epic, Story, core-config e PRD: ou seja, tava errado e nem sabia que tava errado. Estar confuso é estar consciente da fronteira do que você ainda não domina. É o pré-requisito do aprender. Quem nunca se confunde nunca aprende nada novo: só repete o que já sabia. Então não fica esperando a confusão passar antes de agir. A confusão NÃO passa parado. A confusão passa testando, errando, lendo a documentação, fazendo a pergunta no grupo, vendo os outros errarem do seu lado. A confusão é movimento, não pausa.
1. Confusão invisível
Você não sabe que não sabe. Parece fácil porque ainda não viu Epic, Story, PRD, CoreConfig e gates.
2. Confusão consciente
Você percebe a quantidade de peças. É desconfortável, mas é avanço cognitivo.
3. Confusão operacional
Você testa, erra, lê, compartilha e converte dúvida em procedimento.
Como sair da confusão sem travar
1Nomeie a peçaNão entendeu PRD, Story ou CoreConfig? Primeiro descubra o que é, não tente decorar tudo junto.
2Teste pequenoUse Local para fazer um erro controlado e barato.
3CompartilheO insight de um aluno vira atalho para o resto do cohort.
Antes de executar, descubra qual etapa você pulou
Quando algo parece confuso, quase sempre uma dessas três etapas ficou fraca.
A aula não quer reduzir Briefing, PRD e Stories a três palavras decoradas. Ela quer dar um diagnóstico. Quando a execução trava, pergunte qual camada ficou vaga. A resposta normalmente aparece rápido.
A execução travou ou virou puxadinho?
Não corrija direto no código. Descubra qual etapa anterior falhou.
Briefing fraco
Ninguém sabe explicar problema, público, escopo e restrição em linguagem simples.
signal
PRD raso
A ideia existe, mas faltam etapas, decisões, stack e trade-offs.
bench
↓ ↓ ↓
Story grande
A Story mistura várias entregas e não tem aceite verificável.
pain
↓ ↓ ↓
Qual camada precisa voltar?
Voltar uma etapa cedo é barato. Remendar depois é puxadinho.
Volte para briefing antes de pedir PRD.Ninguém sabe explicar problema, público, escopo e restrição em linguagem simples.
Detalhe o PRD antes de quebrar em Stories.A ideia existe, mas faltam etapas, decisões, stack e trade-offs.
Quebre em unidades menores antes do Dev.A Story mistura várias entregas e não tem aceite verificável.
Comece a usar. Mesmo errado. E compartilhe.
Seu tema de casa pra antes do próximo encontro: seis movimentos práticos pra acelerar a curva de confusão.
O que eu quero de vocês até o próximo encontro é simples, e desconfortável. Eu quero que vocês comecem a usar, mesmo errado. Quero que vocês quebrem coisa, deletem, refaçam, percebam que pediram pro porta-aviões fazer aviãozinho de papel, e contem isso pro grupo. Porque a abundância vai aumentando quando o conhecimento circula. Tudo que vocês descobrirem aqui: bug estranho, squad que não entendeu o briefing, PRD que ficou raso, Story que nasceu torta: joga no grupo. O insight de um vira atalho pros outros vinte. É inteligência coletiva.
Sequência mínima para não virar puxadinho
Use sempre que uma ideia parecer pronta para executar.
briefing→prd→stories→execução local→compartilhar aprendizadoBriefing— Escreva problema, público, escopo e restrição.PRD— Detalhe arquitetura de produto antes de construir.Stories— Quebre em unidades pequenas com aceite claro.Local— Teste errado sem custo alto.Grupo— Converta o erro em conhecimento circulando.
Exemplo preenchido: tema de casa de uma landing pequena
BriefingLanding para uma aula aberta de IA. Público: founders de negócio B2B. Escopo: hero, autoridade, programa, oferta e formulário. Não inclui blog, área logada ou multi-idioma.
PRD geradoStack simples, formulário integrado e deploy em preview. Decisão: copy final vem do founder; IA organiza wireframe, componentes e checklist de publicação.
Stories1) Hero + headline + CTA. 2) Seção de autoridade. 3) Programa em blocos. 4) Formulário com validação. 5) Deploy preview com domínio de teste.
Erro propositalUsar Squad Creator para gerar a landing inteira, sentir o peso da ferramenta e comparar com a rota menor: design + dev + deploy.
CompartilhadoPostar no grupo o PRD, o erro de roteamento e a regra aprendida: ferramenta grande demais também vira puxadinho.
Portão da aulaVocê só passa para execução séria quando consegue explicar briefing, PRD e Story do seu projeto em frases simples.
- Briefing solo: Escolhe um projeto pequeno: pode ser uma landing, um squad próprio, um app que tu já queria. Escreve em até uma página: o que quer fazer, pra quem, qual problema resolve, qual escopo.
- Gera o PRD: Manda o briefing pra dentro da AIOX e pede pra ele detalhar o PRD. Lê o que sai. Bate o que sai com o que tu pediu. Onde divergiu, anota.
- Quebra em Stories: Pede pra quebrar o PRD em Stories executáveis. Não tenta executar tudo. Só veja a granularidade. Sente se cada Story cabe num critério de aceitação claro.
- Erra de propósito: Faz pelo menos uma coisa errada: chama o squad errado pra tarefa errada (porta-aviões pra aviãozinho), pula uma etapa, manda comando sem especificação. Vê o que quebra.
- Compartilha no grupo: Posta no grupo o que aprendeu errando. Pode ser print, pode ser parágrafo, pode ser áudio. O insight bruto vale mais que o relatório bonito.
- Lê o que os outros postaram: Antes do próximo encontro, lê pelo menos três compartilhamentos dos colegas. A abundância circula quando o conhecimento circula.
Bloco de código: as três etapas antes de construir
O esqueleto que separa mansão de puxadinho, para o aluno copiar antes de mandar executar.
01briefing:02problema: "Que dor real isso resolve?"03publico: "Para quem?"04escopo: "O que entra e o que NAO entra"05prd:06arquitetura: "Como o produto se organiza antes de existir codigo"07stories:08- id: "story-1"09entrega: "Unidade pequena com aceite claro"10aceite: "Esta pronta quando..."