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.

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, e pretendo cumprir essa promessa. Este post não é aquele post.

Mas a Prova me forçou a perceber algo mais útil antes do que eu esperava:

Quando uma coisa deixa de ser uma ideia com nome e começa a virar um produto real, o bottleneck muda.

Pelo menos foi assim que eu senti neste build.

A parte difícil não era fazer um LLM gerar code.

A parte difícil, pelo menos nesta fase para mim, 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.

A lição mais útil é outra: o que passa a importar quando um produto deixa de ser apenas uma demo.

O nome foi a parte fácil

Preciso admitir: dar o nome Prova foi uma das decisões mais fáceis de todo o processo.

O nome encaixou porque ele realmente combinava com o produto.

Prova significa algo como prova ou teste. E esse é, basicamente, o trabalho do produto. Ele não existe para massagear o ego de ninguém nem para fazer alguém se sentir builder antes da hora. Ele existe para fazer a pessoa provar o trabalho. Soa bem, é útil, é searchable. Em outras palavras, essa era a parte fácil.

A parte mais difícil começou logo depois. Porque, 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 programa estruturado para AI builders, voltado para marketers e profissionais de publicidade que querem sair do "usar AI tools" para "construir workflows, pilotos e operating systems reais". Na prática, isso significou 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 honesto hoje é soft launch: o core production system está live e funcionando, mas ainda existe trabalho intencional de launch readiness na lista, incluindo cleanup do return path do billing portal e uma cobertura mais completa de MFA automation. 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

Talvez essa tenha sido a lição mais importante de todas.

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 havia o sprint review eval harness.

Depois a composition ganhou um retrieval gate, basicamente 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 a composition ganhou 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
julgar os resultados em grounding, audience differentiation, difficulty gradient, curriculum coherence, review quality e comparação com authored work

Esse foi o learning loop real.

Em português simples, 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 de que o sprint estava grounded, apropriado para o nível e ainda podia ser revisado pelos mesmos padrões do curriculum authored.

Não era "o modelo devolve JSON ou não?"

Era mais:

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.

E é por isso que acho essa parte tão importante.

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.

Boa parte do aprendizado real aconteceu num loop bem apertado entre 8 e 10 de abril:

schema groundwork
composed sprint lifecycle
tagged knowledge rebuild
retrieval gate
composition calibration
full eval pass
integration coverage
browser QA no fluxo live

Essa sequência importa.

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 e confirmation 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 funciona

Essa é a camada de prova voltada para quem compra.

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

17 Supabase migrations aplicadas através do bootstrap atual de schema em production
4,390 knowledge-base rows em production publicadas e tagueadas para composition retrieval
38 downloadable resources publicados
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

Eu não estou listando esses números para parecer ocupado.

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. Ele me ajudou 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.

Mas a Prova me empurrou para uma conclusão mais importante:

Eu acho que 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.

Interface de chat 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.

E eu acho que é nas promessas que product building fica sério.

Esta é a lição de abril que me parece mais útil

Eu ainda devo o veredito completo dos 30 dias com Codex em May 2, 2026, e pretendo publicar isso nessa data.

Esse post vai ser o lugar certo para a timeline de custos, a história dos limits, o que senti falta no Claude e o que mudou no meu modelo de trabalho no dia a dia.

Mas a Prova já me ensinou algo mais duradouro do que uma comparação de tools:

A parte interessante de AI product building raramente é a demo.

É o ponto em que o seu system começa a fazer promessas reais para users e você percebe quantas dessas promessas moram fora do code gerado.

Eu respeito muito mais essa parte agora.

E, honestamente, acho que é dessa parte que mais builders deveriam falar.

Perguntas frequentes

O que é a Prova?

Prova é um programa estruturado para AI builders, pensado para marketers e profissionais de publicidade que querem sair do uso de AI tools para a construção de workflows, pilotos e operating systems reais. Em termos de produto, isso significa 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