Dev com IA v6.2 · 6 módulos · 30 aulas de uns 15 minutos
Claude e Codex juntos, do briefing ao aceite: um planeja ou implementa, o outro critica o artefato real, e os testes e você decidem. Com modelo e esforço escolhidos por etapa e o custo medido.

Trocar "parece certo" por "conferi assim".
Plano em arquivo, criticado pelo outro modelo sobre o mesmo arquivo.
Um constrói em etapas; o outro revisa o diff com o briefing e os testes.
Testes pertinentes, comportamento real e decisão humana.
Trocar de sessão ou de modelo sem explicar tudo de novo.
Escolher modelo e esforço por etapa e medir custo × resultado.
Dev com IA v6.2
Os termos técnicos do curso em palavras simples. Cada termo leva às aulas em que aparece.
Arquivo de texto na raiz do projeto com as regras e a ordem de leitura. O Codex lê sozinho ao começar; outros assistentes leem quando alguém manda.
Aparece em: Aula 23
Porta de acesso para um programa usar o serviço de IA diretamente, cobrada por consumo e aberta com uma chave secreta.
Aparece em: Aula 29
Linha de teste separada dentro do Git. Você testa mudanças nela sem mexer na versão que já funciona.
Arquivo curto com objetivo, escopo, critérios de aceite e limites de uma tarefa. Os dois modelos leem o mesmo.
Aparece em: Aula 2 Aula 5 Aula 6 Aula 7 Aula 8 Aula 9 Aula 10 Aula 11 Aula 12 Aula 13 Aula 14 Aula 15 Aula 16 Aula 17 Aula 18 Aula 20 Aula 22 Aula 23 Aula 24 Aula 25 Aula 26 Aula 27 Aula 30
Assistente de programação da Anthropic que lê e altera arquivos numa pasta do seu computador.
Programa usado por comandos digitados no terminal, sem janelas nem botões.
Aparece em: Aula 8
Assistente de programação da OpenAI que lê e altera arquivos numa pasta do seu computador.
Uma versão salva no Git, com data e uma frase dizendo o que mudou.
Frase escrita antes do trabalho que diz como você vai conferir que ficou pronto. Ex.: 'a mensagem de teste chega na caixa da recepção'.
Aparece em: Aula 1 Aula 2 Aula 3 Aula 6 Aula 10 Aula 12 Aula 16 Aula 20 Aula 26 Aula 30
A lista do que mudou entre duas versões de um arquivo: linhas que saíram (com −) e linhas que entraram (com +).
Controle de quanto o modelo analisa antes de responder. Mais esforço costuma demorar mais e consumir mais uso da conta.
Aparece em: Aula 27
Programa de controle de versões: guarda cada mudança dos arquivos de uma pasta, para você ver o que mudou e voltar atrás. O módulo 3 ensina o necessário.
Arquivo curto que registra decisões, pendências e a próxima ação, para outra conversa ou outro modelo continuar de onde parou.
Aparece em: Aula 5 Aula 21 Aula 22 Aula 23 Aula 24 Aula 25 Aula 27
O programa de IA que lê o seu pedido e escreve a resposta, como o Claude ou o GPT. Outro modelo = outra IA; uma conversa nova do mesmo assistente também serve como segundo olhar.
Aparece em: Aula 1 Aula 2 Aula 5 Aula 6 Aula 7 Aula 10 Aula 13 Aula 17 Aula 20 Aula 21 Aula 23 Aula 24 Aula 25 Aula 26 Aula 27 Aula 28 Aula 29 Aula 30
Complemento que se acrescenta a um programa para dar a ele uma função nova.
Primeiro pedido de uma sessão: o assistente lê os arquivos do projeto e o handoff, sem mexer em nada, e devolve um resumo com as fontes.
Um modelo faz o trabalho e outro modelo, ou outra conversa, examina o resultado real apontando falhas com evidência.
Aparece em: Aula 2 Aula 7 Aula 13 Aula 20 Aula 25 Aula 28 Aula 30
Uma ida e volta entre plano e crítica: o revisor aponta achados e o autor responde cada um e escreve a nova versão.
Aparece em: Aula 9
Área protegida em que o assistente trabalha com permissões limitadas. No modo só leitura, ele lê os arquivos mas não consegue alterar nada.
Janela de texto em que você digita comandos para o computador executar e lê a resposta.
Aparece em: Aula 4 Aula 8 Aula 11 Aula 12 Aula 13 Aula 19 Aula 24 Aula 27 Aula 30
Verificação que o computador roda sozinho e responde 'passou' ou 'falhou', sempre do mesmo jeito. A IA pode escrever o teste para você.
Módulo 1 · Aula 1 de 5

Você consegue olhar um resultado feito com IA e separar o que você conferiu do que você só aceitou.
A IA escreve código, texto e planilha em minutos, e com muita segurança. O problema é que segurança não é prova. Quem entrega o trabalho responde por ele, não a IA.
Em 1 minuto
Assistentes de código como o Claude Code e o Codex trabalham rápido. No fim, escrevem um resumo do que fizeram.
Esse resumo é a opinião da IA sobre o próprio trabalho. Às vezes está certo. Às vezes diz "testado" sem ter testado nada.
Rafael, desenvolvedor autônomo, pediu um formulário de contato para o site de uma clínica. A resposta veio em dois minutos, com "testado e funcionando".
RafaelCrie o formulário de contato da página da clínica. O envio vai para o e-mail da recepção.
IAPronto. Criei o formulário com nome, telefone e mensagem, e o envio para a recepção. Testado e funcionando.
Parece completo. Mas o que foi testado, e como?
RafaelComo exatamente você testou o envio para a recepção?
IAConferi que a página abre e que o formulário aparece. Não enviei nenhuma mensagem de verdade. Para testar o envio, mande uma mensagem pela página e veja a caixa da recepção.
Uma pergunta mostrou que "testado" era só a página abrindo.
Aceitar é confiar no resumo. Conferir é abrir a coisa feita e ver se ela faz o que devia.
Rafael abriu a página, preencheu o formulário e clicou em enviar. A tela mostrou "mensagem enviada", mas nada chegou na caixa da recepção.
O que fez: leu "testado e funcionando" e mandou o link para a clínica.
Resultado: a recepção descobre o erro dias depois, com pacientes sem resposta.
O que fez: enviou uma mensagem de teste e olhou a caixa da recepção.
Resultado: achou o erro antes da entrega e pediu a correção.
Saldo: cinco minutos de conferência no lugar de uma semana de mensagens perdidas.
Não existe uma conferência só. Este curso usa três, sempre juntas.
A primeira é um critério de aceite, escrito antes. A segunda é abrir e usar o resultado. A terceira é um segundo olhar: outro modelo, uma conversa nova ou outra pessoa.
Carla, analista de operações, gera com IA o relatório semanal de entregas. Ela confere o total de pedidos contra a planilha original antes de enviar à diretoria.
Se travou aqui, é normalParece trabalho demais para cada pedido? Não é para cada pedido. Comece só pelo que vai para outra pessoa: cliente, chefe, equipe.
Teste-se
A IA terminou a tarefa e escreveu "todos os testes passaram". O que isso é?
Um segundo modelo acha falhas que o primeiro não viu. Mesmo assim, a decisão de entregar continua sua.
Carla pede a outro modelo que revise o relatório. Ele aponta duas cidades trocadas. Quem decide se o relatório sai hoje é ela.
Produz, revisa e aponta falhas com a evidência.
Define o critério, olha o resultado real e decide se entrega.
Pratique agora 0/3
Pronto quando você tiver marcado cada item do caso como "conferido" ou "aceito". Cerca de 8 minutos, no papel ou no bloco de notas.
É só leitura de um caso. Se ficar em dúvida num item, marque "aceito": na dúvida, não foi conferido.
O caso. Rafael pediu à IA uma página de preços. Ela respondeu: "Página criada, os três planos aparecem, o botão leva ao pagamento e o texto foi revisado". Rafael abriu a página e viu os três planos. Não clicou no botão. Não leu o texto. Mandou o link ao cliente.
Você já separa o que foi visto do que foi só dito.
Cola da aula
Aula 1 · Dev com IA v6.2 · INEMA.CLUB
Módulo 1 · Aula 2 de 5

Você consegue dizer o que fecha a conferência de um trabalho além da opinião de um segundo modelo.
Pedir a outro modelo que revise é um bom passo. O risco é parar aí: "o outro também aprovou, então está certo". Duas calculadoras com o mesmo número errado digitado dão o mesmo resultado errado.
Em 1 minuto
Quando você pede ao mesmo modelo, na mesma conversa, que revise o próprio trabalho, ele costuma concordar consigo mesmo. Um modelo diferente, ou uma conversa nova, olha com menos apego.
Só tem um assistente? Abra uma conversa nova nele: já é um olhar com menos apego. Outro modelo é melhor ainda. O curso chama isso de revisão cruzada: um faz, o outro confere.
Rafael pediu ao Claude o plano de uma área de acesso com senha para o site da clínica. Depois pediu ao Codex que lesse o mesmo plano e apontasse falhas.
RafaelRevise o plano que você acabou de escrever.
ClaudeO plano está completo e cobre os requisitos. Não vejo ajustes necessários.
Quem escreveu, na mesma conversa, confirmou o próprio plano.
RafaelLeia o plano abaixo e aponte falhas, com o trecho que mostra cada uma.
CodexFalha 1: o plano não diz o que acontece quando a pessoa erra a senha várias vezes. Onde: a parte "Entrada" do plano lista só e-mail, senha e o botão entrar.
Um olhar de fora achou um caso que o autor não previu.
A revisão cruzada acha falhas. Ela não garante que não sobrou nenhuma. Se os dois modelos leram o mesmo dado errado, os dois vão concordar com o erro.
Carla pediu a um modelo a fórmula do prazo médio de transporte, da saída do armazém até a entrega. O segundo modelo revisou e aprovou. Os dois contaram a partir da data do pedido, e não da data de saída do armazém.
O que Carla tinha: a fórmula e o "está correta" dos dois modelos.
O que aconteceu: o prazo de transporte saiu dois dias maior que o real.
O que Carla fez: calculou à mão três pedidos e comparou com a fórmula.
O que aconteceu: a diferença apareceu no primeiro pedido.
Saldo: três contas à mão pegaram o que duas revisões deixaram passar.
Se travou aqui, é normalEntão a revisão não serve? Serve, e muito. Ela só não é a última palavra. Pense nela como mais um par de olhos, não como o carimbo final.
Três coisas fecham o ciclo, e nenhuma é a opinião de um modelo. O critério de aceite escrito antes. O teste no resultado real. A sua decisão.
Na área de acesso da clínica, o critério de Rafael era "depois de cinco senhas erradas, aparece o aviso de esperar dez minutos". Ele testou errando a senha cinco vezes.
Teste-se
Claude escreveu, Codex revisou e aprovou. O que ainda falta antes de entregar?
Para a revisão valer, o segundo modelo recebe o mesmo briefing e o trabalho de verdade: o arquivo, o plano, a planilha. Nunca um resumo do que o primeiro disse que fez.
Carla passou a colar o pedido original e anexar a planilha pelo clipe do chat. Antes, ela colava só a resposta da primeira IA. Num assistente de código, basta citar o arquivo pelo nome.
"O outro modelo disse que a fórmula está certa. Confira."
O pedido inicial, a planilha e a fórmula, com: "aponte falhas com o trecho que mostra cada uma".
Pratique agora 0/3
Pronto quando você tiver respondido as três perguntas do caso. Cerca de 8 minutos, no papel ou no bloco de notas.
É só leitura de um caso. Se duas respostas parecerem certas, escolha a que tem teste no resultado real.
O caso. Carla pediu ao Claude uma rotina que junta as planilhas de entrega da semana. Colou a resposta no Codex com "está certo?". O Codex respondeu "sim, parece correto". Carla mandou o relatório à diretoria.
Você já sabe o que falta quando "os dois concordaram".
Cola da aula
A síntese do INEMA de 27 de setembro de 2026 resume assim: a revisão cruzada ajuda a revelar problemas, mas concordância entre modelos não comprova que o sistema funciona. Critérios de aceite, testes e verificação humana fecham o ciclo.
O kit Use Both, resumido na área Codex + Claude do Eventos INEMA, diz o mesmo no nível 1: uma IA escreve o plano, a outra critica o mesmo arquivo, só lendo, com achados com evidência e gravidade, em no máximo duas rodadas. "Duas IAs concordando não é prova independente."
Na leitura de Mark Kashef, autor do vídeo que acompanha o kit, o modelo que escreveu o plano, ainda mais na mesma sessão, tende a aprová-lo. Um modelo diferente, ou uma sessão nova, dá outro resultado. É um relato do autor, sem medição publicada.
Fontes: Área Codex + Claude — Eventos INEMA · Guia do Use Both
Aula 2 · Dev com IA v6.2 · INEMA.CLUB
Módulo 1 · Aula 3 de 5

Você consegue escrever três critérios de aceite, que se conferem com sim ou não, para uma tarefa real sua.
Sem critério escrito antes, "pronto" vira o que a IA achar que é pronto. Aí a conferência depende de memória e de humor. Com o critério, qualquer pessoa confere do mesmo jeito.
Em 1 minuto
O critério de aceite troca um desejo por uma coisa que dá para olhar. "Fácil de achar" vira "o link Contato aparece no menu de todas as páginas".
Rafael reescreveu o pedido do formulário da clínica. Saíram "bonito" e "funcionando". Entraram três frases que ele consegue conferir.
"Um formulário de contato bonito e funcionando."
1. A mensagem de teste chega na caixa da recepção.
2. O campo telefone recusa letras.
3. No celular, a página não rola para os lados.
Saldo: três coisas que qualquer pessoa confere em cinco minutos.
Leia cada critério e pergunte: alguém que não fez o trabalho responde com sim ou não? Se a resposta for "depende", o critério ainda é desejo.
Carla escreveu "relatório claro". Não passou no teste. Trocou por "cada cidade aparece uma vez, com o total de pedidos da semana".
Se travou aqui, é normalNão sai critério nenhum? Pense em como o trabalho pode dar errado na mão do cliente. Cada erro possível, virado ao contrário, é um critério.
Escrever o critério só para você ajuda. Colar o critério no pedido ajuda mais: a IA passa a trabalhar para passar nele. E você pede que ela diga como vai conferir cada um.
Rafael colou os três critérios no fim do pedido. A resposta passou a listar como conferir cada um, em vez de só dizer "testado".
RafaelCrie o formulário de contato da clínica. Critérios de aceite: 1. A mensagem de teste chega na caixa da recepção. 2. O campo telefone recusa letras. 3. No celular, a página não rola para os lados. No fim, diga como conferir cada critério.
IAFormulário criado. Para conferir: 1. Envie uma mensagem de teste e veja a caixa da recepção. 2. Digite letras no telefone: o envio deve ser bloqueado. 3. Abra a página no celular e tente rolar para os lados.
A IA devolve um roteiro de conferência, não um "funcionando".
CarlaJunte as planilhas de entrega da semana num relatório novo. Critérios de aceite: 1. Total de pedidos igual à soma das planilhas. 2. Cada cidade aparece uma vez, com o seu total. 3. Embaixo de cada tabela, o nome da planilha de onde veio. No fim, diga como conferir cada critério.
IARelatório criado. Para conferir: 1. Some a coluna de pedidos das planilhas e compare com o total do relatório. 2. Leia a lista de cidades procurando nomes repetidos. 3. Confira se cada tabela tem o nome da planilha embaixo.
O mesmo jeito de pedir funciona para relatório.
Um bom pedido tem a parte de fora: o que a IA não deve tocar. Sem isso, ela "melhora" coisas que ninguém pediu, e a conferência fica maior.
Carla acrescentou: "não altere as planilhas originais; grave o relatório num arquivo novo". Ela não precisa mais conferir se os dados de origem mudaram.
Gerar o relatório semanal num arquivo novo, com os três critérios.
Não alterar as planilhas originais. Não mudar o formato do relatório.
Pratique agora 0/3
Pronto quando você tiver três critérios que passam no teste do sim ou não e uma linha do que fica de fora. Cerca de 10 minutos, no papel ou no bloco de notas.
Você só escreve; nada é enviado a ninguém. Se não tiver tarefa de código, use uma de texto ou planilha: o critério funciona igual.
Tarefa: <o que você vai pedir à IA> Critérios de aceite: 1. <algo que se confere com sim ou não> 2. <outro> 3. <outro> Fora: <o que a IA não deve tocar> Exemplo da Carla: Tarefa: relatório semanal de entregas 1. Total de pedidos igual à soma das planilhas da semana 2. Cada cidade aparece uma vez, com o seu total 3. Embaixo de cada tabela, o nome da planilha de onde veio Fora: não alterar as planilhas originais
Você já transforma um desejo em critérios que outra pessoa consegue conferir.
Cola da aula
Aula 3 · Dev com IA v6.2 · INEMA.CLUB
Módulo 1 · Aula 4 de 5

Você consegue trocar um limite vago por três limites que dá para conferir: tentativas, arquivos e tempo ou gasto.
Tarefa longa com IA consome tempo e o uso da sua conta. Uma frase como "pare em duas horas" parece um limite, mas a IA pode não cumprir. O limite que protege você é o que alguém ou alguma coisa confere.
Em 1 minuto
A IA lê "pare em duas horas" como qualquer outra frase. Ela pode não ter relógio à mão e pode achar que falta pouco. A frase ajuda, mas não garante nada.
O risco cresce no modo automático, em que o assistente aprova as próprias ações e segue sem pedir a sua confirmação. Cada etapa consome o uso da sua conta.
Rafael deixou o assistente no modo automático corrigindo o formulário, "em no máximo uma hora". Voltou do almoço e ele estava na décima tentativa.
"Corrija o envio do formulário. Pare em uma hora."
O que aconteceu: dez tentativas, e o trabalho seguiu depois da hora.
No pedido: "no máximo duas tentativas, só o arquivo do formulário". Fora do pedido: ele ficou por perto, com um alarme de 30 minutos.
O que aconteceu: parou na segunda tentativa e descreveu o que faltava.
Cada limite responde a uma pergunta que você checa depois. Quantas tentativas fez? Que arquivos mudou? Quanto tempo ou uso gastou? Uma tentativa é cada vez que a IA diz que vai tentar de outro jeito.
Carla mandou a IA trabalhar numa pasta de cópias. Depois abriu a pasta das planilhas originais no modo Detalhes (no Mac, Lista) e olhou a coluna "Data de modificação": nenhuma data de hoje.
Limite no pedido você confere depois. Trava para o trabalho na hora. Para tempo, com você por perto, basta um alarme: quando tocar, clique no botão de parar do assistente (um quadrado, no app e na extensão) ou aperte Esc no terminal.
Para gasto, entre no site onde você assinou, abra as configurações da conta e procure "Uso" (em inglês, "Usage"). Ali você mede. Trava de gasto só existe quando a conta aceita um teto, o que é comum em conta paga por consumo.
Carla achou a página de uso da conta dela e anotou quanto uma tarefa de relatório consumia. Passou a saber quantas cabem na semana.
Alarme de 30 minutos. Tocou: botão de parar, e peça o relato do que foi feito.
Página de uso da conta, aberta antes e depois da tarefa. Teto de gasto, se a conta oferecer.
No terminal do Linux, o comando timeout encerra outro programa quando o tempo acaba. No Mac, ele vem com o pacote coreutils (brew install coreutils) e se chama gtimeout.
$ timeout 30m claude -p "Corrija o envio do formulário. No máximo 2 tentativas. Altere só contato.html."
...
$ echo $?
124
124 quer dizer que o tempo acabou e o programa foi encerrado. Outro número é a resposta do próprio programa: zero se ele terminou bem.
Com o Codex, troque claude -p por codex exec. Encerrar no meio pode deixar um arquivo pela metade: confira o que mudou antes de seguir.
Se travou aqui, é normalNão achou a página de uso da sua conta? Comece só pelo alarme. A página de uso você procura com calma depois, uma vez só.
O limite só funciona se você disser o que fazer quando ele chega. Peça: pare, descreva o que tentou, o que falhou e o que precisaria para seguir.
Carla recebeu um aviso claro depois de duas tentativas: uma planilha tinha colunas em outra ordem. Ela arrumou a planilha em dois minutos.
CarlaJunte as planilhas da pasta "entregas-copia". No máximo 2 tentativas. Se não der, pare e diga o que tentou, o que falhou e o que falta.
IAParei após 2 tentativas. Tentei juntar as planilhas pela ordem das colunas. Falhou: uma das planilhas tem a coluna "cidade" em outra posição. Falta: me dizer se posso reordenar as colunas dessa planilha na cópia.
Um bloqueio descrito vale mais que uma décima tentativa.
Pratique agora 0/3
Pronto quando o seu pedido tiver limite de tentativas, lista de arquivos, instrução de parada e o alarme combinado. Cerca de 10 minutos, no bloco de notas.
Você só escreve o pedido; não precisa enviar agora. Não fez a aula 3? Use qualquer tarefa que você pediria à IA nesta semana.
<seu pedido, com os critérios de aceite> Limites: - No máximo 2 tentativas. - Altere só: <arquivo ou pasta>. - Se bater um limite, pare e diga o que tentou, o que falhou e o que falta.
Você já transforma "não demore" em limites que dá para conferir.
Cola da aula
O kit Use Both, um guia aberto para usar Claude e Codex juntos, chama isso de "meta com condição de parada": objetivo com sucesso observável (quais testes, qual saída) e limites de arquivos, tentativas e gasto. Pedir "pare em duas horas" é um pedido, não um limite garantido.
No vídeo que acompanha o kit, o autor, Mark Kashef, relata que o modo de meta do Codex (em que ele persegue um objetivo sozinho) gasta de 3 a 5 vezes mais tempo e tokens. É um relato dele, sem medição publicada.
Defina limites verificáveis para tarefas longas. Confira preços, cotas e ferramentas disponíveis na conta antes de usar recursos pagos. Preços e limites mudam; o que vale é o que a sua conta mostra no dia.
Fontes: Área Codex + Claude — Eventos INEMA · Guia do Use Both
Aula 4 · Dev com IA v6.2 · INEMA.CLUB
Módulo 1 · Aula 5 de 5

Você consegue montar o briefing do seu piloto: objetivo, o que fica dentro e fora, critérios de aceite e limites, num arquivo só.
Nas aulas anteriores você viu as peças soltas: conferir, revisão cruzada, critério e limite. Soltas, elas se perdem entre um pedido e outro. Juntas num arquivo, viram o começo de um método que qualquer modelo segue.
Em 1 minuto
Este curso segue cinco passos, um módulo para cada. O primeiro você já praticou: definir a tarefa. Os outros vêm nos próximos módulos.
O último passo é o handoff: um registro para a próxima conversa continuar sem você explicar tudo de novo.
Rafael colou os cinco passos na parede do escritório. Toda tarefa com IA para um cliente passa por eles.
Um ponto de partida comum: o Claude escreve o plano e o Codex critica. Depois, um constrói e o outro revisa. Essa é uma rota para começar, não um ranking de qual modelo é melhor.
Só tem um assistente? Comece com ele fazendo e uma conversa nova dele criticando. O método é o mesmo.
Carla tem o Codex e um chat de IA. Ela usa o Codex para fazer e o chat, numa conversa nova, para criticar.
Plano: Claude escreve, Codex critica.
Construção: um faz, o outro revisa o que mudou.
A qualidade da entrega na sua tarefa. Modelos, acesso e cobrança mudam de conta para conta.
O briefing junta num arquivo de texto o que você escreveu nas aulas 3 e 4. Os dois modelos recebem o mesmo arquivo. Assim, ninguém trabalha com um resumo.
A terminação .md quer dizer texto simples, no formato Markdown: os # marcam títulos. Os assistentes leem bem esse formato.
Rafael salva o briefing.md na pasta do projeto do cliente. No Claude Code e no Codex, ele digita @ no pedido e escolhe o arquivo. Num chat, ele cola o texto.
O curso inteiro gira em torno de um piloto seu. Escolha uma tarefa real e pequena, que caiba em uma ou duas horas do seu trabalho. Grande demais, o ciclo se perde. De mentira, ninguém confere de verdade.
Carla escolheu a rotina que junta as planilhas de entrega da semana. É pequena, ela faz toda semana e sabe dizer quando está certa.
"Automatizar todos os relatórios da empresa."
"Juntar as planilhas de entrega da semana num relatório, conferido contra a soma."
Se travou aqui, é normalNenhuma tarefa parece pequena o bastante? Pegue um pedaço de uma grande: só uma página, só um relatório, só uma fórmula.
Pratique agora 0/4
Pronto quando o arquivo briefing.md tiver as quatro partes preenchidas. Cerca de 12 minutos, no computador.
É um arquivo de texto seu; nada é enviado. Se não souber um limite, escreva "a definir" e volte à aula 4. Sem computador agora? Escreva no app de notas do celular e crie o arquivo depois.
# Briefing: <nome do piloto> ## Objetivo <uma frase: para que serve> ## Dentro e fora Dentro: <o que pode mudar> Fora: <o que não pode mudar> ## Critérios de aceite 1. <sim ou não> 2. <sim ou não> 3. <sim ou não> ## Limites - Tentativas: <no máximo 2> - Arquivos: <quais> - Tempo ou gasto: <onde fica a trava>
Você já tem o briefing que os dois modelos vão ler no módulo 2.
Cola da aula
Aula 5 · Dev com IA v6.2 · INEMA.CLUB
Módulo 2 · Aula 1 de 5

Você consegue pedir à IA um plan-v1.md com escopo, suposições, critérios de aceite e riscos, sem ela mexer em nada ainda.
Quando o plano fica no meio da conversa, ele se mistura com perguntas, correções e código. Ninguém consegue criticá-lo inteiro. Num arquivo, o plano vira uma coisa que outra IA e você leem do começo ao fim.
Em 1 minuto
plan-v1.md, na pasta do piloto.O plano é a primeira coisa que a IA escreve. Se ele sai só na conversa, some quando você rola a tela. Em arquivo, ele fica na pasta, com nome e versão.
Assim o segundo modelo lê exatamente o mesmo texto que você leu.
Rafael pediu o plano do formulário da clínica. Na primeira vez, veio na conversa, misturado com código. Na segunda, pediu um arquivo.
RafaelPlaneje o formulário de contato da clínica.
IAClaro. Primeiro vou criar o formulário. Já criei o arquivo contato.html com os campos. Em seguida…
O plano virou obra no meio da resposta. Não sobrou nada para criticar.
RafaelLeia briefing.md. Escreva o plano em plan-v1.md, com escopo, suposições, critérios de aceite e riscos. Não implemente nada ainda.
IAGravei plan-v1.md na pasta do piloto. Não alterei nenhum outro arquivo.
Um arquivo que qualquer pessoa, ou outra IA, pode ler inteiro.
Um plano que se critica tem quatro partes. Escopo: o que entra e o que fica fora. Suposições: o que a IA está dando por certo. Critérios de aceite: como conferir. Riscos: o que pode dar errado.
Os critérios de aceite vêm do seu briefing. O plano diz como cada um vai ser testado.
No plan-v1.md de Rafael, a parte de riscos avisou: a hospedagem da clínica pode bloquear o envio de e-mail.
Assistentes de código gostam de começar logo. Sem a frase "não implemente nada ainda", o plano vira obra. E obra errada custa mais para desfazer do que plano errado para corrigir.
A frase é um pedido. No Claude Code existe uma trava de verdade: o modo de planejamento, que impede editar arquivos. Aperte Shift+Tab até ele aparecer; o plano volta na conversa, e você mesmo o salva em plan-v1.md.
Carla pediu o plano da rotina das planilhas e esqueceu a frase. O assistente já criou três arquivos novos na pasta. Ela teve de apagar tudo e pedir de novo.
Pedido: "Planeje a rotina das planilhas."
Resultado: três arquivos criados antes de alguém ler o plano.
Pedido: "Escreva o plano em plan-v1.md. Não implemente nada ainda."
Resultado: um arquivo só, para ler em cinco minutos.
A parte de suposições é a mais valiosa. Os erros costumam se esconder no que ninguém escreveu. Quando a IA escreve o que deu por certo, você e o revisor conseguem discordar.
No plan-v1.md de Carla apareceu: "todas as planilhas têm as mesmas colunas, na mesma ordem". Ela sabia que não era verdade para uma cidade. O erro apareceu antes de qualquer tentativa.
O plano manda "juntar as planilhas pela ordem das colunas". Ninguém percebe o que isso supõe.
"Suponho que todas as planilhas têm as mesmas colunas, na mesma ordem." Carla lê e corrige na hora.
Se travou aqui, é normalO plano veio longo demais? Peça: "resuma em uma página, mantendo as quatro partes". Plano curto se critica melhor.
Pratique agora 0/3
Pronto quando existir um plan-v1.md na pasta do piloto com as quatro partes e nenhum outro arquivo novo. Cerca de 10 minutos, no computador.
O pedido diz para não implementar nada. Se o assistente criar outros arquivos mesmo assim, interrompa (tecla Esc no Claude Code; botão de parar no app) e apague só o que ele criou. Não fez a aula 5? Escreva três linhas de briefing no próprio pedido.
Leia briefing.md. Escreva o plano em plan-v1.md, na mesma pasta. Inclua quatro partes: escopo (dentro e fora), suposições, critérios de aceite (cada um com o teste que vai conferir) e riscos. Não implemente nada ainda. Não altere nenhum outro arquivo.
Você já tem um plano em arquivo, pronto para outra IA atacar.
Cola da aula
O primeiro fluxo do kit Use Both, "planejar e depois desafiar", começa assim: criar plan-v1.md para a tarefa, sem implementar nada, com escopo, suposições, critérios de aceite (cada um com o seu teste) e riscos. O mesmo arquivo segue depois para a crítica do outro modelo, só leitura. O nome com número de versão permite guardar o plano original quando vier a versão revisada.
Fontes: Guia do Use Both · Área Codex + Claude — Eventos INEMA
Aula 6 · Dev com IA v6.2 · INEMA.CLUB
Módulo 2 · Aula 2 de 5

Você consegue pedir a outra IA uma crítica do seu plano em que cada achado traz falha, evidência, impacto e a menor correção.
"Parece bom" e "poderia considerar mais casos" não ajudam ninguém. Uma crítica só serve quando aponta o trecho, diz o que acontece se ninguém corrigir e propõe o conserto mais simples.
Em 1 minuto
Na crítica, você quer achados, não um plano novo escrito por cima do seu. Por isso o pedido diz: leia, aponte, não altere arquivos. Essa frase ainda é um pedido; a trava de verdade, que impede alterar, vem na aula 8.
O revisor pode ser outro modelo ou uma conversa nova do mesmo assistente. É a revisão cruzada da aula 2 aplicada ao plano.
Rafael mandou o plan-v1.md do formulário ao Codex, com o pedido de crítica só leitura. Recebeu três achados e nenhum arquivo mudado.
RafaelLeia briefing.md e plan-v1.md. Liste os achados do plano. Para cada achado: falha, trecho do plano, impacto e a menor correção. Não altere arquivos.
CodexAchado 1. Falha: o plano não diz o que acontece se o envio falhar. Trecho: "enviar para o e-mail da recepção". Impacto: o paciente vê "enviado" e a mensagem se perde. Menor correção: mostrar um aviso de erro e registrar a falha.
Um achado que Rafael consegue conferir e corrigir sem perguntar nada.
Falha é o que está errado ou faltando. Evidência é o trecho que mostra isso. Impacto é o que acontece se ninguém corrigir. A menor correção é o conserto mais simples que resolve.
Peça também uma gravidade: alta, média ou baixa. Assim você sabe por onde começar.
Carla pediu a crítica do plano das planilhas no chat de IA, numa conversa nova. Pediu os achados em ordem de gravidade.
Sem os quatro campos, a crítica vira conselho genérico. Você não sabe se concorda, porque não sabe do que se trata.
A primeira crítica que Rafael recebeu, sem o molde, dizia "considere validar melhor os campos". Com o molde, virou um achado sobre o telefone.
"Considere validar melhor os campos do formulário."
Falha: o plano não trata telefone com letras. Evidência: "campo telefone, texto livre". Impacto: fere o critério 2 do briefing. Menor correção: aceitar só números.
Se travou aqui, é normalO revisor devolveu achados que parecem errados? Ótimo: você não precisa aceitar todos. Na aula 9, você aprende a responder cada um com "aceito", "rejeitado com evidência" ou "em aberto".
Sem o briefing, o revisor julga o plano pelo gosto dele. Com o briefing, julga pelo que você pediu. Mande os dois arquivos, de verdade.
Carla colou no chat o briefing, depois o plano, e só então o pedido de crítica. No assistente de código, basta citar os dois arquivos pelo nome.
O revisor sugere trocar a planilha por um banco de dados. Fora do escopo.
O revisor aponta que o plano esqueceu o critério "cada cidade aparece uma vez".
Pratique agora 0/3
Pronto quando você tiver um review.md com pelo menos dois achados nos quatro campos. Cerca de 10 minutos, no computador.
O pedido é só leitura: nenhum arquivo muda. Use outro assistente ou uma conversa nova do mesmo. Não fez a aula 6? Peça a crítica de qualquer plano que você tenha em texto.
Leia briefing.md e plan-v1.md. Critique o plano, só lendo. Liste os achados. Para cada achado, escreva: - Falha: - Evidência (o trecho exato do plano): - Impacto (o que acontece se ninguém corrigir): - Menor correção: - Gravidade (alta, média ou baixa): Ordene por gravidade. Não altere nenhum arquivo.
Você já recebe crítica que dá para conferir, não conselho genérico.
Cola da aula
Aula 7 · Dev com IA v6.2 · INEMA.CLUB
Módulo 2 · Aula 3 de 5

Você consegue pedir a crítica do plano a outro assistente com um comando, ou pelo caminho manual, e abrir o review.md que volta.
Copiar o plano de uma janela e colar na outra funciona, mas cansa e erra: falta um trecho, sobra outro. Existem caminhos em que um assistente chama o outro e a resposta cai direto num arquivo.
Em 1 minuto
O Claude Code e o Codex podem conversar de três jeitos automáticos. O primeiro é um plugin oficial do Codex para o Claude Code. O segundo é um comando que chama o outro assistente e grava a resposta num arquivo.
O terceiro é a revisão de uma mudança publicada, que aparece no módulo 3. Todos, inclusive o manual, seguem a regra do módulo: o revisor recebe o briefing e o arquivo real.
Rafael usa o segundo caminho: um comando só, rodado na pasta do piloto.
No terminal, dentro da pasta do piloto, o comando codex exec faz um pedido e sai. Ele é a CLI do Codex.
A opção --sandbox read-only põe o Codex numa sandbox só leitura. A opção -o grava a última resposta em review.md.
A pasta do piloto de Rafael ainda não usa o Git. Por isso ele acrescenta --skip-git-repo-check, que o Codex pede fora dele.
$ codex exec --skip-git-repo-check --sandbox read-only -c model_reasoning_effort=medium -o review.md 'Leia briefing.md e plan-v1.md. Liste os achados do plano, cada um com falha, evidência, impacto e a menor correção. Não altere arquivos.'
...
$ ls
briefing.md plan-v1.md review.md
O ls mostra que só apareceu o review.md. O plano continua igual.
-c model_reasoning_effort=medium escolhe o esforço médio. O módulo 6 volta nisso.Se quem escreveu o plano foi o Codex, o revisor pode ser o Claude. O comando claude -p faz um pedido, imprime a resposta e sai. O sinal > grava essa resposta num arquivo.
A trava fica na opção --permission-mode plan: é o modo de planejamento, em que o Claude lê os arquivos mas não altera nenhum. Sem ela, "não altere arquivos" seria só um pedido.
Rafael inverteu os papéis num segundo projeto: o Codex planejou e o Claude revisou.
$ claude -p --permission-mode plan 'Leia briefing.md e plan-v1.md. Liste os achados do plano, cada um com falha, evidência, impacto e a menor correção. Não altere arquivos.' > review-claude.md
Nada aparece na tela: a resposta foi toda para review-claude.md.
--model e --effort; os nomes dependem da sua conta. O módulo 6 volta nisso.Se travou aqui, é normalNunca usou terminal? Faça pelo caminho manual, o item 4 do quadro: abra uma conversa nova, cole o briefing, o plano e o pedido de crítica da aula 7, e salve a resposta como review.md. O resultado é o mesmo.
O conteúdo da crítica não muda. Muda o trabalho braçal e o risco de colar a coisa errada. Com o comando, o revisor lê os arquivos direto da pasta.
Carla usa o Codex pelo app e um chat de IA. Ela ficou com o caminho manual e guardou o pedido de crítica num arquivo, para colar sempre igual.
Conversa nova, cola briefing, plano e pedido. Salva a resposta como review.md. Funciona em qualquer chat.
Um comando na pasta. O revisor lê os arquivos e a resposta cai em review.md. Menos cópia, menos erro de colagem.
Pratique agora 0/3
Pronto quando existir um review.md ao lado do plan-v1.md e o plano estiver igual ao de antes. Cerca de 12 minutos, no computador.
O revisor roda só leitura. Se o comando der erro, confira se está na pasta do piloto e se o assistente está conectado à sua conta; se não resolver, use o caminho manual. Para abrir o terminal na pasta: no Windows 11, botão direito na pasta › Abrir no Terminal; no Mac, digite cd e um espaço e arraste a pasta para a janela. No Windows, use o PowerShell: as aspas simples não funcionam no Prompt de Comando. Não fez as aulas 5 e 6? Use qualquer plano em texto.
codex exec --skip-git-repo-check --sandbox read-only -o review.md 'Leia briefing.md e plan-v1.md. Liste os achados do plano, cada um com falha, evidência, impacto e a menor correção. Não altere arquivos.'
Só tem o Claude Code? Use este:
claude -p --permission-mode plan 'Leia briefing.md e plan-v1.md. Liste os achados do plano, cada um com falha, evidência, impacto e a menor correção. Não altere arquivos.' > review.md
Você já recebe a crítica de outro assistente sem mexer no plano.
Cola da aula
A área Codex + Claude do Eventos INEMA lista três formas de ligar os dois: o plugin oficial do Codex para o Claude Code (openai/codex-plugin-cc), uma CLI chamando a outra com a resposta salva num .md, e um pull request (a revisão de uma mudança publicada) que o outro modelo revisa. Os dois comandos desta aula foram conferidos no ambiente do INEMA; as opções mudam com as versões, então rode codex exec --help e claude --help para ver as da sua máquina.
Por padrão, o codex exec só roda dentro de uma pasta com controle de versões. Fora dela, a opção libera a execução. No módulo 3, a pasta do piloto passa a ter esse controle e a opção deixa de ser necessária.
Aula 8 · Dev com IA v6.2 · INEMA.CLUB
Módulo 2 · Aula 4 de 5

Você consegue responder cada achado da crítica, decidir quando parar o debate e saber quando vale automatizá-lo.
Plano e crítica podem ir e voltar para sempre. Cada rodada gasta tempo e uso da conta, e a partir de certo ponto os dois só concordam por cansaço. Quem decide o que fica em aberto são os testes, não mais uma rodada.
Em 1 minuto
Uma rodada de revisão é uma ida e volta: a crítica chega e cada achado recebe uma resposta. Aceito: entra no plano. Rejeitado com evidência: você mostra por que não. Em aberto: ninguém sabe ainda.
Carla respondeu os três achados do plano das planilhas. Um aceito, um rejeitado e um em aberto.
A primeira rodada acha a maior parte das falhas. A segunda confere se as correções ficaram boas. Depois disso, cada rodada acha menos e custa o mesmo. E os dois modelos começam a concordar, o que a aula 2 mostrou que não é prova.
Rafael deixou o debate do formulário ir até a quinta rodada. As três últimas só trocaram palavras de lugar.
Rodadas 3, 4 e 5: ajustes de redação. Os dois assistentes terminam "de acordo". Nenhum teste nomeado.
Rodada 1 acha falhas. Rodada 2 confere as correções. O que sobrou vira teste antes de construir.
Teste-se
Depois da segunda rodada, os dois modelos concordam que o plano está pronto. O que isso garante?
Achado em aberto não se resolve discutindo. Ele vira um teste escrito no plano, para rodar quando existir o que testar. Assim o debate para, mas a dúvida não some.
O achado da cidade em branco virou um teste. Rodar com a planilha de Juiz de Fora, que tem cidade em branco, e conferir onde o pedido aparece.
CarlaO achado 3 está em aberto: não sei o que fazer com cidade em branco. Transforme em um teste para o plano, sem decidir por mim.
IATeste proposto: rodar a rotina com uma planilha que tenha uma linha de cidade em branco. Conferir se o pedido aparece no total geral e onde ele é listado. A decisão sobre o que é certo fica com você.
O teste diz o que conferir. A regra de negócio continua sendo de Carla.
Para plano pequeno, duas rodadas feitas à mão bastam. Para plano grande, existe o claudex, um plugin do Claude Code. No comando /claudex:plan --rounds 2 <tema>, o Claude escreve o PLAN.md e o Codex critica, com um revisor diferente a cada rodada. O ciclo repete até a aprovação ou até o número de rodadas. O padrão é 3; fixe 2 para seguir a regra desta aula.
Rafael usa as duas rodadas manuais no formulário. Guardou o claudex para o sistema de agendamento da clínica, bem maior.
Duas rodadas à mão. Você lê cada achado e responde.
/claudex:plan --rounds 2, com o número de rodadas fixado. No fim, você ainda lê o plano e nomeia os testes.
Se travou aqui, é normalNão usa o Claude Code? Ignore o claudex por enquanto. As duas rodadas manuais funcionam com qualquer assistente, até com uma conversa nova do mesmo.
Pratique agora 0/3
Pronto quando cada achado do caso tiver uma resposta e o em aberto tiver virado teste. Cerca de 8 minutos, no papel ou no bloco de notas.
É um caso para treinar. Se um achado parecer tanto aceito quanto rejeitado, marque em aberto e escreva o teste que decidiria.
O caso. O briefing de Rafael pede um formulário de contato para a clínica, só na página de contato. A crítica trouxe três achados. A: "o plano não limita o tamanho da mensagem". B: "trocar as cores da página inicial para destacar o contato". C: "não está claro se a recepção quer cópia das mensagens no celular".
Você já encerra o debate com cada achado respondido e a dúvida guardada num teste.
Cola da aula
No fluxo "planejar e depois desafiar", o kit pede para reconciliar os achados como aceitos, rejeitados com evidência ou em aberto (o kit diz "não resolvidos"), salvar plan-v2.md e review.md, e limitar a duas rodadas de revisão. E lembra: concordância não é prova; nomeie os testes ou a evidência necessários antes de implementar.
Segundo a área Codex + Claude do Eventos INEMA, os dois são complementares. O claudex é software que automatiza o debate de um plano grande. O Use Both é método para todo o resto: revisar mudança, meta com condição de parada, trocar de sessão.
Fontes: Guia do Use Both · Área Codex + Claude — Eventos INEMA
Aula 9 · Dev com IA v6.2 · INEMA.CLUB
Módulo 2 · Aula 5 de 5

Você consegue fechar o plan-v2.md do seu piloto, com cada achado respondido e cada critério de aceite ligado a um teste.
Receber a crítica é metade do caminho. A outra metade é juntar o que foi aceito numa versão nova. Sem perder o plano original, e sem esquecer o que ficou em aberto. E sem transformar a rota do kit em verdade absoluta.
Em 1 minuto
O kit Use Both traz uma tabela de quem faz o quê. Para planejar: o Claude escreve e o Codex critica as premissas. A linha de chegada é um plano com escopo e critérios de aceite, cada um com o seu teste. São preferências iniciais registradas pelo autor, não um ranking medido de modelos.
Rafael começou pela rota da tabela. No segundo projeto, inverteu os papéis para ver qual crítica achava mais problemas reais na tarefa dele.
Modelos, acesso e cobrança mudam de conta para conta e de mês para mês. Por isso a pergunta útil não é "qual é o melhor". É "nesta tarefa, qual crítica achou falhas reais, com evidência".
Carla comparou duas críticas do mesmo plano: uma do Codex, outra de uma conversa nova do chat. Contou quantos achados tinham evidência que ela conferiu.
"Dizem que o modelo X é o melhor para planejar." Carla usaria só ele, sem conferir.
Crítica 1: 3 achados, 2 conferidos. Crítica 2: 5 achados, 1 conferido. Nesta tarefa, a crítica 1 serviu mais.
Não escreva por cima do plan-v1.md. A versão nova é um arquivo irmão: plan-v2.md. Assim você compara as duas e sabe o que mudou por causa da crítica.
O plan-v2.md traz os achados aceitos, uma lista dos rejeitados com a evidência e os em aberto como teste.
A pasta do piloto de Rafael ficou com quatro arquivos, cada um com um papel.
Antes de construir, confira se cada critério de aceite do briefing tem um teste no plano. Critério sem teste é critério que ninguém vai conferir.
Rafael pediu essa conferência a uma conversa nova. Um critério tinha ficado sem teste.
RafaelLeia briefing.md e plan-v2.md. Liste cada critério de aceite do briefing e o teste do plano que o confere. Aponte critério sem teste. Não altere arquivos.
IACritério 1, mensagem chega na recepção: teste de envio real. Critério 2, telefone recusa letras: teste de digitação. Critério 3, abre no celular: nenhum teste no plano.
A lacuna apareceu antes da primeira linha de código.
Se travou aqui, é normalSeu review.md tem achados demais? Leve para o plan-v2.md só os de gravidade alta e média. Os de gravidade baixa recebem a resposta "em aberto (baixa)" e ficam no review.md; não entram no plan-v2.md.
Pratique agora 0/4
Pronto quando o plan-v2.md estiver na pasta, ao lado do plan-v1.md, com todo critério de aceite ligado a um teste. Cerca de 12 minutos, no computador.
O plan-v1.md não muda: você cria um arquivo novo. Não fez as aulas 6 a 9? Use o molde com qualquer plano e crítica que tiver em texto.
Leia briefing.md, plan-v1.md e review.md (com as minhas respostas: aceito, rejeitado ou em aberto). Escreva plan-v2.md, arquivo novo: - incorpore os achados aceitos; - liste os rejeitados com a evidência; - transforme os em aberto em testes com nome. Não altere plan-v1.md nem review.md. Não implemente nada.
Você fechou o plano do piloto: criticado, respondido e com um teste para cada critério.
Cola da aula
O cartão de rotas do kit Use Both, resumido na área Codex + Claude do Eventos INEMA, traz preferências iniciais registradas no vídeo de Mark Kashef, traduzidas em tarefas. O próprio kit diz que são escolhas editoriais, não ranking medido: experimente e fique com a rota que produzir melhor evidência. O vídeo cita Claude Opus 5.5 e GPT-6 Astra; modelos, ferramentas, limites e cobrança mudam conforme a conta, e o fluxo de trabalho é mais portátil que esses nomes.
Fontes: Área Codex + Claude — Eventos INEMA · Guia do Use Both
Aula 10 · Dev com IA v6.2 · INEMA.CLUB
Módulo 3 · Aula 1 de 5

Você consegue criar um branch de teste e ler um git diff linha a linha, dizendo o que saiu e o que entrou.
No módulo 2 alguém criticou o plano. Agora a IA vai mexer em arquivos de verdade. Para revisar o que ela fez, você precisa ver exatamente o que mudou, e não o que ela diz que mudou.
Em 1 minuto
git diff, linha com − saiu e linha com + entrou.O Git guarda versões dos arquivos de uma pasta. Com ele, você compara a versão de antes com a de agora, linha por linha.
Para revisar trabalho de IA, isso é o que importa. O resumo diz "alterei o formulário". A diferença mostra quais linhas, em quais arquivos.
Rafael pediu uma correção no campo telefone do site da clínica. O resumo falava de um arquivo. A diferença mostrou dois: a IA também tinha mexido no rodapé.
Pergunta: "o que você mudou?"
Resposta: o resumo da IA, com a memória dela.
Pergunta: "o que mudou?"
Resposta: o Git lista os arquivos que mudaram, inclusive os novos, e mostra as linhas.
Saldo: Rafael achou a mudança no rodapé, que ninguém tinha pedido.
Antes de a IA mexer, crie um branch. Se a mudança não prestar, a versão que funciona continua intacta.
No terminal, dentro da pasta do projeto, um comando cria o branch e já entra nele. O git status confirma onde você está.
Rafael criou o branch formulario-contato antes de pedir qualquer coisa à IA. A versão publicada do site ficou no branch principal.
$ git switch -c formulario-contato
Switched to a new branch 'formulario-contato'
$ git status
On branch formulario-contato
nothing to commit, working tree clean
"Switched to a new branch" = branch criado e você já está nele. "nothing to commit" = nada mudou ainda.
Depois que a IA trabalha, rode primeiro o git status: ele lista todos os arquivos que mudaram, inclusive os novos. Arquivo novo não aparece no git diff até você usar o git add, que a aula 13 mostra.
Em seguida, o git diff mostra o diff. Cada arquivo alterado vem com o nome. Linha que começa com − saiu; linha com + entrou. As outras são contexto, sem mudança.
No diff de Rafael, uma linha do campo telefone saiu e outra entrou no lugar. Ele leu as duas e viu a regra nova: só números, espaço, parênteses e hífen.
$ git diff
diff --git a/contato.html b/contato.html
index 3f2a1c0..8b7d4e2 100644
--- a/contato.html
+++ b/contato.html
@@ -14,3 +14,3 @@
<label for="telefone">Telefone</label>
- <input type="text" id="telefone" name="telefone">
+ <input type="tel" id="telefone" name="telefone" pattern="[0-9 \(\)\-]+">
<label for="mensagem">Mensagem</label>
As cinco primeiras linhas dizem qual arquivo e em que trecho. Depois, − a linha antiga e + a nova. Diff longo abre página por página: Espaço avança, q sai.
Teste-se
No diff, uma linha começa com −. O que isso quer dizer?
Se você usa o assistente pelo app, não precisa abrir o terminal. Peça a ele que mostre o diff completo do que mudou. O assistente roda o comando e cola o resultado.
Carla usa o Codex pelo app. Depois de cada pedido, ela escreve: "mostre o git diff completo". Assim ela vê as linhas, e não só a frase "alterei o juntar.py".
Planilha .xlsx é diferente: no diff ela aparece só como "Binary files differ", sem as células. Para planilha, peça ao assistente o resumo das células que mudaram, ou trabalhe com a cópia em CSV, que o diff mostra linha por linha.
CarlaSome os pedidos por cidade no arquivo juntar.py.
IAPronto. Ajustei a soma por cidade.
Ajustou onde? Quantas linhas? Não dá para saber.
CarlaMostre o git diff completo do que você mudou.
IAdiff --git a/juntar.py b/juntar.py --- a/juntar.py +++ b/juntar.py @@ -8,1 +8,1 @@ -total = pedidos.sum() +total = pedidos.groupby("cidade").sum()
Agora Carla vê a linha que saiu e a que entrou.
Se travou aqui, é normalO diff parece sopa de letras? Leia só três coisas: o nome do arquivo, as linhas com − e as linhas com +. O resto é endereço e contexto.
Pratique agora 0/4
Pronto quando você tiver lido um diff do seu briefing.md e anotado uma linha que saiu e uma que entrou. Cerca de 12 minutos, no computador.
Tudo acontece na pasta do piloto, com o briefing da aula 5; não fez? Crie qualquer arquivo de texto ali. Se aparecer "git: command not found" (no Windows: "O termo 'git' não é reconhecido"), instale o Git pelo site oficial, git-scm.com, e feche e reabra o terminal. Se o commit pedir nome e e-mail, rode os dois comandos git config que ele mostrar, trocando o nome e o e-mail de exemplo pelos seus. Prefere não usar terminal? Peça cada passo ao seu assistente, na pasta do piloto.
git init git add briefing.md git commit -m "briefing inicial" git switch -c teste-diff git diff
Você já lê, no próprio Git, o que mudou num arquivo.
Cola da aula
Aula 11 · Dev com IA v6.2 · INEMA.CLUB
Módulo 3 · Aula 2 de 5

Você consegue pedir só a primeira etapa do seu piloto, com os critérios do briefing colados e uma parada no fim.
Pedir a tarefa inteira de uma vez gera uma mudança enorme. Ninguém revisa bem trezentas linhas. Em etapas, cada mudança é pequena, conferida e revisada antes da próxima.
Em 1 minuto
Quando a IA faz tudo num pedido só, o diff fica longo. Você passa os olhos, cansa e aprova. É assim que o erro entra.
Rafael pediu "o formulário inteiro, com envio e validação". Voltaram mudanças em sete arquivos. Na vez seguinte, pediu só os campos: um arquivo, poucas linhas.
Pedido: formulário completo.
Diff: sete arquivos. Rafael aprovou sem ler tudo.
Pedido: só os campos do formulário.
Diff: um arquivo, que ele leu linha a linha.
Saldo: mudança pequena é mudança que você de fato confere.
Pegue o plano do módulo 2 e separe em etapas que caibam em um pedido. Cada etapa herda do briefing o critério de aceite que ela deve cumprir.
Carla dividiu a rotina das planilhas em três etapas. A primeira só lê as planilhas da semana. O critério dela: o total de linhas lidas é igual à soma das linhas das planilhas.
O pedido tem quatro partes: onde ler o contexto, qual etapa fazer, os critérios dela e a ordem de parar no fim. Com a parada, a IA não emenda a etapa seguinte sem você conferir.
Rafael cita os arquivos pelo nome, com @, e pede a etapa 1. A resposta lista o que mudou e como conferir.
RafaelLeia @briefing.md e @plan-v2.md. Faça só a etapa 1: os campos do formulário. Critérios desta etapa: 1. Nome, telefone e mensagem aparecem na página. 2. O campo telefone recusa letras. Altere só contato.html. No fim, pare, liste os arquivos mudados e diga como conferir cada critério.
IAEtapa 1 feita. Arquivo mudado: contato.html. Para conferir: 1. abra a página e veja os três campos; 2. digite letras no telefone e tente enviar. Parei aqui. A etapa 2 é o envio.
Um arquivo, dois critérios, e a IA parou esperando você.
Se travou aqui, é normalNão tem o plan-v2.md do módulo 2? Use só o briefing da aula 5 e escreva você a etapa 1 no pedido. O resto funciona igual.
A versão salva no Git se chama commit. Neste curso ele vem depois da revisão da aula 13. Até lá, a mudança está só nos arquivos, e dá para desfazer.
Se a etapa não prestou, o git restore . devolve os arquivos que o Git já acompanha à última versão salva. Arquivo novo que a IA criou não some com ele: veja no git status e apague à mão.
Carla não gostou da primeira tentativa da etapa 1. Pediu ao Codex, pelo app: "desfaça as mudanças desta etapa com git restore e mostre o git status". Tudo voltou como antes.
$ git status
On branch etapas-relatorio
Changes not staged for commit:
modified: juntar.py
$ git restore .
$ git status
On branch etapas-relatorio
nothing to commit, working tree clean
"modified" = arquivo mudado e ainda não salvo. Depois do git restore ., "nothing to commit" = voltou à última versão salva.
git add da aula 13, use git restore --staged --worktree . para desfazer também o que foi preparado.Pratique agora 0/3
Pronto quando o pedido da etapa 1 tiver contexto, etapa, critérios e parada, e você tiver conferido a resposta. Cerca de 10 minutos, no computador.
A IA mexe só no arquivo que você listar, dentro do branch de teste da aula 11 (não fez? peça ao assistente: "crie um branch de teste e entre nele"). Se ela passar da etapa 1, aperte o botão de parar (Esc no terminal) e peça o relato. Num chat comum, cole o texto do briefing no lugar do @.
Leia @briefing.md <e @plan-v2.md, se tiver>. Faça só a etapa 1: <o que é a etapa 1>. Critérios desta etapa: 1. <sim ou não> 2. <sim ou não> Altere só: <arquivo>. No fim, pare, liste os arquivos mudados e diga como conferir cada critério. Exemplo da Carla: Leia @briefing.md. Faça só a etapa 1: ler as planilhas da semana. Critérios desta etapa: 1. O total de linhas lidas é igual à soma das linhas das planilhas. 2. As planilhas originais não mudam. Altere só: juntar.py. No fim, pare, liste os arquivos mudados e diga como conferir cada critério.
Você já pede trabalho em etapas que dá para conferir uma a uma.
Cola da aula
Aula 12 · Dev com IA v6.2 · INEMA.CLUB
Módulo 3 · Aula 3 de 5

Você consegue pedir ao outro modelo a revisão de uma etapa com o pacote certo: briefing, diff e o resultado das suas conferências.
Na aula anterior a IA entregou uma etapa. Se o revisor recebe só "eu fiz isso", ele revisa uma frase. Com o pacote certo, ele revisa o trabalho e aponta a linha exata do problema.
Em 1 minuto
A revisão cruzada de uma etapa precisa de três coisas. O briefing, para saber o que era pedido. O diff, para ver o que mudou. E o que você conferiu, com o resultado.
Rafael anota as conferências da etapa num arquivo conferencias.txt: "3 campos aparecem: sim. Telefone recusa letras: sim." Essa folha vai junto para o revisor.
Com o resumo, o revisor tende a concordar. Com o pacote, ele compara o pedido com a mudança e com o que foi conferido. Aí aparece o critério que ninguém testou.
Rafael mandou o pacote da etapa 1 ao Codex. A revisão notou que o conferencias.txt dizia "sim" para o telefone sem dizer como foi conferido.
RafaelO Claude disse que fez os campos do formulário. Está bom?
CodexParece adequado. Campos de formulário são uma mudança simples.
O revisor aprovou uma frase.
RafaelLeia briefing.md, mudanca.diff e conferencias.txt. Liste os achados. Para cada achado: onde, o que falha, impacto e a menor correção. Não altere arquivos.
CodexAchado 1. Onde: conferencias.txt, linha "Telefone recusa letras: sim". Falha: não diz como foi conferido. Impacto: médio. Menor correção: digitar letras no telefone, tentar enviar e anotar o que apareceu.
O achado aponta o arquivo, a linha e a correção.
Antes do commit, a versão salva, peça ao Git o diff num arquivo, pelo terminal. Depois chame o outro modelo em modo só leitura, com a resposta gravada em arquivo.
Pelo app, o caminho é o mesmo em palavras. Peça a quem fez: "rode git add -A e grave o git diff --staged em mudanca.diff". Depois abra uma conversa nova, no outro assistente ou no mesmo, e cite os três arquivos. No app, "não altere arquivos" é um pedido, não uma trava: depois, confira no git status que nada mudou.
Carla faz tudo pelo app. O Codex fez a etapa; o chat de IA, numa conversa nova, recebe os três arquivos anexados pelo clipe. Se o chat recusar o .diff, ela renomeia para mudanca.txt.
$ git add -A
$ git diff --staged --output=mudanca.diff
$ codex exec --sandbox read-only -o review.md "Leia briefing.md, mudanca.diff e conferencias.txt. Liste os achados. Para cada achado: onde, o que falha, impacto e a menor correção. Não altere arquivos."
As duas primeiras linhas preparam tudo, inclusive arquivos novos, e gravam o diff. A terceira chama o Codex só para ler, e a resposta fica em review.md. No Claude: claude -p --permission-mode plan "…mesmo pedido…" > review-claude.md. No Windows, prefira o PowerShell 7 ou o app para esse >, que no PowerShell antigo pode estragar os acentos.
Se travou aqui, é normalO comando longo assusta? Copie, troque só os nomes de arquivo se forem outros, e cole. Ou siga o caminho pelo app, que chega no mesmo lugar.
"Pode melhorar" não ajuda ninguém. Peça cada achado com onde está, o que falha, o impacto e a menor correção. Assim você decide rápido o que corrigir.
Carla recebeu um achado vago sobre a etapa de soma. Pediu de novo, nas quatro partes, e veio o ponto exato: a linha da soma, onde a cidade com e sem acento virava duas.
"A soma por cidade pode ter inconsistências."
Onde: juntar.py, linha da soma. Falha: "São Paulo" e "Sao Paulo" viram duas cidades. Impacto: total dividido. Correção: tirar acentos antes de somar.
Pratique agora 0/3
Pronto quando você tiver um review com pelo menos um achado nas quatro partes, ou a frase "nenhuma falha encontrada" com o que foi lido. Cerca de 10 minutos, no computador.
O revisor só lê. Só tem um assistente? Abra uma conversa nova nele para revisar. Não fez a etapa da aula 12? Revise o diff do briefing, da aula 11.
Leia briefing.md, mudanca.diff e conferencias.txt. Revise a etapa <número> contra os critérios do briefing. Para cada falha: onde, o que falha, impacto (alto, médio, baixo) e a menor correção. Se não achar falha, diga o que leu para concluir isso. Não altere arquivos.
Você já pede revisão do trabalho real, com evidência em cada achado.
Cola da aula
"Dividir construir e revisar": um assistente constrói à parte da versão que funciona; o outro revisa o diff com o briefing e o resultado dos testes. Testes e a sua aprovação decidem o que entra. O revisor recebe o mesmo briefing e o artefato real, nunca um resumo vago do que o primeiro fez.
Segundo o vídeo que acompanha o kit: o complemento oficial do Codex para o Claude Code; uma linha de comando chamando a outra, com a resposta salva num arquivo; ou um pedido de mudança num site de código, que o outro modelo revisa.
Fontes: Área Codex + Claude — Eventos INEMA · Guia do Use Both
Aula 13 · Dev com IA v6.2 · INEMA.CLUB
Módulo 3 · Aula 4 de 5

Você consegue conferir uma imagem feita com IA em quatro pontos: ferramenta e cobrança antes, arquivo real, tamanho de uso e versão irmã.
Imagem também é uma mudança no projeto, e também erra com confiança. Ela pode custar crédito sem você ver, vir só como link ou chegar com letras inventadas nas bordas.
Em 1 minuto
Ter um assistente de código não garante que ele gere imagem. Quando gera, cada imagem pode descontar crédito da conta. Confira as duas coisas antes de pedir.
Por isso, escreva no pedido: se não houver ferramenta, pare e avise, sem usar outro serviço pago. Sem essa ordem, ele pode trocar sozinho.
Rafael queria um banner para a página de contato da clínica. Antes, perguntou ao assistente se havia ferramenta de imagem na sessão e como ela cobrava.
RafaelAntes de gerar: esta sessão tem ferramenta de imagem? Como ela é cobrada? Se não tiver, pare e me diga; não use outro serviço.
IANão encontrei ferramenta de imagem nesta sessão. Parei aqui, sem gerar nada. Posso escrever a descrição do banner para você gerar onde tiver acesso.
Com a ordem escrita no pedido, parou e avisou em vez de procurar outro serviço.
Uma descrição de imagem não é imagem. Um link temporário também não: ele some. Só conta o arquivo salvo na pasta do projeto, com nome claro.
Carla pediu uma capa para o relatório semanal. A primeira resposta trouxe só um link. Ela pediu de novo: "salve o arquivo em imagens/capa-relatorio-v1.png".
Uma descrição da imagem, ou um link que expira.
O arquivo imagens/capa-relatorio-v1.png, dentro da pasta do projeto.
Numa miniatura, quase toda imagem parece boa. Abra no tamanho real de uso e confira três coisas: texto, marcas e recorte. É comum aparecerem letras inventadas nas bordas.
Na tela pequena, a capa de Carla estava ótima. Impressa em folha inteira, apareceu uma palavra sem sentido no canto e uma pessoa com o rosto cortado.
Teste-se
A imagem ficou ótima na miniatura. O que você faz antes de usar?
Precisou mudar a imagem? Salve a nova ao lado, com outro número, e guarde o original. Anote no projeto qual versão está em uso. Assim dá para voltar e comparar.
Rafael gerou o banner onde tinha acesso, em três versões. Guardou as três e anotou no briefing (briefing.md): "banner em uso: v2".
Se travou aqui, é normalSeu assistente não gera imagem? Tudo bem: as conferências dos passos 2 a 4 valem para qualquer imagem, feita por IA, por você ou por um designer.
Pratique agora 0/4
Pronto quando você tiver uma imagem do piloto conferida nos três pontos e uma versão irmã salva ao lado. Cerca de 10 minutos, no computador.
Nada é gerado nem cobrado: use uma imagem que você já tem, do projeto ou uma foto sua. Se o assistente disser que vai gerar algo, pare antes.
Antes de gerar qualquer imagem: esta sessão tem ferramenta de imagem? Como ela é cobrada? Não gere nada agora e não use outro serviço.
Você já confere uma imagem de IA como confere qualquer outra mudança.
Cola da aula
Só se houver uma ferramenta de imagem disponível na sessão; confira acesso e cobrança antes. O pronto é o arquivo real no projeto, aberto no tamanho em que vai ser usado. Guarde o original e salve revisões como arquivos irmãos, registrando qual versão o projeto usa.
Um roteiro automático pede a imagem ao gerador do Codex e grava o arquivo numa pasta. Cada geração consome crédito da assinatura, por isso roda só quando autorizada; sem autorização, o padrão é um gerador local gratuito. Depois de gerar, a imagem é conferida: o texto das bordas pode vir inventado.
Aula 14 · Dev com IA v6.2 · INEMA.CLUB
Módulo 3 · Aula 5 de 5

Você consegue entregar uma mudança do seu piloto com a revisão cruzada registrada num arquivo: achados, o que corrigiu e o que recusou.
Revisão que fica só na conversa se perde. Amanhã ninguém lembra o que foi achado nem por que um ponto foi recusado. E, sempre com o mesmo revisor, você não descobre se a outra rota funciona melhor na sua tarefa.
Em 1 minuto
revisao-etapa-N.md, ao lado do código."Claude faz, Codex revisa" é uma rota para começar, não um ranking. Numa etapa, experimente o inverso e compare pela sua régua: qual rota achou mais falhas reais?
Só tem um assistente? A troca é entre conversas: uma faz, outra nova revisa, e na etapa seguinte o contrário.
Rafael fez a etapa 2 com o Codex e pediu a revisão ao Claude. O Claude achou uma falha no envio que a rota anterior não tinha pegado nesta tarefa.
Claude faz a etapa. Codex revisa o diff.
Codex faz a etapa. Claude revisa o diff.
Nem todo achado vale correção. Corrija o que aponta onde, mostra a falha e bate com um critério do briefing. Recuse o que é gosto ou está fora do escopo, e escreva por quê.
Carla recebeu dois achados. Um apontava cidades repetidas por causa do acento: corrigiu. O outro sugeria trocar o formato do relatório, que está no "Fora" do briefing: recusou.
"São Paulo" e "Sao Paulo" contavam como duas cidades. Critério 2 do briefing.
"Trocar o formato do relatório." Motivo: está no Fora do briefing.
Se travou aqui, é normalNa dúvida se corrige ou recusa? Pergunte: isso quebra algum critério do briefing? Se sim, corrija. Se não, anote e siga.
Um arquivo curto por etapa guarda a revisão. Quem revisou, o que achou, o que foi corrigido, o que foi recusado e por quê. Ele fica na pasta do piloto, junto do código.
O revisao-etapa-2.md de Rafael tem seis linhas. No módulo 5, é esse arquivo que outra conversa vai ler para continuar.
No Git, o módulo inteiro vira uma sequência: branch, etapa, pacote, revisão, correção, registro e commit. O commit vem por último, depois da revisão. É a primeira mudança do seu piloto feita e conferida por dois olhares.
Carla fez a etapa 2 pelo app, na ordem da janela abaixo. Da etapa ao commit, levou uns quarenta minutos, e o revisao-etapa-2.md ficou na pasta.
Pratique agora 0/4
Pronto quando a pasta do piloto tiver o revisao-etapa-N.md preenchido a partir do review.md da aula 13 e a etapa estiver salva num commit. Cerca de 12 minutos, no computador.
Tudo acontece no branch de teste; a versão que funciona não muda. Não tem o review.md da aula 13? Treine com o exemplo da Carla no molde. Se a revisão pedir algo grande, anote "fica para outra etapa" e siga.
# Revisão da etapa <N> Fez: <modelo ou conversa> · Revisou: <outro> Achado 1: <o que é> · corrigido | recusado (motivo) Achado 2: <o que é> · corrigido | recusado (motivo) Conferido depois: <o que você testou e o resultado> Exemplo da Carla: # Revisão da etapa 2 Fez: Codex · Revisou: chat de IA, conversa nova Achado 1: cidade com e sem acento virava duas · corrigido Achado 2: trocar o formato do relatório · recusado (Fora do briefing) Conferido depois: cada cidade aparece uma vez; total confere com as planilhas
Você fechou o módulo 3 com uma mudança feita, revisada, corrigida e registrada.
Cola da aula
Reserve de 30 a 45 minutos. Na etapa seguinte do piloto, inverta a rota: quem revisava faz, quem fazia revisa. Só tem um assistente? Uma conversa faz, outra nova revisa.
git status e anote o resultado de cada critério em conferencias.txt.revisao-etapa-N.md.git add -A
git diff --staged --output=mudanca.diff
codex exec --sandbox read-only -o review.md "Leia briefing.md, mudanca.diff e conferencias.txt. Liste os achados. Para cada achado: onde, o que falha, impacto e a menor correção. Não altere arquivos."
git add -A
git commit -m "etapa 2 revisada"
No Claude, a revisão só leitura é claude -p --permission-mode plan "…" > review-claude.md.
Fontes: Área Codex + Claude — Eventos INEMA · Guia do Use Both
Aula 15 · Dev com IA v6.2 · INEMA.CLUB
Módulo 4 · Aula 1 de 5

Você consegue escrever, ao lado de cada critério do seu briefing, como ele vai ser conferido e quem confere.
No módulo 1 você escreveu os critérios. Critério sem jeito de conferir vira enfeite do briefing. Na hora da entrega, cada um precisa de uma verificação combinada antes.
Em 1 minuto
Todo critério de aceite precisa de um jeito combinado de conferir. Sem isso, cada pessoa confere de um jeito, ou ninguém confere.
Rafael pegou os três critérios do formulário da clínica e escreveu, ao lado de cada um, como ia conferir.
Um teste automático confere uma regra do mesmo jeito, quantas vezes você quiser. Ele é ótimo para "recusa letras" ou "o total bate". Ele é fraco para "o texto faz sentido" ou "a página está bonita".
Carla pôs uma célula de conferência na planilha: ela compara o total do relatório com a soma das planilhas e mostra "confere" ou "não confere". Já a lista de cidades ela lê com os próprios olhos.
Regras que se repetem: soma, formato, campo obrigatório. Roda igual toda vez.
Sentido, aparência, tom, o caminho do usuário. Precisa de alguém olhando.
Numa célula vazia da planilha do relatório, ela escreveu uma fórmula que compara o total com a soma das planilhas. Por exemplo: =SE(B2=SOMA(C2:C8);"confere";"não confere"), com B2 sendo o total do relatório e C2 a C8 os totais de cada planilha. Troque as células pelas suas. Não sabe montar? Peça à IA a fórmula, dizendo quais células comparar.
Se travou aqui, é normalNão sabe se um critério dá teste automático? Pergunte: dá para escrever a regra como conta ou formato (soma, só números, campo preenchido)? Então é automático. Depende de olhar, ler ou usar? Conferência manual.
A IA escreve o teste automático. Seu trabalho é pedir um teste por critério e ver a saída dele: o texto que ele mostra ao rodar. Não aceite só "criei os testes, todos passam".
Rafael pediu um teste só para o critério do telefone e a saída dele, antes e depois da correção.
RafaelCrie testes para o formulário.
IACriei testes para o formulário. Todos passam.
Quais testes? Conferindo qual critério? Não dá para saber.
RafaelCrie um teste para o critério 2 do briefing.md: o telefone recusa letras. Teste com o texto "abc". Rode antes de corrigir e me mostre a saída. Depois corrija e rode de novo.
IAAntes da correção: FALHOU — o campo aceitou "abc". Depois da correção: PASSOU — o campo recusou "abc".
Um critério, um teste, e a saída mostrada nas duas vezes.
Um teste mal escrito pode passar sempre, com o erro ou sem ele. Por isso vale ver o teste falhar uma vez, quando o erro ainda existe. Se ele nunca falhou, você não sabe se ele olha para a coisa certa.
Numa cópia, Carla mudou de propósito um valor da última planilha, e a célula continuou dizendo "confere". A fórmula somava C2 a C7 e deixava a última planilha de fora.
"Confere" com os valores certos e também com um valor mudado de propósito.
O que prova: nada.
Com a fórmula somando C2 a C8: "não confere" com o valor mudado; "confere" com os certos.
O que prova: que ele enxerga o erro.
Teste-se
A IA escreveu um teste para "o total bate" e ele passou de primeira. O que você pede em seguida?
Pratique agora 0/3
Pronto quando cada critério do seu briefing tiver uma linha "como confiro" e "quem confere". Cerca de 10 minutos, no computador.
Você só escreve no seu arquivo; nada roda ainda. Não tem o briefing.md da aula 5 (na pasta do piloto)? Use três critérios de qualquer tarefa sua.
## Como confiro 1. <critério 1> → <como confiro> · <automático ou manual> · quem: <nome> 2. <critério 2> → <como confiro> · <automático ou manual> · quem: <nome> 3. <critério 3> → <como confiro> · <automático ou manual> · quem: <nome> Exemplo da Carla: 1. Total igual à soma das planilhas → célula de conferência · automático · quem: Carla 2. Cada cidade uma vez → ler a lista · manual · quem: Carla 3. Origem embaixo de cada tabela → olhar cada tabela · manual · quem: colega da diretoria
Você já sabe como cada critério do seu piloto vai ser conferido.
Cola da aula
Aula 16 · Dev com IA v6.2 · INEMA.CLUB
Módulo 4 · Aula 2 de 5

Você consegue conferir uma mudança do seu piloto fazendo o caminho de quem vai usar, do começo ao fim, com dados de teste.
Um teste confere uma regra. Quem usa o sistema passa por várias regras seguidas, num celular, com pressa. Muito erro só aparece nesse caminho inteiro.
Em 1 minuto
O teste automático olha uma regra de cada vez. Ele não vê o celular pequeno, o teclado cobrindo o botão, a mensagem que cai na pasta de spam.
No formulário da clínica, o teste do telefone passou. No celular de Rafael, o teclado cobria o botão enviar, e não dava para rolar até ele.
O que Rafael viu: PASSOU — o campo recusou "abc".
O que o paciente viu: um botão enviar que não dava para alcançar.
O que Rafael fez: abriu no celular, preencheu como paciente e tentou enviar.
O que achou: o botão escondido, antes da clínica.
Pense em quem vai usar e onde. Faça o mesmo caminho, no mesmo tipo de aparelho, do primeiro clique até o resultado final.
A diretoria lê o relatório de Carla no celular, pelo e-mail. Ela passou a mandar o relatório para si mesma e abrir no celular antes de enviar.
Confira com dados inventados e deixe claro que são de teste. Assim ninguém confunde o teste com um caso de verdade, e nenhum dado de pessoa real circula.
Rafael envia como "Paciente Teste" e combina com a recepção: mensagem com esse nome pode apagar.
Carla confere numa cópia das planilhas, nunca nas originais.
Nome e telefone de um paciente de verdade no formulário de teste.
"Paciente Teste", telefone de exemplo e a recepção avisada.
Se travou aqui, é normalNão dá para testar sem mexer em coisa real, como um envio de e-mail? Mande para você mesmo primeiro. Só depois, uma vez, para o destino de verdade, avisando quem recebe.
Opcional: se o seu assistente não mexe no navegador, pule esta parte. Alguns assistentes conseguem mexer no navegador ou no computador, como o Claude Code com a extensão do Chrome. Isso só funciona se a ferramenta estiver disponível na sua conta: ter o assistente no computador não basta.
Mesmo com a ferramenta, três coisas ficam com você: senha, pagamento e o clique final de enviar. A IA prepara e para. Se ela recusar uma ação por segurança, não troque de modelo para contornar: faça você pelo caminho normal.
RafaelAbra a página de contato da clínica e preencha: nome "Paciente Teste", telefone "11 90000-0000", mensagem "teste do formulário". Pare antes de enviar.
IAPreenchi nome "Paciente Teste", telefone "11 90000-0000" e mensagem "teste do formulário". Parei antes de enviar. Confira os campos e me diga se posso clicar em enviar.
A IA preparou; o envio espera a sua confirmação.
Pratique agora 0/3
Pronto quando você tiver feito o caminho de quem usa, do começo ao fim, e anotado o que viu. Cerca de 10 minutos, no aparelho que o usuário usa.
Use dados de teste e uma cópia, nunca o original. Se o seu piloto ainda não tem nada funcionando, faça o caminho no resultado de qualquer tarefa com IA desta semana.
Você já confere o sistema do jeito que ele vai ser usado.
Cola da aula
O kit chama de "uso supervisionado do computador": delegar uma ação autorizada numa interface quando não há outro caminho. Prefira conta de teste e registro inventado. Confirme que o assistente tem mesmo a ferramenta de uso do computador. Digite senha e código de verificação você mesmo, nunca no pedido. Peça para preparar e parar antes de enviar, comprar, publicar ou apagar. Revise os campos finais e confira o resultado depois.
O kit também diz: se uma ferramenta recusar uma ação sensível, não passe para outro modelo para contornar a recusa. Use o caminho normal, feito por uma pessoa.
Fontes: Área Codex + Claude — Eventos INEMA · Guia do Use Both
Aula 17 · Dev com IA v6.2 · INEMA.CLUB
Módulo 4 · Aula 3 de 5

Você consegue pedir a menor correção para uma falha do seu piloto e registrá-la numa linha do arquivo FALHAS.md.
Quando algo quebra, a vontade é pedir "refaça direito". A IA refaz muito mais do que o necessário, e você tem de conferir tudo de novo. E sem registro, o mesmo erro volta no mês seguinte.
Em 1 minuto
A menor correção é a mudança mais curta que faz o critério voltar a passar. Quanto menor, menos coisa para conferir de novo e menos chance de quebrar outra parte.
O botão enviar sumia sob o teclado do celular. Rafael quase pediu "refaça o formulário". Pediu só para o botão ficar visível com o teclado aberto.
Pedido: "O formulário está ruim no celular, refaça."
Resultado: página nova, e os três critérios para conferir de novo.
Pedido: "Deixe o botão enviar visível com o teclado aberto. Não mude mais nada."
Resultado: uma mudança, um ponto para conferir.
O que falhou, com a evidência. O que corrigir, e só isso. O que a IA deve contar no fim: o que mudou e o que ficou igual.
A fórmula de Carla contava o prazo a partir da data errada. Ela pediu a correção só da fórmula, com a planilha de exemplo que mostrava o erro.
CarlaFalhou: o prazo de transporte conta da data do pedido. Evidência: pedido 3 da planilha anexa. Corrija só a fórmula do prazo, para contar da data de saída. Não mude colunas nem o formato. No fim, diga o que mudou e o que ficou igual.
IAMudei a fórmula do prazo para contar da data de saída. Ficaram iguais as colunas e o formato. Para conferir: calcule à mão o pedido 3 e compare.
Falha com evidência, correção delimitada, relato do que mudou.
Corrigiu? Antes de seguir, escreva uma linha num arquivo chamado FALHAS.md, na pasta do piloto. Quatro campos: data, o que quebrou, a menor correção, e se foi prompt (o seu pedido) ou infra (algo fora do pedido). Sem história longa.
Rafael cria o FALHAS.md do mesmo jeito que criou o briefing.md na aula 5. Também dá para pedir ao assistente: "crie FALHAS.md na pasta do piloto com este cabeçalho". A linha mais recente fica em cima.
Prompt, aqui, é o seu pedido: marque "prompt" quando o pedido induziu o erro, ou a IA entendeu errado. Infra é quando o problema está fora do pedido: máquina, rede, serviço fora do ar, conta, endereço. Quando for os dois, marque os dois.
Depois de dez linhas, Carla viu que seis eram "prompt" e todas falavam de coluna. Passou a colar o nome das colunas em todo pedido.
"O pedido não dizia de qual data contar o prazo."
"O endereço de envio da clínica estava errado no provedor de e-mail."
Se travou aqui, é normalNão sabe se foi prompt ou infra? Marque "?" e siga. Com o tempo, as linhas parecidas mostram a resposta.
Teste-se
A IA não conseguiu terminar porque o serviço dela ficou fora do ar. Que etiqueta vai na linha?
Pratique agora 0/3
Pronto quando a pasta do piloto tiver um FALHAS.md com o cabeçalho e uma linha preenchida. Cerca de 8 minutos, no computador.
É um arquivo de texto seu. Ainda não teve falha no piloto? Registre a última vez que uma IA errou num trabalho seu, ou use a falha do botão de Rafael. As barras e os tracinhos do molde desenham a tabela: copie como está.
| data | o que quebrou | menor correção | prompt ou infra | |---|---|---|---| | <dd/mm> | <o que quebrou, em poucas palavras> | <a mudança mínima que resolveu> | <prompt, infra ou os dois> |
Você já tem o registro que mostra, com o tempo, onde seus pedidos falham.
Cola da aula
Aula 18 · Dev com IA v6.2 · INEMA.CLUB
Módulo 4 · Aula 4 de 5

Você consegue escrever a meta de um erro difícil: o sucesso que dá para ver, os limites e a hora de a IA parar e relatar.
Tem erro que não sai em uma nem em duas tentativas. A tentação é dizer "resolve isso, custe o que custar". Aí a IA roda muito tempo, gasta muito, e ninguém sabe dizer se chegou.
Em 1 minuto
Um pedido sem meta deixa a IA decidir quando parar. Ela pode parar cedo demais ou não parar nunca. Uma meta diz como saber que chegou.
O relatório de Carla dava um total diferente só em algumas semanas. Ela escreveu a meta com uma semana que falhava e o resultado esperado.
"O total às vezes não bate. Resolve isso."
"Com as planilhas da semana 38, o total do relatório é igual à soma das planilhas. A célula de conferência mostra 'confere'."
Sucesso observável: a entrada, o resultado esperado e como conferir. Limites: quais arquivos, quantas tentativas. Ponto de relato: quando parar e contar o que tentou. E, fora do pedido, a trava de tempo ou gasto, como na aula 4.
Rafael usou o mesmo molde para um erro que só acontecia com telefone de outro estado.
Diga as duas saídas no pedido. Se o critério passar, a IA para, sem acrescentar recursos que ninguém pediu. Se bater o limite, ela para e descreve o bloqueio.
Na terceira tentativa, a IA de Carla parou e mostrou onde estava a diferença.
CarlaMeta: com as planilhas da semana 38, o total do relatório é igual à soma das planilhas. Como conferir: a célula de conferência mostra "confere". Só o arquivo juntar.py. No máximo 3 tentativas. Se passar, pare. Se não, pare e diga o que tentou, o que falhou e o que falta.
IAParei após 3 tentativas; a meta ainda não passa. Tentei três formas de somar a semana 38. Falhou: uma planilha da semana 38 tem pedidos repetidos em duas linhas. Falta: você dizer se pedido repetido conta uma vez.
Sem chegar, a IA entregou um bloqueio claro, com a pergunta que só Carla responde.
Se travou aqui, é normalNão sabe o resultado esperado? Então o erro ainda não está entendido. Primeiro peça à IA só para achar um caso que falha, sem corrigir nada.
Alguns assistentes têm um modo de meta, em que perseguem o objetivo sozinhos. Segundo o autor do vídeo que acompanha o kit Use Both, o Codex tem um modo de meta (/goal), que gasta de 3 a 5 vezes mais tempo e tokens. É relato, não medição: confira se o modo existe na sua versão e no app.
Com ou sem esse modo, as condições são as mesmas: sucesso observável, limites no pedido e uma trava de verdade. Rodar muito tempo não prova nada; o que prova é o critério passando.
Rafael não usa o modo de meta para o site. Ele manda o pedido comum, com as mesmas três partes.
Mesma meta, mesmos limites, e uma trava de tempo ou gasto de verdade.
Pedido comum com as mesmas três partes. Funciona em qualquer assistente.
Pratique agora 0/3
Pronto quando você tiver uma meta com sucesso observável, três limites e as duas saídas. Cerca de 10 minutos, num arquivo meta.md na pasta do piloto ou no bloco de notas.
Você só escreve; não precisa enviar agora. Sem erro difícil no piloto? Use o do total de Carla, trocando pela sua planilha ou página.
Meta: com <a entrada que falha>, <o resultado esperado>. Como conferir: <o teste ou a conferência>. Limites: só <arquivos>; no máximo <3> tentativas. Se passar, pare, sem acrescentar nada. Se não passar, pare e diga o que tentou, o que falhou e o que falta.
Você já transforma um erro difícil numa tarefa com começo, fim e limite.
Cola da aula
Para um problema bem definido que precisa de trabalho longo: escreva o objetivo com condição de sucesso observável (quais testes, qual entrada, qual saída esperada); limite arquivos, ferramentas, rodadas de revisão e gasto, começando pequeno; use o recurso de meta do app se houver, ou um pedido comum com as mesmas condições; ponha um controle real de uso ou de tempo se precisar de teto; peça relato num ponto definido ou num bloqueio repetido. Quando os testes de aceite passarem, pare, sem acrescentar recursos.
Pronto quer dizer: evidência de teste que cumpre a condição, ou um bloqueio relatado com o que foi tentado. Tempo longo de execução não é nota de qualidade. As comparações de velocidade, persistência e custo do vídeo são a experiência do autor, não garantia medida.
Fontes: Área Codex + Claude — Eventos INEMA · Guia do Use Both
Aula 19 · Dev com IA v6.2 · INEMA.CLUB
Módulo 4 · Aula 5 de 5

Você consegue fechar o aceite do seu piloto: para cada critério, a evidência que você viu e a decisão de entrar, entrar com pendência ou voltar.
Chegou a hora de entregar. Testes passaram, o outro assistente aprovou, você usou de verdade. Falta a decisão, escrita, com o que a sustenta. É isso que você mostra se alguém perguntar "quem conferiu?".
Em 1 minuto
Cada critério de aceite do briefing vira uma linha: o critério, a evidência e o resultado. No fim, a decisão e o seu nome.
Rafael montou o aceite do formulário da clínica num arquivo aceite.md, ao lado do briefing.md.
"A IA disse que passou" não é evidência. Evidência é a captura de tela da caixa de entrada, a saída do teste, a soma feita, o link aberto no celular. Para capturar a tela: Windows+Shift+S no Windows, Cmd+Shift+4 no Mac, e botão de ligar + volume para baixo, na maioria dos celulares. Algo que outra pessoa pode olhar e concordar.
No aceite do relatório, Carla trocou "revisado pela IA" pela célula de conferência dizendo "confere" e pela lista de cidades lida por ela.
"O Codex revisou e disse que está tudo certo."
"Célula de conferência: 'confere'. Lista de cidades lida por mim: nenhuma repetida."
Nem tudo é "perfeito" ou "refazer". Muitas vezes o certo é entrar com uma pendência pequena, escrita, com dono e prazo. O que não pode é a pendência ficar só na sua cabeça.
Todos os critérios de Carla passaram, mas o título do relatório saiu com a semana escrita errada. Ela aceitou com pendência: corrigir o título até sexta.
Se travou aqui, é normalNa dúvida entre "entra com pendência" e "volta"? Pergunte: se o cliente vir essa falha amanhã, ele consegue usar mesmo assim? Se sim, pendência. Se não, volta.
A revisão cruzada e os testes ajudam a decidir. A decisão continua humana. Nem a aprovação de dois modelos assina no seu lugar.
Rafael manda à clínica o link e uma frase: "conferido por mim, critério por critério; o aceite está no projeto".
Testes, caminho de quem usa, revisão cruzada.
Você, com nome e data no aceite.
Teste-se
Um critério não tem evidência, mas as duas IAs dizem que ele passa. Qual decisão cabe?
Pratique agora 0/4
Pronto quando a pasta do piloto tiver um aceite.md com a evidência de cada critério e a sua decisão assinada. Cerca de 12 minutos, no computador.
É um arquivo seu; nada é enviado. O piloto ainda não está pronto? Faça o aceite do que existe: a decisão honesta pode ser "volta", e isso também é um resultado.
# Aceite: <nome do piloto> | critério | evidência (o que eu vi) | resultado | |---|---|---| | <critério 1> | <captura, saída do teste, soma, link> | <ok, falhou ou não conferido> | | <critério 2> | <...> | <...> | | <critério 3> | <...> | <...> | Decisão: <entra, entra com pendência, ou volta> Pendência (se houver): <o quê, quem, até quando> Assinado: <seu nome> · <data>
Você fechou o módulo 4 com o aceite do seu piloto, assinado e com evidência.
Cola da aula
Aula 20 · Dev com IA v6.2 · INEMA.CLUB
Módulo 5 · Aula 1 de 5

Você consegue escrever, num arquivo, onde o trabalho parou, as decisões, as pendências e a próxima ação exata.
Uma conversa nova com a IA começa sem lembrar de nada. Sem registro, você explica tudo de novo, e a IA às vezes desfaz uma decisão que já estava tomada. Um arquivo curto resolve isso.
Em 1 minuto
Cada conversa com o modelo tem um tamanho máximo. Quando ela acaba, ou quando você abre outra, o que foi combinado fica para trás.
O handoff leva esse combinado para a próxima conversa. É como a passagem de plantão num hospital: quem chega lê antes de mexer no paciente.
Rafael parou o formulário da clínica numa sexta. Na segunda, abriu uma conversa nova e disse só "continue o formulário".
RafaelContinue o formulário de contato.
IAPosso criar o formulário com nome, e-mail, telefone e mensagem. Você quer que o envio vá para qual e-mail?
A IA começou do zero e perguntou o que já estava decidido.
RafaelLeia handoffs/latest.md e me diga onde paramos, antes de mexer em qualquer arquivo.
IAParamos no envio para a recepção. Decidido: o campo telefone recusa letras. Pendente: a mensagem de teste não chegou. Próxima ação: enviar um teste e conferir a caixa da recepção.
A IA começou pelo que o arquivo diz. Confira a resposta contra o arquivo, linha por linha.
Um bom handoff cabe numa tela. Ele diz onde o trabalho parou, o que foi decidido, o que ficou pendente e qual é a próxima ação.
Carla escreve o dela toda sexta, ao fechar o relatório da semana. Leva cinco minutos.
A parte que mais falha é a última. "Continuar o formulário" não diz nada. A próxima ação boa diz o que fazer, onde e como saber se deu certo.
Rafael trocou a frase vaga por uma que qualquer assistente consegue seguir, até outro modelo.
"Próxima ação: continuar o formulário."
"Próxima ação: enviar uma mensagem de teste pela página de contato e conferir a caixa da recepção. Se não chegar, olhar o envio em contato.html."
Saldo: a conversa nova começa pelo passo certo, sem perguntar nada.
Se travou aqui, é normalNão sabe qual é a próxima ação? Escreva a pergunta que falta responder, como "descobrir por que a mensagem não chega". Uma pergunta clara também serve.
No fim da sessão, peça ao assistente que escreva o handoff. Ele tem os detalhes da conversa à mão, mas erra. Depois, leia e corrija: é você quem responde pelo que está ali.
Um cuidado: o handoff registra o que houve. Ele não autoriza a próxima conversa a enviar, publicar ou apagar nada sozinha.
Carla pede o handoff antes de fechar. Na primeira vez, a IA escreveu "total conferido". Carla não tinha conferido, e corrigiu para "pendente".
CarlaAntes de encerrar, escreva o handoff em handoffs/latest.md com: onde parou, decisões, pendências e a próxima ação exata. Marque como pendente tudo o que eu não conferi.
IAHandoff gravado. Pendências: total de pedidos não conferido contra a soma das planilhas. Próxima ação: somar a coluna de pedidos das planilhas e comparar com o total do relatório.
"Marque como pendente o que eu não conferi" evita que o handoff diga mais do que aconteceu.
Pratique agora 0/3
Pronto quando o arquivo latest.md, dentro da pasta handoffs do piloto, tiver as quatro partes. Cerca de 10 minutos, no computador: este módulo pede o computador.
É só um arquivo de texto seu. Não fez o piloto dos módulos anteriores? Use qualquer trabalho que você vai retomar amanhã. Arquivo novo no Windows: botão direito na pasta › Novo › Documento de texto, e renomeie (a aula 5 mostra o passo a passo). Ative antes Exibir › Mostrar › Extensões de nomes de arquivos; senão o arquivo vira latest.md.txt. Também pode pedir ao assistente: "crie handoffs/latest.md com este molde".
# Handoff — <data> ## Onde parou <o que foi feito e em que pasta ou arquivo está> ## Decisões - <o que não se discute de novo> ## Pendências - <o que ainda não foi conferido> ## Próxima ação <um passo exato: o quê, onde e como saber se deu certo>
Você já deixa o trabalho pronto para ser retomado por qualquer conversa.
Cola da aula
Aula 21 · Dev com IA v6.2 · INEMA.CLUB
Módulo 5 · Aula 2 de 5

Você consegue pedir a uma conversa nova um resumo do projeto com as fontes e as contradições, antes de ela mexer em qualquer arquivo.
O handoff só ajuda se alguém ler. E ler não basta: a conversa nova precisa mostrar o que entendeu, para você conferir antes de ela agir. Neste curso, esse primeiro pedido se chama prime. Não é um comando da ferramenta: é um texto que você cola.
Em 1 minuto
O prime é o par do handoff. Um escreve no fim da sessão; o outro lê no começo da próxima.
Em vez de "continue", você pede: leia estes arquivos, não altere nada e me diga onde estamos.
Carla abre a conversa da segunda-feira sempre com o mesmo pedido, salvo num arquivo de texto. Copia, cola e espera o resumo.
CarlaLeia briefing.md e handoffs/latest.md. Não altere nenhum arquivo. Me diga: o objetivo, uma regra, a última decisão, a próxima ação e qualquer contradição, citando o arquivo de cada informação.
IAObjetivo: relatório semanal de pedidos por cidade (briefing.md). Regra: não alterar as planilhas originais (briefing.md). Última decisão: cidades em ordem alfabética (latest.md). Próxima ação: somar a coluna de pedidos e comparar com o total (latest.md). Contradições: nenhuma encontrada.
Cada informação vem com o arquivo de onde saiu. Assim dá para conferir.
Um bom prime responde sempre as mesmas cinco perguntas. O objetivo vem do briefing; a decisão e a próxima ação vêm do handoff. Se uma delas vier errada, o problema está no arquivo, não na próxima tarefa.
Rafael confere o resumo em um minuto: compara cada linha com o handoff que ele mesmo escreveu na sexta.
O handoff é um registro do passado, não um pedido novo. Se ele diz "falta enviar o relatório", a conversa nova não envia por conta própria. Ela resume e espera você.
Uma vez, o assistente de Rafael leu "próxima ação: publicar a página" e já começou a publicar. Desde então, o prime dele diz "não altere nada e espere a minha ordem".
"Vi no handoff que falta publicar. Publicando a página agora."
"O handoff indica publicar a página como próxima ação. Aguardo a sua confirmação."
Se travou aqui, é normalParece desconfiança demais com a IA? É o mesmo cuidado de quem chega no plantão: primeiro lê e confere, depois mexe.
Quando dois arquivos dizem coisas diferentes, o prime aponta. É melhor descobrir isso no resumo do que no meio do trabalho.
Numa outra semana, o briefing de Carla pedia cidades em ordem alfabética. O handoff daquela semana registrava "ordenar por total de pedidos". O prime mostrou o conflito, e ela decidiu em dez segundos.
IAContradição: briefing.md pede cidades em ordem alfabética; handoffs/latest.md registra "ordenar por total de pedidos". Qual vale?
CarlaVale a ordem alfabética. Corrija o handoff.
A dúvida apareceu antes do trabalho, não depois do relatório pronto.
Teste-se
O prime respondeu com uma próxima ação que não está em nenhum arquivo. O que isso indica?
Pratique agora 0/3
Pronto quando uma conversa nova tiver devolvido o resumo com as fontes e você tiver conferido cada linha. Cerca de 10 minutos, no computador: este módulo pede o computador.
O pedido proíbe alterar arquivos: é só leitura. Sem o handoff da aula 21? Apague do pedido a linha do handoff e faça só com o briefing.md da aula 5, que fica na pasta do piloto. Se o seu arquivo é briefing.txt, troque o nome no pedido. Se a IA começar a mudar algo, clique no botão de parar (ou a tecla Esc).
Leia briefing.md e handoffs/latest.md, nesta ordem. Não altere nenhum arquivo e não execute nada. Me diga, citando o arquivo de cada informação: 1. O objetivo e os critérios de aceite. 2. Uma regra, com o arquivo de origem. 3. A última decisão. 4. A próxima ação exata. 5. Qualquer contradição entre os arquivos. Depois, espere a minha ordem.
Você já começa uma sessão sabendo o que a IA entendeu, antes de ela mexer em algo.
Cola da aula
Aula 22 · Dev com IA v6.2 · INEMA.CLUB
Módulo 5 · Aula 3 de 5

Você consegue montar, na pasta do piloto, os arquivos mínimos e a ordem de leitura que qualquer assistente segue.
Instruções, decisões e tarefas guardadas só na memória de uma ferramenta ficam presas a ela. Na troca de assistente, você perde tudo. Guardadas em arquivos de texto no projeto, qualquer assistente lê.
Em 1 minuto
Cada assistente guarda coisas do seu jeito: memória própria, histórico de conversas, arquivo de instruções. Isso funciona enquanto você usa só aquele assistente.
Quando o conhecimento vive em arquivos de texto dentro da pasta do projeto, o assistente vira só quem executa. Trocar de assistente, ou de modelo, deixa de custar o seu trabalho.
Rafael tinha as regras do site da clínica só no CLAUDE.md e na memória do Claude Code, que o Codex não procura. Quando testou o Codex, teve de explicar tudo de novo, e esqueceu duas regras.
Regras na memória de um assistente. Decisões espalhadas em conversas antigas.
Na troca: explicar tudo de novo.
Regras, tarefa e handoff em arquivos de texto na pasta do piloto.
Na troca: o outro assistente lê os arquivos.
Você não precisa de muita coisa. Cinco arquivos cobrem o piloto: regras, objetivo, tarefa, contexto e passagem de plantão.
Carla montou a pasta do relatório assim em quinze minutos. Dois deles ela já tinha: o briefing e o handoff.
Os nomes das pastas são só um combinado. Nenhum assistente abre "tasks" sozinho. Quem pede a leitura é o AGENTS.md, com a ordem de leitura logo no topo. O assistente costuma seguir; o prime da aula 22 confere se seguiu.
O Codex lê o AGENTS.md sozinho ao começar. O Claude Code lê o CLAUDE.md. Para ele seguir as mesmas regras, ponha no CLAUDE.md a linha @AGENTS.md.
Rafael escreveu as regras uma vez só, no AGENTS.md. O CLAUDE.md dele tem uma linha, e os dois assistentes seguem as mesmas regras.
Se travou aqui, é normalSeu assistente não é nenhum dos dois? Tudo bem. No primeiro pedido, escreva "leia o AGENTS.md antes de tudo". Num chat comum, que não abre a pasta, cole o AGENTS.md e depois cada arquivo da ordem de leitura, um abaixo do outro, com o nome do arquivo em cima.
Arquivo sem dono vira bagunça: a IA muda uma regra que era sua, ou você esquece de atualizar a tarefa. Combine quem mexe em quê.
Carla deixou claro no AGENTS.md: regras e decisões, só ela muda; o handoff, a IA escreve e ela confere.
AGENTS.md, briefing.md e as decisões. A IA pode sugerir mudança; quem aprova é você.
handoffs/latest.md no fim da sessão, e o andamento em tasks/current.md.
Pratique agora 0/3
Pronto quando a pasta do piloto tiver AGENTS.md com a ordem de leitura, tasks/current.md e handoffs/latest.md. Cerca de 12 minutos, no computador: este módulo pede o computador. Comece pelos três; o context/overview.md entra quando houver fatos conferidos a registrar.
São arquivos de texto seus; nada é apagado. Pasta nova no Windows: botão direito › Novo › Pasta. Arquivo novo: como o briefing.md da aula 5. Não tem o handoff da aula 21? Crie o arquivo com a frase "primeira sessão".
# AGENTS.md — <nome do piloto> Ordem de leitura: 1) briefing.md 2) tasks/current.md 3) handoffs/latest.md Leia antes de agir. Nada é enviado ou publicado sem a minha aprovação. ## Regras - <o que vale para todas as tarefas> ## Donos - AGENTS.md, briefing.md e decisões: só eu mudo. - handoffs/latest.md: a IA escreve no fim da sessão, eu confiro.
Você já tem o conhecimento do piloto num lugar que qualquer assistente lê.
Cola da aula
O kit agente-claude-codex usa sete lugares, cada um com dono: AGENTS.md (regras e ordem de leitura), context/overview.md (fatos verificados, com fonte e data), context/current-state.md (o que funciona e o que está pendente), context/sources.md (de onde vem cada informação), context/decisions/ (uma decisão aceita por arquivo), tasks/current.md (objetivo, dono, critério de pronto, próxima ação) e handoffs/latest.md (a continuação para a próxima sessão).
Misturar fato com hipótese, ou decisão com preferência, é o que faz o assistente repetir erro antigo e contradizer o que já foi resolvido. Uma informação só passa de memória solta para contexto aprovado com a sua aprovação.
Levar instruções, skills e memória de um assistente para outro é o tema do curso Claude → Codex: auditar, adaptar, provar em sessão nova e fazer handoff.
Fontes: Área Claude → Codex — Eventos INEMA · Curso Claude → Codex · Guia do kit agente-claude-codex
Aula 23 · Dev com IA v6.2 · INEMA.CLUB
Módulo 5 · Aula 4 de 5

Você consegue passar o seu piloto de um assistente para outro com handoff e prime, e conferir que o novo entendeu antes de ele trabalhar.
Você vai trocar de assistente. O limite de uso chega, outro faz melhor uma parte, ou você quer um olhar de fora. Sem método, a troca custa uma hora de explicação. Com os arquivos da aula 23, custa dez minutos.
Em 1 minuto
Ninguém usa um modelo só para sempre. O uso da conta acaba no meio da semana, o preço muda, ou outro assistente faz melhor uma parte do trabalho.
A troca boa não depende de memória. Ela passa pelos arquivos: o handoff de quem sai e o prime de quem entra.
Na quarta, apareceu o aviso de que o limite de uso do Claude de Rafael estava perto. Ele pediu o handoff na hora e seguiu no Codex. Se o limite já tivesse acabado, ele escreveria as quatro linhas do handoff à mão.
Contar o projeto de memória ao novo assistente. Uma hora, e duas regras esquecidas.
O novo lê os arquivos, resume com as fontes, e Rafael confere. Dez minutos.
A ordem importa. Primeiro o registro, depois a leitura, depois a conferência. Só então o trabalho.
Carla tem o Codex e um chat de IA. Ela faz a troca ao contrário: o Codex monta o relatório e, para a revisão, ela passa ao chat numa conversa nova, colando os arquivos.
Quem usa o terminal pode fazer o prime do Codex com uma trava extra: o modo de sandbox só leitura. Mesmo que ele quisesse, não conseguiria alterar arquivos.
Rafael roda o prime na pasta do site. A resposta fica gravada em prime.md, e ele lê com calma antes de liberar o trabalho.
$ codex exec --sandbox read-only -o prime.md "Leia AGENTS.md e siga a ordem de leitura. Não altere nada. Responda as cinco perguntas do prime, com o arquivo de cada resposta."
...
$ cat prime.md
O -o grava a última resposta num arquivo. O cat mostra esse arquivo na tela. Se a pasta não usa Git, acrescente --skip-git-repo-check: sem isso, o codex exec se recusa a rodar.
O equivalente é claude -p --permission-mode plan "<o mesmo pedido>" > prime.md. O -p responde uma vez e sai. O modo plan é o modo de planejamento: ele lê, mas não altera arquivos.
O assistente que entrou responde as cinco perguntas do prime, as mesmas da aula 22. Se uma resposta vier errada, olhe primeiro os arquivos. A falha quase sempre está num texto vago, como o briefing ou o handoff, e não no modelo.
O Codex de Rafael errou a próxima ação: disse "criar o formulário". O handoff dizia só "continuar". Rafael reescreveu a próxima ação e rodou o prime de novo.
Se travou aqui, é normalCinco perguntas parecem muito para cada troca? Comece pela 4. Se a próxima ação vier certa, as outras costumam vir também.
Pratique agora 0/3
Pronto quando o assistente que entrou tiver respondido as cinco perguntas e você tiver marcado cada uma como certa ou errada. Cerca de 10 minutos, no computador: este módulo pede o computador.
Tudo aqui é leitura. Só tem um assistente? Faça a troca para uma conversa nova dele: o método é o mesmo. Sem o AGENTS.md da aula 23? Troque a primeira linha por "leia briefing.md e handoffs/latest.md".
Leia AGENTS.md e siga a ordem de leitura dele. Não altere nenhum arquivo e não execute nada. Responda, citando o arquivo de cada resposta: 1. Qual é o objetivo e o critério de aceite? 2. Cite uma regra e o arquivo de onde ela vem. 3. Qual foi a última decisão? 4. Qual é a próxima ação exata? 5. Há conflito entre os arquivos? Depois, espere a minha ordem.
Você já troca de assistente sem perder o que o piloto sabe.
Cola da aula
Aula 24 · Dev com IA v6.2 · INEMA.CLUB
Módulo 5 · Aula 5 de 5

Você consegue fechar no seu piloto o ciclo completo: handoff numa sessão, prime numa sessão nova, conferência e uma segunda opinião.
Nas quatro aulas anteriores você viu as peças: handoff, prime, arquivos no projeto e troca de assistente. Agora elas viram rotina. E o mesmo ciclo dá, de brinde, uma segunda opinião sem precisar de outro assistente.
Em 1 minuto
/advisor, que cobra à parte. Confira antes de usar.Uma conversa nova não carrega o apego da anterior. Com o prime, ela lê o briefing, o handoff e o trabalho real. Aí você pede a crítica: falhas, com o trecho que mostra cada uma.
É a revisão cruzada do módulo 1, feita com o que você já tem. Outro modelo olha com ainda menos apego, quando você tiver acesso.
Carla tem o Codex e um chat de IA. Desta vez, revisou sem sair do Codex: abriu uma conversa nova dele, fez o prime e pediu a crítica.
CarlaAgora leia relatorios/semana.md e aponte falhas contra os critérios de aceite do briefing.md, com o trecho que mostra cada uma. Não altere nada.
IAFalha 1: o critério 2 do briefing.md diz "Cada cidade aparece uma vez, com o seu total". Na tabela de totais de relatorios/semana.md, a cidade Pelotas aparece em duas linhas.
O critério vem do briefing de Carla, desde a aula 3. Ela abriu o relatório e conferiu: eram mesmo duas linhas.
No Claude Code existe o comando /advisor, seguido do nome de um modelo. Ele liga um modelo mais forte, que o modelo principal consulta durante a sessão. O mesmo comando troca ou desliga o conselheiro.
Dois cuidados. O próprio Claude Code avisa que o conselheiro cobra créditos de uso à parte. E o Codex não tem esse comando. A conversa nova com prime funciona em qualquer assistente, sem custo extra.
Rafael digitou /advisor no Claude Code e leu o aviso de cobrança. Para o piloto, ficou com a conversa nova; o conselheiro fica para um erro difícil.
Conversa nova, prime com os arquivos, pedido de falhas com evidência.
O /advisor: um modelo mais forte consultado durante a sessão, cobrado à parte. Confira o custo antes.
Juntando tudo, o dia de trabalho com IA tem quatro tempos. Ele é o mesmo em qualquer assistente, porque só depende de arquivos de texto.
Rafael fecha toda sessão com o handoff e abre toda sessão com o prime. Diz que perdeu o medo de fechar a conversa.
Se travou aqui, é normalParece ritual demais para uma tarefa de meia hora? Para tarefas curtas, basta o handoff de uma linha: a próxima ação exata.
O laboratório do módulo junta as cinco aulas numa passada só. O resultado é o piloto pronto para ser retomado por qualquer assistente, a qualquer dia.
Carla fez o laboratório numa sexta e retomou na segunda. O prime acertou as cinco perguntas na primeira tentativa.
Cada segunda começa com "onde eu estava mesmo?", e a IA repete perguntas.
Cada segunda começa com um resumo conferido e a próxima ação exata.
Saldo: dez minutos de handoff e prime no lugar de meia hora de reconstrução.
Pratique agora 0/4
Pronto quando uma conversa nova tiver acertado as cinco perguntas e conferido cada critério de aceite com o trecho, marcando falha ou "ok". Nenhuma falha também é resultado. Cerca de 12 minutos, no computador: este módulo pede o computador.
Tudo é leitura, menos o handoff, que é um arquivo seu. Não fez as aulas anteriores? Use o briefing.md da aula 5 e um handoff de uma linha. Se a IA começar a alterar algo, clique no botão de parar.
Leia AGENTS.md e siga a ordem de leitura dele. Não altere nenhum arquivo e não execute nada. Responda, citando o arquivo de cada resposta: 1. Qual é o objetivo e o critério de aceite? 2. Cite uma regra e o arquivo de onde ela vem. 3. Qual foi a última decisão? 4. Qual é a próxima ação exata? 5. Há conflito entre os arquivos? Depois, para cada critério de aceite do briefing.md, diga "ok" ou "falha", com o trecho do trabalho que mostra isso.
Você fechou o módulo 5 com um piloto que qualquer assistente retoma e revisa.
Cola da aula
O kit Use Both chama isso de "handoff e prime": o handoff grava o estado num arquivo portátil; o prime faz o próximo assistente ler e verificar esse estado antes de continuar. No kit agente-claude-codex, cada handoff vira um retrato com data em handoffs/history/, que nunca é sobrescrito, e handoffs/latest.md é a cópia do mais recente.
O comando /advisor, seguido do nome de um modelo, define um modelo conselheiro que o principal consulta durante a sessão. O conselheiro precisa ser pelo menos tão capaz quanto o modelo principal, e o uso dele é cobrado em créditos à parte. A síntese do INEMA trata o uso para investigar gargalos como orientação a conferir: teste numa tarefa sua e compare com a conversa nova com prime.
Fontes: Área Codex + Claude — Eventos INEMA · Área Claude → Codex — Eventos INEMA · Guia do Use Both
Aula 25 · Dev com IA v6.2 · INEMA.CLUB
Módulo 6 · Aula 1 de 5

Você consegue comparar dois modelos numa tarefa sua, com os seus critérios de aceite, e dizer qual entregou melhor ali.
Toda semana aparece uma lista de "melhor IA do momento". Ela responde a uma pergunta geral. A sua pergunta é outra: qual entrega melhor esta tarefa, na sua conta, hoje.
Em 1 minuto
Um modelo que vai bem na média pode ir mal na sua tarefa. E os nomes mudam rápido. Em setembro de 2026, os mais citados nas fontes deste curso eram o Claude Opus 5.5 e o GPT-6 Astra.
Daqui a alguns meses, serão outros. A forma de escolher continua a mesma.
Rafael leu que um modelo "era o melhor para código". No formulário da clínica, esse modelo entregou o campo de telefone aceitando letras.
RafaelQual é o melhor modelo para programar?
IADepende do uso. Vários modelos se destacam em programação, cada um com pontos fortes diferentes.
Uma pergunta geral recebe uma resposta geral.
RafaelMesmo briefing para os dois modelos. Qual passou nos três critérios de aceite do formulário?
Ficha do RafaelModelo A: 3 de 3. Modelo B: 2 de 3, faltou recusar letras no telefone.
A resposta vem da sua conferência, não da opinião de alguém.
Comparação justa muda uma coisa só: o modelo. O pedido, o material e os critérios ficam iguais. Se você muda duas coisas, não sabe qual fez a diferença.
A régua é o que você já tem: o critério de aceite do seu briefing. Não fez o briefing da aula 5? Escreva agora três critérios de sim ou não para a tarefa.
Carla fez as duas rodadas no Codex, com a mesma pasta de planilhas e o mesmo briefing. Entre uma e outra, trocou só o modelo, no seletor perto do nome dele.
Se travou aqui, é normalNão sabe onde troca o modelo? No Claude Code, o comando /model lista os modelos da sua conta; no app, procure o seletor perto do nome do modelo. Só tem acesso a um? Compare o mesmo modelo em duas conversas novas, com o mesmo pedido: você já aprende a usar a régua.
Uma resposta caprichada, com títulos e frases seguras, parece melhor. A régua pergunta outra coisa: passou ou não passou em cada critério?
O relatório do primeiro modelo vinha com gráfico e texto bonito, mas repetia uma cidade. O do segundo era seco e passou nos três critérios.
Aparência: gráfico, títulos, resumo elegante.
Régua: 2 de 3. Uma cidade aparece duas vezes.
Aparência: uma tabela simples.
Régua: 3 de 3. Total bate, cidades únicas, origem embaixo.
Saldo: a escolha sai da ficha, não da primeira impressão.
O resultado da comparação vale para aquele tipo de tarefa, naquele mês. Anote tarefa, modelo, critérios que passaram e a data. Quando mudar o modelo, o preço ou a tarefa, compare de novo.
Rafael guarda uma linha por comparação num arquivo escolhas.md, na pasta do piloto. Em três meses, ele já sabe qual modelo usa para cada tipo de pedido.
28/09/2026 · formulário de contato · modelo A 3 de 3, modelo B 2 de 3 · fica o A.
Modelo novo, preço novo ou tarefa de outro tipo.
Teste-se
Carla quer saber qual modelo usar no relatório semanal. O que ela faz primeiro?
Pratique agora 0/3
Pronto quando você tiver respondido as três perguntas do caso. Cerca de 10 minutos, no papel ou no bloco de notas.
É só leitura de um caso. Se ficar em dúvida, volte à régua: conta o que passou, não o que parece melhor.
O caso. Rafael deu o mesmo briefing a dois modelos para a página de preços de um cliente. Critérios: os três planos aparecem; o botão leva ao pagamento; no celular, a página não rola para os lados. O modelo A entregou uma página bonita: os três planos aparecem e ela não rola para os lados, mas o botão não abria nada. O modelo B entregou uma página simples que passou nos três. Ele usou um pedido um pouco diferente para o B.
Você já compara modelos pela régua da sua tarefa, não pela fama.
Cola da aula
A área Codex + Claude do Eventos INEMA registra que o vídeo de Mark Kashef cita Claude Opus 5.5 e GPT-6 Astra. A síntese do INEMA de 27 de setembro de 2026 cita os mesmos nomes, mas ressalta que modelos, acesso e cobrança variam. A recomendação é comparar a qualidade da entrega na tarefa concreta, em vez de fixar uma regra universal de qual é melhor.
O cartão de rotas do kit Use Both (Claude/Opus planeja, Codex critica; Claude constrói, Codex revisa o que mudou) é uma preferência inicial registrada no vídeo de Mark Kashef. A área Codex + Claude do Eventos INEMA avisa: são escolhas editoriais, não ranking medido. Experimente e fique com a rota que produzir melhor evidência na sua tarefa.
Fontes: Área Codex + Claude — Eventos INEMA · Guia do Use Both
Aula 26 · Dev com IA v6.2 · INEMA.CLUB
Módulo 6 · Aula 2 de 5

Você consegue marcar o esforço alto, médio ou baixo para cada passo do ciclo do seu piloto, e dizer por quê.
Muita gente deixa o esforço no máximo para tudo, por segurança, ou no mínimo, para economizar. As duas escolhas custam: uma em tempo e uso da conta, a outra em erros nas partes difíceis.
Em 1 minuto
O modelo é qual IA trabalha. O esforço de raciocínio é quanto ela analisa antes de responder. Você pode mudar um sem mudar o outro.
Rafael usa o mesmo modelo o dia todo. O que ele muda é o esforço: alto no plano da área de acesso, baixo para trocar textos de botões.
Qual IA faz o trabalho. Troca quando a comparação da aula 26 mostra que outra entrega melhor.
Quanto ela analisa. Sobe e desce a cada etapa, no mesmo modelo.
Suba o esforço quando um erro custa caro ou quando há muitas partes para considerar juntas. Planejar, caçar um erro que ninguém acha e revisar uma mudança grande entram aqui.
O quadro percorre o ciclo inteiro, do briefing ao handoff.
Carla pediu esforço alto só na hora de planejar como juntar planilhas com colunas diferentes. O resto do trabalho foi em médio.
Tarefa de rotina, como renomear, formatar ou trocar um texto, costuma sair igual com menos esforço, mais rápido e gastando menos. Confira pelos critérios. Mas "o mínimo para tudo" não é regra segura: a parte difícil sai pior.
E há um limite: se faltou a planilha ou o critério, nenhum esforço resolve. Primeiro o material, depois o esforço.
Carla subiu o esforço para o máximo quando o relatório saiu errado. Continuou errado: faltava a planilha de quinta-feira na pasta.
Pedido: "Pense com calma e refaça o relatório."
Resultado: demorou o triplo e o total continuou errado.
Pedido: o mesmo, com a planilha de quinta na pasta.
Resultado: total igual à soma das planilhas.
Saldo: o que faltava era material, não raciocínio.
Se travou aqui, é normalNão sabe se a tarefa é difícil? Comece em médio. Suba só se a resposta falhar num critério por falta de análise, e não por falta de material.
Cada ferramenta mostra esse controle de um jeito, e nem todas mostram. No app ou na extensão, quando existe, fica perto do nome do modelo. No chat, pode aparecer como "raciocínio", "pensar mais" ou "pensamento estendido", às vezes só liga ou desliga. No terminal, vai no próprio comando.
Rafael pede a crítica do plano em esforço alto e a lista dos textos de botão em baixo, cada uma no seu comando.
$ codex exec -c model_reasoning_effort=high "Leia plan-v1.md e aponte falhas com evidência."
$ claude -p --effort low "Liste os textos de botão que aparecem em contato.html."
No Codex, o esforço é o model_reasoning_effort (de minimal a high; alguns modelos aceitam mais), escrito no config.toml do Codex ou no comando com -c. No Claude Code, é o --effort (low, medium, high, xhigh ou max).
Teste-se
A IA errou o total do relatório. Antes de subir o esforço, o que você confere?
Pratique agora 0/3
Pronto quando cada um dos cinco passos do seu piloto tiver um nível e uma frase de motivo. Cerca de 8 minutos, no papel ou no bloco de notas.
Você só anota; nada roda. Não tem piloto? Use o formulário do Rafael ou o relatório da Carla como exemplo.
Passo | Esforço | Por quê 1. Definir o briefing | <baixo/médio/alto> | <motivo> 2. Planejar e criticar | < > | < > 3. Construir | < > | < > 4. Revisar e comprovar | < > | < > 5. Registrar o handoff | < > | < >
Você já distribui o esforço pelas etapas, em vez de um botão fixo para tudo.
Cola da aula
A síntese do INEMA de 27 de setembro de 2026: planejamento e problemas difíceis podem justificar esforço médio ou alto; tarefas rotineiras podem usar menos; uma revisão complexa também pode precisar de mais. O nível mínimo para todo o restante não é uma regra segura.
A mensagem que deu origem ao curso resume o motivo: ajustar o modelo e o esforço a cada etapa evita gastar recursos de uma tarefa complexa em ações simples.
Fontes: síntese executiva e mensagem de 27/09/2026, nos arquivos de origem do curso, pasta docs/.
Aula 27 · Dev com IA v6.2 · INEMA.CLUB
Módulo 6 · Aula 3 de 5

Você consegue preencher, para cada etapa do seu piloto, o tempo, o uso da conta e os problemas que foram achados.
"Ficou caro" e "valeu a pena" costumam ser impressão. Sem uma medida simples, a decisão da aula 30 vira opinião. Medir é anotar três números por etapa, na hora.
Em 1 minuto
A medida cabe numa planilha de oito colunas. Uma linha por etapa do ciclo, preenchida logo que a etapa termina. Depois de uma semana, ninguém lembra quanto tempo levou.
Rafael abriu a planilha piloto-custos na pasta do piloto e preencheu a linha do plano assim que a crítica terminou.
A IA responde em dois minutos, mas você gastou vinte lendo e conferindo. O tempo que conta é o seu, do pedido até a conferência. É ele que a sua hora de trabalho paga.
Carla anotava só a espera pela resposta: três minutos. Quando incluiu a conferência do total, a etapa passou a vinte e cinco.
Anotado: 3 minutos.
Conclusão: "a IA faz o relatório em três minutos".
Anotado: 25 minutos, com 15 de conferência.
Conclusão: ainda menos que as duas horas à mão.
Saldo: a comparação honesta é com o jeito antigo, conferência incluída. Por isso a planilha tem a coluna "Jeito antigo".
O uso de IA é medido em tokens. Você não precisa contá-los: basta abrir a página de uso da conta antes e depois da etapa e anotar a diferença, na unidade que ela mostra.
A página de uso fica nas configurações da conta, no site do serviço (em inglês, "Usage"). A aula 4 mostrou onde procurar. Conta da empresa? Peça a página de uso a quem administra.
Rafael anotou o percentual do limite semanal da assinatura antes e depois da crítica do plano. A crítica em esforço alto usou bem mais que a troca de textos.
AntesUso da semana: 18%
DepoisUso da semana: 23%
Na planilhaCrítica do plano · esforço alto · 5 pontos do limite semanal · 2 falhas achadas
O número exato importa menos que comparar etapas entre si.
Se travou aqui, é normalA sua página de uso não mostra número por tarefa? Anote o que ela mostra, antes e depois. Se nem isso aparecer, fique só com o tempo: já dá para comparar. Conta usada por outras pessoas ao mesmo tempo distorce o antes e depois: anote "conta compartilhada" ao lado.
Custo sozinho não diz se valeu. O outro lado da conta são os problemas achados antes da entrega, e por quem: pela revisão cruzada, pelo teste ou por você.
Na semana do piloto, a revisão do outro modelo achou a cidade repetida, e o teste à mão achou o total errado. Os dois teriam ido para a diretoria.
Tempo seu e uso da conta em cada etapa.
Problemas achados antes da entrega, critérios que passaram.
Teste-se
A etapa de revisão foi a que mais gastou da conta. O que você olha antes de cortá-la?
Pratique agora 0/3
Pronto quando a planilha tiver as colunas e pelo menos duas linhas preenchidas. Cerca de 10 minutos, no computador.
É uma planilha sua; nada é enviado. Não lembra o tempo de uma etapa antiga? Escreva uma estimativa e marque "estimado": a partir de agora, anote na hora.
Colunas (uma por célula, na primeira linha): Etapa | Modelo e esforço | Tempo seu (min) | Jeito antigo (min) | Uso antes | Uso depois | Problemas achados (por quem) | Critérios que passaram Exemplo da Carla: Relatório semanal | Codex, médio | 25 | 120 | 40% | 42% | cidade repetida (revisão), total errado (teste) | 3 de 3
Você já tem custo e resultado lado a lado, etapa por etapa.
Cola da aula
Aula 28 · Dev com IA v6.2 · INEMA.CLUB
Módulo 6 · Aula 4 de 5

Você consegue dizer, olhando a sua conta, se paga assinatura ou por uso e qual é o limite. E anota onde conferiu, com a data.
Preços, limites e ferramentas incluídas mudam de um mês para outro e de uma conta para outra. O que você leu num vídeo pode não valer para a sua. A única fonte segura é a sua conta, no dia.
Em 1 minuto
Na assinatura, você paga um valor fixo e tem um limite de uso por período. Quando o limite acaba, espera o período virar ou, se o plano oferecer, compra uso extra. No pagamento por uso, cada token consumido entra na conta, e o teto de gasto, quando existe, é você que define.
O pagamento por uso costuma vir por uma API, com uma chave secreta.
Rafael usa o Claude Code pela assinatura. Um cliente pediu uma automação que chama a IA sozinha toda noite: essa vai por uso, com chave e teto de gasto na conta do cliente. Assim o gasto fica com quem usa, e a assinatura pessoal dele não entra no trabalho do cliente.
Paga: valor fixo por mês.
Limite: uso por período; acabou, espera ou compra extra, se o plano oferecer.
Paga: pelo que consome.
Limite: o teto de gasto, se você definir.
Anote numa ficha o que a sua conta mostra hoje: tipo, limite, onde viu e a data. Quando algo mudar, você percebe comparando com a ficha. A senha e a chave nunca entram na ficha nem em arquivo do projeto.
Carla fez a ficha do Codex da empresa. Descobriu que o colega usava uma conta, e ela outra, com limites diferentes.
O OpenRouter é um serviço que dá acesso a vários modelos com uma conta só, pagando por uso. Modelos abertos podem rodar num serviço desses ou no seu próprio computador.
Podem ser boas opções para certas tarefas. Mas entram no curso como orientação a conferir: preço do dia, qualidade na sua tarefa pela régua da aula 26, e para onde vão os dados.
Carla pensou num modelo aberto mais barato para o relatório. Parou antes: as planilhas têm nome de clientes, e ela não sabia onde o serviço guardaria os dados.
"Esse é mais barato, vou usar." Sem teste, sem saber para onde vão os dados.
Preço de hoje, teste com a régua numa tarefa sem dados de clientes, e a política de dados lida.
Se travou aqui, é normalNão sabe se pode mandar dados de clientes para outro serviço? Na dúvida, não mande. Pergunte a quem cuida disso na empresa e teste antes com dados inventados.
Há quem diga que o uso de IA hoje é subsidiado e vai encarecer. Pode ser. Mas é uma previsão de mercado, não um fato demonstrado.
O método deste curso se sustenta sem ela: medir custo e resultado por tarefa e guardar o conhecimento do projeto em arquivos que qualquer assistente lê. Se o preço subir, você já sabe onde cortar. Se cair, sabe onde ampliar.
Rafael não mudou nada por causa da previsão. Mudou quando a planilha da aula 28 mostrou duas coisas. A crítica em esforço alto valia a pena. A troca de textos, não.
"Vai encarecer, então uso o mínimo em tudo."
"A planilha mostra onde o esforço compra resultado. Ali eu mantenho."
Teste-se
Um vídeo diz que o limite da assinatura é de tantas horas por semana. O que você faz?
Pratique agora 0/3
Pronto quando o arquivo conta-ia.md tiver tipo, limite, onde conferiu e a data. Cerca de 8 minutos, no computador.
Você só lê a sua conta e anota; nada é contratado nem mudado. Nunca copie senha ou chave para a ficha. Não achou o limite? Escreva "não mostrado" e a data.
# Conta de IA Serviço: <qual, e de quem é a conta> Tipo: <assinatura ou por uso> Limite: <o que a página mostra; se só percentual, anote o percentual> Teto de gasto: <definido? quanto?> Onde vi: <caminho no site> · <data> Senha e chave: nunca aqui
Você já sabe o que a sua conta cobra e até onde vai, com data e fonte.
Cola da aula
A síntese do INEMA de 27 de setembro de 2026 separa o que foi verificado do que foi sugerido na conversa. OpenRouter e modelos de código aberto podem entrar na estratégia quando forem adequados ao projeto, mas não são recomendações verificadas pela página analisada, e devem ser confirmados no ambiente e nas ferramentas disponíveis antes de virar procedimento padrão.
A ideia de que a IA hoje é subsidiada e poderá custar mais por uso no futuro é tratada como hipótese de mercado. A recomendação prática já se sustenta sem essa previsão: medir custo e resultado por tarefa e manter o conhecimento do projeto portátil.
Fontes: síntese executiva de 27/09/2026, nos arquivos de origem do curso, pasta docs/.
Aula 29 · Dev com IA v6.2 · INEMA.CLUB
Módulo 6 · Aula 5 de 5

Você consegue entregar o relatório de uma página do seu piloto e escrever a decisão: ampliar, ajustar ou parar, com o motivo.
Um piloto sem decisão no fim vira só uma experiência. O relatório junta o que você mediu no curso inteiro e responde a uma pergunta: vale fazer assim de novo, em mais tarefas?
Em 1 minuto
Tudo o que você produziu no curso vira seis linhas. Elas trazem a tarefa do briefing, os critérios de aceite que passaram, os problemas achados e por quem. Depois, o custo e a comparação da planilha da aula 28, e a decisão.
Rafael montou o relatório do formulário da clínica em quinze minutos, copiando dos arquivos da pasta do piloto.
Se travou aqui, é normalPulou alguma etapa do piloto? Escreva "não feito" na linha. Um relatório honesto com lacunas vale mais que um completo inventado.
Ampliar é usar o método em mais tarefas do mesmo tipo. Ajustar é repetir o piloto mudando uma coisa. Parar é concluir que, para esse tipo de tarefa, o jeito antigo é melhor. Parar também é resultado.
Carla ampliou para o relatório mensal. Rafael ajustou: a revisão cruzada do plano achou muito, mas a da troca de textos não achou nada, e ele vai tirá-la.
O modelo pode resumir o relatório e apontar números que não batem. A decisão de ampliar é de quem responde pelo trabalho. Escreva a decisão, o motivo e quando vai rever.
Carla escreveu: "Ampliar para o relatório mensal. Motivo: 3 de 3 critérios e 25 minutos contra duas horas. Revisar em 30 dias."
"O piloto foi interessante, vamos ver."
Depois de um mês: ninguém lembra o que foi medido.
"Ampliar. Motivo: 3 de 3 critérios, 25 minutos contra 120. Revisar em 30 dias."
Depois de um mês: ela compara com o novo mês.
O ciclo do curso é o começo. Três caminhos do INEMA, todos abertos, continuam daqui.
O guia do Use Both traz os seis níveis de uso conjunto e prompts prontos. O claudex automatiza o debate de um plano grande entre Claude e Codex. E o curso Claude → Codex ensina a guardar o contexto do projeto em arquivos que qualquer assistente lê.
O claudex roda no terminal, com o Claude Code e o Codex prontos para uso. Os outros dois servem para quem usa o app.
Rafael foi para o Use Both. Quer dar ao assistente uma meta com teste de sucesso e limite de parada, como na aula 19. Carla foi para o curso Claude → Codex: a equipe dela usa assistentes diferentes.
Pratique agora 0/4
Pronto quando relatorio-piloto.md tiver as seis linhas e a decisão com data de revisão. Cerca de 12 minutos, no computador.
É um arquivo seu; nada é enviado. Faltou uma etapa? Escreva "não feito". Se quiser, peça a um assistente que confira se os números do relatório batem com a planilha, e a decisão continua sua.
# Relatório do piloto Tarefa: <do briefing.md> Critérios: <quantos de quantos passaram> Problemas achados: <quantos, e por quem: revisão, teste, você> Custo: <tempo seu e uso da conta, da planilha> Comparação: <coluna "Jeito antigo (min)" da planilha; se for estimativa, escreva "estimado"> Decisão: <ampliar, ajustar ou parar> · Motivo: < > · Revisar em: <data>
Você fechou o piloto com uma decisão que outra pessoa entende e confere.
Cola da aula
Aula 30 · Dev com IA v6.2 · INEMA.CLUB