Plan Mode em 30 min: demanda latente num domingo

Domingo, 22h. Boris Cherny abre o GitHub Issues do Claude Code e começa a rolar.

Esse é o hábito dele. Toda noite de domingo, ele passa por issues abertas por usuários de verdade. Não para fechar bugs — para farejar qual padrão está pedindo pra sair da tela.

Naquela noite, ele viu o mesmo pedido escrito em cinco jeitos diferentes.

• “não escreva código ainda, só planeje”
• “deixa eu confirmar a abordagem primeiro”
• “antes de codar, lista os passos”
• “please don’t code yet”
• “faz um plano, depois a gente executa”

Todo mundo pedindo a mesma coisa com palavras diferentes. Separar a fase de planejar da fase de implementar.

Em 30 minutos, Boris implementou. Deploy no dia seguinte. É o Plan Mode.

O que eu entendi errado no começo

Meu primeiro contato com o Plan Mode foi medíocre.

Vi o Shift+Tab, achei “ah, é um toggle de modo”, apertei uma vez pra testar, e esqueci. Durante semanas, usei o Claude Code em auto-mode direto. “É só mandar implementar que sai.”

Saía. E eu reescrevia metade na manhã seguinte. Já contei essa história em outro post: desenhei o dia no Plan Mode e o retrabalho despencou. Lá mostro como passei a usar a ferramenta.

Aqui o assunto é outro: quem construiu a ferramenta, e por que ela tem essa forma.

Demanda latente, não requisito

Boris tem um nome pra esse padrão: demanda latente.

As pessoas só adotam ferramentas que tornam mais fácil aquilo que já estão fazendo. Elas não vão usar algo que pede para fazerem algo novo.

Lido rápido parece óbvio. Lido devagar vira uma faca.

Ninguém abriu um issue dizendo “quero um Plan Mode”. Ninguém sabia que esse nome existia. O que existia era um comportamento espontâneo: usuários inventando prompt-hacks pra forçar o modelo a planejar antes.

Boris não desenhou um recurso novo. Ele viu o comportamento, retirou o atrito e deu um nome.

O código final é ridículo de tão simples. Uma linha conceitual: “please don’t code.” Um atalho: Shift+Tab. Pronto.

Por que a implementação cabe em 30 min

Porque o produto já existia. Estava na cabeça dos usuários.

Isso me incomoda, porque contradiz como eu fui ensinado a pensar em produto. A escola que eu peguei era: faça entrevistas, extraia requisitos, priorize backlog, planeje sprint. Nesse mundo, 30 minutos é o tempo pra abrir o Linear.

Boris pulou tudo isso. Ele leu issues brutos de domingo à noite, viu o mesmo pedido em cinco jeitos, e foi direto implementar. Sem roadmap, sem OKR, sem reunião de prioridade.

Fico me perguntando: por que, no meu trabalho, eu nunca faço assim?

Pensei nisso por uma semana. Minha resposta parcial: porque eu não ponho a mão nos issues brutos. Olho dashboard, olho release notes de concorrente, olho tweet de influencer. Tudo filtrado. Boris pega o cru.

Dá pra ver na linha do tempo o quanto esse hábito encurta o ciclo.

Três pistas que indicam demanda latente

Pego a ideia de Boris e tento aplicar no meu próprio trabalho. Hoje olho pra três pistas na tentativa de reconhecer demanda latente antes que ela vire um produto do concorrente.

Pista 1: o mesmo pedido em cinco jeitos

Se cinco usuários diferentes pedem a mesma coisa com palavras diferentes, você tem uma demanda. Se cinco pedem com as mesmas palavras, você tem um meme. Boris procurou a primeira.

Pista 2: o usuário contorna sozinho

Se o usuário já está resolvendo o problema por fora (prompt-hack, planilha paralela, bookmarklet), o produto já existe. Falta tirar o atrito. Reset do CLAUDE.md foi assim também: gente colando contexto no prompt toda vez, até alguém notar que isso podia virar arquivo.

Pista 3: a implementação é constrangedoramente simples

Se a solução cabe em 30 minutos, é porque o trabalho duro (descobrir o que fazer) já foi feito pelos usuários. Solução complicada quase sempre está resolvendo o problema errado.

O desconforto de deixar as coisas simples

A parte que mais me pega no caso do Plan Mode é: ele é tão simples que fica difícil cobrar por ele.

“Please don’t code.” Uma linha. Dá pra escrever isso num Discord bot em 10 minutos. Então por que o Plan Mode funciona e o Discord bot não?

Minha hipótese: porque o Plan Mode roda no mesmo terminal onde o engenheiro já está. Zero fricção de contexto. Nada pra abrir, nada pra configurar, nada pra lembrar.

É a ideia de “a IA viver no mesmo terminal”. É posicionar a ferramenta como extensão de um comportamento que já existe.

É aí que a filosofia do Claude Code se separa de várias outras ferramentas de IA: ela quer estar onde você já está.

Prazo de validade curto

Boris mesmo acha que o Plan Mode não dura muito.

O Plan Mode talvez fique desnecessário em mais um mês.

A ideia é que o próprio modelo detecte “aqui preciso planejar” e entre no modo sozinho. Sem atalho, sem toggle. Só o comportamento certo, na hora certa.

Parece correto. E também dói um pouco. A gente acabou de aprender onde fica o Shift+Tab, e já estão me avisando que ele vai sumir. Lido como lição: o produto final da demanda latente não é um botão, é um comportamento.

O que eu passei a fazer

Mudei duas coisas pequenas na minha rotina depois de ler sobre esse episódio:

Primeiro, abri de volta a aba de issues dos repositórios que eu uso. Olho uma vez por semana, sem filtro, só rolando. Já peguei três pedidos repetidos que eu nunca teria visto no release notes.

Segundo, mudei o critério pra começar algo. Antes era “esse é um recurso bonito?”. Agora é “estou vendo o mesmo pedido em cinco jeitos?”. Se não, deixo pra lá. A espera é parte do trabalho.

O Shift+Tab tá aí. Boris implementou isso num domingo. Vale perguntar o que, na minha semana, ainda caberia em 30 minutos — se eu estiver olhando pro lugar certo.

---

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews