Como o Grok Bot foi construído em um mês: as decisões de produto por trás do agente

A parte mais interessante da conversa de Roman Ugarte com Lenny Rachitsky, no episódio How we built Grok Bot in a month, não é o cronograma agressivo (quatro semanas até um produto interno funcional, mais três até o lançamento público). É a sequência de decisões de produto que tornou esse cronograma possível, e que qualquer time construindo um agente de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → hoje vai encarar.

Ugarte não é um nome qualquer nessa discussão: antes do Grok Bot, ele liderou Growth no Cursor e ajudou a escalar a empresa de 15 para mais de mil pessoas antes da aquisição pela SpaceX. Ou seja, ele já tinha visto de perto o que faz um produto de IA para desenvolvedor pegar tração, e escolheu deliberadamente não reaproveitar essa base.

A decisão que definiu tudo: construir do zero, não plugar no Cursor

O caminho óbvio seria adicionar o agente de conhecimento como mais uma feature dentro do Cursor, um produto já com distribuição, base de usuários e infraestrutura. O time fez o contrário: começou um produto novo, isolado, do primeiro git init.

Essa é uma decisão de produto antes de ser técnica. Plugar num produto existente te dá velocidade de distribuição, mas te obriga a herdar o modelo mental do produto antigo. O Cursor é um editor de código, um agente que faz knowledge work (trabalho de escritório, pesquisa, redação, análise) para um público mais amplo não cabe confortavelmente na mesma casca. Construir do zero é mais caro no começo e mais barato depois, porque você não paga o imposto de compatibilidade com decisões que não foram feitas para o seu caso.

Para o dev brasileiro, a pergunta que fica é concreta: quando o time decide encaixar o novo recurso de IA no monólito que já existe "porque é mais rápido", quanto desse ganho inicial vira dívida de arquitetura seis meses depois? A escolha do Grok Bot sugere que, para um produto de categoria nova, o custo de reaproveitar pode ser maior que o de recomeçar.

Onboarding manual: quase 300 primeiros usuários atendidos a mão

O ponto que mais destoa da cultura de "escala primeiro" é este: o time fez o onboarding pessoal de quase 300 dos primeiros usuários. Não um fluxo self-service polido, não um tour guiado in-app. Gente do time sentando com gente que ia usar.

Isso é discovery em estado bruto. Não é pesquisa com survey e NPS, é observação direta de onde o produto trava, quando a pessoa desiste, qual instrução ela dá ao agente e como ela reage quando ele erra. Um agente de IA é especialmente difícil de instrumentar só por métrica, porque o mesmo "clique" (mandar um prompt) esconde intenções radicalmente diferentes. Ver a pessoa usando resolve ambiguidade que dashboard nenhum resolve.

O trade-off é honesto e vale nomear: esse método não escala e não deve escalar. Ele serve para a janela em que você ainda está descobrindo o que o produto é. Passada essa fase, insistir em onboarding manual vira gargalo. A lição transferível não é "faça onboarding manual", é: nas primeiras centenas de usuários, o custo de estar na sala vale mais do que o tempo economizado automatizando cedo demais.

A régua dos 100%: por que "quase certo" não serve para agente

Ugarte resume em um post no X citado no episódio a tese de produto que orientou o Grok Bot:

Uma IA que faz 100% do trabalho parece categoricamente diferente de uma que te leva a 90% do caminho.

Roman Ugarte

Essa frase parece motivacional, mas é uma decisão de escopo com consequência técnica direta. Um agente que entrega 90% obriga o usuário a revisar, corrigir e completar o resto, e o esforço de auditar uma resposta quase certa costuma ser tão grande quanto fazer do zero, porque você não sabe onde estão os 10% errados. Um agente que fecha o loop inteiro muda a natureza da interação: de "copiloto que eu supervisiono" para "colega a quem eu delego".

É daí que vem a filosofia que o episódio chama de colleague-pilled: projetar o agente para se comportar como um colega de trabalho a quem você passa uma tarefa e recebe o resultado pronto, não como uma ferramenta que você opera passo a passo. A diferença de produto é enorme. "Colega" implica confiança, contexto persistente e responsabilidade pelo entregável inteiro, e cada uma dessas propriedades puxa decisões de engenharia: memória, capacidade de usar ferramentas de forma encadeada, e principalmente tolerância a erro muito mais baixa.

O alerta prático para quem constrói: mirar nos 100% é caro e nem sempre é o alvo certo. Para tarefas de altíssima consequência (código que vai para produção, transação financeira), o modelo copiloto com humano no loop pode ser mais responsável do que um agente que "resolve sozinho". A régua dos 100% do Grok Bot funciona porque o domínio de knowledge work tolera que a pessoa peça de novo se não gostou. Nem todo domínio tolera.

O que sustenta a vantagem quando todo mundo tem o mesmo modelo

A parte sobre moats (barreiras de defesa competitiva) é onde o episódio conversa mais diretamente com o mercado atual. Ugarte tem autoridade para falar disso porque viu o Cursor seguir ganhando num mercado em que dezenas de concorrentes usam os mesmos modelos de fundação (Codex, ChatGPT Work, OpenClaw e outros são citados como parte do cenário).

O raciocínio implícito é o que interessa ao dev: se o modelo é commodity (qualquer um chama a mesma API), a vantagem não está no modelo. Está em quão bem o produto captura contexto, quão rápido o time itera com base no que vê os usuários fazendo, e na experiência que envolve o modelo. Foi o que o onboarding manual comprou: entender o comportamento real antes que a concorrência entendesse.

O que um dev BR tira daqui

É importante calibrar: nada disso é benchmark reproduzível nem receita garantida. É o relato de um time com recursos, talento e timing raros, num contexto que a maioria não tem. Mas três decisões viajam bem para projetos menores:

• Categoria nova pede base nova. Antes de plugar o recurso de IA no que já existe, pergunte quanto do modelo mental antigo você vai ser obrigado a carregar.
• Fique na sala no começo. Nas primeiras dezenas ou centenas de usuários, observação direta vale mais que qualquer painel de métrica, ainda mais para agente, onde a intenção por trás do prompt é invisível no log.
• Defina explicitamente sua régua de acerto. 100% muda a categoria do produto, mas custa caro e não serve para todo domínio. Decidir isso cedo evita construir um copiloto quando o usuário queria um colega, e vice-versa.

O episódio completo, com os detalhes de cronograma e as duas decisões de produto que Ugarte credita pelo sucesso, está atrás do paywall da Lenny's Newsletter. A pergunta boa para levar para a própria mesa não é "como copio o Grok Bot", e sim: no seu produto de IA, você está mirando nos 90% confortáveis ou nos 100% que mudam a natureza da relação com o usuário, e sua arquitetura sabe qual dos dois você escolheu?

Fonte: Lenny's Newsletter