Vibe codingを超えて with Addy Osmani［YouTube要約］
(youtube.com)- Google Chromeチームで13年間勤務したエンジニアリングリーダー Addy Osmaniが、プロフェッショナルなソフトウェアエンジニア向けのAIベースの開発方法論を紹介
- Vibe codingは高速なプロトタイピングには有用だが、本番品質のソフトウェア開発にはエンジニアリング原則と人間の監督が不可欠
- AIツール活用時には、仕様主導開発、テスト作成、コード理解を通じて品質を担保し、モデルの思考過程をレビューして生成されたコードを完全に把握する必要がある
- LLMはアプリケーションの約70%までを素早く生成できるが、残り30%の完成度・セキュリティ・保守性を確保するには、シニアエンジニアの専門性がさらに重要になる
- 非同期バックグラウンドエージェント、並列コーディングなど新しい開発ワークフローが登場しており、エンジニアは批判的思考とコード理解力を維持しながらAIを活用する生涯学習者であるべき
Vibe Coding vs. AI支援エンジニアリングの違い
- Vibe codingはAIとの創造的なフローに完全に没入し、高レベルのプロンプティングに集中してコードそのものは忘れてしまうやり方
- AIの提案を深く検討せず受け入れ、高速な反復実験に集中
- プロトタイプ、MVP、学習目的に有用で、速度と探索を正確性や保守性より優先
- AI支援エンジニアリングは、AIを強力な協働者として活用しつつ、エンジニアリング原則を置き換えないアプローチ
- AIはソフトウェア開発ライフサイクル全体で、ボイラープレート、デバッグ、デプロイなどを支援するforce multiplierとして機能
- 人間のエンジニアがアーキテクチャ設計、モデルレビュー、生成されたすべてのコードの理解に対する責任を維持
- 最終成果物のセキュリティ、拡張性、保守性を保証するのはエンジニアの役割
- ソフトウェアエンジニアリングの専門性が高いほど、LLMを使った成果物の質が向上する
- 本番品質のプログラミングでは、他人に完全に説明できるコードだけをリポジトリにコミットすべき
AddyのAIツール活用法
- **仕様主導開発（Spec-driven development）**中心のアプローチ
- 何を作るかについて明確な計画を立てることが重要
- Vibe codingは個人用ツール、使い捨てプロジェクト、アイデアの可視化に活用
- プロトタイプでビジョンを明確にした後、実際の要件を文書化してLLMの高品質な成果物を引き出す
- テスト作成によるリスク低減
- 最新モデルでも時に複雑すぎる、または誤ったコードを生成することがある
- テストによって動作を証明し、問題発生時に明確に特定できる
- Chrome DevTools MCPの活用
- LLMにブラウザに対する「視覚」を与え、レンダリング、コンソールエラー、警告などを検知
- ブラウザをループに含めることでフィードバックループを改善
- 新しいモデル、ツール、プラットフォームに対する継続的な実験とチーム間での知見共有
- 心理的安全性を醸成し、共に学ぶ文化を構築
GoogleでのAIツール観察と学び
- Googleの実証済みソフトウェアエンジニアリング原則はAI時代でも有効
- 品質とデューデリジェンスへの関心は依然として重要
- プロンプトエンジニアリングとコンテキストエンジニアリングの重要性
- LLMで最良の結果を得るための適切な「呪文（incantations）」の構成
- コンテキストウィンドウの最適化で高品質な結果の確率を高める
- プロジェクトごとの説明、詳細、ファイル、例などLLMの学習データにないコンテンツを含める
- AI nativeエンジニアへの転換促進
- 問題解決の前にまずAIに試させるという思考法を鍛える
- 評価ベンチマーク、RAG vs. ファインチューニングなどAI専門性の構築
- 人間の監督の重要性
- AIがコード作成とレビューの両方を行うと、実際に何がデプロイされるのか不確実になる
- PR速度の増加により、人間のレビューがボトルネックになる現象が発生
- コードレビューのベストプラクティスはなお進化中
Addyが好むツール
- 主にKlein in VS Codeを使用
- Cursor、GitHub Copilotも多くの機能を提供
- ツールが見せる**思考過程（thinking log）**のレビュー
- ソリューション構築の過程でモデルの意思決定と生成コードを確認
- PR前にコードをレビューして将来の保守可能性を確保
- LLMが問題解決に失敗したときに自力でデバッグできる能力を維持
- コードの動作原理を理解していないと、ジャングルに放り込まれたように感じる
- プロのエンジニアと一般人の違い
- プロンプトを入力するだけなら誰でもできる
- コードの動作原理の理解、モデル失敗時に修正する能力、会議で明確に説明する能力が差別化要因
70%問題の本質
- LLMは動くアプリケーションの約70%を非常に速く生成できるが、残り30%で苦戦する
- 最後の30%の構成要素
- 「Two steps back」パターン: 1つのプロンプトでUIや機能を全面的に書き換えるなど、誤った方向に進む
- 隠れた保守コスト: 明確でない仕様のまま責任をLLMに委ねると収益性が低下
- セキュリティ脆弱性: APIキー露出、XSS問題など、全体的な思考不足による問題
- Vibe codingで作ったPoCは本番デプロイ前に書き直しが必要
- 実際のユーザーベースを扱うコードベースでは、セキュリティと品質が必須
- 経験豊富なエンジニアは最後の30%をはるかに容易に完成できる
- ジュニアエンジニアはLLMに再プロンプトし続ける以外の次の一手が分からないことが多い
- 批判的思考と問題解決マインドセットの重要性が際立つ
- コードを読み、システムを理解し、すべての部分がどうつながっているかを把握する実直さは依然として不可欠
効率的なLLM活用のための戦術
- プロジェクトマネージャー的マインドセットを採用
- 作業を小さく検証可能な単位に分解
- すべての要件を一度に投げても効果的ではない
- 明確な期待値を設定し、AIとの反復作業に備える
- モジュール化されテスト可能なコードを書く
- コードレビュー実施など、ソフトウェアエンジニアリングのベストプラクティスはAI時代でも有効
- 入出力制約の考慮と十分なコンテキスト提供
- 新しい習慣だが、良い結果につながる
- 人間をループに含める実直さの維持が成功の鍵
- LLMに責任を渡すほど、問題発生リスクは高まる
自律エージェントと新しいワークフロー
- 非同期バックグラウンドコーディングエージェントの登場
- Jewels、Devin、CodexなどのツールとGitHubの実験
- バックログの一部を委任し、非同期に実装させるというアイデア
- 現在の状況
- テスト作成・更新、ライブラリのバージョン移行などにはすでに効果的
- ダークモード追加のような小さな変更の委任に適している
- 管理上の課題
- オーケストラの指揮者としてすべての作業を管理する適切なインターフェースが必要
- 同時に管理できる現実的な作業数を考慮
- 人間の注意力は有限なため、徹底したコードレビューには少数の作業しか並行処理できない
- Vibe designingの進化
- FigmaのMCPを通じてデザイナーと開発者の協業を強化
- デザイナーがビジョンを機能的プロトタイプへ変換し、本番化可能なコードに近づける
EMとPMの役割変化
- PMの役割
- 問題のフレーミング、メトリクス、エージェントポリシーにより多くの時間を投資
- EMの役割
- 評価（evals）、安全性レビュー、チームがAIを自信を持って活用できるよう支援
- 結果に対する責任は変わらない
- プロダクトエンジニアリングにおけるセンス（taste）の重要性
- 誰でもプロンプトで似たような機能を作れるため、差別化要因はセンス
- ジュニア vs. シニア
- AIが下限を押し上げる一方で、上限も同時に上昇する
- ジュニアはより速くスタートできる
- 仕様作成、作業分解、システムアーキテクチャ理解、効果的なレビュー能力を持つシニアはさらに価値が高まる
- 最後の30%は単純作業ではなくレバレッジである
新しい役割と開発者教育の変化
- **フォワードデプロイドエンジニア（Forward deployed engineers）**など新しい役割の台頭
- 顧客とより密接に協力し、AIで機能を素早く構築して要件フィードバックを得る
- 開発者、PM、デザイナーの役割間の境界が曖昧になる可能性
- AIエンジニアリング教育
- 高校や大学でプロンプトおよびコンテキストエンジニアリングのベストプラクティスを教える必要性
- システム設計とエンジニアリングの思考法をどう維持するか模索
- トリオプログラミング
- ジュニア、シニア、AIが一緒に作業
- シニアがAI生成コードを説明するよう求めたり、システムの他部分とのつながり方を説明したりする
AI作業時における批判的思考の重要性
- AIツール使用時には、受け入れやすさゆえに批判的思考力が低下するリスクがある
- 特に重要でない作業ではTab/Acceptを押してすべて受け入れてしまう傾向
- 信頼が蓄積するほど、批判的レビューが減少する
- コードレビューのボトルネック
- AI生成コードの速度向上により、人間のレビューがボトルネックになる
- LGTM（Looks Good To Me）の乱発リスク
- 対応戦略
- 特定機能や曜日には意図的にAIなしで作業し、批判的思考力を維持
- 主要LLMプロバイダーがすべてダウンしたらどうするかを考える
- コードを書くこと vs. 読むこと
- 自分でコードを入力すれば自己レビューが起こり、他者も書き手を把握してレビューする
- AI時代には読むこととレビューすることの比重が増す
- コードレビューへのAI活用
- AIの「承認」は1つのシグナルにすぎない
- CI/CD通過、テスト成功などと同様に、品質に対する個人的視点は依然として必要
- なお作業の20〜30%はAIなしで実行し、頭脳を使い続けるべき
学習ツールとしてのLLM
- 新しいコードベース理解のための強力なツール
- 最初のタスクは価値提供のために新機能をプロンプトすることではなく、コードベースの動作を学ぶことであるべき
- プログラミング概念、フレームワーク、アーキテクチャパターンの理解に有用
- 別言語で書かれたコードベース間で機能移植する際に不可欠
- チーム文化の醸成
- AIを学習ツールとして使うのは問題ないという認識を広める
- 実験やベストプラクティス共有を定期的に奨励
- 新入社員の迅速なオンボーディング
- AIツールが24/7信頼できるメンターの役割を果たす
- シニアエンジニアに一日中質問するより気軽に学べる
- Claude Codeの学習モード
- 説明モードと学習モードを提供
- 一時停止して、ユーザーに特定部分を自分で実行するよう求める
AIツールの進化と期待値設定
- ツール進化の歴史
- テンプレートのダウンロード → CLIとスキャフォールディング → AIベースのブートストラップ
- 各段階で開発者体験は少しずつ改善
- 学習データの限界認識
- GitHubのpermissiveライセンスコードやオープンウェブのパターンに基づく
- **最低公倍数（lowest common denominator）**のパターンを反映する可能性
- 最高水準のセキュリティ、性能、アクセシビリティは保証されない
- Stack Overflowのコピペとの類似性
- 過去: メール検証の正規表現のようなものをStack Overflowからコピー
- 現在: LLMが類似パターンを生成するが、エッジケースやセキュリティ問題の可能性がある
- サードパーティライブラリ vs. 自前実装
- LLMで小さなバージョンを自前実装できても、保守責任を負うことになる
- ライブラリならセキュリティ問題などへの中央集権的な修正が可能
- 各選択肢のトレードオフを考える必要がある
- 低い期待値と高い制御力の維持が鍵
優れたソフトウェアエンジニアの定義変化
- **生涯学習者（Lifelong learner）**の重要性は不変
- フレームワーク、ツール、業界が進化しても、新しいことを学ぼうとする開放性が不可欠
- 成長マインドセット（Growth mindset）
- 新しいモデル、ツール、プラットフォームを喜んで試す
- 失敗から学び、制約条件を理解する
- リーダーシップの役割
- リーダーが学習に開かれている姿勢を示せば、チームの心理的安全性が醸成される
- Addyは毎週月曜日にチーム内ニュースレターを執筆
- 個人プロジェクト、文章、考えを共有
- AIおよびAIエンジニアリングの重要なアップデートを選別
- 他の幹部も有用に活用
- 情報過多時代のキュレーション
- ソーシャルネットワークでは毎時間根本的な変化が起きているように感じられる
- リーダーが本当に重要なことを選別してチームを導く
- 技術力の維持
- 論文、ホワイトペーパー、ブログ、動画、講義などを継続して読み視聴する
- チームがどこに時間を投資すべきかをガイドする
- 製品開発との接続
- コーディングワークフロー改善の取り組みが製品の顧客体験改善にも寄与
愛用ツールとおすすめ
- 好きなプログラミング言語: JavaScript
- 個人的な好みというより、誰でもWebにビルドしてデプロイできる開放性ゆえ
- ゲートキーパーなしの解放感を提供
- 現在いちばん好きなツール: Bolt
- Vibe codingのスキャフォールディングツール
- 最近カスタムエージェント対応を追加（Claude Codeなど利用可能）
- 高品質な成果物と優れたデザイン
- Supabase、認証プロバイダーなど統合の自動化機能
- 設定時の摩擦除去に注力
- おすすめ書籍
- "The Software Engineer's Guidebook"
- "AI Engineering" by Chip Huyen - AIエンジニアリングの基礎的側面を学ぶための本
1件のコメント
同名の書籍は11月に出版されるそうです〜
https://x.com/TeeDDub/status/1983150672205041823