AIハイプサイクルを生き抜く6つの実証済みワークフロー

人工知能と開発、コードを使った構築における課題の一つは、みんなが「これが俺の特別なハックや」とか「これが俺の使うツールセットや」みたいな感じで、自分だけのギミックを探してることやな。そして、それが全部もろそうに感じるんや。そのツールを使わへんかったら、そのプロンプトを使わへんかったら、まさにその通りに構築せへんかったら、うまくいかへんみたいな感じでな。

俺はちょっと違うことをやりたかってん。複数の業界リーダーが実践してるワークパターンを見て回りたかったんや。この人たちは全員が創業者ってわけやないで。個人ハッカーもおるし、プロダクトリーダーもおる。ソフトウェア構築を始めたい人にとって、今がどれだけ豊かで多様な機会があるかを体現してる人たちや。

彼らはまた、どれだけ多くの異なるツールを使えるかも体現してる。この記事にはたくさんのツールレビューを含めてるで。そういうのが好きな人なら、物足りんことはないはずや。おそらくウェブ上のどこよりも、AIを使った業界のコーディングツールについて包括的に見れる内容やと思う。とはいえ、このアプローチの核心は、俺が見つけることができた6つの実証済みワークパターンと、それらのワークパターンを作るために異なるツールをどう組み合わせるかの例を示すことやと思ってる。

安定した要素としてのワークパターン

俺はこれらのワークパターンを、絶えず変化し続ける新しいツール、新しいプロンプトパターン、新しいリーダーが現れて新しいハックを教えてくれる、新しいアプリケーションの海の中で、隠れた安定した要素として見てるんや。AIに関しては振り返るたびに新しいことがあるやろ？だから俺が求めてたのは、実戦でテストされて、戻って頼りにできるパターンやってん。

そんなわけで、全部で6つを見て、途中でリーダーたちの例も見ていこうや。1番目は、コードベースマッピングとオンボーディングや。これを開発パターンとは思わへんかもしれんけど、実際にそうなんや。AIを使って既存のコードベースを素早く理解できる。オンボーディングやレガシーコードの調査のためのマップや要約、グラフを生成できるんや。

これは当然、既存のコードベースがある場合に特に有用や。チームに誰かを素早く迎え入れたい場合、AIの出力をさらなる改良の出発点として扱えるんや。この文脈では、新しい構築者のオンボーディングを非常に高速化できる。高レベルなコンテキストを非常に素早く抽出できるし、エンジニアでない人がコードベースを知るのにとても有用なんや。

実際に、特定のコーディングパターンを知るのを助けるように設計されたプロンプトをいくつか書いたことがある。非常に似てる、非常に似たプロセスや。コードベースマッピングとオンボーディングを使ってる実際のリーダーたちの例を見てみよう。

実践例から見るコードベースマッピング

Claire Voは初期のリポジトリ分析にDevinを使って、本番のコードベースでDevinの評価に基づいて自分の評価をリファクタリングしてる。DevinにPRやテストを生成させて、初回で約80%の成功率やと言ってて、その後の編集にはcursorに切り替えて訓練してるんや。

CJ ZafirはPRDsと計画をcursorに読み込ませて、具体的にはcursorsの.cursor rulesファイルを使って永続的なコンテキストを確立し、それからGemini 2.5を使って大きなコードベースをスキャンしてる。

Eric ProvenarはClaude Codeにrepo prompts onboard/onboardファイルでコンテキストを与えてプライミングし、そこから構造化されたXML編集を可能にしてる。これらはとても戦術的で具体的で、それだけを見たら「ほんまに、もう、圧倒されるわ」って感じやろな。repo prompt/onboardファイルって何やねん？cursorsの.cursor rulesファイルって何やねん？それらを調べることはできるし、レポートでもっと詳しい情報を提供してるから、深く掘り下げることもできる。

調べ物をして迷子になるってことやないんや。共通のパターンを見落としたら迷子になるってことや。それが俺が伝えたいことなんや。ClaireはDevinで初期評価をやってる。CJはPRD計画をcursor rulesに読み込んでる。EricはClaude Codeにrepo prompt/onboardファイルを読み込んでる。彼らはマッピングに必要なコンテキストを与えてるんや。

Gurgaly OrosはClaude Codeのcodecs コマンドラインを大規模プロジェクトのセッションコンテキストに使ってる。MelvinはWindsurfのCascadeを大規模データベースの自動コンテキストに使ってる。これに使えるツールがどれだけ多様かわかるやろ。Simon WillisもClaude Code/Onboardファイルを使ってるけど、GitHub actionsのコンテキストに使ってるんや。これらのツールはいろんな方法で組み合わせて使えるんや。

だから俺の目標は、唯一無二の黄金のベストな方法を教えることやない。なぜなら、誰かが現れるからや。ChatGPT-5が現れて、特定のツールベースで何がベストかについての考え方を変えるやろう。でも、コードベースマッピングとオンボーディングにAIを使う事実は変わらへん。それは残るし、だからこそ俺はそれを取り上げるんや。

ツールと原則

ここでよく言及されるツールは何かって？Claude CodeとDevin、cursor、windsurf、そしてIDERも挙げておきたい。IDERもここでは有用やで。この最初のマッピングとオンボーディングの部分から引き出すべき原則は、AIをリポジトリに向けることや。要約やグラフを求めてプロンプトして、そこから改良していく。

小さなコードベースから始めるのがええやろな。コンテキストファイルを定期的に更新する。チームの場合は、これらのAI生成ドキュメントを、協力的なオンボーディングのためのドキュメントみたいに共有できるんや。

パターン2に移ろう。計画優先開発や。実際、俺がMavenコースを教えるときによく教えるやつや。AIをアーキテクトとして使って、コードを生成する前に計画、機能、ロジック、エッジケースを概説するんや。

それから承認して改良して進む。実際に、そこに到達する方法として疑似コードをシミュレートできるんや。ClaudeにReactアーティファクトをコード化してもらって、それが疑似コードになって、何をしたいかを理解するのに役立つ。これは無関係な出力を防ぐ。一貫性を保証する。保守性を保証して、便利なことに、やった作業はすべてドキュメントとしても機能するんや。

リーダーたちの計画優先アプローチ

これらのリーダーたちがどうやってるかを見るために戻ってみよう。CJ Zafirはcursorにアプローチと計画を求める。アクションリストを生成して、チャンクで構築して、o3 miniを使って、冗談抜きで、40ステップの計画を開発してる。

Dan Shipperは対戦プロセッサーをClaude Codeに設定して、対立する目標を持つ並列サブエージェントを作り、長時間実行で出力を統合してる。

これも計画のアクションや。Eric Provenaは計画をo3にチャット経由で委任し、それからClaudeが編集を適用する。Gurgelyは計画モードとClaude Code、そしてcodexコマンドラインを並列タスクのロードマップサブエージェントに使ってる。

これらのリーダーたちが、一緒に作業することに満足できるツールを手に入れて、それから自分にとって意味のある方法でこれらのワークフローの動作を実行してるって考えてほしいんや。君もおそらく好みのツールがあるやろう。たとえ君のツールが同じでなくても、Claude Codeを使ってなくて他の何かを使ってても、同じプロセスを実行できるんや。Claude Codeの計画と同じように、lovableの計画もできるんや。

Peter YangはClaude Codeで3つのエージェントをデモして、品質の高い計画のための「think ultra hard」みたいなカスタムコマンドを使ってる。

Riley BrownはCursor Composerを図表段階での計画に使ってる。計画しなければ、出力が冗長で間違ったものになることがわかってるんや。実際、これは全体的に見られることなんや。Dan Shipperは、計画が良くないと高負荷でClaudeのスロットリング問題が起きることを指摘してる。

物事が限界まで押し進められると、モデルの拒否も起きる可能性がある。つまり、Claudeはコンテキストが尽きると完全に拒否することがあるんや。CJ Zafirは、Windsが初期ステップ後に壊れることがあると指摘してる。本質的に、落とし穴は計画の重要性を思い出させてくれるんや。なぜなら、そういう風に多少もろいものがあるなら、計画に戻って従い続けられるように、しっかりとした計画を持っておいた方がいいからや。

計画の重要性と原則

俺が知ってる成功するアプリケーションを構築できる人たちは、8対2の努力を計画優先に置いて、それから実行する。なぜなら、いつでも計画側に戻れるからや。原則は、分解を求めるプロンプトや。解決しようとしてることの全体像を実際に得られるスケッチソリューションデザインみたいなものを探すんや。

コーディングする前にその計画を承認して、それから必要なツールを何でも使って、複雑な機能のレイアウトを実際に計画するんや。見ての通り、Claude Codeでできる。cursor でやってる人もおるし、windsurfでやってる人もおる。lovableでもバージョンをできるやろな。それから、時間が経っても計画に戻れるところは戻りたいんや。

計画に押し戻してくれる作業習慣を持つ必要がある。パターン3や。これはツールに関連してる。これはどこにも行かへん。1億ドルへの最速ツールって何か知ってる？もうcursorやない。lovableや。バイブコーディングツールや。Microsoftが GitHub用にSparkっていう自分たちのコピーキャット版を立ち上げるほど大きな話題になってるんや。

自然言語駆動コーディングの台頭

自然言語駆動コーディングやバイブコーディングは、ある意味でそれ自体がパターンやと思う。独自の放送時間を与えたかったんや。コード生成のために自然言語でプロンプトする。改良のために反復する。プロトタイプ、スクリプティング、探索に理想的や。そして正直、実際のアプリケーションも構築できる。

lovableで小規模サービス事業向けのCRMを構築した人を知ってる。lovableで暗号通貨監視に焦点を当てた小さなアプリケーションを構築した人も知ってる。強みはスピードや。非常に非常に迅速に物事を進めることができる。多くのツールで全くセットアップが不要で、非コーダーもブロックされない。

非コーダーの君をブロックしてる唯一のものは、ますます意図の明確さなんや。何をしたいかが明確なら、作ることができるんや。Riley BrownはCursorを100%のAIワークフローに使って、それからRepletを使ってアイデアから展開まで素早く行く。RileyはCRMを、俺が話してたのと似たような感じで、1つのプロンプトでデモして、UIを素早くゲーム化できるんや。

Melvin VivosはWindsurfにデプロイをプロンプトして、UIにはGeminiに切り替える。似たようなことや。Peter YangはClaude Codeでアプリの説明をタイプして、エージェントにそれらを構築するよう求める。バイブコーディングと呼ばれて俺がlovableについて話してても、これらのリーダーたちはlovableやboltやGitHub sparkみたいなプロンプト駆動ツールだけに自分たちを限定してないことに気づくやろ。

cursorでこれをやってる。Claudeでこれをやってる。これらのツールでバイブコーディングができるんや。CJ ZafiaはcursorにUIの調整をプロンプトし、v0eroをUIに使う。CJは曖昧なプロンプトがあると、コードを間違った方向に向けてしまうという考えと格闘してる。CJだけやない。Peter、Melvin、Riley、その他言及した人たちも、自然言語でプロンプトするときに意図を持ってプロンプトしなければ、コードベースを間違った方向に導いてしまうケースを見たことがあるって言ってる。

自然言語開発の課題と改善

自然言語駆動開発での最大の課題の一つは、曖昧な人間のフレーズを非常に明確なコードに解釈しなければならないことや。それがなんとか動くってのは奇跡や。そしてどんどん良くなってる。lovableは実際に先週末にエージェントを立ち上げたと思う。エージェントの焦点は、外科的な修正を行ってコード編集と更新の精度を向上させることで、lovableでより少ないトークンを消費させることや。なぜなら、lovableは人間の言語意図についてシステムが最初に推測することを見て、改良と反復のオプションが必要だということを認識してるからや。

バイブコーディングの応用原則は、非常に明確に記述しなければならないってことや。セキュリティとスタイルのためにレビューしなければならない。小さく始めて反復すべきや。そして計画とペアにする必要がある。俺はそれをとても強調する。上で言った通りや。計画とペアにしろ。

もっと読みたければ、バイブコーディングについて別の記事を全部書いてある。バイブコーディングバイブルって呼ばれてると思う。深く掘り下げるのに役立つやろう。これらのツールの強さを考えると、みんなが遊んでみることで恩恵を受ける分野やと思う。

AI拡張デバッグ

パターン4に移ろう。AI拡張デバッグや。バグ、バグ、バグ、バグ、バグ。バグって何回も聞くわ。AIをデバッグに引き込みたいんや。AIにエラーを分析してもらい、修正を提案してもらい、解決まで繰り返してもらい、修正実行サイクルとテストをできるだけ自動化してもらいたいんや。

これに取り組んだリーダーたちの例やけど、Claire VoはDevinをdata dogでのデバッグに使って、人間のレビューでテストを生成してる。Riley BrownはcursorのターミナルアクセスをAPIセットアップに使って、それからdiffで修正してる。Simon WillisはClaude Codeでファイルごとにコミットをレビューしてる。これが何を必要とするかを考えると、常にうまくいくとは限らないってことを認識しなければならない。そのバグを何度も何度も叩いても、どこにも行けないケースを見たことがある。

どんな修正も回帰を導入する可能性があることを認識する必要がある。それを減らすことが実際に新しいlovableエージェントビルドの目標やった。論理的なバグには人間が必要かもしれない。だから、Zafirが経験したようにwindsurfがセッション途中で止まる場合、何が起こってるかを理解するために人間が介入する必要があるかもしれない。

特にDevinは、このツールを攻撃するつもりやないけど、Devinは雑然としたリポジトリではパフォーマンスが落ちる可能性がある。だから、コードを整理整頓しておくことは、構築の隠れた成功事例の一つなんや。

デバッグの原則と手法

原則的な観点から、後戻りする場合、エラートレースをAIに非常に明確に提示することに責任を持ちたいんや。これらのツールの隠れた点の一つは、ローカルホストプレビューや、lovableでプロンプトしてるときに時々見る画面上のプレビューを見ることができないってことや。彼らは知らない。得ているエラートレースをモデルに明確に貼り付ける必要がある。

明確な根本原因評価をプロンプトできるようになるべきや。そのためのプロンプトを持ってて、共有できる。明確に掘り下げて根本原因を見つけて、それから提案された修正を持って戻ってくるってやつや。それから、慎重に修正することを確認する必要がある。どのファイルが触られるかを確認する。実際の本番ビルドの場合は、本番に展開する前にサンドボックスで動作を確認できるように、サンドボックス化を推奨するで。

パターン5に移ろう。AI支援コードレビューとリファクタリングや。AIをプリプールレビュアーとして想像してみろ。フィードバックをプロンプトして、自動的にリファクタリングするなどや。Claire VoteはPRのためにDevinをchat PRDにチェーンして、外科的変更のためにcursorを使う。Devinが初期レビュアーとして機能することを可能にしてる。

Gurglyはロールアウト中のインライン編集にcursorとWindsurfを使ってる。Simon WillisはClaude Codeをレビューした後、ファイルごとにコミットしてる。ここでの落とし穴は、盲目的に信頼すると、システムが何をしてるかを実際にチェックしなけて、厄介な回帰を得る可能性があることや。

Zapierによると、cursorはスコープ外を編集する可能性があるけど、cursorだけやない。レポート後レポートでこれを見たことがある。lovableも時々これをする。Claude Codeも時々これをする。複雑さは混乱を招く可能性があるので、スコープを超えたより大きな編集を得ることがある。

レビューと制約の重要性

ここで呼び出すべき原則は、レビューをプロンプトして、そのレビューの周りの制約とガードレールを非常に具体的にプロンプトしたいってことや。コードの特定の部分をレビューしたければ、そう言え。それが何かを言え。スコープ外編集問題を避けるために、できるだけ制約しろ。

最終承認には人間がいることを確認しろ。結果のコードがどのように見えて動くべきか、それが関連するあらゆる依存関係について明確なルールがあることを確認しろ。

パターン6、コンテキストエンジニアリングと一貫性の強制や。そう、たくさんの言葉があるけど、そこに到達するで。Claude markdownファイルや.cursor rulesファイルのような、ターゲット上の出力のためにプロンプトに前置される明確なガイドラインを持つAI読み取り可能ファイルを維持したいんや。ハウススタイルの維持について話すとき、これが俺の意味することや。

これはドリフトを減らすやろう。幻覚を減らすやろう。コードベース全体でベストプラクティスを強化し、利益を複合させる。CJ Zafirはこのために.cursor rulesとcursorを使ってる。Eric Provenaはリポジトリでclaude.mdを使ってる。Gurglyはコンテキスト制限を処理するためにmodel context protocolを使ってる。Melvin Vivasは自動コンテキストにcascadeを使ってる。

コンテキストエンジニアリングの統合

ここで見てることの一つは、俺がコンテキストエンジニアリングと一貫性の両方を組み合わせてることや。なぜなら、それらは関連してると思うからや。markdownファイルに一貫したルールがあれば、model context protocolをより確実に通してコンテキストを取得し、コンテキストを外科的に取得し、コンテキストを過度に取得しないことができる。明確な原則と例を持つルートファイルがあることが本当に重要なんや。

数日前にClaude Codeサブエージェントがローンチされたことも指摘しておきたい。サブエージェントは対戦プロセッサーや並列タスクエージェントのようなマルチエージェントワークフローを可能にして、これによってかなり複雑なプロンプトベースのセットアップを構築できるんや。

これらのサブエージェントの責任ある手動オーケストレーションに入り、別々のルールと別々のタスクを与えることができれば、信じられないような、信じられないようなことができる。PRDを拡張するエージェントを1つ持てる。アーキテクトするエージェントを別に持てる。構築する3番目のエージェントを持てるなどや。

でも、適用するときにこれらの原則に従うことが本当に本当に重要や。なぜなら、サブエージェントは本質的に君を加速させるだけやからや。実際に異なる能力を与えてくれるわけやない。これらの原則をうまく適用してれば、より速く進むことを可能にするだけや。

6つのパターンの再確認

だから、この6つをもう一度見て、本当に理解してもらいたいんや。ツールの言及に混乱してほしくない。原則について考えてほしいんや。コードベースマッピングとオンボーディング。ここでの持続可能な原則は、AIをリポジトリに向けることや。リポジトリの要約をプロンプトして、手動で改良するんや。

計画優先開発。まず何を構築したいかを理解するためにプロンプトする。まず計画を開発する。コーディングする前に計画を承認する。これは本当に、本当に重要や。

バイブコーディングや自然言語駆動開発。Lovableのようなバイブコーディングツールである必要はないけど、もちろん多くの人にとってはそれが素晴らしい場所や。何をしたいかを明確に記述しなければならない。計画の部分に戻るんや。セキュリティ、スタイルのためにレビューしなければならない。以前にやったことがなければ小さく始めて、思慮深く反復する意欲を持つべきや。時には並行して。

俺は時々、boltとlovableとrepletで並行して構築して、どれが最も遠くまで連れて行ってくれるかを見ることがある。パターン4、AI拡張デバッグとテスト。実際のエラートレースを貼り付けて、何が間違ってるかを明確に伝えることを確認したいんや。システムがハウスルールに沿って受け入れる修正の種類について、根本原因にどのように到達するかについて、非常に具体的で規範的であること。

特に本番データベースでは、修正を慎重に適用すべきや。パターン5、AI支援コードレビュー。コードのレビューをプロンプトして、レビューを見たい範囲だけに制約できる場所にいたいんや。人間が2回目のパスをしなければならないことを覚えておけ。でも、Devinのようなツールを使って多くのことを素早く完了させることはできる。

Claireがそこで素晴らしい例やと思う。最後に、パターン6、コンテキストエンジニアリング。2つの基本原則を通じて、ドリフトと幻覚を減らす機会としてコンテキストエンジニアリングを見ることが本当に重要や。1つはAI読み取り可能ファイルの維持で、もう1つはターゲット上の出力のための明確なプロンプトや。

だから、Guregelyがmodel context protocolを使うとき、それは明確なルールを持つことと、model context protocolにどこに行けばいいかを伝える明確なプロンプトを持つことの組み合わせなんや。

まとめと将来展望

これが6つのパターンで、俺はそれらをさらに深く掘り下げるつもりや。記事でそれぞれのリーダーについて話すし、それらのツールから出てきたすべての異なる落とし穴について話すつもりや。

完璧なツールはない。でも俺が強調したいのは、このワークフローパターンの全体的なレビューが持続可能だということや。ChatGPT-5が出てきても、たぶん今週の後半に、君は道に迷うことはないやろう。なぜなら、これらの持続可能なパターンにそれをスロットできるからや。非常に非常に非常に速く変化する世界で、しがみつけるものなんや。

よく受ける質問で締めくくりたい。なぜ気にすべきなのか？なぜ気にすべきなのか？開発のためのプロンプトやAIでのコード開発の使用は、AIが実際に何ができるかを人々が理解するのを助ける最も簡単で最も効率的な方法の一つやと君に言いたいんや。なぜなら、それがとても明確やからや。プロンプトが動くか動かないかや。

だから、構築者になる予定が全くなくても、lovableを探索することを考えることを勧める。アイデアを表現するためのコード開発で遊べるシンプルなツールを探索することを。去年多くの人と共有した最も強力なことは、技術的に十分でない、自分の技術的創業者になれない、自分のアイデアのために自分の構築者になれないという古い時代の恐れは、もう真実やないってことや。

自分の技術的創業者になれる。作りたいあらゆるアイデアのために自分の構築者になれるんや。今のところ、知識がないために実際に何かができない人を見たことがない。AIに教えてもらう方法を知ってて、それについて書いたことがあるんやけど、AIで構築することを可能にする方法でこれらの6つのワークパターンを適用する方法を知ってるとき、作りたいものの夢を実現する立場にいるんや。

新しい時代の可能性

俺が言ってるのは、そして俺が信じてないのは、俺たち全員が自分のアプリだけを構築して、お互いからアプリを買わない未来や。それは真実やないと思う。料理は長い間存在してる。俺たちにはキッチンがあって、料理するけど、それでもレストランに行く。それでもDoor Dashを使う。

同じように、俺たちはまだソフトウェアを買うやろう。でも、料理の仕方を知ることと構築の仕方を知ることは、同等に有用なスキルやと思う。実際、コーディングの仕方を知ることは、今では料理の仕方を知ることより難しくない。人工知能のおかげではるかにシンプルになったんや。

だから、これを聞いてて構築を試したことがない人がいるなら、これが俺の嘆願や。取り残されてほしくない。試せるようになってほしいんや。だからこそ、これらのツールとこれらのリーダーの例を、個別で具体的で持続可能なパターンに分解する時間を取ったんや。

構築してる人にとっても、持続可能なパターンはかなり有用や。構築する人たちから聞くことの一つは、ついていくのが難しいってことや。すべてが変わる。これらの持続可能なパターンは変わらないやろう。新しいツールがスロットインするかもしれんけど、パターンはそこにあり続けるやろう。

継続的な学習と成長

例えば、バイブコーディングは明日もそこにあるやろう。どこにも行かない。だから、これらをAI開発革命の6つの基礎的なワークパターンとして見て、自分の作業をより効果的にするためにどこでレベルアップしたいかを見つけろ。

たぶん君はバイブコーディングが本当に本当に得意や。たぶん君がもっと学ぶ必要があるのは計画についてや。たぶん君がもっと学ぶ必要があるのはレビューについてや。俺たち全員が成長できることがある。

個人的に、俺はテスト駆動開発がもっと上手になれると思う。構築しながらAIにユニットテストを実行してもらうことがもっと上手になれると思う。それが俺の成長分野や。みんなそれぞれ成長分野がある。

これでの俺の目標は、君がそれらに飛び込んで有用だと感じられるように、パターンを示すことや。これが役に立ったことを願う。これが今のAI開発での混沌や変化してることの一部を神秘化を解いたことを願う。