🪞 Computer use assistindo computer use
O autor mostra um app que ele mesmo construiu, com vários agentes conectados a assinaturas e provedores de modelo, cada agente podendo ter o próprio computador. "De todos os recursos, o computer use é o mais fraco, porque é o mais difícil de ensinar a um agente completamente cru." A saída: mandar o Codex abrir o app, pedir uma tarefa de navegador ao agente interno e assistir.
💡 Onde isso se aplica além do vídeo
Qualquer app com um agente dentro: um assistente de atendimento, um bot de pesquisa, um painel com "pergunte à IA". O fluxo é o mesmo: tarefa pequena e só de leitura, observação externa, ponto de falha, código, reteste.
📝 O prompt 03, traduzido
Copie e rode
Testar o agente do seu app pela interface, ligar a falha ao código e retestar (Codex com computer use; app e checkout do código na mesma versão; ambiente isolado)
Teste meu app pela interface real dele, incluindo o próprio recurso de computer use.
App: <NOME_OU_CAMINHO_DO_APP>
Repositório correspondente: <CAMINHO_DO_REPO>
Tarefa de navegador: <TAREFA_PEQUENA_SO_DE_LEITURA>
Fonte para conferir: <URL_PUBLICA>
Critérios de sucesso: <CONDICOES_OBSERVAVEIS_DE_APROVACAO>
Abra uma conversa de teste limpa no app correto. Peça ao agente do app que execute a tarefa de navegador usando a capacidade de computer use dele. Observe as ações e a saída das ferramentas. Não substitua a navegação do app pela sua e depois marque o app como aprovado.
Confira um fato devolvido contra a fonte pública. Feche e reabra a conversa para testar persistência. Capture o ponto exato de falha se a tarefa travar, perder contexto, usar a janela errada ou devolver uma afirmação sem suporte.
Se falhar, reproduza a falha e verifique que o checkout fornecido compila este app. Na cópia local de desenvolvimento, corrija a menor causa, rode os testes relevantes, recompile ou relance conforme necessário e repita o teste de interface idêntico. Preserve trabalho não relacionado. Limite esta execução a três tentativas de reparo; se ainda falhar, devolva a evidência e o próximo passo de diagnóstico.
Devolva comportamento antes/depois, arquivos alterados, resultados de teste, qualquer falha restante e um pedido reproduzível. Não faça deploy público, não acesse conversas privadas, não faça compras nem envie mensagens externas.| Marcador | No vídeo | No seu caso |
|---|---|---|
| TAREFA_PEQUENA_SO_DE_LEITURA | Uma busca no Google Flights usando "suas habilidades de computador" | Algo que termina em minutos e não muda nada: consultar, comparar, ler. |
| URL_PUBLICA | A página do Google Flights com o resultado | Um lugar público onde um fato da resposta pode ser conferido. |
| CONDICOES_OBSERVAVEIS | "O agente do app navega, devolve um voo com preço, e a conversa reaberta mantém o resultado" | Três a cinco condições visíveis. Nada de "funciona bem". |
⚠️ Versão do app e do código têm que bater
O prompt pede "verifique que o checkout fornecido compila este app". Se o código é de uma versão e o app instalado é de outra, o reparo corrige uma linha que o app em teste não tem, e o reteste passa ou falha por motivo errado.
🚫 Não substitua o trabalho do app
"Do not substitute your own browsing for the app's work and then mark the app as passing." O Codex tem o próprio computer use e é melhor nele do que o app em teste. É exatamente por isso que a tentação existe. O prompt fecha essa porta.
✓ Comportamento correto do observador
- ✓Envia a tarefa ao agente do app e espera.
- ✓Descreve cada ação que o app fez ("abriu nova aba", "digitou a rota", "parou no seletor de datas").
- ✓Quando o app trava, registra o ponto e para: não completa.
- ✓Usa o painel do próprio app (o vídeo cita um componente para "espiar" as ações) como fonte das observações.
✗ Encenação que reprova o teste
- ✗O observador abre o navegador dele, faz a busca e cola o resultado na conversa do app.
- ✗Relatório com "a busca foi concluída" sem dizer quem concluiu.
- ✗"O app teve dificuldade, então eu terminei para verificar o resto do fluxo."
- ✗Marcar aprovado com base no resultado final, ignorando que o app não chegou lá.
🧐 Como saber, lendo o relatório
- •Toda ação tem sujeito: "o agente do app clicou", nunca "cliquei".
- •As falhas têm ponto exato, não desfecho: "travou ao tentar selecionar a data de volta", não "não deu certo".
- •Se o observador fez algo, foi antes (abrir o app, criar a conversa) ou depois (conferir o fato na fonte), nunca no meio da tarefa.
💾 Persistência: fechar e reabrir
A sequência de persistência
Terminar (ou travar) a tarefa
Registrar o estado final da conversa: o que o app respondeu, o que ficou na tela.
Fechar a conversa
Fechar de verdade, não minimizar. Se o app tem "sessões", sair da sessão.
Reabrir a mesma conversa
Pelo histórico do app. Não criar uma nova.
Comparar
O resultado está lá? O agente lembra do que fez? Uma pergunta de follow-up funciona?
📊 Por que o app do vídeo falhou
- •O agente interno usava um modelo mais antigo, com janela de contexto menor.
- •O app não tinha um recurso de compactação da conversa: quando o histórico de ações de computer use cresceu, estourou.
- •O Codex viu a falha "muito rapidamente" e o autor conclui: com um objetivo declarado, ele "veria a falha, ajustaria o código, relançaria e repetiria o ciclo até melhorar".
💡 Duas causas comuns de falha de persistência
Histórico de computer use é pesado (cada passo carrega uma imagem). Apps que não resumem ou descartam capturas antigas estouram o contexto. E apps que guardam o estado só em memória perdem tudo ao fechar. As duas aparecem neste teste e não aparecem em nenhum log.
🔧 O ciclo de reparo com teto de três tentativas
| Seção do relatório | O que precisa ter |
|---|---|
| Antes / depois | O comportamento observado na interface nas duas rodadas, com o ponto exato de falha da primeira. |
| Arquivos alterados | Lista curta. Se for longa, a "menor causa" não foi respeitada. |
| Resultados de teste | Os testes relevantes que rodaram, e o resultado. Não "todos os testes", que pode levar horas. |
| Falha restante | Se após três tentativas ainda falha: a evidência e o próximo passo de diagnóstico, não uma quarta tentativa. |
| Pedido reproduzível | O prompt exato para repetir o teste amanhã, com o app relançado. |
⚠️ Os quatro "não" do reparo
Não faça deploy público. Não acesse conversas privadas do app. Não faça compras. Não envie mensagens externas. O ambiente é isolado por isso: o reparo acontece na cópia de desenvolvimento e o resto do mundo não fica sabendo até você decidir.
🌙 Rodar de madrugada, e o que fazer quando o app não tem agente
"Na verdade eu iria querer que isso rodasse por horas, talvez com algo como um comando de objetivo, e acordar com uma série de bugs identificados e corrigidos." O prompt do kit é o que torna isso seguro: objetivo observável, teto de três tentativas por falha, sem deploy, e relatório com pedido reproduzível.
Objetivo, não tarefa
"Fazer o computer use do app completar a busca de voo e persistir ao reabrir" é um objetivo. O agente decide quais falhas atacar, dentro do teto.
Teto por falha
Três tentativas por falha, não três no total. Uma falha resistente vira "evidência e próximo passo" e o agente segue para a próxima.
O que você lê de manhã
Uma lista: falha, ponto exato, causa, arquivos, teste que passou, ou "não resolvido, próximo passo". Nada de "melhorei o app".
✓ App sem agente: a jornada de usuário
- ✓Criar um rascunho de projeto.
- ✓Salvar.
- ✓Fechar o app.
- ✓Reabrir e confirmar que o rascunho está lá, com o mesmo conteúdo.
✗ O que não serve como jornada
- ✗"Navegar pelo app e ver se está tudo bem."
- ✗"Testar todas as telas."
- ✗Uma jornada que muda dados de produção.
- ✗Uma jornada sem estado para persistir (nada para reabrir e conferir).
💡 Regra do "make it yours" do guia
Para um app sem agente, troque a tarefa de navegador por uma jornada concreta com começo, meio e algo para reabrir. O resto do prompt (observar, ponto de falha, reparo com teto, mesmo teste) fica igual.
🧪 Teste rápido do módulo
Três perguntas. Clique numa opção para ver a resposta.
1. O agente do seu app travou na seleção de datas. O Codex abriu o próprio navegador, terminou a busca e marcou o app como aprovado. O que está errado?
2. Após três tentativas de reparo, o app ainda falha. O que o agente faz?
3. O reparo passou num teste ligeiramente diferente do original (tarefa mais curta). Vale?
📋 Resumo do módulo
Próximo módulo:
2.4 - A entrega da edição