「Vibe Coding」と現実

 (cendyne.dev)
19 ポイント 投稿者 GN⁺ 2025-03-24 | 9件のコメント | WhatsAppで共有
  • 最近、Andrej Karpathyの発言が話題に: "Vibeに身を任せて、指数関数的な成長を受け入れ、コードが存在することさえ忘れましょう。"
  • "Vibe Coding"とは、明確な計画やコード記述なしに、AIツールへ問題解決を委ねる傾向を意味する
  • LLM（大規模言語モデル）エージェントを通じて自然言語で命令を出すことで、コードを生成・修正できるようになった
    • 2022年: ChatGPTでコードのコピーと修正が可能に
    • 2023年: IDEと統合されたCopilotでコードレビューと修正が可能に
    • 2024〜2025年: プロジェクト内の複数ファイルを修正し、自前でテストと修正まで可能に

「Vibe Coding」の仕組み

  • 技術者・非技術者のどちらも、LLMベースのエージェントを通じてプロジェクトを設定可能
  • 単純な命令でWebサイトやアプリを生成可能（例: "スキーリゾートのWebサイトを作る"）
  • 初期設定の後は自動修正やテストが可能

  • 例:

    • Cursor、GitHub Copilot Agent Modeなどは、ファイル修正やコマンド実行が可能
    • 自動修正とテストを実行 → 一貫性不足によりエラーが発生する可能性

エージェントの自律性の問題

  • エージェントは自動で作業を実行できるが、完全な自律性を持つわけではない
  • ユーザー承認なしで実行されると危険が生じる可能性（例: YOLOモードでコマンド実行）
  • コード品質と正確性の問題が発生する可能性

  • 主な問題:

    • 既存コードの再利用に失敗 → 同一コンポーネントを繰り返し生成
    • クライアント側でサーバー側ロジックを実行しようとする
    • 誤ったコード修正後にエラーが発生 → 修正時に失敗
    • ユニットテストの作成に失敗、またはコード破壊が発生

現実的な限界

  • Claude 3.7 Sonnetなどのモデルは、訓練データの限界を超えられない
  • コードベース内で文脈を失うと、一貫した修正は不可能
  • コード規模が大きくなると性能が低下し、文脈維持も不可能になる
  • LLMのコンテキストウィンドウの上限を超えると、一貫性の問題が発生

  • 具体的な問題事例:

    • TypeScriptインターフェースの複製
    • クライアントでサーバーロジックを実行
    • 重複コンポーネントの修正失敗
    • ユニットテスト作成の失敗
    • コードリファクタリング後のエラー修正失敗

問題解決の試み

  • Claude Plays Pokémon: エージェントがリアルタイムに相互作用しながらゲームをプレイ
  • メモリ保持や反復的なエラー修正で失敗
  • 長期記憶の構築に失敗 → 継続的なエラー発生

  • 改善の可能性:

    • MCP（Model Context Protocol）およびメモリ管理の改善が必要
    • コード修正時に、LLMが以前の修正内容を正確に反映する必要がある
    • ドメイン別の記憶や作業履歴の保持が必要

結論

  • 「Vibe Coding」は、機能的な概念の実装には80%程度まで到達できるが、信頼できて安全な製品を作るには、経験豊富な人間の努力が必要
  • AIエージェントは、熟練した人々が独立してより多くを創造できるようにするが、経験と直感が必要な難しい問題を解決できる人々を置き換えることはできない。
  • 現在の水準では、「Vibe Coding」が実際に有用な製品につながるのは難しく、熟練開発者の助けが不可欠
  • 「Vibe Coding」はコード記述の補助手段にすぎず、完全な代替手段ではない

関連記事

9件のコメント

 
nicewook 2025-03-25

「現在のレベル」という部分に目が行きます。人間の時間感覚でLLMを見ているのではないでしょうか？
 
ng0301 2025-03-24

AIと一緒にコーディングしていて感じるのは、AIにコードの一部だけを渡しても文脈を理解できるように、単一責任の原則＋TDDっぽい単位で細かく分割していくと、大きな文脈を読まなくても、部分的な文脈だけで十分に捉えられるようにしておく必要があるということです
 
ifmkl 2025-03-24

AIを趣味活動でいちばん多く使っているのはWebゲーム制作ですが、同感です。ある程度以上の規模になると、ある瞬間からAIの集中力とでも言うべき部分が目に見えて低くなることがあるんですよね。私はこれを次のようなやり方で活用していて、ゲーム内の全体ツリーとソースコードをTOCを含めた1つのファイルにまとめ、新しいスレッドを作成する際にそのファイルをアップロードして作業を続けます。そして質問をするときは、必ず現在のプロジェクト名を明示的に伝えたうえで回答を求めます。それでもなお、まだ不満の残る部分はありますが……以前は現実の生活が忙しくてとても手を出せなかった趣味を、比較的短い時間で形にしていけている点はとても満足しています。
 
pcj9024 2025-03-24

ざっくり作って、残りの細部を整えるパターンは本当に良いです
 
psguny9 2025-03-24

いろいろ試みていますが、記憶力の限界は明らかにあります。PoCレベルでは良いです。素早く可能性／使い勝手を確認するという面では良いです。

問題は、なおさら熟練者が必要だということです。
 
colus001 2025-03-24

コーディングで大半の時間を費やすのはデバッグとコードを読むことだと考えると、かなり誇張が激しいと思います。AIを作る人たちはみんなこういう論調で話しますが、少なくとも現在の状況を見る限り、そうではないように思います。人の手が必要ない状況に至るなら、あえてコーディングが必要でしょうか？ ただAPIの説明を入れて、LLMをバックエンドとして使うほうがいいのでは。
 
reagea0 2025-03-24

実際にスキーマを設定して受け取り、そのように使うことが多いです。
 
nowdoit7 2025-03-24

同感です。初期には魔法に近い開発速度を見せますが、規模が大きくなり、ファイルが増えるほど、これを管理する責任者（ここでは人間）が効果的に管理できなければ、膨れ上がるだけでエラーだらけの成果物を受け取ることになります。すでに手の施しようがない段階まで行くと、クレジット（Windsurf）やリクエスト（Cursor）だけを無駄にすることになります。今後ますます良くなっていくでしょうが、現時点ではAIコードを100%信頼してはいけません。
 
GN⁺ 2025-03-24
Hacker Newsの意見

  • 「AIの誇張 vs. 現実」の大きな違いは、人々がよく口にする生産性の数値にある。たとえば、YCのパートナーは、ある企業がコーディング性能で「100倍の速度向上」を主張していると引用している。このような主張は外部の観察者にも明白に表れるはずで、自己申告を必要としないはずだ。

    • YCの夏季バッチは84日間にわたって行われ、デモデーで終わる。100倍の速度向上とは、チームが1日もかからずにデモデー級の機能を備えたアプリを作るのと同じことだ。もし100倍が本当なら、パートナーは新しいバッチについて「顧客と朝食を取り、新しいことを学び、刺激を受け、その日のうちにアプリを書き直し、その結果がデモデー級の機能を備えている」と語るはずだ。しかし、そのような話はないので、100倍という数字は不正確だ。
    • 10倍の向上であっても、パートナーは「今期のバッチでは、人々が1週目にデモデー級のアプリを本番投入している」と言うはずだ。パートナーは、チームがどれだけの仕事をどの期間で完了するかについて大きなサンプルサイズを持っている。したがって、10倍も事実ではない。

  • 現在、私たちはアウトソーシング・ブームをなぞっている。あらゆる誇張された主張とともに、現実は違う。LLMコーディングエージェントについての議論も見分けがつきにくい。

  • Goコミュニティが、コンピュータは人間のGoプレイヤーに勝てないと言っているようなものだ。すでに、より性能の高いソートを見つけるモデルの例がある。適切なインセンティブと時間が与えられれば、コンピュータは私たちを追い越すだろう。

    • 「Vibe coding」はまだ現実ではない。経験と技術でミスを修正し、導く必要がある。しかし、改善の軌道は見えている。

  • コーディングLLMに関する新たな問題点を共有する。オフショア開発者はチームに完全に統合されている。しかし、LLMの使用が無秩序で散発的なため、提出されるプルリクエストが悪夢になっている。

    • LLMを使ってコード作成の支援は受けているが、非常に慎重に使っている。時間の節約にはなるが、品質向上にはならない。正しく依頼する方法を見極めるのにかかる時間、出力を検証する時間、小さなバグを修正する時間が、その利点を相殺してしまう。
    • 「Vibe coding」をせず、職を失わないよう注意すべきだ。

  • 「Vibe Coding」は概念の80%を実装できる。しかし、信頼でき、安全で、価値のあるものを作るには、経験豊富な人間が必要だ。

    • 80%は、よくても概念実証にすぎない。80%とは、QAがバーに入っていくようなものだ。

  • 最近、ClaudeとOpenAI o3-miniを使ってMatlabコードをPythonに変換しようとしたが、性能は非常に悪かった。ほぼすべての重要な行に誤りがあった。自動化が必要な作業だが、失敗した。

  • 「Vibe-TDDing」は、テストがないよりはましだ。コーディングとテストを理解しているなら、LLMを使って負の外部効果を減らすことができる。

  • SaaSの構築方法を共有して以来、奇妙なことが起きている。APIキーの使用量が上限に達し、サブスクリプションが回避され、DBにランダムなものが生成されている。これはいたずらの可能性がある。

  • 多くのエンジニアがAIコーディングツールの能力と生産性を過小評価しているのを見て、自分の仕事に安心感を覚える。Cursorを手放すつもりはない。

    • AIツールが得意なこと: 反復的なコード作成、複雑なDSA作業、単純で退屈な作業、限定的なリファクタリング
    • AIツールが苦手なこと: 製品/ビジネスをコードにマッピングすること、大規模なリファクタリング
    • コード品質は問題ではない。AIは依然として生産性向上に大いに役立つ。