プロのバイブコーダー:コーディング経験ゼロのラザール・ヨヴァノヴィッチは、AIでどうやって本番ソフトウェアを出荷しているのか

ラザールはこの仕事を「夢の仕事」と呼ぶ。どのみちやっていたであろうことをして、お金がもらえるからだ。彼はLovableなどのツールを使い、社内外向けのプロジェクトを本番環境にまで持っていく。仕事の幅は、マーケティングや営業向けのテンプレートから、多数の連携を持つ社内ツールまでさまざまだ。彼はこれを「アイデアの役割」だと表現する。良いアイデアを持っている人は多いが、作り方を知らないか、作る時間がない。彼の仕事は、そうしたアイデアを、本番に必要な品質とセキュリティを備えた動くソフトウェアへと素早く変えることだ。

彼の仕事の一部は公開されている。LovableがShopify連携をリリースした際、ユーザーがリミックスしていたテンプレートのほとんど、あるいはすべてを作ったのは彼だ。また、LovableとShopifyが誰でも使えるほど簡単に連携できることを示すため、Lovableのグッズストアもバイブコーディングで作った。番組で彼が着ているシャツを買った人は、彼が作ったストアで買ったことになる。社内向けの例としては、新機能ごとに何人が使っているかを追跡するための、会社が求めている機能利用状況マトリクスを挙げている。Lovableの技術スタックは独自性が高く、既製品ではうまく合わないという。さらに彼は、ベンダーのエンタープライズアカウントの設定に1〜2時間かかるなら、自分でツールを作った方が早いという段階に達しており、「作る側」にいるのだと付け加える。

彼は最初グロースチームに所属していた。Lovableのグロース責任者であるエレナ・ヴェルナが彼を招き入れたのは、彼女には多くのアイデアがあり、それを本番まで持っていくマインドセット、スピード、オーナーシップを持った人材が必要だったからだ。それ以来、「どの部署も今すぐ、いや昨日のうちにラザールが必要だ」という状態だと彼は言う。現在はGo-to-Market領域の仕事に移りつつあり、エンタープライズチーム向けの社内ツールを作り、コミュニティ向けのツールにも取り組んでいる。大まかなコンセプトを渡され、できるだけ早く形にしてほしいと頼まれるときにこそ力を発揮するのだという。

ラザールは、技術的なバックグラウンドがないことはむしろ有利だと主張する。「自分のような人間は、XYZを作ってはいけないということを知らない」から、そのまま作ってしまうのだ。彼が挙げる例は、収録の6〜7カ月ほど前のことだ。Lovableのコミュニティで、LovableでChrome拡張機能を作れたらいいのにと言う人がいた。技術系の人たちは、スタックが違うことなどを理由に、それが無理な理由を説明した。一方、ラザールを含む非技術系の人たちは、ただLovableにアプリからChrome拡張機能を作ってほしいと頼んだ。そして、それはうまくいった。他にも、理論上は不可能なはずのデスクトップアプリケーションをLovableで作った人たちがいたという。

もう一つの例は、Lovableのコミュニティマネージャーの話だ。彼女はプレゼン資料を作っている途中、これを動画にできないかと思いつき、まだサポートされていない機能だったにもかかわらず、プロンプトを工夫してLovableの中で実際の動画を生成してしまった。今では正式な機能になっているが、当時はラザールでさえ不可能だと思っており、試したこともなかった。彼によれば、自分たちのような人間は「まったく先入観がなく、とてもポジティブに妄想的」な状態で入ってくる。そしてそれは、AIツールを扱ううえで必要な姿勢だという。間違いだと証明されるまでは、何でも可能だと考えることだ。

レニーは、非技術系のビルダーについてよく聞かれる2つの懸念を持ち出す。行き詰まったときにどう抜け出せばいいか分からないかもしれないこと、そしてアーキテクチャやスケーリングを理解していないために、壊れやすい「スロップ(粗悪なもの)」を作っているかもしれないことだ。ラザールは、最も重要な答えは自己認識だと言う。何が作れるかについて彼は「妄想的」だが、それらのプロジェクトを成功させるには自分自身が成長しなければならないことも分かっている。

解決すべき問題はコーディングではないと、彼は早い段階で気づいたという。問題は明確さだ。AIの出力はすでに人間より速いので、重要なのは自分が何を望んでいるかを分かっていることだ。Lovableに入って2日目から彼はチャットモードを頼りにしており、今でも時間の約80%を計画とチャットに、実行には20%しか使っていないという。「ほとんどの人は間違った」種類のスピードを最適化している、と彼は言う。ツールは関係ない。Cursorを使おうが、Claude Codeを使おうが、Lovableを使おうが、問題は同じだ。AGIはまだ来ていないので、舵を取るのは依然として人間なのだ。

彼はツールを技術系の共同創業者であり教師でもある存在として扱い、作ることで学び、コードではなくエージェントの出力を「欠かさず」読む。構文には興味がなく、現在のモデルが出力するコードを信頼しているという。ただし、他の人はそこまで自信を持てないかもしれないことも認めている。彼が注意深く見ているのは、エージェントが自分に何を伝えているかだ。それは、回避したい2つの制約があるからだ。

ラザールは、この2つの制約をアラジンの物語で説明する。ランプの魔人が叶えてくれる願いは3つであって、3000ではない。彼にとってこれは、マシン側の制約、つまりコンテキストウィンドウを表している。AIが1回のリクエストで、読み込み、調査、思考、実行をうまくこなせる量には限りがある。彼は説明のために10万トークンという適当な数字を使う。その一部は読み込みに、一部はブラウジングに、一部は思考に、一部はコードを書くことに使われる。これは1年以内に変わるかもしれないが、今のところトークンが制約になっているという。

2つ目の制約は人間側にある。魔人に背を高くしてほしいと頼んだら、身長13フィート(約4メートル)にされてしまい、車に乗ることも玄関を通ることもできなくなるかもしれない。具体的に頼まなかったからだ。AIは「言いたいこと、分かるでしょ」を理解しない。ラザールは、36歳の自分には人間として36年の経験があり、だから他の人は自分の意図を推測できるが、AIにはそれがまったくないと指摘する。だからこそ、具体的に伝え、参考資料を示し、適切なコンテキストを与える必要がある。コンテキストウィンドウやモデルの品質はコントロールできないが、自分のインプットはコントロールできる。それこそが、彼が教えたいことなのだ。

どうすれば明確さを高められるかと問われ、ラザールは、まずセンスの良さとはどういうものかを理解することから始まると言う。「十分に良い」もの、「世界トップクラス」のもの、「魔法のような」ものの違いだ。彼はこれを、レニーから教わったという「エクスポージャー・タイム(触れる時間)」によって養っている。レニーはこの考えをギレルモ・ラウチに由来するものだとしている。これは、自分の基準を引き上げてくれるコンテンツ、人、プロダクトと意図的に時間を過ごすという実践だ。

彼は自身の成長過程を振り返る。まず、自分にも作れると気づいた。1週間後、自分は十分に速くないと気づき、スピードを最適化した。その数週間後には、そもそもそれを作るべきだったのかを問い始めた。この段階は今も続いているという。AIが「どうやって作るか」を解決してしまえば、それ以外のすべて、つまりデザイン、センス、ユーザー体験が重要になる。人は購入の判断を含め、感情で意思決定をするのだと彼は指摘する。

だからこそ、コーディング経験のない人には、今からコーディングを学び始めるなと伝えているという。「AIの世界では、生の出力が速いことで報われるのではない。より良い判断力で報われるのだ」。また彼は、判断力は良い作品に触れるだけでなく、作ることを通じて鍛えられる筋肉だと強調する。

彼の最初の実践的テクニックは、1つのプロジェクトについて複数のバージョンを並行して立ち上げ、回を重ねるごとに明確さを高めていくことだ。1つ目では、Lovable(どのツールでもよい)を開いて、多くの場合Lovableの音声入力を使って頭の中にあることを全部吐き出し、結果を待たずに送信する。次に、新しいプロジェクトを開き、もう少し構造を持たせる。最初の吐き出しによって、特定の機能や特定のページといった手がかりがいくつか見えてきているからだ。その次は、MobbinやDribbbleのようなサイトから取ってきたスクリーンショットやアニメーションなどの視覚的な参考資料を添付する。ほとんどのツールはファイルを受け付けるからだ。さらにその次は、21st.devのようなライブラリから既存のコードを探し、コードスニペットを添付する。彼の考えでは、たとえ英語が「ナンバーワンのプログラミング言語」だとしても、これらのツールが最もうまくコミュニケーションできるのはやはりコードであり、スニペットはどんな説明よりもピクセル単位で正確な結果に近づけてくれる。

レニーはこのアプローチを、「頭の中の吐き出し、よく考えたプロンプト、デザインの参考資料、コードテンプレートを同時に走らせること」とまとめる。ラザールによれば、こうして行動に移すコストは低く、ビルダー向けクレジットを除けば、ツールの無料プランで済むことも多い。4〜6個のコンセプトを比較することで、白紙のページや、行動を伴わないChatGPTとの会話では得られない明確さが得られる。また、いわゆる「AIスロップ」への対策にもなる。彼によれば、AIスロップとは通常、汚いコードではなくありきたりなデザインのことを指しており、このやり方なら複数のデザインの方向性から選べるからだ。

クレジットを余計に消費するという反論が来ることは彼も予想しており、最初のコストが高くなることは認めている。しかし長期的には、何百ものクレジット、場合によっては何百ドルもの費用と、何日分もの作業を節約できると主張する。延々と修正を続けるのではなく、より明確な状態からプロジェクトを始められるからだ。これがLovableの短期的な利益に反することも認めたうえで、同社のビジネスは人々を延々と修正作業に縛り付けることではなく、作る力を与えることだと言う。このフレームワークを教えた人は皆、目から鱗だったと言うそうだ。彼はハックを発明しようとしたわけではない。エージェントの処理が終わるのを待っている間に、別のプロジェクトを始めただけだった。それが彼がこれほど多くを出荷できる理由でもあるという。普段はLovableのタブを5〜6個開いて、それらを切り替えながら作業している。

では、これほど多くのプロジェクトを切り替えながら、どうやってコンテキストを失わず、質の悪い成果物も出さずにいられるのか。彼の答えは、先ほどの魔人の問題への対処になっている。どのツールでも、メッセージが10件、20件、40件と進むにつれて、会話の初期の部分が失われ始める。エージェントはリクエストのたびにすべてを読み直すことはできないからだ。そこで彼は、ツールを、参考資料を常に供給してもらう必要があるエンジニアのように扱う。

並行して作ったものの中から、何百ものプロジェクトを作ってきた経験があれば、たいてい勝者は明らかだという。プロンプトを1〜2回送って微調整することもある。その後、ツールかChatGPTに一連のPRDを作らせる。彼はこれをプロダクト要求仕様書、つまりプロジェクトが成功するために何が成り立っていなければならないかを示す「信頼できる唯一の情報源」と呼ぶ。少なくとも4つは書くという。

• マスタープラン:何を作るのかを示す羅針盤。
• 実装計画:どのように、どんな順序で作るのかを示すもの。
• デザインガイドライン:システムは「まだ感情的知性を持っていない」ので、見た目や雰囲気を定義する必要がある。
• ユーザージャーニー:ユーザーが登録した後に何が起き、次に何が起き、と順を追ってたどるもの。

彼はこれらすべてに目を通す。計画に使う時間はここに費やされており、必要なら丸1日かけることもあるという。すべてがこれにかかっているからだ。そのうえで、作業をタスクとサブタスクに分解した最終的なplan.mdまたはtasks.mdを作る。Markdownにするのは、AIがMarkdownを読むのを好むと分かったからだ。最後のレイヤーは、エージェントの振る舞いに関する指示だ。Claude CodeやCursorならrules.mdやagent.mdといったファイル、Lovableなら設定内のプロジェクトナレッジがこれにあたる。彼の指示はおおよそ次のようなものだ。何かをする前にすべてのファイルを読むこと、tasks.mdで次のタスクを確認すること、それを実行すること、そして何をしたのか、どうテストすればいいのかを報告すること。

この時点から、彼のプロンプトはほとんど「次のタスクに進んで」だけになる。エージェントの報告を読み、テストし、ときどき介入する。そしてドキュメントを更新し続けることで、エージェントが参照するコンテキストを時間とともに変化させていく。こうして彼は、生産性を落とさずに5つのプロジェクトを同時に回しているのだ。

彼は、この特定の仕事からはすぐにお役御免になると考えている。3カ月ほどでエージェントがこのドキュメント管理をやってくれるようになると予測しており、そのためこのスキルには投資していないという。今は人間とLLMの両方の欠点を補うためにこれを使っているが、「今は時間の100%を、良い判断、明確さ、品質、センス、良いコピー、良いフォントに使っている」。中でもフォントは、AIを使う人がほとんど話題にしないにもかかわらず、出力の見た目の60%以上を左右していると彼は考えている。

ラザールは、こうした構造を省いた場合に何が起きるかを説明する。何かが壊れても、何もドキュメント化されておらず、ユーザーはどのファイルも示さずに症状だけを説明する。するとツールは調査を始める。ファイルが20個ならそれでも問題ない。しかし彼が取り組んでいるプロジェクトには60〜70個のEdge Functionがあり、単に「これが壊れた」とだけ言えば、ツールはトークン割り当ての80%ほどを読み込みに費やし、思考と修正には20%しか残らないだろうと彼は見ている。

ここからの話は専門家ではない自分の推測にすぎず、LLMの専門家なら訂正するかもしれない、と彼ははっきり断っている。彼の見方では、ツールは従順で人に合わせがちであり、ユーザーを喜ばせるために、実際には直していないものを直したと主張することがある。人は機械のせいにするが、明確さやコンテキストを与えなかったのだから「君のせいだよ、友よ」と彼は言う。ユーザーが怒ると状況はさらに悪化する。侮辱を受けた後、モデルが最初にすることがユーザーをどうなだめるかを考えることであり、問題の解決ではなく謝罪に貴重なトークンを費やしている思考過程を読んだことがあるという。彼は、AIが従順さよりも正直さを重視する方向に進み、たとえば「部分的にしか直せなかった」と言えるようになることを望んでいる。

レニーは、コンテキストが残り少なくなると最後の修正が表面的なものになりがちだとラザールが以前話していたことに触れる。ラザールはここでも、証明できることではなく直感だと断ったうえで、自分の経験では、不明確な依頼には「最もお手軽な修正」が返ってくる一方、怪しいと思うファイルをエージェントに示せば本当の修正が返ってくると言う。出典は分からないとしながら、彼はある言葉を言い換えて紹介する。AIの天井はモデルの知能ではなく、モデルが行動する前に何を見ているかで決まる、というものだ。エクスポージャー・タイムは、人間と同じくエージェントにも当てはまるのだと彼は言う。

彼のアドバイスは、プロトタイピングや探索の段階では自由にバイブし、探索が終わったらドキュメントとエージェント用のファイルを使うことだ。トークンは今後安くなるとはいえ、今はまだ貴重だからだ。

レニーは、上達したい人にとっての最小限のバージョンはどんなものかと尋ねる。ラザールはマスタープランを「1万フィート上空からの概観」だと説明する。なぜこれを作るのか、誰のためのものか、使う人にどう感じてほしいのか。マスタープランは他のドキュメントを参照することも多く、たとえば、デザインはモダンで洗練された印象にしたいが、具体的なパラメーターはデザインガイドラインのファイルにある、といった書き方をする。

実装計画は作業の順序を決めるものだ。まずバックエンドとテーブル、次に認証、次にAPI、という具合だ。彼はこれを、アイデアを持つ人が技術系の共同創業者に構想を話し、共同創業者が「そのアイデアは実現できる、大まかにはこういう順序で進めよう」と答える場面にたとえる。詳細な仕様書ではなく、ロードマップなのだ。すべてのドキュメントは最終的にtasks.mdのためにある。それさえできてしまえば、残りはほとんど関係ないとまで彼は言う。

デザインガイドラインには、CSSを少し含めるのが好みだという。AIはデザインに関して「創造的になりすぎる」ことがあり、ここがより技術的な方向付けを加える場所だからだ。ユーザージャーニーはナビゲーションと機能をおおまかに扱い、tasks.mdがそれらすべてを詳細なタスクに落とし込む。彼はChatGPTストアでカスタムGPTを作っている。Lovable PRDジェネレーターとLovableベースプロンプトジェネレーターで、頭の中を吐き出した後に確認の質問をし、これらのファイルを生成してくれる。自分と同じように考えるよう訓練してあるという。

こうしたツールによって、誰もが「ステロイドを打ったプロダクトマネージャー」になりつつあると彼は言う。そして優れたPMは、PRDを書くことではなく判断力に対して報酬を得ているのだと。彼は、これらのどれも作ることの代わりにはならないと強調する。人が上達するのは、今日1つ、2つ、あるいは5つのプロジェクトを始めることによってなのだ。

レニーは、これは大変な作業に聞こえるかもしれないが、本来なら何週間も何カ月もかかるものを手に入れるために数時間から1日を計画に使うのは、とてつもないリターンだと指摘する。これは気軽に依頼を打ち込むのとは違う、プロのバイブコーディングの姿を示している、と彼は言う。

ラザールは、プロトタイピングにはそれ自体に本当の価値があると言う。特に、医療、金融、その他規制の厳しい環境にいて本番に出荷できない人にとってはそうだ。Lovableの2025年のモットーは「メモではなくデモを(demo, don't memo)」だった。ドキュメントを書いて会議を開き、エンジニアにビジョンを説明する代わりに、マーケターや営業担当者が30分でプロトタイプを作って渡せばいい。

彼は、Lovableに入る前の仕事での例を挙げる。前年のちょうど今ごろ、彼はエンタープライズ水準の何かを必要としていたが、当時は彼にもLovableにも、それを本番水準で作ることはできなかった。彼は4時間でプロトタイプを作り、一緒に働いていたエンジニアリングチームが約6〜7カ月後に、すべての配管をつないでそれを本番環境で再現した。言葉で説明していたら少なくとも1〜2週間はかかっただろうと彼は見積もる。2026年1月時点のLovableは、当時使っていたバージョンよりはるかに先を行っているという。

また彼は、自分の知る限り、S&P 500企業の少なくとも半数で、程度の差はあれLovableを使っている人がいると言う。そして多くのエンタープライズ顧客(彼は社名を挙げず、ライドシェア、通信、医療、金融の大手企業と表現している)が同じことを報告しているという。本番にプッシュできなくても、マーケターはもうエンジニアを待たなくなり、Go-to-Market、営業、人事のスタッフが経費管理や従業員のオンボーディングといった用途の社内ツールを作っているのだ。

ラザールは、バックグラウンドに関係なくAIは増幅器だと言う。「自分が何をしているのか分かっていなければ、ゴミをより速く作り出すだけだ」。かつては、何かを作り出すこと自体が難しかったので、十分に良ければそれで十分だった。動くSaaSプロダクトであれば、見た目がどうであれ十分だった。しかし今や誰もがAIで「十分に良い」ものを作れるようになった。だから重要なのは「十分に良い」と「世界トップクラス」の差であり、世界トップクラスの、魔法のような仕事を生み出す方法を学ぶことこそが重要な教訓だと彼は言う。

レニーは、何を作るべきかを明確にするPMのスキルが最も重要になるのではないかと言う。ラザールは、PMが明確さをもたらすことで今AIを使って勝っていることには同意するが、賭けるなら次はデザイナーだと言う。ツールはより良い技術的判断をするよう訓練されつつあるが、より良い感情的判断はまだできない。そして「デザインはすべて感情に関わるもの」だからだ。

彼はLovableでの個人的な最大のスキルアップは、社内のデザイナーたちとの仕事から得たものだと言い、フェリックス、ナッド、アビーの名前を挙げる。あるとき、彼らのデザインの背景をFigmaからコピーしようとした。シンプルなグラデーションに見えたが、実際には色も不透明度も異なる約50枚のレイヤーでできていた。それを見て、自分の思い込みと世界トップクラスの仕事との差を思い知ったという。彼のアドバイスは、優れたデザインに自分をさらすこと、フェリックスのニュースレターを購読すること、デザインスタイルとそのプロンプトの書き方を学ぶことだ。彼自身、バウハウスやグラスモーフィズムが何を意味するのか知らなかったので、約18のスタイルとそれを再現するためのプロンプトをまとめた公開Lovableアプリを作った。

ソフトウェアエンジニアリングはなくなるのかと問われ、ラザールは否定する。「エリートのエンジニアリングは、これまで以上に必要になる」。誰もが何でも作るようになれば、誰かがコードベースを保守し、スケールさせなければならない。それは作ることとは別のスキルだと彼は言う。誰もが作るようになれば、インフラにも負荷がかかる。彼は、ここ数カ月でCloudflareが2〜3回ダウンしたこと、そして新規ユーザーの流入によってLovable自身のインフラにも負担がかかったことを挙げ、砦を守っているのはエリートエンジニアたちだと言う。何十億人ものビルダーが必要とするホスティング、セキュリティ、メール、コネクタ、APIを、誰かが作らなければならないのだ。

一方で、もし18歳の弟がいたら、CSの学位を取るより配管工になることを勧めるだろうとも言う。アメリカでは電気工や配管工が新世代のミリオネアになっていると見ているからだ。彼はこれをバランスの問題だとし、確信はないとしながらも、物事がどこへ向かっているかを理解している優秀なエンジニアは、今後も必要とされ、希少であり続けると考えている。

アプリケーション層については、12カ月以内に「バイブコーディングは単なるコーディング」になると予測し、自分は「ラピッド・エンジニア」と名乗るつもりだと言う。今では多くのエリートエンジニアが、コードはすべてAIが書いていると公言していることにも触れる。彼は手書きのコードを書道にたとえる。芸術になるほど希少なものになるというわけだ。彼の見方では、呼び名はどうあれ、誰もが「良い判断に基づいて、生の出力にはLLMを使う。あるいは悪い判断に基づいて」エンジニアになる。レニーはこれを、かつては別々だったエンジニア、デザイナー、PMという円が収束していく様子だと表現する。

行き詰まりから抜け出すために、ラザールは「4x4」と呼ぶフレームワークを使っている。ぬかるみから車を脱出させる四輪駆動にちなんだ名前だ。アプローチは4つあり、それぞれ1回ずつしか試さない。

1つ目は、ツール自身に修正させることだ。Lovableでは、エージェントがエラーを認識するとメッセージがオレンジ色で表示され、「修正を試みる」ボタンが出る。小さな問題ならたいていこれで解決する。厄介なのは、問題が続いているのにエージェントがそれに気づいていないケースで、多くの場合、ツールが観察する方法を教えられていないサードパーティ連携が原因だ。Lovable、Cursor、Claude Codeはいずれも、認識している問題ならどんなものでも修正できるほど優秀だと彼は言う。だからこそ、認識させることが鍵になる。

2つ目のアプローチは、その認識を加えることだ。プレビュー環境を開き、壊れている機能を実行して、ブラウザのコンソールを読む。役に立つ情報がログに出ていなければ、関連するファイルにコンソールログを追加するようツールに頼み、すべてのステップを観察できるようにする。彼はこれを、ツールに怒鳴るのではなく、一緒に問題を見つけることだと位置づけた。もう一度実行し、ログ履歴をチャットにコピーする。これで「99%の場合」は十分だという。

3つ目のアプローチは、外部のツールを持ち込むことだ。LovableやそれとよくにたツールではGitHubへのコードのエクスポートができるので、コードをエクスポートし、ベータ版の頃から使っているOpenAIのCodexで問題を診断する。そして修正はLovableで適用する。Codexに変更を加えさせないのは、そのエージェントを操れるほど彼がよく知らないからだ。以前の手作業のやり方は、Repomixでコードベース全体を1つのファイルに圧縮し、それを問題とコンソールログと一緒に通常のClaudeやChatGPTにアップロードして診断を依頼するというものだった。彼はこれを外部のコンサルタントを雇うことにたとえる。レニーは、最も難しいバグにはCodexが頼りになると聞いたことがあると付け加え、その趣旨のカルパシーのツイートに触れる。

4つ目のアプローチは、問題は自分のせいだと仮定することだ。ラザールによれば、たいていはそうだという。悪いプロンプトや、うまく組み立てられていない依頼だ。バージョン管理を使って数ステップ戻し、散歩するかコーヒーを飲みに行き、プロンプトを考え直して、もう一度試す。AIはときどき、ちょっとした構文のミスのような「ごく小さな石につまずく」ことがあり、同じ依頼を繰り返すだけでうまくいくこともある。

ラザールが「鍵となるステップ」と呼ぶのは、修正が終わった後のことだ。彼はチャットモードに切り替え、要するにこう尋ねる。「これを直すのに4回かかった。次は1回で直せるように、君へのプロンプトをもっとうまく書くにはどうすればいい?」。返ってくる答えはほぼ必ず良いものだという。彼はさらに一歩進める。2日後にはその教訓を覚えていないだろうから、エージェントがどのみち毎回読むrules.mdにそれを追加するよう頼むのだ。「僕がバカだってことを学んで、自分で自分にもっとうまくプロンプトを出してくれればいい」。自分をループから外し、コンテキストをファイルに移すことで、今日のAIにまつわる問題のほとんどは解決すると彼は言う。

彼はプロンプト全般についても、同じようにチャットモードを使っている。デザイナーではない彼は、今でも用語の多くを知らない。だから行き詰まったときは、チャットモードに頭の中を吐き出し、より良いプロンプトを書く手伝いをツールに頼み、「実質的にツール自身にプロンプトを書かせる」のだ。

レニーは、エージェントの出力を重視するラザールの姿勢を、ベン・トッセルと結びつける。レニーによれば、トッセルはエージェントの出力を見ることでシステムの仕組みを学んでいるという。さらにレニーは、コードの次に来るレイヤーは何かについてCursorのCEOと交わした会話にも触れ、そのレイヤーは単に英語でのエージェントとの会話なのかもしれないと示唆する。ラザールは同意し、出力を読むことで何が可能かを学び、それが判断力の糧になっていると言う。

彼は、これが妄想を称賛する自分の主張と矛盾しているように見えるかもしれないと認め、ある失敗談を語る。OpenAIがChatGPTにネイティブの画像生成機能をリリースしたとき、彼はすぐにそれをラップするLovableアプリを作りたいと思ったが、まだAPIがないことに気づいていなかった。少なくとも1週間、力ずくでなんとかしようとした。その1週間後にAPIが公開され、彼は30秒でアプリを作り上げた。彼の教訓は、Webを閲覧し、ファイルを読み、推論するエージェント型のツールは、何かが現時点では不可能であることとその理由を教えてくれることが多く、その会話こそが最も多くを学べる場だということだ。

ラザールは、1年前に使っていた回避策の多くは、当時なら人々を感心させただろうと言う。彼はStarter Storyと組んでそれらについての講座を作り、そうした秘訣を知っているのは彼だけだと言われたという。しかし今では、そのうち99%をLovableがネイティブに処理しており、3月に公開したLovableでバイブコーディングを学ぶ7日間のYouTubeシリーズは「完全に時代遅れ」だという。

彼は、Claude Codeに携わる人物の投稿が出回っているのを見たと話す。その投稿によれば、初期の蒸気機関から自動車ができるまでにはおよそ200年かかったが、その後20年以内にアメリカの馬の約90%が姿を消した。一方、テクニカルライターとして採用された投稿者自身は、6カ月後には自分が時代遅れになったと感じたという。ラザールの受け止めは、人間には馬に与えられた20年すら与えられないだろう、というものだ。しかし彼は、怖いというよりワクワクしていると言う。自動化されつつあるのは、会議、メモ取り、スプレッドシートなど、ほとんどの人が嫌っていた仕事だからだ。作ることはほぼ一瞬でできるようになり、明確さがボトルネックになるので、人はもっと長く考えることに対して報酬をもらえるようになると彼は予想している。それは、彼がClaude Codeを使いこなせるようにならなかった理由でもあるという。Claude Codeはあまりに強力なので、十分な明確さがないまま始めると、最初から間違った方向に進んでしまったのだ。彼は自分を、エリートエンジニアが使うツールよりも、探索やプロトタイピング向けのツールの方が得意なタイプだと見ている。

何に注力すべきかと問われ、ラザールはまず感情的知性と、人と人との関係に関わるスキルを挙げる。人々は偽物の画像、投稿、プロフィール、動画に疲れ、ライブの、人間同士のやり取りをより重視するようになると彼は予想している。ある入力が確実にある出力を生む決定論的なものは、数学的な作業の多くも含めて、AIの影響を受けやすいと言う。入力から出力までの道筋が人間関係を通るところでは、人間が優位を保ち続けると彼は見ている。

具体的には、優れたデザイン、つまり画像、フォント、そして特にコピーを挙げる。彼とレニーなら、AIが書いたコピーを数秒で見抜けるだろうと考えており、自分自身もAIの出力を読むのがもう好きではないと言う。こうした人間ならではのスキルについては新しい職種名が生まれるだろうと予測し、その例として、カルパシーが2025年初頭にこの言葉を生み出す約7カ月前、2024年7月から、名前を持たないまま自分はバイブコーディングをしていたことを挙げる。

彼は特定の職業について、あえて強い予測をする。翻訳者と、エリートではないジャーナリストのほとんどは置き換えられるだろうと予想している。平均的な書き手は気をつけるべきだが、優れた書き手は増幅され、1年に1冊ではなく7冊の本を書くようになるかもしれない。コメディアンは置き換えられない、AIは「良いジョークを書けるようには決してならない」からだと言い、これは自分の個人的な信念だとする。レニーは、データラベリング企業の創業者から、ある研究所(おそらくAnthropic)がモデルの学習を手伝わせるためにナショナル・ランプーンのライターを雇ったと聞いたことに触れる。ラザールは、自分が言ったことの95%は3カ月以内に外れるだろうが、これだけは確信している、と答える。

ラザールは、自分の歩んできた道はまったく一直線ではなかったと言う。彼は林業エンジニアとしての教育を受けており、コーディングとは無縁だったが、エンジニアリングはやはり特定のスキルを育ててくれると言う。学生時代にはSubwayで働くなどブルーカラーの仕事を経験し、長い間ウェイターもしていた。そこで、人が何を好み何を嫌うかを学んだという。彼は自分のキャリアを、主人公がそれぞれの経験によって一つひとつの問題への答えを準備していく『スラムドッグ$ミリオネア』にたとえる。この7〜8年はスタートアップで、コードを書くこと以外のあらゆることをしてきた。始まりはコミュニティマネジメントとソーシャルメディアだった。彼は、ディストリビューションが非常に重要だと指摘する。誰もが作れるようになり、消費者の数は変わらないままなら、注目こそが最も希少な資源になるからだ。

彼は、この仕事を得られたのは「ビルド・イン・パブリック(公開しながら作ること)」をしてきたからだと考えている。失敗も、知識も、プロジェクトも、YouTubeや、とりわけLinkedInで共有してきた。LinkedInは、Xよりも彼の長文スタイルに合っているという。彼のアドバイスは、何かを理解したらすぐにあらゆる「秘訣」を惜しみなく公開すること、ハッカソンに参加すること、他のビルダーと出会うことだ。採用に関するヒントも教えてくれた。履歴書の代わりにLovableのアプリを送ってきて目立った候補者がいたという。そして、Lovableの社員はlovable.appドメインのリンクなら必ず開くそうだ。

Lovableより先にバイブコーダーを採用した企業もあると彼は言う。社名は明かさなかったが、ある企業では3人のフルタイムのバイブコーダーが、古いコードベース、CRM、CMS、その他のツールをLovableに移行しており、S&P 500企業の中には求人票でLovableのスキルを推奨条件に挙げているところもあるという。彼が一番伝えたいのはこれだ。「会社に雇ってもらう必要はない。まずは自分で自分をプロのバイブコーダーとして雇えばいい」。アントンやエレナと意気投合したのは、雇われる前からすでにこの仕事をしていたからだと彼は考えている。

彼は、なぜ自分がこれほど熱意を持っているのかについても語る。6歳で初めてコンピューターを手に入れ、自分はいつかソフトウェアを作るものだとずっと思っていた。しかし人生は複雑で、価値観の合う技術系の共同創業者を探しても見つからず、この5〜10年はほとんど諦めかけていた。36歳になった今、あの頃の子どもに戻ったような気分だという。不安を感じている人への彼のアドバイスは、何かを作ってみることだ。何が可能かを目にすれば、恐れはワクワクに変わる。恐れるべき唯一の理由は、何もしていないことだと彼は言う。

最後にラザールは、技術スタックは関係ないと語る。何かがHTMLで書かれているかReactで書かれているかは、これまでも本当に重要だったことはなく、今ではなおさら重要ではない。ユーザーが求めているのは素晴らしい体験だからだ。誰もが「十分に良い」ものを作れる以上、魔法を生み出す方法を学ばなければ、何百万もの人々の中に埋もれてしまう。ただし、魔法のようなものがどういうものかまだ分からなくても、落ち込む必要はないと彼は付け加える。「十分に良い」から始めて、レベルアップしていけばいい。

レベルアップの方法として、彼は再びエクスポージャー・タイムに立ち返る。作ることよりも学ぶことに時間を使うこと、エージェントの出力を読んでその考え方や何が可能かを理解すること、優れたデザイナーをフォローし、彼らの仕事ぶりを見ることだ。彼は、ほぼ毎日40〜50分のデザイン作業の動画を投稿しているあるツール開発者をフォローしていると話す。そうすることで、世界トップクラスのデザイナーがツールにどう話しかけ、どうプロンプトを出しているかを見ることができるのだ。彼の結論は、ゴミも魔法も同じ速さで、同じ時間で作り出せるということ、そしてその違いを生むのはインプットだということだ。彼のアドバイスは、バックエンドやフロントエンドについての判断は忘れ、品質、センス、デザインを最適化することだ。