O code foi a parte fácil de colocar a Prova no ar

A Prova começou a parecer real para mim no momento em que o produto parou de me deixar me enganar.

Uma homepage consegue ficar aspirational por muito tempo.

Um produto live não consegue.

Quando as pessoas já podem se cadastrar, confirmar email, cair no lugar errado, bater em billing state, enviar trabalho e esperar que o sistema lembre o que aconteceu, o bottleneck muda.

O produto passa a fazer promessas reais. E o trabalho invisível fica muito visível.

Atualização em 16 de abril de 2026: desde que rascunhei a primeira versão deste post, a Prova já se moveu para um split mais claro entre Operator e Builder. Mantive a tese principal intacta e atualizei os detalhes específicos de produto abaixo para alinhar com o que está live agora.

Se você viu os três posts que escrevi em março e no começo de abril sobre a troca do Claude Max pelo Codex, esse experimento continua em andamento. Eu já prometi um follow-up de verdade para May 2, 2026. Este post não é aquele post.

Se você ainda não viu a Prova: é o meu produto de coaching para marketers e profissionais de publicidade, com um Operator path para redesenho de workflow e um Builder path para entregar uma primeira fatia útil.

A parte difícil, pelo que vivi neste push, não era fazer um LLM gerar code. Era tudo o que ficava ao redor do code.

Se você está construindo com AI agora, especialmente algo que envolve usuários reais, dinheiro real ou real product state, acho que esta é justamente a parte sobre a qual quase ninguém te avisa.

O nome foi a parte fácil

Preciso admitir: dar o nome Prova foi a decisão fácil. Prova significa algo como prova ou teste, e isso combina com o trabalho real do produto: fazer a pessoa provar o trabalho, não massagear o ego de builders.

A parte mais difícil começou logo depois. No momento em que a Prova deixou de ser só um nome e uma landing page, ela passou a exigir todas aquelas coisas pouco glamourosas que produtos reais sempre exigem:

assessment logic
onboarding state
authored progression
review visibility
billing flows
auth hardening
content publishing
release gates

Isso mudou a minha forma de pensar tanto sobre AI tools quanto sobre product building.

No que a Prova realmente precisava se transformar

Prova agora é um produto mais opinionado do que era quando comecei a rascunhar este post. A superfície se dividiu em dois entry paths mais claros: um Operator path para quem está redesenhando workflows e um Builder path para quem está tentando entregar uma primeira fatia útil. No lado builder, isso agora significa um Build Reality Check, um Build Brief, um Build Plan, uma execution lane enquanto o build está em movimento e um launch gate antes de mostrar para um usuário real.

Por baixo dessa superfície mais limpa, o trabalho de sistema mais duro é o mesmo ponto que eu já fazia quando rascunhei este post. Ainda é assessment e onboarding, um produto sprint-first em vez de chat-first, progression guiada por review, product state durável e uma camada de mentor que se comporta mais como office hours em torno do sprint atual do que como um chat genérico de AI.

Para deixar claro: eu não estou dizendo que a Prova está "pronta". Eu adoraria poder dizer isso e seguir em frente, mas seria conveniente demais e provavelmente também não seria verdade. O enquadramento certo hoje continua sendo controlled launch: o billing portal e os recovery flows estão live, mas o trabalho em aberto saiu de product plumbing básico e se deslocou para tornar o Builder path, a execution lane e o launch gate mais honestos sob uso real. Eu acho, inclusive, que isso torna a lição mais útil, não menos. É assim que product building se parece no mundo real. Não está terminado. Não é fake. Só está real o suficiente para que o próximo erro custe alguma coisa.

O trabalho que eu não conseguia simplesmente gerar

A versão mais fácil de um AI product sempre é a versão demo.

Você consegue fazer parecer viva bem rápido:

uma homepage
uma chat box
alguns screenshots polidos
uma frase de produto convincente

Isso serve para um teaser de lançamento.

Não serve muito para entender onde está o trabalho de verdade.

Para mim, esse trabalho começou a aparecer em seis lugares.

1. O sistema de sprints precisava parar de fingir

Eu não queria que a Prova virasse mais um produto que parece estruturado na landing page e vira genérico assim que a pessoa entra.

Fixed authored sprints foram úteis até deixarem de ser.

O problema real apareceu quando um learner passava por um sprint, mas o gap real seguinte não era o próximo sprint authored do catálogo.

A resposta preguiçosa teria sido:

"Deixa o modelo inventar o próximo sprint: title, rubric, review criteria, tudo."

Eu não confiava nisso.

Então o sistema precisou ficar mais estrito.

Agora o reviewer ainda consegue recomendar o canonical next sprint quando o caminho authored faz sentido. Ele consegue atribuir um adaptive detour, um sprint temporário que ajuda o learner a corrigir uma foundation gap antes de voltar para o caminho principal. E quando o próximo gap real fica fora do authored catalog, ele pode pedir um composed sprint.

Isso parece pequeno em um blog post.

Num produto, não é pequeno.

Porque um composed sprint não é apenas "texto dinâmico".

Ele precisa criar um sprint placeholder, persistir a atribuição, preservar o return path para a roadmap canônica, preencher o sprint packet e depois deixar o resto do sistema tratar esse sprint como real product state.

A constraint que tornou isso confiável era bem simples:

o modelo não pode inventar o padrão.

O composed sprint preenche apenas o packet: title, summary, context, assignment, example.

O submission schema e a review rubric continuam vindo de um authored template sprint.

Essa foi uma das maiores lições de todo esse build.

Se você quer que algo dinâmico continue confiável, mantenha o contrato fixo e deixe o modelo operar dentro dele.

Foi também uma parte em que o Codex me ajudou muito. Não de um jeito flashy, do tipo "olha o que ele gerou". Mas de um jeito muito mais útil: migrations, router logic, placeholder lifecycle, request state, integration tests e todo aquele trabalho chato de contratos que faz um produto dinâmico parecer menos fake.

E eu também preciso admitir que a versão preguiçosa me tentou, pelo menos por um instante. Deixar o modelo ser clever. Deixar o sistema parecer magical. Arrumar depois. A ideia parece ótima até você se imaginar explicando uma sprint assignment ruim para um usuário pagante.

2. Retrieval precisava ser curricular, não só semantic

No momento em que eu deixei o sistema compor sprints, a qualidade de retrieval deixou de ser um detalhe de backend.

Ela virou qualidade de curriculum.

Se o produto fosse compor um sprint sobre tooling, measurement ou competitive intelligence, ele não podia simplesmente puxar chunks "mais ou menos relacionados" da knowledge base e torcer para o packet parecer coherent.

A knowledge base precisava ficar mais inteligente.

Nós reconstruímos tudo a partir do corpus real: blog posts, course modules, transcripts, companions, templates e recursos mais profundos.

Depois fizemos chunking dessas fontes de forma diferente dependendo do tipo de material.

Blog posts narrativos podiam continuar maiores.

Instructional modules precisavam de chunks guiados por heading.

Templates e reference assets precisavam de chunking mais estruturado, para preservar tables, checklists, slide references e quick-reference sections em vez de achatar tudo em parágrafos genéricos.

Depois veio o tagging.

Não apenas "sobre o que isso fala?", mas também:

que tipo de chunk é esse
quais topic tags combinam com ele
para qual audience ele serve
a que difficulty level ele pertence

Isso transformou retrieval de "nearest vector wins" em algo bem mais próximo de curricular matching.

O produto passou a poder pedir algo como:

"Me traga material grounded para este topic, para esta audience, neste nível."

Esse é um sistema bem mais sério do que simplesmente colar RAG em uma demo.

3. Evals precisavam testar a pipeline, não só o modelo

Eu não queria declarar vitória só porque um composed sprint parecia decente na UI. Então o sistema de evals precisou crescer junto com o produto.

Primeiro, um sprint review eval harness. Depois a composition ganhou um retrieval gate, um pass/fail check para ver se o tagged retrieval realmente estava melhorando o grounded material em comparação com a baseline sem tags. Depois um harness end-to-end completo: compor o sprint packet, gerar synthetic submissions válidas para o schema, rodar o reviewer real em cima dessas submissions e julgar os resultados em grounding, audience differentiation, difficulty gradient, curriculum coherence, review quality e comparação com authored work.

O objetivo era impedir que "personalized progression" virasse fake personalization. Se o sistema fosse dizer "este próximo sprint é realmente para você", ele precisava de mais do que um packet bonitinho. Precisava de evidência:

o packet ficou grounded?
o track framing realmente mudou o work product?
level 2 e level 5 ficaram materialmente diferentes?
o reviewer continuou acertando o pass/revise?
o composed sprint continuou parecendo parte do curriculum, e não algo flutuando ao lado?

Esse loop revelou problemas reais. Revise submissions fracas que ainda assim continuavam fortes demais. Audience framing que colapsava entre tracks. Packets de measurement que soavam bem mas não respondiam a perguntas de confiança diferentes para learners diferentes.

Um dos momentos mais humilhantes para mim foi perceber quantas vezes alguma coisa podia parecer "bem boa" na UI e ainda assim quebrar assim que eu fazia uma pergunta mais dura. Um packet podia soar fluido e continuar genérico demais. Um revise case podia parecer plausível e ainda assim fácil demais. Isso fez bem para o meu ego, eu acho.

O sistema não melhorou porque eu tive um bom prompt. Ele melhorou porque o produto podia falhar na minha frente, dentro de um eval harness, antes de falhar na frente dos usuários. Não foi um milagre. Foi um loop controlado.

4. Os pontos em que a confiança é testada precisavam ser reais

Aqui também é onde produtos reais se separam de demos.

Ninguém liga para o quão elegante está sua camada de AI se:

email confirmation quebra
Google sign-in é instável
o usuário fica preso num auth loop
faltam abuse controls
account hardening parece um detalhe de última hora

Na Prova, essa camada de credibilidade acabou incluindo:

email confirmation que leva as pessoas de volta para o fluxo certo do produto
Google SSO
app-based two-factor auth opcional (TOTP MFA)
proteção com Turnstile em auth e assessment

Esse é o tipo de trabalho de que quase ninguém se gaba, porque soa operacional e chato.

Eu acho que isso é um erro.

É justamente no operacional e no chato que produtos ganham confiança ou a perdem em silêncio.

5. Billing precisava ser testável, não só imaginável

Eu ando cada vez mais cético com builders que falam de monetization como se ela estivesse a um screenshot do Stripe de estar resolvida.

Billing fica real muito rápido.

Não se trata apenas de:

"Alguém consegue pagar, tecnicamente?"

Trata-se também de:

o que acontece durante o trial state
o que acontece quando o webhook state chega tarde
como testar com segurança sem fazer teatro na própria superfície de receita
como verificar o flow inteiro sem inventar exceções one-off que deixam o sistema menos confiável depois

A Prova agora tem um subscription flow real e também um internal QA checkout path justamente para verificação de billing com mais segurança. Isso pode soar pequeno. Não é. Quanto mais sério o produto fica, mais você precisa de maneiras de testar a lógica comercial sem mentir para si mesmo sobre o que foi ou não foi verificado.

6. Operations precisavam virar parte do produto

Uma das coisas que fez a Prova parecer real para mim foi eu ter precisado tratá-la como um sistema operacional separado, e não como um feature encaixado dentro do meu site atual. Separate production system, separate Supabase project, separate Vercel project, separate auth configuration, separate billing setup, separate release gates.

Essa frase não é sexy. Também é, provavelmente, a frase que mais importa.

Porque produtos não quebram só na camada de UI. Eles quebram onde sistemas se encontram, onde premissas vazam, onde environments se desalinham, onde alguém diz "a gente arruma isso depois do launch" e depois essa versão de pós-launch nunca chega de verdade.

Quanto mais eu trabalhava na Prova, mais eu respeitava frases operacionais e entediantes.

Se você quiser um teste de pressão rápido para o seu próprio AI product, pergunte:

que padrão continua fixo quando o modelo fica dinâmico
que retrieval mantém o output grounded
que eval pega fake personalization antes de um usuário
qual edge de auth, billing ou state te envergonharia amanhã

Se essas respostas ainda estão nebulosas, o produto provavelmente ainda é mais demo do que sistema.

A prova que realmente importa

Eu não quero falar de productization só no abstrato, porque isso faz a coisa soar mais filosófica do que ela realmente é.

A prova mais importante não é "quantas migrations eu escrevi?"

É: o que já funciona para um usuário real?

Nesta fase de soft launch, o produto agora pode dizer de forma crível:

email signup, confirmation e password recovery funcionam
Google SSO funciona
TOTP MFA opcional funciona
downloadable resources e signed downloads funcionam
sprint submission e AI review funcionam em production
Stripe checkout handoff e billing portal access funcionam

Essa é a camada de prova voltada para quem compra.

Embaixo disso, também existe prova de sistema no repo e no rollout:

4,390 knowledge-base rows em production publicadas e tagueadas para composition retrieval
um tagged retrieval gate vencendo a baseline sem tags
uma 18-case composition eval suite completa passando pelo seu gate
um internal QA checkout path mais seguro para verificar billing

O que eu ainda não tenho é prova externa ampla, vinda de um conjunto significativo de usuários, dizendo: "isso mudou meus resultados." Ainda é cedo demais para isso, e eu não quero fingir.

Eu estou listando isso porque é muito fácil subestimar o que realmente significa "transformar uma ideia em produto" quando você só fala em linguagem de launch.

O importante não são as contagens em si.

É o que elas representam:

o sistema de sprints deixou de ser decorativo
retrieval deixou de ser difuso
evaluation deixou de ser performativa
o product state ficou durável o bastante para ser confiável

Trabalho invisível continua sendo trabalho.

E geralmente é o trabalho mais duro.

O que isso mudou na minha cabeça

Eu ainda acho que AI tools importam. Claro que importam. O Codex foi útil nesta fase porque parecia competente, cuidadoso e metódico, bom em me ajudar a atravessar trabalho de engineering sem muito teatro emocional. O Claude ainda me parece melhor quando o trabalho fica mais ligado a gosto, mais criativo. O veredito completo dos 30 dias com Codex vem em May 2, 2026, e esse post vai ser o lugar certo para a timeline de custos, a história dos limits e o que mudou no meu modelo de trabalho no dia a dia.

Mas a Prova me empurrou para uma conclusão mais importante do que qualquer comparação de tools.

AI pode acelerar a implementação. Mas não elimina a necessidade de julgamento sobre boundaries do produto, sequencing, credibilidade e verdade operacional. Esse julgamento continua sendo o trabalho.

Landing page não é produto. Conceito com nome não é produto. Componente gerado definitivamente não é produto.

Para mim, o que faz algo começar a parecer produto é a arquitetura invisível em volta da experiência visível. No momento em que usuários reais podem entrar, pagar, progredir, travar, se recuperar, enviar trabalho e confiar no state que estão vendo, você deixa de brincar com uma demo. Você passa a fazer promessas.

É nas promessas que product building fica sério. Essa é a parte que eu respeito muito mais agora, e acho que é dessa parte que mais builders deveriam falar.

Perguntas frequentes

O que é a Prova?

Prova agora é um produto de coaching estruturado para marketers e profissionais de publicidade que querem um caminho mais sério para trabalho com AI. Atualmente tem dois entry paths mais claros. O Operator path é para redesenho de workflow, measurement e julgamento de rollout. O Builder path é para entregar uma primeira fatia útil, e agora passa por um Build Reality Check, um Build Brief, um Build Plan, uma execution lane e um launch gate. Por baixo dos dois paths, o produto real continua sendo assessment, onboarding, sprint progression, review logic, resources, billing, auth e product state funcionando juntos, em vez de uma única chat box de AI fingindo ser o sistema inteiro.

O que é um composed sprint na Prova?

Um composed sprint é um sprint packet gerado para um gap real de learner que fica fora do authored catalog atual. A constraint importante é que o modelo não inventa sozinho o padrão. O packet é dinâmico, mas o submission schema e a review rubric continuam vindo de um authored template sprint.

Por que AI product building fica mais difícil depois da demo?

Porque, no momento em que usuários reais podem se cadastrar, pagar, se recuperar de erros, enviar trabalho e confiar no state que estão vendo, o produto começa a fazer promessas. A partir daí, os sistemas invisíveis em volta da camada de AI, como auth, qualidade de retrieval, evals, billing e operations, importam mais do que aquele primeiro output impressionante de uma demo.

Se você está construindo com AI agora, eu realmente queria saber:

qual foi o primeiro momento em que o seu projeto ficou desconfortavelmente real, o momento em que uma demo virou uma promessa?

E isso da minha parte.

Cheers, Chandler