INEMA.CLUBPRODev com IA v6.2

Dev com IA v6.2 · 6 módulos · 30 aulas de uns 15 minutos

Um faz, o outro confere

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.

Um desenvolvedor e uma analista de operações conferem juntos uma folha impressa com marcações de caneta, ao lado de dois notebooks abertos.

Módulo 1 · Validar é o trabalho

Trocar "parece certo" por "conferi assim".

Módulo 2 · Planejar e criticar

Plano em arquivo, criticado pelo outro modelo sobre o mesmo arquivo.

Módulo 3 · Construir e revisar o diff

Um constrói em etapas; o outro revisa o diff com o briefing e os testes.

Módulo 4 · Comprovar e decidir

Testes pertinentes, comportamento real e decisão humana.

Módulo 5 · Continuidade: handoff e prime

Trocar de sessão ou de modelo sem explicar tudo de novo.

Módulo 6 · Modelos, esforço e orçamento

Escolher modelo e esforço por etapa e medir custo × resultado.

Glossário · 22 termos

Dev com IA v6.2

Glossário

Os termos técnicos do curso em palavras simples. Cada termo leva às aulas em que aparece.

AGENTS.md

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

API

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

branch

Linha de teste separada dentro do Git. Você testa mudanças nela sem mexer na versão que já funciona.

Aparece em: Aula 11 Aula 12 Aula 15

briefing

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

Claude Code

Assistente de programação da Anthropic que lê e altera arquivos numa pasta do seu computador.

Aparece em: Aula 1 Aula 8

CLI

Programa usado por comandos digitados no terminal, sem janelas nem botões.

Aparece em: Aula 8

Codex

Assistente de programação da OpenAI que lê e altera arquivos numa pasta do seu computador.

Aparece em: Aula 1 Aula 8

commit

Uma versão salva no Git, com data e uma frase dizendo o que mudou.

Aparece em: Aula 11 Aula 12 Aula 13 Aula 15

critério de aceite

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

diff

A lista do que mudou entre duas versões de um arquivo: linhas que saíram (com −) e linhas que entraram (com +).

Aparece em: Aula 11 Aula 12 Aula 13 Aula 15

esforço de raciocínio

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

Git

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.

Aparece em: Aula 8 Aula 11 Aula 12 Aula 13 Aula 15 Aula 24

handoff

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

modelo

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

plugin

Complemento que se acrescenta a um programa para dar a ele uma função nova.

Aparece em: Aula 8 Aula 9

prime

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.

Aparece em: Aula 22 Aula 23 Aula 24 Aula 25

revisão cruzada

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

rodada de revisão

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

sandbox

Á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.

Aparece em: Aula 8 Aula 24

terminal

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

teste automático

Verificação que o computador roda sozinho e responde 'passou' ou 'falhou', sempre do mesmo jeito. A IA pode escrever o teste para você.

Aparece em: Aula 16 Aula 17

tokens

Pedaço de texto que o modelo lê ou escreve. O uso de IA é medido e cobrado em tokens.

Aparece em: Aula 4 Aula 19 Aula 28 Aula 29

Módulo 1 · Aula 1 de 5

Gerar ficou fácil. Conferir, não.

Um desenvolvedor segura a página impressa de um site e circula um erro com caneta vermelha, com o notebook aberto ao lado.

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

  1. A IA diz "pronto" com a mesma confiança quando acerta e quando erra.
  2. Conferir é olhar o resultado real, não o resumo que a IA fez dele.
  3. A decisão de entregar é sua. A IA ajuda a conferir, mas não assina.

1A IA diz "pronto" com a mesma voz quando erra

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".

Assistente de código

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.

Toque ou clique nos dois botões do quadro: a mesma tarefa, antes e depois de perguntar.

2Conferir é olhar o resultado real

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.

Aceitou

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.

Conferiu

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.

3Três formas de conferir

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.

Conferência do relatório de Carla
1 Critério: total de pedidos igual ao da planilha
2 Abrir o relatório e somar a coluna de pedidos
3 Pedir a outra IA, ou a uma conversa nova, os números sem fonte
  1. 1Escrito antes de pedir o relatório.
  2. 2Feito por ela, no arquivo real.
  3. 3Um olhar de fora, que o módulo 2 ensina.

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 é?

4A IA ajuda a conferir; quem decide é você

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.

O que a IA faz

Produz, revisa e aponta falhas com a evidência.

O que é seu

Define o critério, olha o resultado real e decide se entrega.

Os dois cartões estão certos: um é da IA, o outro é seu.

Pratique agora 0/3

Conferido ou só aceito?

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.

Ver gabarito

Três planos: conferido, ele viu. Botão: aceito, ninguém clicou. Texto revisado: aceito, ninguém leu. Em um minuto: clicar no botão e ver se abre o pagamento certo, e ler o texto da página procurando preço ou nome errado.

Você já separa o que foi visto do que foi só dito.

Cola da aula

Conferir

  1. Resumo da IAé uma declaração, não uma prova.
  2. Três conferênciascritério escrito antes, resultado aberto, segundo olhar.
  3. Decisãoentregar ou não é sempre sua.

Seu próximo passo

Você já sabe separar o que conferiu do que só aceitou.

No próximo resultado de IA que for para outra pessoa, confira uma afirmação abrindo o resultado real. Leva cinco minutos.

Na próxima aula: e se outro modelo disser que está tudo certo? Duas IAs concordando ainda não é prova.

Aula 1 · Dev com IA v6.2 · INEMA.CLUB

Módulo 1 · Aula 2 de 5

Duas IAs concordando não é prova

Uma analista de operações confere à mão, com uma calculadora de mesa, uma linha de um relatório impresso que dois modelos já tinham aprovado.

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

  1. Um modelo diferente acha falhas que o autor não vê.
  2. Mas os dois podem errar juntos, se leram a mesma coisa errada.
  3. Quem fecha: critério de aceite, teste no resultado real e a sua decisão.

1Quem escreveu tende a aprovar o que escreveu

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.

Revisão do plano

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.

Toque ou clique nos dois botões do quadro e compare as duas revisões.

2Os dois podem errar juntos

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.

Dois aprovaram

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.

Conferiu no 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.

3O que fecha a conferência

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.

O que fecha o ciclo
1 Critério de aceite, escrito antes do trabalho
2 Teste no resultado real, feito por alguém
3 Decisão humana: entra ou não entra
  1. 1Diz o que conferir.
  2. 2Mostra se passou.
  3. 3Assume a responsabilidade.

Teste-se

Claude escreveu, Codex revisou e aprovou. O que ainda falta antes de entregar?

4O revisor recebe o original, não um resumo

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.

Resumo

"O outro modelo disse que a fórmula está certa. Confira."

Original

O pedido inicial, a planilha e a fórmula, com: "aponte falhas com o trecho que mostra cada uma".

Com o resumo, o revisor confere uma frase. Com o original, confere o trabalho.

Pratique agora 0/3

O que ainda falta?

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.

Ver gabarito

1. Só a resposta do Claude, sem as planilhas e sem o pedido original: faltou o material para conferir. 2. Algo como "o total de pedidos do relatório é igual à soma das planilhas da semana". 3. Somar a coluna de pedidos das planilhas e comparar com o total do relatório.

Você já sabe o que falta quando "os dois concordaram".

Cola da aula

Revisão cruzada

  1. Outro olharmodelo diferente ou conversa nova acha o que o autor não vê.
  2. Não é provadois modelos podem errar juntos.
  3. Quem fechacritério, teste no real e a sua decisão.

Seu próximo passo

Você já sabe usar um segundo modelo sem tratá-lo como carimbo final.

Na próxima revisão que pedir, mande o original e peça "falhas com o trecho que mostra cada uma". Leva dois minutos a mais.

Na próxima aula: se o critério de aceite fecha o ciclo, como escrever um que funcione?

Material complementar · De onde vem esta aulaAprofundamento do tópico. Não conta no tempo da aula.

O que as fontes dizem

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."

Por que o autorrevisor falha

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

O critério de aceite vem antes do trabalho

Uma analista de operações escreve à mão uma lista curta de conferências numa ficha de papel, antes de pedir o relatório à IA.

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

  1. Desejo é "bonito e funcionando". Critério é "a mensagem de teste chega".
  2. Um bom critério se responde com sim ou não, por quem não fez o trabalho.
  3. O critério vai dentro do pedido, junto com o que não pode mudar.

1Desejo não se confere; critério sim

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.

Desejo

"Um formulário de contato bonito e funcionando."

Critério

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.

2O teste do sim ou não

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".

Ficha de Carla · relatório semanal
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
  1. 1Confere com uma soma.
  2. 2Confere lendo a lista de cidades.
  3. 3Confere lendo a linha embaixo de cada tabela.

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.

3O critério vai dentro do pedido

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".

Assistente de código

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.

Toque ou clique nos dois botões do quadro. O roteiro é para você executar; ele não substitui a conferência.

4Diga também o que não pode mudar

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.

Dentro

Gerar o relatório semanal num arquivo novo, com os três critérios.

Fora

Não alterar as planilhas originais. Não mudar o formato do relatório.

"Dentro" e "Fora" vão no mesmo pedido. O "Fora" diminui o que você precisa conferir.

Pratique agora 0/3

Três critérios para uma tarefa sua

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

Critério de aceite

  1. Antesescreva o critério antes de pedir o trabalho.
  2. Sim ou nãoquem não fez precisa conseguir responder.
  3. No pedidocole os critérios e o que fica de fora.

Seu próximo passo

Você já escreve o "pronto" antes de começar.

Use os três critérios da prática no próximo pedido real. Cole no fim e peça o roteiro de conferência.

Na próxima aula: critério sem limite vira trabalho sem fim. Como pôr uma trava de verdade?

Aula 3 · Dev com IA v6.2 · INEMA.CLUB

Módulo 1 · Aula 4 de 5

"Pare em duas horas" é um pedido, não uma trava

Um desenvolvedor põe um cronômetro de cozinha e uma ficha de papel ao lado do notebook antes de começar uma tarefa com IA.

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

  1. Frase no pedido é pedido. Trava é o que para o trabalho mesmo sem a IA querer.
  2. Três limites conferíveis: tentativas, arquivos e tempo ou gasto.
  3. Bateu o limite, a IA para e descreve o bloqueio. Ela não insiste.

1Frase no pedido não é trava

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.

Pedido

"Corrija o envio do formulário. Pare em uma hora."

O que aconteceu: dez tentativas, e o trabalho seguiu depois da hora.

Limite e trava

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.

2Três limites que se conferem

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.

Limites da tarefa
1 Tentativas: no máximo 2
2 Arquivos: só os que o pedido lista
3 Tempo ou gasto: uma trava fora da IA
  1. 1Confere contando, na conversa, quantas vezes a IA disse que ia tentar de outro jeito.
  2. 2Confere na coluna "Data de modificação" da pasta.
  3. 3Confere no relógio e na página de uso da conta.

3A trava mora fora da IA

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.

Trava de tempo

Alarme de 30 minutos. Tocou: botão de parar, e peça o relato do que foi feito.

Medida de gasto

Página de uso da conta, aberta antes e depois da tarefa. Teto de gasto, se a conta oferecer.

O alarme depende de você por perto. Para parar sem você, só a trava automática do quadro abaixo.
Trava automática, para quem usa o terminal

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.

Terminal · Linux
$ 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ó.

4Bateu o limite: parar e descrever o bloqueio

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.

Assistente de código

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.

A pasta "entregas-copia" é uma cópia que Carla fez antes: botão direito na pasta original › Copiar, e Colar ao lado.

Pratique agora 0/3

Ponha três limites no seu pedido

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

Limites de verdade

  1. Pedido não é travaa frase ajuda, mas não para nada.
  2. Três limitestentativas, arquivos e tempo ou gasto.
  3. Paradano limite, a IA descreve o bloqueio.

Seu próximo passo

Você já sabe pôr uma trava que funciona mesmo sem a IA concordar.

Entre no site do seu assistente de IA, procure a página de uso da conta e guarde o link nos favoritos. Leva cinco minutos.

Na próxima aula: juntar tarefa, critério e limites num arquivo só, e ver o ciclo inteiro.

Material complementar · Meta com condição de paradaAprofundamento do tópico. Não conta no tempo da aula.

De onde vem esta 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.

O que a síntese do INEMA recomenda

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

O ciclo em cinco passos e o briefing do seu piloto

Um desenvolvedor e uma analista de operações prendem fichas de papel em sequência num quadro de cortiça, ligadas por setas, montando o caminho de uma tarefa.

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

  1. O ciclo: definir, planejar e criticar, construir e revisar, comprovar, registrar.
  2. Tudo começa num arquivo: o briefing, que os dois modelos leem.
  3. O piloto é uma tarefa pequena, de uma ou duas horas, não o sistema inteiro.

1O ciclo inteiro numa ficha

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.

O ciclo do curso
1 Definir: objetivo, dentro e fora, critérios, limites
2 Planejar e criticar: um escreve o plano, o outro ataca
3 Construir e revisar: um faz, o outro lê o que mudou
4 Comprovar: testes, resultado real, sua decisão
5 Registrar: handoff para a próxima conversa
  1. 1Módulo 1, este.
  2. 2Módulo 2.
  3. 3Módulo 3.
  4. 4Módulo 4.
  5. 5Módulo 5. O módulo 6 mede o custo de tudo.

2Quem faz o quê é uma rota inicial

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.

Rota inicial

Plano: Claude escreve, Codex critica.
Construção: um faz, o outro revisa o que mudou.

O que decide

A qualidade da entrega na sua tarefa. Modelos, acesso e cobrança mudam de conta para conta.

Comece pela rota inicial e fique com a que der melhor resultado na sua tarefa.

3O briefing é o arquivo que todos leem

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.

briefing.md · formulário da clínica
1 Objetivo: pacientes mandam mensagem pelo site
2 Dentro: página de contato · Fora: página inicial e cores
3 Aceite: mensagem chega na recepção; telefone recusa letras; abre no celular
4 Limites: 2 tentativas; só contato.html; alarme de 30 minutos a cada vez que a IA trabalha
  1. 1Uma frase: para que serve.
  2. 2O que pode e o que não pode mudar.
  3. 3Os critérios da aula 3.
  4. 4Os limites da aula 4.

4O piloto: uma tarefa pequena de verdade

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.

Grande demais

"Automatizar todos os relatórios da empresa."

Bom piloto

"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

Escreva o briefing do seu piloto

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>
Criar o arquivo no Windows
1 Pasta do piloto
2 Exibir › Mostrar › Extensões de nomes de arquivos
3 Botão direito › Novo › Documento de texto
4 briefing.md
  1. 1Abra a pasta que você criou para o piloto.
  2. 2Ligue as terminações. No Windows 10: aba Exibir, marque Extensões de nomes de arquivos.
  3. 3Clique com o botão direito num espaço vazio da pasta.
  4. 4Renomeie para briefing.md e confirme. Para abrir: botão direito › Abrir com › Bloco de Notas.
No Mac: TextEdit › Formatar › Converter em Texto Simples, cole o molde e salve como briefing.md; se ele perguntar, escolha "Usar .md". Deu problema com a terminação? Um briefing.txt também serve.

Você já tem o briefing que os dois modelos vão ler no módulo 2.

Cola da aula

Ciclo e briefing

  1. Cinco passosdefinir, planejar e criticar, construir e revisar, comprovar, registrar.
  2. Briefingum arquivo com objetivo, dentro e fora, critérios e limites.
  3. Pilotouma tarefa real e pequena, que você sabe conferir.

Seu próximo passo

Você fechou o módulo 1 com o briefing do seu piloto pronto.

Releia o briefing amanhã, com a cabeça descansada. Corrija um critério que ainda dependa de opinião.

No módulo 2: um modelo escreve o plano a partir do seu briefing, e o outro tenta derrubá-lo.

Aula 5 · Dev com IA v6.2 · INEMA.CLUB

Módulo 2 · Aula 1 de 5

O plano mora num arquivo, não na conversa

Um desenvolvedor marca com lápis o desenho técnico de uma casa, numa folha azul estendida sobre a mesa, antes de começar a obra.

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

  1. Peça o plano num arquivo: plan-v1.md, na pasta do piloto.
  2. Quatro partes: escopo, suposições, critérios de aceite e riscos.
  3. Escreva "não implemente nada ainda". Criticar um plano custa menos que desfazer código.

1Plano na conversa some; plano em arquivo fica

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.

Assistente de código

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.

Toque ou clique nos dois botões do quadro e compare os dois pedidos.

2As quatro partes de um plano

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.

plan-v1.md · formulário da clínica
1 Escopo: página de contato com nome, "campo telefone, texto livre" e mensagem; "enviar para o e-mail da recepção". Fora: página inicial e cores
2 Suposições: a recepção usa um único e-mail
3 Critérios de aceite: os 3 do briefing, cada um com o teste
4 Riscos: a hospedagem pode bloquear o envio de e-mail
  1. 1O que entra e o que fica fora.
  2. 2O que a IA deu por certo.
  3. 3Como cada critério vai ser conferido.
  4. 4O que pode dar errado.

3"Não implemente nada ainda"

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.

Sem a frase

Pedido: "Planeje a rotina das planilhas."

Resultado: três arquivos criados antes de alguém ler o plano.

Com a frase

Pedido: "Escreva o plano em plan-v1.md. Não implemente nada ainda."

Resultado: um arquivo só, para ler em cinco minutos.

4Suposição escrita é erro que se acha

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.

Suposição escondida

O plano manda "juntar as planilhas pela ordem das colunas". Ninguém percebe o que isso supõe.

Suposição escrita

"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

Peça o plan-v1.md do seu piloto

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

Plano em arquivo

  1. plan-v1.mdo plano fica na pasta do piloto, não na conversa.
  2. Quatro partesescopo, suposições, critérios de aceite e riscos.
  3. Sem obra"não implemente nada ainda" vai no pedido.

Seu próximo passo

Você já transforma "planeje isso" num arquivo que dá para criticar.

Leia o seu plan-v1.md em voz baixa, só a parte de suposições. Anote uma pergunta que faria a quem escreveu.

Na próxima aula: quem vai ler esse plano sem piedade, e como pedir uma crítica que sirva.

Material complementar · De onde vem o plan-v1.mdAprofundamento do tópico. Não conta no tempo da aula.

O pedido do kit Use Both

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

Crítica só leitura: achado com evidência

Uma analista de operações lê um documento impresso e escreve anotações na margem com caneta vermelha, apontando trechos específicos.

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

  1. O revisor só lê. Ele não altera o plano nem outro arquivo.
  2. Cada achado tem quatro campos: falha, evidência, impacto e menor correção.
  3. O revisor recebe o briefing e o plano de verdade, nunca um resumo.

1O revisor só lê

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.

Revisor

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.

2Os quatro campos de um achado

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.

review.md · achado 1 do plano de Carla
1 Falha: nada trata planilha com colunas em outra ordem
2 Evidência: "juntar as planilhas pela ordem das colunas"
3 Impacto: totais de uma cidade somados na coluna errada
4 Menor correção: juntar pelo nome da coluna
  1. 1O que está errado.
  2. 2Onde está, com as palavras do plano.
  3. 3Por que importa.
  4. 4O conserto mais simples.

3Achado vago não é achado

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.

Vago

"Considere validar melhor os campos do formulário."

Achado

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.

O achado cita o critério do briefing que seria quebrado.

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".

4O revisor recebe o briefing e o plano

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.

Só o plano

O revisor sugere trocar a planilha por um banco de dados. Fora do escopo.

Briefing e plano

O revisor aponta que o plano esqueceu o critério "cada cidade aparece uma vez".

Pratique agora 0/3

Peça a crítica do seu plan-v1.md

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

Crítica que serve

  1. Só leiturao revisor aponta; não reescreve nem altera arquivos.
  2. Quatro camposfalha, evidência, impacto e menor correção.
  3. Base comumbriefing e plano vão juntos para o revisor.

Seu próximo passo

Você já pede crítica com evidência, e não opinião.

Guarde o molde da prática num arquivo pedido-critica.md na pasta do piloto. Vai usar de novo no módulo 3.

Na próxima aula: chamar o outro modelo sem copiar e colar, com um comando só.

Aula 7 · Dev com IA v6.2 · INEMA.CLUB

Módulo 2 · Aula 3 de 5

Ligar Claude e Codex: três caminhos e o manual

Um desenvolvedor, sentado entre um notebook e um monitor maior, passa uma folha impressa de um lado da mesa para o outro.

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

  1. Três caminhos automáticos: o complemento oficial, um comando chamando o outro, e a revisão de mudança publicada. E o manual.
  2. No comando, o revisor roda travado em só leitura e a resposta vai para um arquivo.
  3. Sem terminal? Copiar e colar numa conversa nova continua valendo.

1Três formas de ligar os dois, mais a manual

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.

Três caminhos e o manual
1 Plugin oficial: openai/codex-plugin-cc
2 Um comando chama o outro; resposta em review.md
3 Revisão da mudança publicada (módulo 3)
4 Manual: copiar e colar numa conversa nova
  1. 1Entra como complemento no Claude Code.
  2. 2Roda no terminal. Exige a CLI do outro assistente, conectada à sua conta.
  3. 3Serve quando já existe código mudado.
  4. 4Funciona com qualquer chat.

2O Codex critica o plano do Claude, com um comando

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.

Terminal · pasta do piloto
$ 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.

O -c model_reasoning_effort=medium escolhe o esforço médio. O módulo 6 volta nisso.

3O caminho inverso: o Claude critica

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.

Terminal · pasta do piloto
$ 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.

Para escolher modelo e esforço, acrescente --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.

4Manual ou por comando: o que muda

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.

Manual

Conversa nova, cola briefing, plano e pedido. Salva a resposta como review.md. Funciona em qualquer chat.

Por comando

Um comando na pasta. O revisor lê os arquivos e a resposta cai em review.md. Menos cópia, menos erro de colagem.

Os dois caminhos estão certos. Escolha pelo que você já usa.

Pratique agora 0/3

Receba a crítica do plano num arquivo

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

Ligar os dois

  1. codex execcom --sandbox read-only e -o review.md.
  2. claude -pcom --permission-mode plan e > review-claude.md.
  3. Manualconversa nova, cola tudo, salva a resposta.

Seu próximo passo

Você já faz um assistente revisar o outro, com a resposta num arquivo.

Leia o review.md e marque, ao lado de cada achado, se você concorda. Leva dez minutos.

Na próxima aula: e se os dois discordarem para sempre? Quando parar o debate.

Material complementar · Os comandos e o pluginAprofundamento do tópico. Não conta no tempo da aula.

O que as fontes registram

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 que --skip-git-repo-check

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.

Fontes: Área Codex + Claude — Eventos INEMA

Aula 8 · Dev com IA v6.2 · INEMA.CLUB

Módulo 2 · Aula 4 de 5

Duas rodadas de revisão e ponto

Uma analista de operações fecha uma pasta de documentos com duas notas adesivas coladas na capa, com gesto de quem decidiu encerrar a discussão.

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

  1. Cada achado recebe uma resposta: aceito, rejeitado com evidência ou em aberto.
  2. No máximo duas rodadas de revisão. Concordar não é prova.
  3. O que ficou em aberto vira teste com nome. Plano grande: o claudex automatiza.

1Cada achado recebe uma resposta

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.

review.md · respostas de Carla
1 Juntar pelo nome da coluna → aceito
2 Trocar a planilha por um banco de dados → rejeitado: fora do briefing
3 Planilha com cidade em branco → em aberto
  1. 1Entra no plano.
  2. 2Não entra, e a evidência está escrita.
  3. 3Vira teste, no passo 3 desta aula.

2Por que parar em duas rodadas

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.

Cinco rodadas

Rodadas 3, 4 e 5: ajustes de redação. Os dois assistentes terminam "de acordo". Nenhum teste nomeado.

Duas rodadas

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?

3O que ficou em aberto vira teste com nome

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.

Assistente

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.

4Plano grande: o claudex automatiza o debate

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.

Tarefa pequena

Duas rodadas à mão. Você lê cada achado e responde.

Plano grande

/claudex:plan --rounds 2, com o número de rodadas fixado. No fim, você ainda lê o plano e nomeia os testes.

Automatizar o debate não automatiza a decisão.

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

Responda os achados

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".

Ver gabarito

A: aceito, limite de tamanho entra no plano. B: rejeitado, o briefing põe a página inicial e as cores no "Fora". C: em aberto; vira a pergunta "a recepção quer cópia no celular?", para a clínica responder antes de construir.

Você já encerra o debate com cada achado respondido e a dúvida guardada num teste.

Cola da aula

Encerrar o debate

  1. Três respostasaceito, rejeitado com evidência, em aberto.
  2. Duas rodadasdepois disso, concordância não acrescenta prova.
  3. Em abertovira teste com nome; plano grande, claudex.

Seu próximo passo

Você já sabe fechar uma revisão sem ficar num debate sem fim.

Escreva ao lado de cada achado do seu review.md: aceito, rejeitado ou em aberto. Leva dez minutos.

Na próxima aula: juntar as respostas no plan-v2.md do piloto e ver por que "Claude planeja" é só um começo.

Material complementar · Reconciliar e pararAprofundamento do tópico. Não conta no tempo da aula.

O que o kit Use Both pede

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.

claudex × Use Both

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

Rota inicial, não ranking, e o plan-v2.md do piloto

Um desenvolvedor e uma analista de operações comparam, lado a lado na mesa, um documento cheio de marcas de caneta e a versão nova, limpa.

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

  1. "Claude planeja, Codex critica" é uma rota para começar, não um ranking.
  2. O plan-v2.md é um arquivo novo; o plan-v1.md fica guardado ao lado.
  3. Antes de construir, cada critério de aceite do briefing precisa ter um teste no plano.

1A tabela de rotas é um ponto de partida

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.

Quem faz o quê · rota inicial
1 Planejar: Claude escreve · Codex critica as premissas
2 Construir: Claude constrói · Codex revisa o que mudou
3 Revisar documento: qualquer um escreve · o outro confere
  1. 1Este módulo.
  2. 2Módulo 3.
  3. 3Vale para texto, relatório e plano.
Fique com a rota que produzir melhor evidência na sua tarefa.

2O que decide é a evidência da sua tarefa

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.

Pela fama

"Dizem que o modelo X é o melhor para planejar." Carla usaria só ele, sem conferir.

Pela evidência

Crítica 1: 3 achados, 2 conferidos. Crítica 2: 5 achados, 1 conferido. Nesta tarefa, a crítica 1 serviu mais.

3O plan-v2.md é um arquivo novo

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.

Pasta do piloto · formulário da clínica
1 piloto-formulario
briefing.md
2 plan-v1.md
3 review.md
4 plan-v2.md
  1. 1Uma pasta por piloto.
  2. 2O plano original, guardado.
  3. 3A crítica, com as suas respostas.
  4. 4A versão que vai para a construção.

4Confira o plan-v2.md contra o briefing

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.

Assistente

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

Feche o plan-v2.md do seu piloto

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

Plano fechado

  1. Rota inicialserve para começar; a evidência da tarefa decide.
  2. Arquivo irmãoplan-v2.md novo, plan-v1.md guardado.
  3. Critério com testenenhum critério do briefing sem conferência prevista.

Seu próximo passo

Você fechou o módulo 2 com o plano do piloto criticado e pronto para virar obra.

Releia o plan-v2.md amanhã e sublinhe o primeiro passo da construção. Só ele.

No módulo 3: alguém constrói a partir do plano, e o outro lê cada linha que mudou.

Material complementar · O cartão de rotasAprofundamento do tópico. Não conta no tempo da aula.

De onde vem a tabela

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

Git só o necessário: ver o que mudou

Um desenvolvedor compara duas folhas impressas quase iguais e marca em verde e vermelho as linhas que mudaram de uma para a outra.

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

  1. O Git guarda versões dos arquivos de uma pasta e mostra a diferença entre elas.
  2. Um branch separa o teste: você mexe nele sem estragar a versão que funciona.
  3. No git diff, linha com − saiu e linha com + entrou.

1O Git mostra o que mudou, não o que foi dito

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é.

Sem Git

Pergunta: "o que você mudou?"

Resposta: o resumo da IA, com a memória dela.

Com Git

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.

2Um branch é uma linha de teste

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.

Terminal · pasta do site
$ 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.

O Git responde em inglês. Leia só o começo de cada linha.

3Lendo o diff: − saiu, + entrou

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.

Terminal · pasta do site
$ 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.

Leia primeiro os nomes de arquivo: arquivo fora do pedido é o primeiro sinal de problema.

Teste-se

No diff, uma linha começa com −. O que isso quer dizer?

4Sem terminal: peça o diff ao assistente

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.

Assistente de código

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.

Toque ou clique nos dois botões do quadro e compare.

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

Seu primeiro diff, na pasta do piloto

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

Git para revisar

  1. git switch -ccria um branch de teste e entra nele.
  2. git statusdiz onde você está e lista tudo o que mudou, até arquivo novo.
  3. git diffmostra as linhas: − saiu, + entrou.

Seu próximo passo

Você já enxerga a mudança real, sem depender do resumo da IA.

No próximo pedido a um assistente de código, peça no fim: "mostre o git diff completo". Leva dez segundos.

Na próxima aula: se a IA faz tudo de uma vez, o diff vira um livro. Como pedir em etapas?

Aula 11 · Dev com IA v6.2 · INEMA.CLUB

Módulo 3 · Aula 2 de 5

Uma etapa por vez, com o critério colado

Uma analista de operações monta uma estante em etapas: prende a primeira prateleira e confere com um nível antes de pegar a próxima peça.

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

  1. Quebre o plano em etapas pequenas, cada uma com o seu critério.
  2. Peça uma etapa, com os critérios colados e "pare ao terminar".
  3. Conferiu a etapa? Ela vai para a revisão da aula 13; o commit vem depois.

1Tudo de uma vez vira um diff que ninguém lê

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.

Tudo de uma vez

Pedido: formulário completo.

Diff: sete arquivos. Rafael aprovou sem ler tudo.

Uma etapa

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.

2Cada etapa com o seu critério

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.

Etapas do piloto de Carla
1 Ler as planilhas · critério: total de linhas lidas confere
2 Somar por cidade · critério: cada cidade uma vez
3 Gravar o relatório · critério: arquivo novo, originais intactas
  1. 1Começa pelo que as outras precisam.
  2. 2Uma coisa nova por etapa.
  3. 3A última entrega o resultado.

3O pedido da etapa: critério colado e parada

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.

Assistente de código

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.

4Etapa ruim? Volte atrás antes de salvar

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.

Terminal · pasta do piloto de Carla
$ 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.

Pelo terminal ou pedindo ao assistente. Se você já rodou o git add da aula 13, use git restore --staged --worktree . para desfazer também o que foi preparado.

Pratique agora 0/3

Peça a etapa 1 do seu piloto

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

Etapas

  1. Pequenauma etapa cabe num diff que você lê inteiro.
  2. Pedidocontexto, etapa, critérios e "pare no fim".
  3. Desfazergit restore . antes do commit, que vem depois da revisão.

Seu próximo passo

Você já transforma um plano em pedidos pequenos e conferíveis.

Escreva as etapas 2 e 3 do seu piloto, cada uma com um critério. Leva cinco minutos.

Na próxima aula: a etapa está feita. Quem confere, e o que essa pessoa precisa receber?

Aula 12 · Dev com IA v6.2 · INEMA.CLUB

Módulo 3 · Aula 3 de 5

O revisor recebe o diff, não o resumo

Um desenvolvedor entrega a uma colega uma pasta com três folhas separadas por clipes: o pedido, a lista de mudanças e o resultado das conferências.

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

  1. O pacote do revisor tem três partes: briefing, diff e resultado das conferências.
  2. Peça achados com onde, o que falha, impacto e a menor correção.
  3. Revisor só lê: ele aponta, não altera arquivo.

1O pacote do revisor tem três partes

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.

Pasta do piloto · pacote da revisão
1 briefing.md · o que era pedido
2 mudanca.diff · o que mudou, linha a linha
3 conferencias.txt · o que você conferiu e o que deu
  1. 1O mesmo briefing que quem fez recebeu.
  2. 2A mudança real, gerada pelo Git.
  3. 3Evidência, não opinião.

2Com o pacote, o revisor acha o que falta

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.

Revisão da etapa 1

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.

Toque ou clique nos dois botões do quadro e compare as duas revisões.

3Montar e enviar o pacote

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.

Terminal · pasta do piloto
$ 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.

"read-only" e "plan" são travas: o revisor não consegue mudar nenhum arquivo.

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.

4Achado útil tem quatro partes

"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.

Achado vago

"A soma por cidade pode ter inconsistências."

Achado útil

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

Peça a revisão da sua etapa 1

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

Revisão do diff

  1. Pacotebriefing, mudanca.diff e conferencias.txt.
  2. Só leituraread-only no Codex, plan no Claude; no app, confira no git status.
  3. Quatro partesonde, falha, impacto, menor correção.

Seu próximo passo

Você já monta o pacote que torna a revisão cruzada útil.

Crie o conferencias.txt na pasta do piloto e anote, em uma linha por critério, o que conferiu hoje.

Na próxima aula: e quando a mudança é uma imagem, e não uma linha de texto?

Material complementar · De onde vem esta aulaAprofundamento do tópico. Não conta no tempo da aula.

Nível 3 do kit Use Both

"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.

Três formas de ligar Claude e Codex

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

Imagens: checar antes, inspecionar depois

Uma analista de operações segura a ilustração impressa ao lado do monitor que mostra a mesma imagem pequena, comparando como ela fica no tamanho real de uso.

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

  1. Antes: a sessão tem ferramenta de imagem? Como ela cobra?
  2. Pronto é o arquivo salvo no projeto, aberto no tamanho em que vai ser usado.
  3. Nunca sobrescreva: salve a versão nova ao lado e anote qual o projeto usa.

1Antes: tem ferramenta, e quanto custa?

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.

Assistente de código

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.

2Pronto é o arquivo no projeto

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".

Não conta

Uma descrição da imagem, ou um link que expira.

Conta

O arquivo imagens/capa-relatorio-v1.png, dentro da pasta do projeto.

3Abra no tamanho em que vai ser usada

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.

Conferência da capa, em tamanho real
1 Texto: alguma letra ou palavra inventada?
2 Marcas: logotipo de empresa que não é sua?
3 Recorte: rosto ou objeto cortado na borda?
  1. 1Olhe as quatro bordas com calma.
  2. 2Marca alheia não pode ir para o cliente.
  3. 3Confira no formato final: página, celular ou impresso.

Teste-se

A imagem ficou ótima na miniatura. O que você faz antes de usar?

4Versão irmã, nunca por cima

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".

imagens · site da clínica
1 imagens
banner-contato-v1.png
2 banner-contato-v2.png
banner-contato-v3.png
  1. 1Uma pasta para as imagens do projeto.
  2. 2A versão em uso, anotada no briefing.

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

Confira uma imagem de verdade

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

Imagem com IA

  1. Antesferramenta existe? Como cobra? Mande parar se não houver.
  2. Arquivosalvo no projeto e aberto no tamanho real.
  3. Versõesv1, v2, v3 lado a lado; anote a que está em uso.

Seu próximo passo

Você já sabe impedir que uma imagem custe sem aviso ou suma do projeto.

Abra a pasta do seu piloto e crie a pasta imagens, mesmo vazia. Leva um minuto.

Na próxima aula: juntar tudo numa mudança do piloto, com a revisão registrada, e trocar os papéis.

Material complementar · Imagem com o Codex no INEMAAprofundamento do tópico. Não conta no tempo da aula.

Nível 2 do kit Use Both

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.

Como o INEMA faz hoje

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.

Fontes: Área Codex + Claude — Eventos INEMA

Aula 14 · Dev com IA v6.2 · INEMA.CLUB

Módulo 3 · Aula 5 de 5

Inverter os papéis e registrar a revisão

Um desenvolvedor e uma analista de operações, sentados à mesma mesa com dois notebooks, revisam o trabalho um do outro.

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

  1. Quem faz e quem revisa pode trocar. Teste a outra rota na sua tarefa.
  2. Corrija o achado que tem evidência; recuse o resto, com o motivo.
  3. Registre tudo em revisao-etapa-N.md, ao lado do código.

1Quem faz e quem revisa podem trocar

"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.

Rota A

Claude faz a etapa. Codex revisa o diff.

Rota B

Codex faz a etapa. Claude revisa o diff.

As duas rotas são válidas. Fique com a que der mais falhas reais na sua tarefa, não com a mais famosa.

2Corrija o que tem evidência; recuse com motivo

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.

Corrigido

"São Paulo" e "Sao Paulo" contavam como duas cidades. Critério 2 do briefing.

Recusado

"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.

3O registro da revisão

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.

revisao-etapa-2.md · formulário da clínica
1 Fez: Codex · Revisou: Claude
2 Achado 1: envio não mostra aviso quando a mensagem falha · corrigido
3 Achado 2: trocar as cores do botão · recusado (Fora do briefing)
4 Conferido depois: envio de teste chegou na recepção
  1. 1Quem fez e quem revisou.
  2. 2Achado corrigido, com o que era.
  3. 3Achado recusado, com o motivo.
  4. 4A conferência depois da correção.

4O laboratório: uma mudança completa

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.

Uma mudança revisada
1 Branch de teste (aula 11)
2 Etapa com critério colado e parada (aula 12)
3 Pacote e revisão só leitura (aula 13)
4 Corrigir, registrar, git add -A e commit (esta aula)
  1. 1Separado da versão que funciona.
  2. 2Mudança pequena.
  3. 3Outro olhar sobre o trabalho real.
  4. 4Registro e, só então, o commit.
O branch e o commit vêm das aulas 11 e 12. Pelo app, peça cada passo ao assistente. O laboratório completo, com os comandos, está no material complementar.

Pratique agora 0/4

Uma mudança do piloto, com a revisão registrada

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

Revisão registrada

  1. Rotastroque quem faz e quem revisa; compare na sua tarefa.
  2. Decidircorrija com evidência, recuse com motivo.
  3. Arquivorevisao-etapa-N.md ao lado do código.

Seu próximo passo

Você já entrega mudanças com dois olhares e um registro que outra pessoa entende.

Releia o seu revisao-etapa-N.md amanhã. Se não entender algo, escreva mais uma linha.

No módulo 4: revisão feita. Mas a mudança funciona de verdade? Hora de comprovar e decidir.

Material complementar · O laboratório completo do móduloAprofundamento do tópico. Não conta no tempo da aula.

Uma mudança revisada, do começo ao fim

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.

  1. No branch de teste, peça a etapa com os critérios colados e a parada (aula 12).
  2. Confira no git status e anote o resultado de cada critério em conferencias.txt.
  3. Gere o pacote e peça a revisão só leitura (aula 13).
  4. Corrija ou recuse cada achado e registre no revisao-etapa-N.md.
  5. Confira de novo e faça o commit.
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

Cada critério pede uma verificação

Uma analista de operações liga a lápis, com setas, cada item de uma ficha de papel a uma linha de uma planilha impressa, para saber como vai conferir cada um.

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

  1. Cada critério ganha uma linha: como confiro e quem confere.
  2. Regra que se repete vira teste automático. Aparência e sentido ficam com a conferência manual.
  3. Teste que nunca falhou não prova nada. Peça para ver ele falhar antes.

1Critério sem verificação é enfeite

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.

briefing.md · como confiro
1 Mensagem chega na recepção → enviar pela página e olhar a caixa
2 Telefone recusa letras → teste automático
3 Não rola para os lados no celular → abrir no celular
  1. 1Conferência manual, feita por Rafael.
  2. 2Uma regra que se repete: o computador confere.
  3. 3Aparência: conferência manual.

2Automático para regra, conferência manual para sentido

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.

Teste automático

Regras que se repetem: soma, formato, campo obrigatório. Roda igual toda vez.

Conferência manual

Sentido, aparência, tom, o caminho do usuário. Precisa de alguém olhando.

Um critério bom diz qual dos dois vai conferi-lo.
Como Carla fez a célula de conferência

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.

3Você não precisa escrever o teste

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.

Assistente de código

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.

Toque ou clique nos dois botões do quadro e compare as duas respostas.

4Teste que nunca falhou não prova nada

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.

Sempre passou

"Confere" com os valores certos e também com um valor mudado de propósito.

O que prova: nada.

Já falhou uma vez

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

Como você vai conferir cada critério

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

Critério e verificação

  1. Como confirouma linha ao lado de cada critério.
  2. Automático ou manualregra que se repete × sentido e aparência.
  3. Ver falharum teste só vale depois de pegar o erro uma vez.

Seu próximo passo

Você já liga cada critério a uma verificação combinada.

Peça à IA o teste do critério que você marcou, com a saída antes e depois da correção.

Na próxima aula: o teste passou. Isso quer dizer que o sistema funciona na mão de quem usa?

Aula 16 · Dev com IA v6.2 · INEMA.CLUB

Módulo 4 · Aula 2 de 5

O teste passou. Agora use de verdade.

Um desenvolvedor, de pé junto à janela, preenche no celular o formulário do site como se fosse um paciente.

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

  1. Teste passando não quer dizer que o sistema funciona na mão de quem usa.
  2. Faça o caminho de quem usa, do começo ao fim, com dados de teste.
  3. Se a IA mexer na tela por você, senha, pagamento e envio ficam com você.

1Teste passando não é sistema funcionando

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.

Só o teste

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.

Caminho inteiro

O que Rafael fez: abriu no celular, preencheu como paciente e tentou enviar.

O que achou: o botão escondido, antes da clínica.

2Faça o caminho de quem usa

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.

Caminho do paciente · formulário da clínica
1 Abrir o site no celular, pelo link que a clínica divulga
2 Preencher nome, telefone e mensagem
3 Enviar
4 Olhar a caixa da recepção, inclusive o spam
  1. 1O mesmo aparelho e a mesma porta de entrada do paciente.
  2. 2Digitando, não colando.
  3. 3Até o fim, sem pular etapa.
  4. 4O resultado lá na ponta, não a tela de "enviado".

3Dados de teste, nunca dados reais

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.

Dado real

Nome e telefone de um paciente de verdade no formulário de teste.

Dado 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.

4Quando a IA usa a tela por você

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.

Assistente com uso do navegador

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

O caminho inteiro, uma vez

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

Caminho do usuário

  1. Além do testeo caminho inteiro pega o que a regra solta não vê.
  2. Mesmo aparelhoe dados de teste, com quem recebe avisado.
  3. IA na telaela prepara; senha, pagamento e envio são seus.

Seu próximo passo

Você já confere o piloto como o usuário vai usar.

Combine hoje com quem recebe os resultados do seu piloto um nome de teste, como "Paciente Teste".

Na próxima aula: você achou um problema. Quanto pedir para a IA mudar?

Material complementar · Uso supervisionado do computadorAprofundamento do tópico. Não conta no tempo da aula.

Nível 4 do kit Use Both

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

A menor correção, e uma linha para não repetir

Um desenvolvedor escreve uma única linha num caderno pautado, ao lado do notebook e de uma xícara de café, registrando uma falha que acabou de corrigir.

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

  1. Peça a menor correção que resolve, e diga o que não pode mudar.
  2. Registre a falha numa linha: data, o que quebrou, a correção, prompt ou infra.
  3. Depois de umas dez linhas, o padrão dos seus erros aparece sozinho.

1Corrija o que quebrou, não o sistema inteiro

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.

Refazer tudo

Pedido: "O formulário está ruim no celular, refaça."

Resultado: página nova, e os três critérios para conferir de novo.

Menor correção

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.

2O pedido de correção tem três partes

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.

Assistente de código

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.

3Uma linha no FALHAS.md

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.

FALHAS.md · pasta do piloto
1 | data | o que quebrou | menor correção | prompt ou infra |
2 | 28/09 | botão enviar sob o teclado no celular | botão visível com teclado aberto | prompt |
3 | 25/09 | envio não chegava na recepção | trocar o endereço de envio | infra |
  1. 1O cabeçalho, escrito uma vez.
  2. 2A falha de hoje, no topo.
  3. 3As antigas descem.

4Prompt ou infra: de onde veio o erro

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.

Prompt

"O pedido não dizia de qual data contar o prazo."

Infra

"O endereço de envio da clínica estava errado no provedor de e-mail."

A etiqueta mostra onde está o conserto: no jeito de pedir ou fora dele.

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

Sua primeira linha no FALHAS.md

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

Corrigir e registrar

  1. Menor correçãoa mudança mais curta que faz o critério voltar a passar.
  2. Pedido em três partesfalha com evidência, só o que corrigir, relato do que mudou.
  3. FALHAS.mddata, o que quebrou, correção, prompt ou infra.

Seu próximo passo

Você já corrige sem abrir uma reforma e guarda o que aprendeu.

Na próxima falha com IA, qualquer uma, escreva a linha antes de seguir para a tarefa seguinte.

Na próxima aula: e o erro que não sai em uma nem em duas tentativas?

Aula 18 · Dev com IA v6.2 · INEMA.CLUB

Módulo 4 · Aula 4 de 5

Erro difícil pede uma meta

Uma analista de operações examina com uma lupa uma planilha impressa, procurando um erro, com um cronômetro de mesa ao lado do notebook.

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

  1. Troque "resolve isso" por uma meta com sucesso observável: qual entrada, qual resultado.
  2. Dê limites no pedido: arquivos e tentativas. E um ponto de relato. A trava de tempo ou gasto fica fora da IA.
  3. Passou no critério, a IA para. Sem enfeite a mais.

1"Resolve isso" não tem fim

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.

Sem meta

"O total às vezes não bate. Resolve isso."

Meta

"Com as planilhas da semana 38, o total do relatório é igual à soma das planilhas. A célula de conferência mostra 'confere'."

2As três partes da meta

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.

meta.md · erro do total
1 Sucesso: semana 38 → total igual à soma; célula diz "confere"
2 Limites: só o arquivo juntar.py; 3 tentativas · trava: alarme de 30 min
3 Relato: ao passar ou ao bater o limite
  1. 1Você confere sem perguntar nada à IA.
  2. 2Limites no pedido; a trava fica fora da IA, como na aula 4.
  3. 3O que tentou, o que falhou, o que falta.

3Chegou: para. Não chegou: relata.

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.

Assistente de código

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.

4Modo de meta: tempo longo não é qualidade

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.

Com modo de meta

Mesma meta, mesmos limites, e uma trava de tempo ou gasto de verdade.

Sem modo de meta

Pedido comum com as mesmas três partes. Funciona em qualquer assistente.

O recurso muda o jeito de rodar. A meta continua sendo sua.

Pratique agora 0/3

Escreva a meta de um erro

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

Meta

  1. Sucesso observávelentrada, resultado esperado, como conferir.
  2. Limites, trava e relatoarquivos e tentativas no pedido, trava fora dele, e quando parar para contar.
  3. Duas saídaspassou, para; não passou, descreve o bloqueio.

Seu próximo passo

Você já sabe dar uma meta a um erro difícil.

Guarde o molde da meta no seu bloco de notas, pronto para o próximo erro que resistir a duas tentativas.

Na próxima aula: tudo conferido. Quem decide se o piloto entra, e com base em quê?

Material complementar · Meta com condição de paradaAprofundamento do tópico. Não conta no tempo da aula.

Nível 5 do kit Use Both

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

Quem decide o que entra é você

Uma analista de operações assina uma folha de aceite, ao lado das folhas conferidas e marcadas com vistos.

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

  1. Aceite é uma decisão com evidência, critério por critério.
  2. Evidência é o que você viu, não o que a IA disse.
  3. Três saídas: entra, entra com pendência registrada, ou volta.

1O aceite cabe numa ficha

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.

aceite.md · formulário da clínica
1 Mensagem chega na recepção → captura da caixa com "Paciente Teste" · ok
2 Telefone recusa letras → saída do teste: falhou antes, passou depois · ok
3 Não rola para os lados → captura do celular sem rolagem lateral · ok
4 Decisão: entra · Rafael · 28/09
  1. 1Evidência de conferência manual.
  2. 2Evidência de teste automático.
  3. 3O caminho de quem usa, da aula 17.
  4. 4A decisão, com nome e data.

2Evidência é o que você viu

"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.

Declaração

"O Codex revisou e disse que está tudo certo."

Evidência

"Célula de conferência: 'confere'. Lista de cidades lida por mim: nenhuma repetida."

3Três saídas, não duas

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.

Decisão do aceite
1 Entra: todos os critérios com evidência
2 Entra com pendência: falha pequena, escrita, com dono e prazo
3 Volta: critério importante sem evidência ou falhando
  1. 1Entrega normal.
  2. 2Entrega, e a pendência fica escrita no próprio aceite.md: o quê, quem, até quando.
  3. 3Menor correção e nova conferência, como na aula 18.

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.

4Ninguém assina por você

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".

O que ajuda a decidir

Testes, caminho de quem usa, revisão cruzada.

Quem decide

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

O aceite do seu piloto

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

Aceite

  1. Por critériocada linha com a evidência e o resultado.
  2. Evidênciao que você viu e outra pessoa pode olhar.
  3. Decisãoentra, entra com pendência, ou volta; com nome e data.

Seu próximo passo

Você já fecha uma entrega com decisão escrita e evidência de cada critério.

Mostre o aceite.md a alguém da sua equipe e pergunte se ele concordaria com a decisão só lendo o arquivo.

No módulo 5: amanhã, outra conversa ou outro assistente continua o piloto. Como passar o bastão sem explicar tudo de novo?

Aula 20 · Dev com IA v6.2 · INEMA.CLUB

Módulo 5 · Aula 1 de 5

Handoff: o estado num arquivo

No fim do dia, um desenvolvedor escreve uma folha curta de anotações e a deixa sobre o teclado do notebook antes de fechar.

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

  1. O handoff é a passagem de plantão: um arquivo curto no fim da sessão.
  2. Quatro partes: onde parou, decisões, pendências e próxima ação exata.
  3. Ele registra o que houve. Não é ordem para a IA sair fazendo.

1A conversa nova não lembra de nada

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".

Conversa nova, segunda-feira

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.

Toque ou clique nos dois botões do quadro e compare a mesma segunda-feira.

2As quatro partes de um handoff

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.

handoffs/latest.md · relatório de Carla
1 Onde parou: relatório da semana gerado na pasta "relatorios"
2 Decisões: cidades em ordem alfabética; planilhas originais não mudam
3 Pendências: total de pedidos ainda não conferido contra a soma
4 Próxima ação: somar a coluna de pedidos das 5 planilhas e comparar
  1. 1Onde está o trabalho, com o nome da pasta.
  2. 2O que não se discute de novo.
  3. 3O que ainda não foi conferido.
  4. 4Um passo só, que dá para fazer amanhã cedo.

3A próxima ação precisa ser exata

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.

Vaga

"Próxima ação: continuar o formulário."

Exata

"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.

4Peça o handoff à própria IA, e confira

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".

Fim da sessão

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

O handoff do seu piloto

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

Handoff

  1. Passagem de plantãoum arquivo curto no fim de cada sessão.
  2. Quatro partesonde parou, decisões, pendências, próxima ação.
  3. Registro, não ordemquem chega lê; não sai fazendo.

Seu próximo passo

Você já sabe fechar uma sessão sem perder o que foi combinado.

Na próxima sessão de trabalho com IA, peça o handoff antes de fechar e corrija uma linha que diga mais do que aconteceu.

Na próxima aula: o handoff está escrito. Como fazer a conversa nova ler e conferir antes de agir?

Aula 21 · Dev com IA v6.2 · INEMA.CLUB

Módulo 5 · Aula 2 de 5

Prime: ler e conferir antes de agir

De manhã, com uma xícara de café ao lado, uma analista de operações lê a folha de anotações deixada junto ao computador antes de começar.

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

  1. O prime é o primeiro pedido da sessão: leia os arquivos e me diga onde estamos.
  2. A resposta responde cinco perguntas, com o arquivo de cada resposta.
  3. Só leitura. Ninguém envia, publica ou apaga nada nessa etapa.

1O primeiro pedido é "leia e me diga"

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.

Conversa nova, segunda-feira

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.

2As cinco perguntas do prime

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 que o prime devolve
1 Objetivo e critérios de aceite
2 Uma regra, com o arquivo de origem
3 A última decisão tomada
4 A próxima ação exata
5 Contradições entre os arquivos
  1. 1Vem do briefing.md.
  2. 2Mostra se ele leu as regras, não só o handoff.
  3. 3Vem do handoff.
  4. 4Vem do handoff.
  5. 5É onde o prime mais ajuda.

3Prime só lê; quem decide o próximo passo é você

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".

Leu e saiu fazendo

"Vi no handoff que falta publicar. Publicando a página agora."

Leu, resumiu e esperou

"O handoff indica publicar a página como próxima ação. Aguardo a sua confirmação."

A frase "não altere nada" no prime separa ler de agir.

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.

4Contradição achada vale ouro

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.

Resposta do prime

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

Faça o prime do seu piloto

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

Prime

  1. Primeiro pedidoleia os arquivos, não altere nada, me diga onde estamos.
  2. Com fontecada informação do resumo aponta o arquivo.
  3. Espere a ordemo handoff é registro, não autorização.

Seu próximo passo

Você já confere o que a conversa nova entendeu antes de ela trabalhar.

Salve o pedido de prime num arquivo de texto na pasta do piloto, para colar sempre igual.

Na próxima aula: briefing, handoff, regras. Onde cada arquivo mora, e quem manda ler?

Aula 22 · Dev com IA v6.2 · INEMA.CLUB

Módulo 5 · Aula 3 de 5

O que importa mora no projeto, não na ferramenta

Uma analista de operações e uma colega organizam pastas de papel de cores diferentes num arquivo, com o notebook aberto na mesa.

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

  1. O que é seu vive em arquivos de texto na pasta do projeto.
  2. O AGENTS.md diz as regras e a ordem de leitura.
  3. Os nomes das pastas são combinados; quem pede a leitura é o AGENTS.md.

1Memória da ferramenta × arquivos do projeto

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.

Preso à ferramenta

Regras na memória de um assistente. Decisões espalhadas em conversas antigas.

Na troca: explicar tudo de novo.

No projeto

Regras, tarefa e handoff em arquivos de texto na pasta do piloto.

Na troca: o outro assistente lê os arquivos.

2Os arquivos mínimos

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.

Pasta do piloto de Carla
1 AGENTS.md
2 briefing.md
3 tasks
current.md
4 context
overview.md
5 handoffs
latest.md
  1. 1Regras estáveis e ordem de leitura.
  2. 2Objetivo, dentro e fora, critérios e limites (aula 5).
  3. 3A tarefa de agora e o que falta.
  4. 4Fatos conferidos do projeto, com a fonte.
  5. 5A passagem de plantão (aula 21).

3Quem pede a leitura é o AGENTS.md

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.

AGENTS.md · site da clínica
1 Ordem de leitura: briefing.md, tasks/current.md, handoffs/latest.md
2 Regra: não alterar a página inicial nem as cores
3 Regra: nada vai ao ar sem a aprovação do Rafael
4 CLAUDE.md, ao lado, com uma linha: @AGENTS.md
  1. 1O que ler, e em que ordem.
  2. 2O "Fora" que vale para todas as tarefas.
  3. 3A decisão final é humana.
  4. 4Assim o Claude Code lê o mesmo arquivo.

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.

4Cada arquivo tem um dono

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.

Você decide

AGENTS.md, briefing.md e as decisões. A IA pode sugerir mudança; quem aprova é você.

A IA escreve, você confere

handoffs/latest.md no fim da sessão, e o andamento em tasks/current.md.

Os dois cartões convivem: um guarda o que é estável, o outro registra o dia a dia.

Pratique agora 0/3

Monte o núcleo do seu piloto

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 cérebro no projeto

  1. Arquivos de textoo que é seu fica na pasta, não na ferramenta.
  2. AGENTS.mdregras e ordem de leitura; o CLAUDE.md aponta para ele.
  3. Donosvocê decide as regras; a IA escreve o handoff.

Seu próximo passo

Você já montou o núcleo que torna o piloto independente de um assistente só.

Leia o AGENTS.md que você escreveu como se fosse outra pessoa. Tire uma regra que só você entende.

Na próxima aula: com tudo nos arquivos, passar o piloto de um assistente para outro sem recomeçar.

Material complementar · Migrar ou ficar agnósticoAprofundamento do tópico. Não conta no tempo da aula.

O núcleo completo

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).

Separar fato, preferência, hipótese e decisã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.

Migrar tudo de um assistente para outro

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

Trocar de assistente sem recomeçar

Um desenvolvedor fecha um notebook e trabalha no outro, com a pasta de anotações do projeto aberta entre os dois, como quem passa o trabalho adiante.

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

  1. No assistente que sai: handoff. No que entra: prime.
  2. Antes de deixar trabalhar, confira as cinco perguntas do prime (aula 22).
  3. Resposta errada no prime quase sempre é arquivo vago. Corrija o arquivo.

1A troca vai acontecer

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.

Recomeçar explicando

Contar o projeto de memória ao novo assistente. Uma hora, e duas regras esquecidas.

Handoff e prime

O novo lê os arquivos, resume com as fontes, e Rafael confere. Dez minutos.

2O caminho da troca, em quatro passos

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.

Trocar de assistente
1 No que sai: pedir o handoff e conferir
2 No que entra: prime, sem alterar nada
3 Conferir o resumo com as cinco perguntas
4 Só então: "pode seguir com a próxima ação"
  1. 1Aula 21.
  2. 2Aula 22.
  3. 3As mesmas cinco da aula 22.
  4. 4A ordem de trabalhar é sua.

3O prime também roda no terminal, só lendo

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.

Terminal · pasta do piloto
$ 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.

No app ou na extensão, o mesmo pedido de prime da aula 22 faz o papel desse comando.
E no Claude Code, pelo terminal?

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.

4As cinco perguntas antes de deixar trabalhar

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.

As cinco perguntas do prime
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?
  1. 1Confere com o briefing.md.
  2. 2Confere com o AGENTS.md.
  3. 3Confere com o handoff.
  4. 4Confere com o handoff.
  5. 5Se houver, você decide qual vale.

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

Passe o piloto para outro assistente

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

Trocar sem recomeçar

  1. Sai e entrahandoff em quem sai, prime em quem entra.
  2. Cinco perguntasobjetivo, regra, decisão, próxima ação, conflito.
  3. Resposta erradacorrija o arquivo, não o assistente.

Seu próximo passo

Você já passa o trabalho de um assistente para outro e confere que ele entendeu.

Na próxima vez que o aviso de limite aparecer, faça a troca pelos quatro passos em vez de esperar o limite voltar.

Na próxima aula: uma segunda opinião dentro do mesmo assistente, e o laboratório que fecha o ciclo.

Aula 24 · Dev com IA v6.2 · INEMA.CLUB

Módulo 5 · Aula 5 de 5

Segunda opinião e o ciclo handoff → prime

Um desenvolvedor e uma analista de operações sentados lado a lado: ela lê em voz alta uma folha de anotações enquanto ele confere no notebook.

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

  1. Conversa nova + prime + "aponte falhas" = segunda opinião no mesmo assistente.
  2. No Claude Code há o /advisor, que cobra à parte. Confira antes de usar.
  3. O ciclo diário: sessão, handoff, prime, conferir.

1Segunda opinião dentro do mesmo assistente

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.

Conversa nova, depois do prime

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.

2O /advisor do Claude Code: saiba o que ele faz antes

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.

Funciona em qualquer um

Conversa nova, prime com os arquivos, pedido de falhas com evidência.

Só no Claude Code, com custo

O /advisor: um modelo mais forte consultado durante a sessão, cobrado à parte. Confira o custo antes.

Comece pelo cartão "Funciona em qualquer um". O outro entra quando o custo valer a pena.

3O ciclo diário

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.

O ciclo diário
1 Sessão: trabalhar na próxima ação
2 Handoff: gravar e conferir handoffs/latest.md
3 Prime: conversa nova lê e resume, sem alterar nada
4 Conferir: cinco perguntas, e só então trabalhar
  1. 1O trabalho em si.
  2. 2Antes de fechar, sempre.
  3. 3Ao abrir, sempre.
  4. 4Volta para o 1.

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.

4O laboratório: o ciclo no seu piloto

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.

Sem o ciclo

Cada segunda começa com "onde eu estava mesmo?", e a IA repete perguntas.

Com o ciclo

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

Laboratório: feche o ciclo no piloto

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

Ciclo e segunda opinião

  1. Segunda opiniãoconversa nova, prime e pedido de falhas com trecho.
  2. Comando novoconfira no seu assistente antes de usar.
  3. Ciclo diáriosessão, handoff, prime, conferir.

Seu próximo passo

Você já trabalha com IA sem depender da memória de uma conversa ou de uma ferramenta.

Amanhã, abra o dia com o prime do piloto e cronometre quanto tempo leva até a primeira ação.

No módulo 6: quanto custou tudo isso? Modelo, esforço e orçamento por etapa.

Material complementar · Handoff e prime nos kitsAprofundamento do tópico. Não conta no tempo da aula.

Nível 6 do Use Both

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 /advisor no Claude Code

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

Escolha pela tarefa, não pelo ranking

Um desenvolvedor compara duas respostas impressas sobre a mesa, com a ficha de critérios ao lado, marcando com caneta o que passou em cada uma.

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

  1. Ranking é média de muitas tarefas. A sua é uma só.
  2. Compare com a mesma tarefa, o mesmo briefing e a mesma régua.
  3. Conte os critérios que passaram, não o tom da resposta.

1Ranking não responde a sua pergunta

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.

A pergunta que você faz

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.

Toque ou clique nos dois botões do quadro e compare as duas perguntas.

2Mesma tarefa, mesmo briefing, mesma régua

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.

Comparação da Carla
1 Mesmo pedido: briefing.md do relatório semanal
2 Mesmo material: cópia das planilhas da semana
3 Mesma régua: os três critérios de aceite
4 Muda só: o modelo, na mesma ferramenta
  1. 1O mesmo arquivo para os dois.
  2. 2Uma cópia para cada, para um não mexer no do outro.
  3. 3Escrita antes de ver as respostas.
  4. 4A única diferença entre as duas rodadas.

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.

3Conte os critérios, não o tom

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.

Mais bonita

Aparência: gráfico, títulos, resumo elegante.

Régua: 2 de 3. Uma cidade aparece duas vezes.

Passou na régua

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.

4A escolha vale para aquela tarefa, com data

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.

O que anotar

28/09/2026 · formulário de contato · modelo A 3 de 3, modelo B 2 de 3 · fica o A.

Quando refazer

Modelo novo, preço novo ou tarefa de outro tipo.

Uma linha por comparação já vira histórico.

Teste-se

Carla quer saber qual modelo usar no relatório semanal. O que ela faz primeiro?

Pratique agora 0/3

Qual modelo fica com esta tarefa?

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.

Ver gabarito

1. A: 2 de 3. B: 3 de 3. 2. Não foi justa: o pedido do B era diferente. 3. Repete o teste do A com o mesmo pedido do B, compara de novo e só então anota a linha com a data.

Você já compara modelos pela régua da sua tarefa, não pela fama.

Cola da aula

Escolher modelo

  1. Sua tarefao ranking é média; a pergunta é a sua.
  2. Uma diferençamesmo briefing e material, muda só o modelo.
  3. Com dataanote a escolha e refaça quando algo mudar.

Seu próximo passo

Você já escolhe o modelo com evidência da sua própria tarefa.

Crie o arquivo escolhas.md na pasta do piloto e escreva a primeira linha, mesmo que seja só do modelo que usou até agora.

Na próxima aula: dentro do mesmo modelo há outro controle, o esforço. Quando vale subir, e quando é desperdício?

Material complementar · Rota inicial, não rankingAprofundamento do tópico. Não conta no tempo da aula.

O que as fontes dizem

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

Esforço alto onde pesa, baixo onde é rotina

Uma analista de operações cola adesivos de três cores numa folha com cinco etapas desenhadas, marcando quanto esforço cada etapa merece.

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

  1. Esforço é um controle diferente do modelo: quanto ele pensa antes de responder.
  2. Planejar e resolver problema difícil pedem médio ou alto. Rotina pede menos.
  3. Mais esforço não traz o arquivo que faltou.

1Modelo e esforço são dois controles

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.

Modelo

Qual IA faz o trabalho. Troca quando a comparação da aula 26 mostra que outra entrega melhor.

Esforço

Quanto ela analisa. Sobe e desce a cada etapa, no mesmo modelo.

Dois botões diferentes. A aula de hoje é sobre o segundo.

2Onde subir: planejar, problema difícil, revisão pesada

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.

Ciclo do piloto · esforço por passo
1 Definir o briefing: você escreve; a IA só revisa, em médio
2 Planejar e criticar: médio ou alto
3 Construir: médio; partes repetitivas, baixo
4 Revisar e comprovar: médio; mudança grande, alto
5 Registrar o handoff: baixo
  1. 1O critério é seu; a IA só aponta furos.
  2. 2Um plano ruim estraga todo o resto.
  3. 3Siga o plano; suba só se travar.
  4. 4Quanto maior a mudança, mais esforço na revisão.
  5. 5Resumir o que já existe é rotina.

3Onde baixar, e onde o esforço não ajuda

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.

Esforço máximo, sem a planilha

Pedido: "Pense com calma e refaça o relatório."

Resultado: demorou o triplo e o total continuou errado.

Esforço médio, com a planilha

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.

4Onde se escolhe o esforço

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.

Onde fica o controle
1 App ou extensão: perto do nome do modelo, quando existe
2 Chat: "raciocínio", "pensar mais" ou "pensamento estendido"
3 Terminal: no próprio comando, como no quadro abaixo
  1. 1Às vezes são níveis; às vezes, um menu.
  2. 2Muitas vezes é só liga ou desliga.
  3. 3O nível vai escrito junto com o pedido.
Não achou o controle? A ferramenta decide sozinha. Vale o resto da aula: material antes, régua depois.
Terminal
$ 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).

O mesmo modelo, dois esforços, cada um na etapa que pede.

Teste-se

A IA errou o total do relatório. Antes de subir o esforço, o que você confere?

Pratique agora 0/3

O esforço de cada passo do seu piloto

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 | < > | < >
Ver gabarito

Uma resposta razoável: briefing médio (só revisão); planejar e criticar alto (um plano ruim estraga o resto); construir médio; revisar médio, alto se a mudança for grande; handoff baixo. O passo 4 é bom para conferir o material: faltou arquivo? Arrume antes de subir o esforço.

Você já distribui o esforço pelas etapas, em vez de um botão fixo para tudo.

Cola da aula

Esforço por etapa

  1. Dois controlesmodelo é qual IA; esforço é quanto ela analisa.
  2. Sobeno plano, no problema difícil e na revisão grande.
  3. Material antesesforço não substitui o arquivo que faltou.

Seu próximo passo

Você já escolhe o esforço pela etapa, não pelo hábito.

No próximo pedido de rotina, baixe o esforço um nível e confira pelos critérios se a entrega continuou igual.

Na próxima aula: quanto custou cada etapa do seu piloto, em tempo e em uso da conta?

Material complementar · O que a síntese diz sobre esforçoAprofundamento do tópico. Não conta no tempo da aula.

Esforço, segundo as fontes

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

Custo sem resultado não diz nada

Um desenvolvedor anota numa caderneta o tempo e o consumo de uma etapa, com um cronômetro de mesa ao lado do notebook.

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

  1. Por etapa, anote: tempo seu, uso da conta e problemas achados.
  2. O seu tempo conta, inclusive o de conferir.
  3. Problema achado antes da entrega é o resultado que o custo comprou.

1Uma linha por etapa

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.

piloto-custos · colunas
1 Etapa
2 Modelo e esforço
3 Tempo seu (min)
4 Jeito antigo (min)
5 Uso antes
6 Uso depois
7 Problemas achados (por quem)
8 Critérios que passaram
  1. 1Qual passo do ciclo.
  2. 2Com que configuração.
  3. 3Pedir, esperar, ler e conferir.
  4. 4Quanto levaria sem IA; estimativa vale, marcada "estimado".
  5. 5O que a página de uso mostra antes.
  6. 6E depois da etapa.
  7. 7Revisão, teste ou você.
  8. 8Quantos de quantos.

2O seu tempo entra na conta

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.

Só a espera

Anotado: 3 minutos.

Conclusão: "a IA faz o relatório em três minutos".

Do pedido à conferência

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".

3Uso da conta: a página de uso antes e depois

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.

Linha do Rafael · crítica do plano

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.

4Problema achado é o resultado

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.

Custo

Tempo seu e uso da conta em cada etapa.

Resultado

Problemas achados antes da entrega, critérios que passaram.

Uma etapa cara que achou dois erros pode valer mais que uma barata que não achou nada.

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

A planilha de custos do seu piloto

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

Medir o piloto

  1. Na horauma linha por etapa, logo que ela termina.
  2. Seu tempodo pedido até a conferência.
  3. Resultadoproblemas achados antes da entrega, e por quem.

Seu próximo passo

Você já mede o piloto com números, não com impressão.

Na próxima tarefa com IA, anote o horário de início e o de fim da conferência. Leva dez segundos.

Na próxima aula: o preço e o limite da sua conta mudam. Onde conferir, e o que muda entre assinatura e pagamento por uso?

Aula 28 · Dev com IA v6.2 · INEMA.CLUB

Módulo 6 · Aula 4 de 5

Preço e limite mudam: confira na sua conta

Uma analista de operações, pensativa, confere no notebook as configurações da conta de IA, com a pilha de faturas do mês ao lado.

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

  1. Assinatura: valor fixo, com limite de uso por período. Por uso: paga pelo que consome.
  2. Anote o tipo, o limite, onde viu e a data. Nunca a senha ou a chave.
  3. OpenRouter e modelos abertos são opções a conferir, não receita.

1Assinatura e pagamento por uso

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.

Assinatura

Paga: valor fixo por mês.

Limite: uso por período; acabou, espera ou compra extra, se o plano oferecer.

Por uso

Paga: pelo que consome.

Limite: o teto de gasto, se você definir.

Nenhum dos dois é melhor em geral. Depende do volume e de quem usa.

2Uma ficha da conta, com data

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.

conta-ia.md · ficha da Carla
1 Serviço: Codex, pela conta da empresa
2 Tipo: assinatura
3 Limite: "40% da semana usados, renova segunda"
4 Onde vi: configurações da conta › Uso · 28/09/2026
5 Senha e chave: nunca aqui
  1. 1Qual serviço e de quem é a conta.
  2. 2Assinatura ou por uso.
  3. 3Copie o que está escrito lá, sem interpretar. Se só aparece percentual, anote assim.
  4. 4Onde e quando você conferiu.
  5. 5Credencial fica no gerenciador de senhas.

3OpenRouter e modelos abertos: confira antes

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.

Trocar pelo preço

"Esse é mais barato, vou usar." Sem teste, sem saber para onde vão os dados.

Conferir antes

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.

4"A IA vai ficar mais cara" é hipótese

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.

Decidir pela previsão

"Vai encarecer, então uso o mínimo em tudo."

Decidir pela medida

"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

A ficha da sua conta

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

Conta e preço

  1. Tipoassinatura com limite por período, ou pagamento por uso com teto.
  2. Ficha datadao que a conta mostra hoje; credencial nunca.
  3. A conferirOpenRouter, modelos abertos e previsões de preço.

Seu próximo passo

Você já confere preço e limite na fonte, não no que ouviu falar.

Ponha um lembrete para daqui a um mês: reabrir a página de uso e atualizar a ficha.

Na próxima aula: com custo, resultado e conta na mão, decidir se o piloto vira rotina.

Material complementar · O que a síntese marca como "a conferir"Aprofundamento do tópico. Não conta no tempo da aula.

Orientação adicional

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.

Sobre o preço futuro

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

Ampliar, ajustar ou parar: a decisão do piloto

Um desenvolvedor e uma analista de operações conversam numa pequena mesa de reunião diante do relatório de uma página do piloto, decidindo o próximo passo.

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

  1. Relatório de uma página: tarefa, critérios, problemas achados, custo e decisão.
  2. Três saídas possíveis: ampliar, ajustar ou parar. Todas são resultado.
  3. A decisão é sua, com data e com a próxima revisão marcada.

1O relatório cabe numa página

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.

relatorio-piloto.md · Rafael
1 Tarefa: formulário de contato da clínica
2 Critérios: 3 de 3 passaram no teste
3 Problemas achados: 2 na crítica do plano, 1 no teste
4 Custo: tempo e uso da conta, da planilha piloto-custos
5 Comparação: o mesmo tipo de tarefa feito do jeito antigo
6 Decisão e data da próxima revisão
  1. 1Do briefing.md.
  2. 2Do aceite do módulo 4.
  3. 3Da planilha, coluna de problemas.
  4. 4Da planilha da aula 28.
  5. 5Da coluna "Jeito antigo (min)" da planilha; estimativa vale, marcada "estimado".
  6. 6O que esta aula ensina a escrever.

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.

2Três saídas, todas legítimas

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.

Quando escolher cada saída
1 Ampliar: critérios passaram e o custo cabe na conta
2 Ajustar: passou, mas uma etapa custou sem achar nada
3 Parar: não passou, ou custou mais que o jeito antigo
  1. 1Mais tarefas do mesmo tipo.
  2. 2Mude uma coisa e repita.
  3. 3Registre o porquê e siga sem culpa.

3A decisão é sua, com data

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."

Sem decisão

"O piloto foi interessante, vamos ver."

Depois de um mês: ninguém lembra o que foi medido.

Decisão escrita

"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.

4Para onde ir depois

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.

Próximos caminhos
1 Use Both: seis níveis e prompts prontos
2 claudex: debate automático de um plano grande (terminal)
3 Claude → Codex: contexto portátil em arquivos
  1. 1Para quem quer aprofundar o uso dos dois juntos.
  2. 2Para quem planeja coisas grandes com frequência.
  3. 3Para quem troca de assistente ou trabalha em equipe.

Pratique agora 0/4

O relatório e a decisão do seu piloto

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

Fechar o piloto

  1. Uma páginatarefa, critérios, problemas, custo, comparação e decisão.
  2. Três saídasampliar, ajustar ou parar, todas com motivo.
  3. Revisão marcadaa decisão tem data para ser revista.

Seu próximo passo

Você terminou o curso com um método testado na sua própria tarefa: um faz, o outro confere, e você decide.

Mostre o relatório do piloto a uma pessoa da sua equipe ou a um cliente. Leva cinco minutos e testa se ele se explica sozinho.

Continua no Use Both, no claudex e no curso Claude → Codex.

Aula 30 · Dev com IA v6.2 · INEMA.CLUB