Prova を出すうえで、code は簡単なほうだった

Prova が real だと感じ始めたのは、product がもう私に自分をだます余地を残してくれなくなった瞬間でした。

Homepage は、かなり長い間 aspirational なままでいられます。

でも live product はそうはいきません。

People が signup し、email を確認し、wrong state に landing し、billing に触れ、work を submit し、そして system が何が起きたのかを正しく覚えていると期待し始めた瞬間、bottleneck は変わります。

Product は real promises を持ち始めます。そして invisible work が一気に visible になります。

2026年4月16日の update: この post の最初の版を書いて以降、Prova はすでに Operator/Builder の split がより明確な方向へ動きました。メインの thesis はそのまま保ちつつ、product 固有の details は今 live なものに合うように下で update しました。

3月から4月初めにかけて、Claude Max から Codex へ切り替える話を私が続けて書いていたのを読んだ人なら、あの experiment がまだ続いていることを知っていると思います。Proper な follow-up は May 2, 2026 に出すと約束しました。これはその post ではありません。

Prova を知らない人のために書いておくと、これは marketers と advertising professionals のための coaching product で、workflow redesign に向けた Operator path と、最初の useful な slice を ship するための Builder path があります。

この push で本当に難しかったのは、LLM に code を generate させることではなく、code の周りにある全部でした。

もし今 AI と一緒に何かを build していて、それが real users、real money、real product state に関わるものなら、これこそ nobody warns you about な部分だと思います。

Naming は簡単だった

正直に言うと、Prova という名前を決めるのは easy part でした。Prova は proof や test を意味し、product の actual job、つまり builder になった気分を与えるのではなく、実際に work を prove させること、にちゃんと合っていたからです。

Hard part はその直後から始まりました。Prova がただの名前や landing page ではなくなった瞬間、real products が必ず要求する unglamorous なものを全部求め始めたからです。

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

それが、AI tools と product building の両方に対する私の見方を変えました。

Prova が本当に何にならなければいけなかったのか

Prova は今、この post の最初の draft を書き始めた頃より opinionated な product になっています。Surface は二つのはっきりした entry path に split しました。Workflows を redesign している人のための Operator path と、最初の useful な slice を ship しようとしている人のための Builder path です。Builder 側では、今それは Build Reality Check、Build Brief、Build Plan、build が動いている間の execution lane、そして real user に見せる前の launch gate を意味します。

その cleaner な surface の下では、harder system work は、この post を draft していた時と同じ point のままです。Assessment と onboarding、chat-first ではなく sprint-first な product、review-driven progression、durable product state、そして generic な AI chat box ではなく、current sprint の周りで office hours のように振る舞う mentor layer。そこは変わっていません。

念のため言っておくと、私は Prova が「done」だと言っているわけではありません。そう言って move on できたら楽ですが、それは少し convenient すぎるし、おそらく正しくありません。今の right framing は still controlled launch です。Billing portal と recovery flows は live ですが、open work は basic な product plumbing から、Builder path、execution lane、launch gate を real な usage の下でより honest にしていく方向へ shift しました。むしろその方が、この lesson は less ではなく more useful になると思います。これが real world の product building です。Finished ではない。でも fake でもない。次の mistakes に cost が生まれるくらいには real です。

Generate できなかった仕事

AI product の easiest version は demo version です。

見た目だけならすぐ alive にできます。

• homepage
• chat box
• slick screenshots
• persuasive な product sentence

それは launch teaser としては useful です。

でも real work を理解するには向いていません。

私にとって、real work が顔を出したのは六つの場所でした。

1. Sprint system が pretending をやめる必要があった

私は Prova を、landing page では structured に見えるのに、中へ入ると generic になる product にしたくありませんでした。

Fixed authored sprints は、十分な間は useful でした。

でも real problem は、learner がある sprint を pass しても、次の real gap が catalog の next authored sprint ではない時に現れました。

Lazy answer はこうです。

"Let the model invent the next sprint: title, rubric, review criteria, everything."

私はそれを trust できませんでした。

だから system はもっと strict になる必要がありました。

今の reviewer は、authored path が correct なら canonical next sprint を recommend できます。Known な foundation gap が出たら adaptive detour を assign できます。これは learner が main path に戻る前に foundation issue を fix するための temporary sprint です。そして next real gap が authored catalog の outside にある時は、composed sprint を request できます。

Blog で書くと small に見えます。

でも product の中では small ではありません。

Composed sprint は単なる dynamic text ではないからです。

Placeholder sprint を create し、assignment を persist し、canonical roadmap への return path を preserve し、sprint packet を fill し、その後 system 全体がそれを real product state として扱える必要がある。

この仕組みを still trustworthy にした constraint は simple でした。

model does not get to invent the standard.

Composed sprint が fill するのは packet だけです。title、summary、context、assignment、example。

Submission schema と review rubric は、still authored template sprint から来ます。

それが今回の build で得た biggest lessons の一つでした。

Dynamic なものを trustworthy のまま保ちたいなら、contract は fixed にして、model はその中で operate させる。私は今そう考えています。

ここは Codex がかなり役に立った場所でもありました。Flashy な "look what it generated" ではなく、もっと useful な意味で。Migrations、router logic、placeholder lifecycle、request state、integration tests。Dynamic product を less fake にする boring contract work です。

しかも私は、一瞬だけですが、lazy version に引かれました。Model に clever でいてもらえばいい。System を magical に見せればいい。後で片付ければいい。でもその考えは、paying user に bad sprint assignment を説明する自分を想像した瞬間、急に弱くなりました。

2. Retrieval は semantic なだけでは足りず、curricular である必要があった

System に composed sprints を作らせるようになると、retrieval quality は backend detail ではなくなりました。

Curriculum quality になったのです。

Tooling、measurement、competitive intelligence の sprint を compose するなら、knowledge base から "kind of related" な chunks を拾って packet が coherent に見えるよう祈る、では済みませんでした。

Knowledge base 自体が smarter になる必要がありました。

Blog posts、course modules、transcripts、companions、templates、deep-dive resources。Real corpus から全部 rebuild しました。

その上で source の種類に応じて chunking を変えました。

Narrative blog posts は larger chunks のままでいい。

Instructional modules には heading-first instructional chunks が必要。

Templates や reference assets には、tables、checklists、slide references、quick-reference sections を preserve する structured chunking が必要でした。

そして tagging です。

単に "what is this about?" ではなく、

• これはどんな chunk か
• どの topic tags が fit するか
• どの audience 向けか
• どの difficulty level に属するか

という layer が必要でした。

その結果 retrieval は "nearest vector wins" ではなく、curricular matching に近いものになりました。

Product はこう聞けるようになったわけです。

"この topic、この audience、この level に対して grounded material を出して。"

それは demo に RAG を bolt しただけのものより、ずっと serious な system でした。

3. Evals は model だけでなく pipeline を test する必要があった

UI 上で one composed sprint が decent に見えたからといって、victory を宣言したくなかったのです。だから eval system も product と一緒に grow しなければならなかった。

最初は sprint review eval harness。そこに composition が retrieval gate を加えました。Tagged retrieval が untagged baseline より実際に grounded material を改善しているかを見る pass/fail check です。さらに full end-to-end harness も加わりました。sprint packet を compose する、schema-valid な synthetic submissions を generate する、real reviewer を走らせる、grounding、audience differentiation、difficulty gradient、curriculum coherence、review quality、authored work との comparability で judge する。

狙いは "personalized progression" が fake personalization に落ちるのを防ぐことでした。System が "this next sprint is actually for you" と言うなら、packet が decent-looking というだけでは足りません。Evidence が必要でした。

• packet は grounded か
• track framing は really work product を変えたか
• level 2 と level 5 は materially different か
• reviewer は still right pass/revise call をしたか
• composed sprint は curriculum の中に belong している感覚を still 持てているか

この loop は real problems を露出させました。Weak な synthetic revise submissions が still too strong だったり、audience framing が tracks across で collapse したり、measurement packets が fine に聞こえるのに、different learners の different trust questions に答えていなかったり。

しかも humble だったのは、UI 上で "pretty good" に見えるものが、stricter question を投げた瞬間に fail する場面を何度も見たことです。Packet は smooth に読める。でも generic すぎる。Revise case は plausible。でも easy すぎる。自分の ego には useful でした。

System が better になったのは one good prompt があったからではありません。Product が public-to-users の前に、public-to-me な場所、つまり eval harness の中で fail できたからです。一つの miracle ではありませんでした。Controlled loop でした。

4. Trust surfaces は本物でなければいけなかった

ここもまた、real products が demos と分かれる場所です。

AI layer がどれだけ elegant でも、もし

• email confirmation が break する
• Google sign-in が flaky
• user が auth loop に trapped される
• abuse controls が missing
• account hardening が afterthought に見える

なら、誰も気にしません。

Prova の credibility layer は最終的にこうなりました。

• right product flow に戻る email confirmation
• Google SSO
• optional app-based two-factor auth (TOTP MFA)
• auth と assessment の Turnstile protection

People はこういう work を operational で boring に聞こえるから brag しません。

でも私は、それは mistake だと思っています。

Operational and boring な場所こそ、products が trust を earn するか、quietly lose するかの分かれ目です。

5. Billing は imaginable ではなく testable でなければならなかった

私は、monetization を one Stripe screenshot で solve したかのように語る product builders に increasingly skeptical です。

Billing はすぐ real になります。

Question は

"technically pay できるのか?"

だけではありません。

• trial state の間に何が起きるか
• webhook state が late に arrive したらどうなるか
• 自分の revenue surface で theater をせずに、どう safe に test するか
• later に reliability を落とす one-off exception を invent せずに、どう whole flow を verify するか

Prova には今、real subscription flow と、safer billing verification のための internal QA checkout path があります。Minor に聞こえるかもしれません。でも違います。Product が serious になるほど、commercial logic を test しながら、自分に嘘をつかない方法が必要になります。

6. Operations は product の一部にならなければいけなかった

Prova が real だと感じた reasons の一つは、existing site に tuck した feature ではなく、different operational system として扱わなければならなかったことです。Separate production system、separate Supabase project、separate Vercel project、separate auth configuration、separate billing setup、separate release gates。

Sexy な sentence ではありません。でも、たぶんこれがいちばん重要な sentence です。

Products は UI layer だけで break するわけではありません。Systems が touch するところ、assumptions が leak するところ、environments が drift するところ、誰かが "we will fix that after launch" と言って、その after-launch version が never really comes になるところで break します。

Prova をやればやるほど、私は boring operational sentences を respect するようになりました。

自分の AI product に fast pressure test をかけたいなら、こう聞いてみてください。

• model が dynamic になっても fixed のまま残す standard は何か
• output を grounded に保つ retrieval は何か
• user より前に fake personalization を catch する eval は何か
• 明日起きたら embarrassing な auth、billing、state edge はどこか

If those answers are fuzzy, product はまだ system より demo 寄りだと思います。

本当に大事な Proof

私は productization を abstractions だけで話したくありません。そうすると、実際以上に philosophical に聞こえてしまうからです。

The proof that matters most は "how many migrations did I write?" ではありません。

今、real user に対して何が actually works しているかです。

この soft-launch phase の時点で、product は credibly 次のことを言えます。

• email signup、confirmation、password recovery が works
• Google SSO が works
• optional TOTP MFA が works
• downloadable resources と signed downloads が works
• sprint submission と AI review が production で works
• Stripe checkout handoff と billing portal access が works

これが buyer-facing layer の proof です。

その underneath には、repo と rollout work に基づく system proof もあります。

• composition retrieval のために 4,390 production knowledge-base rows が published and tagged 済み
• tagged retrieval gate が untagged baseline に勝っている
• full 18-case composition eval suite が gate を pass 済み
• billing verification のための safer internal QA checkout path がある

まだ持っていないものもあります。Meaningful な batch の users が "this changed outcomes for me" と言う broad external proof はまだありません。まだ早すぎるし、そこを fake にしたくありません。

それでも numbers を並べるのは、launch language だけで語ると、「idea を product にする」ことが実際に何を意味するのかを underestimate しやすいからです。

Important なのは counts そのものではありません。

Counts が何を表しているかです。

• sprint system が decorative でなくなった
• retrieval が fuzzy でなくなった
• evaluation が performative でなくなった
• product state が rely できる程度には durable になった

Invisible work is still work.

たいてい、それが harder work です。

この経験が私の頭の中で変えたこと

AI tools が matter するとは今でも思っています。もちろんです。Codex は、この push では useful でした。Competent で careful、methodical に感じたからです。Engineering work を move through するのに役立ちましたし、あまり emotional theater がありませんでした。Claude の方が still better だと感じるのは、work が taste-heavy で creative になる時です。Full 30-day Codex verdict は May 2, 2026 に publish 予定で、cost timeline、limits story、day-to-day working model がどう変わったかは、その post で話します。

でも Prova は、どんな tool comparison よりも重要な conclusion に私を押しました。

AI は implementation を accelerate できます。でも product boundaries、sequencing、credibility、operational truth についての judgment を不要にはしません。That judgment is still the work.

Landing page は product ではない。Named concept も product ではない。Generated component は definitely not a product です。

私にとって、何かが product っぽく感じ始めるのは、visible experience の周りに invisible architecture が立ち上がった時です。Real users が入り、pay し、progress し、block され、recover し、work を submit し、見えている state を trust し始めた瞬間、もうあなたは demo で遊んでいません。Promises をしているのです。

そして私は、product building が serious になるのは promises のところからだと思っています。今の私は、その part を以前より much more respect していますし、その part こそもっと builders が話すべきだと思います。

よくある質問

Prova とは何ですか？

Prova は今、AI work へのより serious な path を求めている marketers と advertising professionals のための structured coaching product です。現在は二つのはっきりした entry path があります。Operator path は workflow redesign、measurement、rollout judgment のための path です。Builder path は最初の useful な slice を ship するための path で、今は Build Reality Check、Build Brief、Build Plan、execution lane、そして launch gate を通っていきます。両方の path の下にある real な product は still、assessment、onboarding、sprint progression、review logic、resources、billing、auth、product state が一緒に動いていることであって、一つの AI chat box が system 全体のふりをしていることではありません。

Prova の composed sprint とは何ですか？

Composed sprint は、current authored catalog の outside にある real learner gap に対して generate される sprint packet です。Important なのは、model が standard 自体を invent しないことです。Packet は dynamic ですが、submission schema と review rubric は still authored template sprint から来ます。

なぜ AI product building は demo の後の方が難しくなるのですか？

Real users が signup し、pay し、errors から recover し、work を submit し、見えている state を trust し始めた瞬間、product は promises を持ち始めます。その時点で、AI layer の周りにある invisible systems、つまり auth、retrieval quality、evals、billing、operations の方が、demo の first output が impressive に見えたかどうかより大事になります。

今 AI と一緒に何かを build しているなら、私は genuinely curious です。

あなたの project が uncomfortable なほど real に感じ始めた最初の瞬間、つまり demo が promise になった瞬間は何でしたか？

今日はここまでです。

Cheers, Chandler