Agentic Codingについて考える「バイブコーディングを超えて」を読んで

Agentic Codingについて考える 「バイブコーディングを超えて」を読んで jig.jp せり バックエンド：Java 1 / 19

AIコーディングの波に乗れていますか？ 2 / 19

3 / 19

章構成 Ⅰ部 基礎 1章 序論：バイブコーディングとは何か？ 2章 プロンプトの芸術：AIと効果的にコミュニケーションする Ⅱ部 AIコーディングの実践 3章 70%問題：実際に動作するAI支援ワークフロー 4章 70%を超えて：人の貢献を最大化する 5章 生成されたコードを理解する：レビュー、改良、所有 6章 AI駆動プロトタイピング：ツールとテクニック 7章 AIでウェブアプリケーションを構築する Ⅲ部 信頼と自律性 8章 セキュリティ、保守性、信頼性 9章 バイブコーディングの倫理的課題 10章 自律型バックグラウンドコーディングエージェント 11章 コード生成を超えて：AI拡張開発の未来 4 / 19 出典: O’Reilly Japan 『バイブコーディングを超えて』 https://www.oreilly.co.jp/books/9784814401420/

• https://www.oreilly.co.jp/books/9784814401420/

今回の発表では 自分が特に刺さった部分のまとめ 自分の意見・経験 5 / 19

バイブコーディング、Agentic Coding、AI支援エンジニアリング Vive Coding 2025/02 X上で、アンドレイ・カーパシーにより提唱 （手動の動作確認など）機能適応性のみを検証→コードレビューをスキップ→速度最大化。 高速なプロトタイピング・探索的（MVPとか）が向いている Agentic Coding [1] AIエージェントが高度な自律性を持つようになったことを活用したソフトウェア開発パラダイム 次のループを繰り返す 目的を理解し：（自然言語の要求を、実行可能なタスク目標に変換する） 計画し：（目標をサブタスクへ分解し、実行順序と依存関係を決める） 実行し：（コード生成・テスト実行・外部ツール利用を自律的に行う） 評価し：（テスト結果やエラーを分析し、品質を判定する。） 改善（問題があれば修正し、必要なら計画を更新して再実行。） 6 / 19 (1) R Sapkota, et al. arXiv:2505.19443 『Vibe Coding vs. Agentic Coding: Fundamentals and P…

AI支援エンジニアリング（「バイブコーディングを超えて」で提唱） ① 計画先行 仕様・制約・受け入れ基準を定義 AI投入前に設計の骨子を固める ② 限定的・目的志向的なAI活用 関数単位／モジュール単位で活用 リファクタリング、テスト生成、移行作業など明確なタスクに適用 ③ 人間によるレビューと統制 AI出力は必ず人が精査 既存プロセス（コードレビュー、CI、テスト）を維持 ④ SDLC全体への統合 設計 → 実装 → テスト → デプロイの全工程でAIを補助的に活用 AIは加速器。意思決定と品質責任は人間。 7 / 19

観点 8 / 19 Vibe Coding Agentic Coding AI支援エンジニアリング 主体 人間（即興） AIエージェント 人間 AIの役割 コード生成器 自律実行主体 副操縦士 プロセス 即興的 自律ループ 計画先行型 ループ構造 明確でない Goal → Plan → Act → Evaluate → Improve 人間中心のPDCA 品質担保 最小限（動作確認中心） エージェント内自己評価 人間レビュー＋既存工程 強み 圧倒的速度 自律的拡張性 信頼性・組織適合性 向いている用途 高速プロトタイピング 自動化・大規模自律開発 実運用・チーム開発

AI支援エンジニアリング（せりの意見★） AI出力は必ず人が精査。 意思決定と品質責任は人間。 既存の大きめのプロジェクト or 大規模開発だと自ずとそうなる コンテキスト長の問題もあり、AI側の認識に限界が出るから。 → （ざっくり）ドキュメントを整備すれば、もちろん効率化はする （個人的に）Claude CodeのPlanモードは設計をしっかりやるには不足があるように感じる 「Yes, auto-accepts edits」の吸引力に負けているだけかもですが。。。 設計までしっかりやるならSDDツール（Spec Kit）等を活用すべきかも 9 / 19

1.3 生産性、近づきやすさ、プログラミングの本質の変化 生産性：定型コードを数分で作り、反復を速くする フロー維持：構文とかはAIに任せて、解きたい問題に集中 参入障壁：新フレームワークの立ち上げ時間短縮 開発者の役割とスキルの変化 「何を作るか」「なぜ動くか」の判断に注力 スキルの本質が 「コードを書く」から「AIにコードを書かせる」 へ転換 10 / 19

1.3 生産性、近づきやすさ、プログラミングの本質の変化（★） フロー維持 特にリファクタ時に感じる 単なる関数抽出のIDE機能より、もう少し人間の欲求を直接対応できる感触 「このクソデカStreamAPIをもう少しどうにかしたいなぁ」 「Record（データクラス）にして整理したいなぁ」 開発者の役割とスキルの変化 実装時のパズル感がより拡大 高レベルな指示でもいける 「今回の機能はこれ。そのために、A機能の◯処理、B機能の△処理を参考に」 ※完全新規の場合は、もちろん設計の工数が大きくなる。 11 / 19

12 / 19

4章 70%を超えて︓⼈の貢献を最⼤化する シニア 深いドメイン知識・専門知識を駆動していく（AIで時間もできる人もいるし） 大規模、厄介なリファクタ、ジュニアにAIに関する指導、AIに限界がある部分（パフォーマンスとか）、利害関係者とコ ミュニケーション（EM、ビジネス層とのコミュニケーションの主導） 13 / 19

4.2 ミドルエンジニア：適応と特化（★） ミドルエンジニアは、おそらく最も大きな圧力に直面しています。 従来のタスク（機能の実装、テストの記述、単純な問題のデバッグ）が自動化される。コード実装から、より専門化され た知識構築の必要性が高まっている → とても実感する。 ドメイン知識とソフトウェアエンジニアリングの知識 解く対象の専門知識 or ユーザー環境の理解 技術スタック、設計、パフォーマンス改善（実装できるだけじゃだめ） 「プリンシプルオブプログラミング」から，初歩の固有名詞（単一責任の原則） 「Good Code, Bad Code」「Tidy First」から，人間が認識しやすいコード ↑ここから，あらためて復習すべきという感覚 積読「脳に収まるコードの書き方」「手を動かしてわかるクリーンアーキテクチャ」 データ分析や（サービスを）自分が使ってみてのドメイン知識（直感） 14 / 19

4.2 ミドルエンジニア：適応と特化（★） AI生成コードをジュニア開発者の出力として扱い厳密レビュー 自動テスト：仕様の正しさの検証を強いるスキル デバッグ：AIはヘルパー（ドメイン不足）→品質保証は人間 人間がレビュー偏重型のペアプロ → 人によって向き・不向きがあるのも現実 仕様をドキュメントとして定めてから開発すれば（SDD）、自分も検証しやすい AIによって、自動テストが膨らませることが簡単にできるがゆえに、良いテストを書くための術を持っておくべき パラメタライズ化テスト、テストダブル、適切なアサーション 「新しいツールを学び、変化に適応する能力」 常に学び続けることがキャリアの安全策 AIのツールの発展も早く、FOMO（乗り遅れる恐怖感）は発生する その中でどのように向き合い、生産性向上につなげるのか。（フロントエンジニアのほうが慣れている？） 15 / 19 先程と同様、（指示を出す）自分自体の能力もネックになる。

4.3 ジュニア開発者：AIとともに成長する 1. 基礎を省略しない AIを家庭教師として使い、「なぜ」を問う（アプローチや1行ごとの処理） ただ「回答だけゲット！」して終わる 欲求に抵抗 （ライブラリ等で）ドキュメントを読み、ゼロからコーディングする時間を確保 2. AI なしで問題解決を実践 定期的に「AIなしの日」を設ける スキルの萎縮を防ぎ、真の自信を築く 結果的により知的にAIを指示できるようになる 16 / 19

3. テストと検証に集中 AIの出力を疑い、単体テスト・手動テストで検証 期待される振る舞いを考える訓練になる（ので、習慣化するととてもよい） AIが見逃したバグを見つけると「あなた」はAIができなかったことをしたことになる→付加価値 （AIを使っているとはいえ）自分の作業を注意深く検証しているという評判を育てれば、上級の同僚はあなたをより 信頼 4. 保守性の目を養う AIコードを同僚のコードのようにレビュー 優れた設計原則を内面化 よりクリーンなコードを得るプロンプト技術を習得 （「できた」で終わらない） 17 / 19

6. フィードバックと指導を求める 人のメンターはソフトスキル、リーダーシップで不可欠 設計の決定やトレードオフを経験者と議論 シニアとペアを組み、AIの使い方だけでなくコミュニケーション方法を学ぶ 7. コミュニケーションと協働 プロンプト作成は要件分析スキル AIへの指示は明確なコミュニケーションの実践であり、問題を考え抜く能力を示す 人間にしかできない協働スキル 知識共有、ドキュメント作成、コードレビューはAIでは代替不可能 チーム内の人対人の協働は引き続き不可欠 開発者の役割の変化 AIとともに働きながら、高レベルな設計やタスク調整に集中 指揮者のような役割へシフトし、コミュニケーションとリーダーシップスキルがより重要に 18 / 19

おわり この本に向いている人：「AI時代の開発について理解したい人」 普段AI開発している人：勘所の言語化、キャリアなど欠けている視点の補完 AI開発してない人：できる・できない、向いている・向いていないという部分の相場感の理解 （開発文化みたいなものが大きいので、）「リーダー層に向いている」という意見も見かけた。 アメリカでは2025年8月出版だが、ツール情報については古いと感じる部分もある 高い視点からの話⇔具体的な話 とAI開発に少しでも関係がある方であれば必ず学びがある本 19 / 19