Como criar um App de Bolão da Copa com IA sem saber programar

Chegou a hora de criar aquele aplicativo pra você gerenciar os palpites da Copa do Mundo com a família, os amigos e a galera da empresa. E eu vou fazer isso ao vivo, do zero, sem escrever uma linha de código — só conversando com a IA. Dá pra criar um aplicativo funcional com IA sem saber programar: o segredo não é dominar código, é aprender a conversar, planejar e dirigir a IA. É justamente por não fazerem isso que a maioria das pessoas e empresas trava na hora de tirar um projeto de IA do papel. O detalhe é que essa é a versão 2. A versão 1 eu fiz antes, levou umas três horas e meia, e não ficou boa: ficou complexa demais, com funcionalidade demais. Eu adiei o lançamento de propósito, justamente pra te ensinar o que importa. O segredo de um app simples não está no código — está em pensar em quem vai usar. Se a sua vó não conseguir usar, ele não está pronto.

O app é um HTML autocontido: um arquivo só, com HTML, CSS e JavaScript tudo dentro, zero dependência externa, que funciona offline e salva os dados no localStorage do navegador. HTML autocontido é aquele app de arquivo único que roda sem internet, sem servidor e sem banco de dados, e que você compartilha mandando um arquivo só. O nome já entrega o propósito: é fácil de mandar pelo WhatsApp e qualquer um abre.

A primeira coisa que eu faço quando vou construir algo com IA é abrir uma conversa, não pedir a execução. A instrução número um é literalmente: "vamos conversar, não crie nada". Isso serve pra conter a ansiedade natural da IA — ela sempre quer completar a missão e sai construindo antes da hora. Trate a IA como um colega genial sentado do seu lado: você não vomita todas as informações de uma vez, você conversa de forma pausada, organizada e autoriza ele a dar opinião. Esse jeito de conversar, planejar e dirigir agentes de IA em linguagem natural — mesmo sem saber programar — é o que eu venho organizando ao longo dos anos e que eu chamo de Método Prompthen: porque, se você só pega um prompt pronto e cola, por melhor que seja o resultado, você não aprende a criar o seu, e é aprendendo a criar o seu que você se multiplica com a IA.

Depois da conversa vem a parte onde você mais gasta tempo: o planejamento. A IA é péssima de planejar — é justamente aí que entra o humano. Você conversa até amarrar cada ponta e transforma isso num arquivo de spec (de especificação), salvo em Markdown, porque é um documento pra humano ler e editar. Esse arquivo tem duas vantagens enormes: se a janela de contexto acabar, o plano continua salvo; e você pode mandar um agente auditar item por item da spec contra o que foi implementado — pra achar código morto, coisa pulada ou coisa quebrada.

A grande sacada técnica é usar subagentes. O agente coordenador só delega e lê o resultado curto; cada subagente tem a própria janela de contexto e gasta os tokens lá, não na janela do coordenador. No exemplo real desse vídeo, o desenvolvedor gastou 172 mil tokens, o investigador 174 mil e o Guardian 300 mil — quase 900 mil tokens no total que não entupiram a janela do coordenador. Não é prova de competência, é dimensão de escala: mostra o tamanho do trabalho que dá pra rodar quando você aprende a coordenar em vez de fazer tudo sozinho. E pra forçar a qualidade, eu uso três palavras-chave o tempo todo: sem pontas soltas, proibido dedução, proibido preguiça — porque, se você tem preguiça de planejar, a IA também vai ter.

Pra fechar, eu rodei tudo isso em dois modelos ao mesmo tempo: Claude Code com Opus, com o meu setup completo de subagentes, e Kimi K2.7, com a função de enxame de subagentes ligada, mas deixado bem mais largado de propósito. Os dois entregaram um app funcionando. O melhor modelo não é o mais famoso nem o que você "torce" — é o que resolve o seu problema dentro do seu orçamento. É por isso que essa comparação está aqui: não pra dizer qual modelo é o rei, mas pra provar que o método funciona em qualquer um deles. Abaixo eu deixei a aula inteira, reorganizada e limpa, com o passo a passo completo — da conversa inicial ao app rodando.

Transcrição da aula

O que a gente vai construir (e por que a vó tem que conseguir usar)

Chegou a hora de criar aquele aplicativo pra você gerenciar os palpites da Copa do Mundo com os amigos, a família e a galera da empresa. É um app bem simples, e o método que eu vou explicar aqui qualquer um consegue aplicar. Mais importante: ele é replicável pra você desenvolver qualquer outra coisa depois.

Quando você precisa fazer um aplicativo simples, que seja fácil de compartilhar pelo WhatsApp ou por qualquer outro lugar, o caminho é fazer um app em HTML autocontido. É isso que a gente vai fazer aqui.

Eu vou te mostrar primeiro a versão 1, que não ficou boa. A gente vai refazer a versão 2 do zero. Aquela primeira eu fiz de teste, só pra estipular quanto tempo o app levaria — e vi que levou tempo demais. Ficou funcionalidade demais, inclusive com algumas informações erradas. A ideia é que a versão 2 fique bem mais intuitiva. Porque, pra esse app ficar bom mesmo, a tua vó tem que conseguir usar.

O segredo de um app simples não está no código — está em pensar em quem vai usar. Se a sua vó não conseguir usar, ele não está pronto.

No app você tem o chaveamento (a tabela de mata-mata), que vai se preenchendo conforme você lança os resultados dos jogos. Você lança os palpites — os seus, dos amigos, dos familiares — e ele monta um ranking. E claro que você precisa de um organizador.

Funciona assim, de um jeito bem simples: existe um organizador, digamos que seja você, que lança os placares. Quem sabe mexer um pouquinho mais no celular vai lá, faz os próprios palpites, exporta uma informaçãozinha e te manda — você importa e pronto, os palpites da pessoa estão ali. E se você tem um familiar que quer participar mas não vai saber exportar, abrir nem lançar os jogos, ele te passa os palpites por texto ou verbalmente, e você mesmo lança em nome dele. Simples assim.

A minha ideia, como quem me acompanha já sabe, é ensinar IA de um jeito que qualquer um consiga aplicar. Seja pra uma brincadeira como essa, seja pro trabalho, seja pro que for. Compartilha esse conteúdo com aquele amigo que você quer ajudar a entender como usar IA no dia a dia pra se tornar mais produtivo.

As duas etapas: primeiro conversar, depois construir

Pra facilitar, a gente divide isso em duas etapas. A primeira é a chamada da IA pra conversar. Quando você vai desenvolver alguma coisa, pensa assim: antes de pedir pra IA fazer, você precisa dar a ela a oportunidade de ter uma conversa com você sobre aquilo — e deixar claro que você está autorizando ela a dar opinião. Isso é muito importante.

Então a primeira informação que você dá pra ela é mais ou menos essa: "vamos conversar, não crie nada, eu quero te explicar uma ideia". Ele confirma, fala que beleza, e aí vem a segunda instrução, já mais mastigada.

E por que montar dessa forma? Porque, se você simplesmente pega um prompt, copia e cola, por melhor que seja o resultado, você não aprende a criar o seu. E se você não aprende a criar o seu, você não consegue se multiplicar com a IA. A ideia é justamente você se multiplicar. Você entender como conversar de forma produtiva com o agente pra poder criar qualquer coisa. Esse é o coração do jeito de trabalhar que eu venho organizando há anos: você não coleciona prompt pronto, você aprende a dialogar.

Eu deixei os itens numerados aqui — 1, 2, 3 e por aí vai — só pra facilitar a gravação. E, como falei, eu vou colocar isso tanto no Claude Code quanto no Kimi, pra gente fazer um comparativo.

Por que rodar dois modelos ao mesmo tempo

O Kimi tem uma função bem legal que muita gente ainda não conhece: o enxame (o swarm). Ele pega e dispara um monte de subagente pra trabalhar. No meu Claude Code, como eu já uso vários subagentes, ele também vai naturalmente chamar subagentes pra fazer o trabalho.

Agora, uma coisa curiosa: como o resultado é um arquivo só, um HTML autocontido, na hora de escrever o código ele não vai colocar vários agentes ao mesmo tempo — não dá pra dois, três, quatro agentes mexerem no mesmo arquivo em simultâneo, isso quebra. No máximo um ou dois. Mas nas partes que precisam de pesquisa na internet, aí sim ele vai chamar vários. Vai ser interessante ver como o enxame do Kimi lida com uma coisa que, em determinado momento, é um arquivo único.

No terminal, uma dica: eu configuro pra que, quando eu seleciono um texto, ele já jogue pro clipboard — como se eu tivesse dado um Ctrl+C e um Ctrl+V automático. Fica bem mais prático.

O Kimi, no momento em que eu gravo, é o Kimi K2.7, e está muito bom. Vai ser curioso acompanhar, porque esse HTML autocontido, dependendo do que você cria, pode virar um arquivo de 5, 10, 20, 30 mil linhas — ele fica enorme porque você coloca tudo dentro dele. Dependendo do agente ou de uma janela de contexto menor, o modelo nem dá conta. Então dá pra ver na prática como cada um se vira.

O conceito que muda tudo: subagentes e a janela de contexto

Aqui vale um conceito que eu considero a maior sacada de todas. O que eu desconfio que vai acontecer é o seguinte: o nosso agente principal, o coordenador, só vai mandar o subagente trabalhar. E o coordenador — que no Kimi está com uma janela de contexto de uns 250 mil tokens — não vai sobrecarregar a janela dele, porque quem trabalha nos arquivos são os subagentes.

E essa é a grande vantagem de usar subagente: cada subagente tem a própria janela de contexto. Acontece a mesma coisa no Claude Code e no Codex. Quando você dá uma tarefa pro subagente — geralmente uma tarefa atômica, resolvida rápido, numa ação só — tudo que ele gasta de contexto, ele gasta na janela dele. Quando ele devolve o bastão pro coordenador ("já fiz tal tarefa"), o coordenador só lê aquele pedacinho de informação e acabou.

O agente coordenador só delega e lê o resultado curto; cada subagente tem a própria janela de contexto e gasta os tokens lá, não na janela do coordenador.

Por isso é tão bom usar subagentes: o seu coordenador gasta muito menos janela de contexto. É como dar um checklist pra alguém e mandar delegar, em vez de fazer tudo sozinho e perder uma hora nisso.

A segunda instrução: o planejamento é onde você mais gasta tempo

Depois da conversa, entra a instrução mais detalhada — aquela que eu montei já pegando tudo que a versão 1 mostrou que não funcionava.

E aqui está a lição mais importante de todas: quando você vai criar alguma coisa, o lugar onde você mais tem que dedicar o teu tempo é no planejamento. Às vezes você vai fazer uma aplicação que leva duas, três horas de desenvolvimento — a versão 1 levou umas três horas e meia. E, muitas vezes, é no planejamento que você gasta mais tempo. Pode ser que você fique duas, três, quatro, cinco horas só planejando.

Isso faz toda a diferença, porque a IA não é boa de planejar — ela é péssima nisso. É aí que entra o humano. Você tem que ajudar, conversando. Por isso aquela história de autorizar a opinião, de pensar que é como se fosse um cara sentado do seu lado. Você conversa com ele sobre o que quer fazer, e ele te ajuda a montar as peças do planejamento.

E esse planejamento não pode ficar só na memória da conversa. Não dá pra simplesmente jogar um prompt e falar "faça", porque ele pode esquecer pedaços pelo caminho.

Por que sempre criar um arquivo de spec

Então, no Claude Code, a gente vai fazer do jeito das boas práticas: dar as instruções e pedir pra ele montar uma spec, um arquivo de planejamento. Quando você tem um arquivo com a especificação do que você vai fazer, ganha duas vantagens grandes.

Primeira vantagem: se a janela de contexto acabar, você tem todo o planejamento salvo. Segunda vantagem: em determinado momento, você pode invocar um agente, dar a ele o caminho do arquivo de spec, e mandar conferir cada item da especificação — se foi implementado ou não, se tem código morto, se algo foi pulado, se alguma implementação está quebrada.

Sempre crie um arquivo de spec: se a janela de contexto acabar, o plano continua salvo; e você pode mandar um agente auditar cada item da spec contra o que foi implementado.

O Claude Code geralmente já faz isso por padrão. No meu, eu tenho instruções que forçam esse comportamento. Mas, como eu quero que você replique isso em qualquer lugar, eu vou colocar essa instrução explicitamente no final.

E quando você estiver montando o seu planejamento, organiza tudo. Não precisa ficar preocupado em escrever num português perfeito, semanticamente redondo. Explica de um jeito natural, como se estivesse conversando com o cara do lado — só que organizado. Se você vomitar todas as informações de uma vez, ele pode se confundir.

O que eu escrevi na spec do bolão

A explicação que eu passei foi mais ou menos essa: a gente vai construir um app de bolão pra Copa do Mundo de 2026. Eu quero que ele seja muito simples pra família e amigos usarem. Vai ter os jogos de mata-mata e um ranking de quem acertou. E o público-alvo são pessoas leigas.

Quando você vai fazer um app simples, é importante falar isso pra IA: que é pra pessoas leigas, gente que nunca usou um app assim. Então tem que ser fácil. Simplicidade extrema. Foi o que eu não gostei na versão 1, por isso larguei ela de mão. Eu preferi adiar o lançamento pra passar exatamente essa informação: quando você faz alguma coisa, você tem que pensar em quem vai usar. E aí você conversa no planejamento sobre usabilidade e experiência do usuário — que tem que ser de simplicidade extrema pra funcionar bem. Tudo direto ao ponto, sem jargão, sem botão de duplo sentido.

As regras técnicas que eu passei:

• HTML autocontido, com CSS e JavaScript, tudo dentro de um arquivo só.
• Zero dependência externa. Assim ele funciona mesmo sem internet.
• Salva tudo no localStorage. Ou seja: você abre o arquivo no celular ou no computador, cadastra as informações, fecha, e quando abrir de novo aquele mesmo arquivo naquele mesmo lugar, tudo volta igual. O ranking que você foi montando fica gravado na memória local do navegador. (Se você abrir em outro lugar, aí não vai estar lá — normal.)
• Sem banco de dados, pra manter o mais simples possível.
• Mobile-first, porque isso vai ser usado mais no celular.
• Em português, com visual moderno e alegre, por causa do clima de Copa.

Sobre a pontuação, eu tomei uma decisão de propósito. Na primeira versão eu tinha várias fórmulas — daquelas que as pessoas usam: "acertou o vencedor ganha tanto, acertou a quantidade de gols de um dos lados ganha tanto". Eu pensei: caramba, vamos simplificar. Você acerta o placar exato ou não acerta. Acertou, 1 ponto. Errou, 0. Sem meio-termo. Se você ainda não fez nenhuma aplicação que funcione de verdade, esse é o caminho: faça o mais simples primeiro, pra você adquirir experiência.

E teve duas regras que precisavam ficar cristalinas, senão vira briga no grupo. A primeira é sobre qual placar conta. Em mata-mata tem prorrogação e pênalti, então eu defini: o palpite e o resultado são o placar do jogo jogado — o tempo normal mais a prorrogação, que é jogo de verdade. O pênalti não conta. Por quê? Porque a disputa de pênaltis embola a conta: o jogo deu, sei lá, 1 a 1, e nos pênaltis foi 5 a 4 — o placar do futebol jogado é 1 a 1, não a marca dos pênaltis. Se você do seu lado quiser mudar essa regra, é só conversar com o agente e pedir. A segunda regra puxa dessa: se der empate no tempo normal, o app tem que ter uma seleção pra marcar quem passou — porque o placar não diz o vencedor, mas a tabela eliminatória precisa saber quem avançou. Quando não é empate, não precisa marcar nada: quem fez 2 num 2 a 1 é quem ganhou, óbvio.

Sobre as telas (as páginas internas): o mínimo de telas possível. Nada de entrar numa página, depois em outra, depois em outra — muito clique deixa chato de usar. Coloquei ranking com medalhinhas pra ficar mais legal, e o chaveamento a partir dos 16 avos — não faz sentido começar com os grupos, 64 times, um monte de resultado; a partir dos 16 avos já vira uma tabela eliminatória bacana.

E um "como jogar" embutido, uma explicaçãozinha rápida de como funciona. Aqui entram os dois personagens: o organizador (que pega os jogos de todo mundo, lança os placares e mantém tudo organizado) e os palpiteiros (que dão os palpites). O organizador também palpita, claro.

A pesquisa em dupla camada (pra não fazer tudo errado)

Uma parte crítica é o dado real: os resultados verdadeiros dos jogos e o chaveamento correto da FIFA. E aqui eu uso uma técnica importante: a pesquisa em dupla camada.

Por quê? Porque se a gente mandar o agente pesquisar na internet e ele pegar a informação errada, a gente vai fazer tudo errado. Então funciona assim: faz uma pesquisa, faz uma segunda pesquisa, e depois compara as duas informações pra ver se batem. Se divergir, pesquisa de novo até bater.

Pra dado real, use pesquisa em dupla camada: pesquisa uma vez, pesquisa de novo, e mande a IA comparar as duas. Se pegar informação errada, faz tudo errado.

E quem compara é a IA, não a gente — porque a IA é maravilhosa pra ler e comparar dados, muito melhor do que nós. Então eu instruí: a primeira investigação busca a classificação dos times e quem está na etapa de 16 avos, com o resultado de cada jogo. Depois vem a segunda, e aí compara. Se achar inconsistência, pesquisa de novo.

Na hora H, eu liberei o agente pra fazer essa pesquisa em segundo plano enquanto eu continuava conversando o resto — assim a gente ganha tempo. Repara que, no meu caso, ele mandou o subagente investigador, que é mais preparado pra isso. Mas, mesmo que você não tenha subagentes personalizados no seu ambiente, tanto o Claude Code quanto o Codex já vêm com subagentes generalistas nativos — então é só mandar ele usar um subagente pra fazer a pesquisa em segundo plano.

Sem pontas soltas, proibido dedução, proibido preguiça

Aqui eu preciso ser honesto sobre uma coisa. Existe aquela estatística de que mais de 90% das empresas que tentaram adotar IA no ano passado, em 2025, não conseguiram. O número exato ninguém sabe — chutam 94%, 95%, eu já vi citarem 91%. Na minha experiência de uso, a maioria das pessoas e das empresas falha ao adotar IA não porque a ferramenta é ruim, mas porque usa do jeito errado — principalmente por falta de planejamento. Isso é a minha leitura, tá? Não é um dado fechado com fonte que eu esteja te vendendo — é o que eu vejo na prática. E é exatamente isso que separa quem consegue de quem entra na conta dos que desistem: conversar antes, planejar com calma e dirigir a IA, em vez de esperar que ela faça tudo sozinha.

Porque, quando você amarra bem o planejamento, a chance de dar certo é muito maior. E no planejamento você consegue, junto com o agente, simular coisas: "peraí, vamos prototipar essa parte que eu não tenho certeza", "vamos simular a jornada do usuário nessas etapas". No planejamento você amarra tudo. Eu tenho projetos aqui cujo planejamento — quebrado em vários arquivos, não num só — passa de 30 mil linhas, porque está tudo bem mastigado.

Se a gente for na preguiça, sem ler as informações que o agente devolve, sem responder cada ponto, as coisas não vão funcionar bem. Não adianta eu mandar o agente conversar e dar opinião, se eu não faço o mínimo que o ser humano tem que fazer, que é participar do planejamento.

E não me venha com a esperança de que a IA vai fazer tudo sozinha. Nem a de 2026, que é boa, faz tudo sozinha — e eu acredito que nem a de 2027 ou 2028 vai. Porque o planejamento depende de muitas informações que só você tem. Você provavelmente não é o maior especialista do mundo em Copa do Mundo, nem em programação. Você precisa trocar informação com a IA. Só com um prompt você não vai passar tudo que ela precisa. É pra isso que serve conversar: você explica o objetivo, ela devolve a opinião, e vocês fazem aquele ping-pong até amarrar todas as pontas.

E você pode forçar isso usando palavras-chave, ditas de um jeito humano mesmo: "não quero pontas soltas, proibido dedução, proibido preguiça". Funciona muito bem, eu uso demais. Eu tenho várias skills próprias que direcionam a IA com esse tipo de linguajar — "proibido deduzir tal coisa", "certifique-se de que os subagentes não terão preguiça". Não dá pra você replicar todas elas, mas o princípio é esse.

A IA sempre vai tentar terminar a tarefa o mais rápido possível. O papel do humano é conversar bem e fazer um bom planejamento. Se você tem preguiça, a IA também vai ter.

JSON pra IA, Markdown pra humano

Enquanto os agentes pesquisam, vale uma distinção que eu uso o tempo todo. Quando o agente vai gerar dados, ele precisa salvar — não confiar no que está escrito na janela de contexto. E aqui vem a regra do formato:

Dados que um subagente gera pra outro consumir, salve em JSON. É mais fácil de encontrar, mais organizado, mais estruturado. Conteúdo que um humano vai ler ou editar, salve em Markdown. Por isso o arquivo de spec, de planejamento, é em Markdown — ele é pra você abrir, ler e talvez editar. Se fosse o mesmo conteúdo em JSON, seria péssimo de ler.

Quando são dados de IA pra IA, priorize JSON. Quando é conteúdo pra humano ler ou editar, use Markdown.

Por isso é bom ter subagentes personalizados: você coloca no system prompt de cada um a obrigação de sempre salvar essas informações, no formato certo. E dá pra organizar melhor ainda — eu sempre mando ele tratar os arquivos de especificação dentro de uma pasta docs. Com o tempo você vai pegando o jeito de como gosta que as coisas fiquem organizadas, e define isso no system prompt do coordenador e dos subagentes.

O puxão de orelha educado (e sempre dar opções)

Uma coisa que acontece muito: às vezes a IA pega uma decisão um pouco mais complexa e joga no seu colo, esperando que você — que não é o expert — decida. Quando ela fizer isso, você dá um puxãozinho de orelha educado. Fala assim:

"Determinada pergunta você não pode jogar no colo do usuário, porque ele pode errar o caminho e colocar tudo a perder. Sempre que fizer uma pergunta, dê as opções, aponte a recomendada e justifique — pra direcionar o usuário."

Assim ele te dá a pergunta com as opções, diz qual recomenda e por quê, e ainda justifica as que não recomenda. Aí você tem contexto pra decidir com segurança: "concordo, vamos na opção A". Nesse app aqui, que é tudo muito simples, quase não foi necessário — mas fica a dica.

E uma observação importante sobre o tom: esses puxões de orelha têm que ser educados. Se você for agressivo, grosseiro, não só não adianta como piora o resultado. Então seja firme e claro, mas sem brigar.

Aconteceu de verdade no meio do processo: numa das perguntas o agente me deu uma dupla interpretação. Em vez de eu arriscar escolher errado, eu mandei ele melhorar as próprias perguntas, colocando opções claras com recomendação e justificativa. Isso destrava a decisão sem risco de deixar o projeto torto.

Opus x Kimi: a diferença aparece na qualidade

Rodando os dois em paralelo, dá pra sentir a diferença. Logo na conversa inicial, o Claude Code com Opus entendeu o escopo inteiro, elogiou a arquitetura, apontou que eu tinha separado corretamente o app dos dados — e, o principal, deu a opinião honesta que eu autorizei, apontando dois ou três pontos de melhoria. Ele traçou o fluxo: o organizador é o dono da verdade, é o device dele que tem todos os palpites e resultados, e o ranking é calculado ali.

O Kimi, que eu deixei mais largado, nesse mesmo momento simplesmente não deu opinião nenhuma — ele foi mais direto pro "vamos fazer". Não que o Kimi seja ruim; o Kimi é bom, e surpreende. Mas dá pra ver a diferença de qualidade do Opus, que é fantástico. Se a gente estivesse fazendo no Codex, provavelmente seria parecido com o Opus, porque o ChatGPT também é muito bom.

O melhor modelo não é o mais famoso nem o que você "torce" — é o que resolve o seu problema dentro do seu orçamento.

Esse é o ponto que eu quero que fique: IA não é time de futebol pra você defender, lado A, lado B, lado C. Você usa a ferramenta que resolve o seu problema, no seu orçamento. E é por isso que essa comparação está aqui — não pra coroar um modelo, mas pra provar que o método funciona igual nos dois. No fundo, o Prompthen é isso: um jeito de dirigir agentes de IA que não depende de qual modelo você usa e que qualquer pessoa consegue aplicar, seja no Claude Code, no Kimi, no Codex ou no que vier depois.

Sobre produtividade, vale pensar: a IA que rende mais costuma ser a que erra menos. Porque erro consome as duas coisas — tempo e token. Uma IA que erra muito te faz gastar muito tempo e muito token corrigindo o mesmo problema; uma que erra menos resolve de primeira e você economiza nos dois. Então nem sempre o que parece mais econômico no papel sai mais em conta no total.

Falando em modelos, é bom não cair na cultura do "saiu um modelo novo, o jogo virou, tudo mudou". Sai novidade de IA o tempo todo — se você tentar correr atrás de tudo, não trabalha nem evolui. Eu, por exemplo, ainda estou testando o Sonnet 5: pelos dados do lançamento, ele parece se equiparar ao Opus 4.6 / 4.7, e foi do 4.6 em diante que, no meu uso, o Opus começou a errar bem menos. Se isso se confirmar, é ótimo ter um modelo mais barato nesse nível — mas eu não dou opinião fechada antes de testar direito. O topo hoje, no meu uso, é o Opus 4.8, que melhorou bastante a visão.

Os subagentes trabalhando: pesquisa, spec e o app do Kimi

No Claude Code, os dois subagentes de pesquisa voltaram, a validação cruzada bateu, e o coordenador montou a spec. Ele até sinalizou honestamente alguns pontos de dúvida e uma divergência que achou entre as pesquisas (num jogo específico, Bélgica e Senegal, ele encontrou inconsistência). E aí é a regra: se achou ponta solta, resolve, pesquisa de novo. Eu não deixo passar.

O Kimi, em paralelo, foi mais rápido — ele é veloz, assim como o MiniMax M3 e o GPT. O Opus é o mais demoradinho dos bons. O Kimi criou o arquivo de spec, montou até um fluxograma da jornada do usuário (o que ficou bem bacana), fez um checklist, e disparou os subagentes com o enxame pra construir. O interessante: quando o app do Kimi ficou pronto, a janela de contexto do coordenador dele estava em uns 45%. Por quê? Porque quase tudo foi feito através dos subagentes — cada um gastando na própria janela.

O app do Kimi saiu com umas 1300 linhas, bem menor do que eu esperava. Abri pra testar e, de primeira, não funcionava — o botão nem respondia. Aí eu fui direto e bruto (de propósito, pra mostrar que dá): "amigo, não funciona, nada. Confira. Manda subagentes testarem tudo antes de mandar pro usuário. Comece por um agente que audita a spec inteira e vê se cada item foi implementado, se tem código morto ou coisa esquecida. Depois, com um novo subagente, faça todos os testes."

E aqui aparece a ordem certa do fluxo: primeiro o auditor confere spec contra implementação e corrige; só depois o testador testa. Não faz sentido gastar token testando uma coisa que já está deficiente. No Kimi, como eu deixei largado, ele acabou rodando as duas coisas meio juntas — não é o ideal, mas mesmo assim funcionou.

E o resultado foi surpreendente: o Kimi voltou com o app corrigido, e ele funcionou muito bem. A gente foi desleixado, só falou "revisa, filho, e corrige", sem detalhar o que revisar, e ele deu conta. O organizador cria o bolão, gera o convite (um código que você copia e manda pelo WhatsApp), o palpiteiro cola o convite, chuta os placares, gera um código e devolve — o organizador cola e importa. Ranking, chaveamento, "como jogar", tudo ali, com pouquíssimas telas. Ficou bem intuitivo.

Teve uma diferença reveladora: como eu não instruí o Kimi sobre o caso de empate no mata-mata (aquele em que precisa marcar quem passou), ele simplesmente não criou isso. O Opus, veremos, criou sozinho. Isso mostra que a saída depende do que você amarra no planejamento — o que você não instrui, o modelo pode não adivinhar.

O bug que o Opus achou sozinho (e por que isso é ótimo)

No Claude Code, quando eu dei o puxão de orelha pra revisar, o Opus foi lá e encontrou um furo grave na arquitetura — e não deduziu, investigou. O problema era esse: como o palpiteiro remoto vai palpitar as fases seguintes (quartas, semifinal) se o app dele não recebe atualização dos resultados anteriores?

No começo eu não tinha entendido o que ele queria dizer. Meu primeiro impulso foi responder "a pessoa está acompanhando a Copa, ela sabe quem chegou lá". E é verdade — o palpiteiro sabe do que aconteceu no mundo real. Mas o ponto do agente era outro: dentro do app, se o arquivo do palpiteiro não tem os jogos da nova fase, ele não tem como palpitar por ali. Era uma coisa que o agente percebeu e eu não tinha sacado. Então a solução foi criar uma forma simples do organizador atualizar os jogos já feitos e passar a fase adiante, fácil e intuitiva.

Isso é o valor de mandar revisar: sempre revise o planejamento, evite a ponta solta, e chame a atenção do agente pra fazer mais uma checagem. A auditoria do Opus não achou nenhum erro de dados (as pesquisas em dupla camada tinham feito bem o trabalho), mas achou decisões de arquitetura pra ajustar. O veredito dele foi ótimo: "a spec não está pronta pra codar — ainda bem que checamos". Foram 17 correções aplicadas na revisão. Muita coisa. É por isso que a revisão do planejamento é importantíssima.

O fluxo completo do Opus: dev, auditoria, design e o Guardian

Quando a spec ficou endurecida e validada, eu mandei prosseguir. E aí, sem eu nem ter percebido no meio da gravação, o Opus executou o fluxo completo com o meu setup de subagentes, na ordem certa:

1. Desenvolvedor — construiu o app. No meu ambiente, esse subagente carrega boas práticas de desenvolvimento.
2. Investigador — pegou a spec e auditou item por item contra a implementação, pra ver se cada coisa foi feita. Achou um problema, que era tão simples que ele mesmo corrigiu na hora.
3. Designer — deu o "tapa" visual. Eu tenho o designer separado do desenvolvedor de propósito: nele eu coloco boas práticas de design, de experiência do usuário, o que é um visual agradável, o que não usar. Assim cada agente é especialista no seu pedaço.
4. Guardian — testou tudo, no fim.

E aqui está o ponto que eu quero que você grave sobre a economia de contexto. Olha os números reais dessa sessão:

• O desenvolvedor trabalhou 16 minutos e gastou 172 mil tokens na janela dele, com 31 ferramentas — nada disso veio pra janela do coordenador.
• O investigador gastou 174 mil tokens em 7 minutos, só auditando spec contra HTML.
• O Guardian gastou 300 mil tokens e ficou quase uma hora (48 minutos) rodando todos os testes.

Somando, dá quase 900 mil tokens que não entraram na janela do coordenador. Isso não caberia de jeito nenhum na janela dele. E olha: esses números não provam competência minha — eles mostram a escala do trabalho que você consegue rodar quando delega. A janela de contexto é como um rolo que vai girando: se você enche ela fazendo tudo sozinho, o coordenador trava. Se você dá um checklist e manda delegar, ele coordena tranquilo e te traz o serviço pronto.

Cada subagente gasta os tokens na própria janela. Somando dev, investigador e Guardian, foram quase 900 mil tokens que não entraram na janela do coordenador — não é prova de competência, é a dimensão do que dá pra rodar quando você coordena em vez de fazer tudo sozinho.

O testador tem que ser "chato": como instruir o Guardian

Vale abrir esse ponto, porque é onde muita gente escorrega. Quando você for criar um subagente testador — pode ser um generalista, funciona também, mas não tão bem — instrua ele como um cara chato. Um verificador exigente. Fala pra ele algo assim:

"Assuma que o colega anterior foi péssimo, foi preguiçoso e criou coisas que não funcionam direito. Você precisa encontrar essas falhas. Destrua a aplicação com testes — no bom sentido — pra achar vulnerabilidades, bugs ocultos e edge cases."

Se você não instrui dessa forma, o agente que confere fica preguiçoso e pensa "ah, acho que tudo funciona". Quando você fala que ele é um destruidor, ele vai fundo. Isso vale tanto pro prompt da tarefa quanto pro system prompt de quem esse agente é.

E tem a regra do Guardian 1:1. No meu setup, eu escrevo "lembre-se, Guardian 1:1" — porque o meu subagente testador se chama Guardian. Isso quer dizer: a cada tarefa realizada, ele manda um verificador. Eu não deixo acumular três, quatro, cinco tarefas pra só então testar. Cada tarefa, uma verificação. O processo fica mais lento, mas eu evito que um bug lá na tarefa 3 vá contaminar o projeto inteiro.

O app do Opus pronto: o toque final que o coordenador dá sozinho

Quando o desenvolvedor do Opus terminou, o app tinha umas 400 linhas — bem enxuto, mas isso por si só não diz muita coisa. O designer fez o polimento, e visualmente ficou mais refinado (o Opus 4.8 melhorou bastante a visão; nas versões anteriores, quando o visual não saía bom, o jeito era mandar um screenshot com exemplos pra ele entender melhor o que é bonito). O Guardian rodou todos os testes e não encontrou problema.

E teve um detalhe lindo no fim: o coordenador percebeu sozinho uma coisa trivial e corrigiu sem eu pedir. Dentro dos jogos, o app estava mostrando uns rótulos com códigos de fase (tipo "oitavas" seguido de um código). O coordenador entendeu que isso confundia o usuário — e como uma das coisas principais do app é ser simples e intuitivo, ele removeu todos esses rótulos por conta própria. É isso que acontece quando o agente coordenador percebe algo muito simples: ele mesmo arruma, sem precisar delegar.

No app do Opus, testando: criei um bolão da família, gerei o convite, copiei o código, colei de volta pra simular a entrada de um palpiteiro. Funcionou perfeitamente. E, no caso de empate no mata-mata, o Opus tinha criado sozinho a caixinha de "quem passou" — exatamente o que eu instruí na spec e que o Kimi, sem essa instrução, não fez. Subestimei o Opus ali; ele já tinha pensado nisso.

Pra fechar, como eu uso o meu Claude Code num servidor pra acessar de qualquer lugar, eu mandei ele subir o app num endereço HTTP local, usando uma skill minha de servidor local. Pra você, provavelmente é só abrir o arquivo direto no navegador.

O que fica de tudo isso

No fim, os dois apps ficaram bons. O do Opus, com o designer, ficou visualmente mais refinado e com aquele caso de empate resolvido sozinho. O do Kimi ficou mais simples, mas totalmente funcional — e isso apesar de eu ter deixado ele largado, quase sem revisar. Os dois superaram a minha versão 1, e o motivo é o mesmo: a instrução inicial e o planejamento foram bons. Não foi o modelo que salvou; foi o método.

E é aí que eu quero te deixar. Eu tenho várias skills que facilitam demais o meu lado — geração de imagem chamando o Codex por subprocesso, o HTML autocontido, a bateria de testes, o servidor HTTP local. Não dá pra você replicar tudo isso agora, e nem precisa. O que importa é que você entenda o caminho: converse antes de mandar criar, gaste o tempo no planejamento, monte a spec, delegue pra subagentes, mande um agente chato quebrar tudo, e não deixe ponta solta.

Esse jeito de trabalhar tem um princípio central no Prompthen: a sua autonomia, não a sua dependência. Não fique colecionando prompt pronto nem skill pronta — aprenda a conversar com a IA e crie as suas. Porque prompt pronto só serve pra uma situação; aprender a conversar serve pra qualquer uma. É assim que você se multiplica de verdade.

Faça o seu bolão. Não copie o meu pronto — refaça, do jeito que a sua dor real pede. E se aparecer um bug amanhã, com esse conhecimento você mesmo corrige em casa.

Eu sou o Paulo Teixeira. Um abraço e até a próxima.