AI駆動開発の本は、「何を任せ、何を確認するか」で選ぶ
本文の状態
日本語全文を表示中
詳細モードで約25分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
Algomatic Tech Blog
Algomatic のエンジニア Go は、AI 支援開発の導入において責任設計が重要となる背景を解説し、7 冊の書籍を責任範囲ごとに分類して選定基準を示す。
AI深層分析を開く2026年9月7日 15:19
AI深層分析
キーポイント
責任設計の重要性
AI にコードを書かせた際の本質的な課題はプロンプトではなく、生成された変更の受け入れ条件や権限委譲範囲を誰が決定するかである。
書籍の目的別分類
7 冊の書籍は『Beyond Vibe Coding』から始まり、特定のツール（Claude Code, GitHub Copilot）や環境（ローカル LLM）に特化した選定基準が提示される。
工程ごとの責任分担
各書籍は仕様を誰が固定し、差分と副作用をどう検証するかという問いに対し、異なる工程や粒度で人間の判断をどこに残すかを提案している。
責任範囲に基づく選定基準
AI駆動開発の本は時系列ではなく、AIに委任する範囲と人間が確認すべき責任範囲で読み分ける。
局所作業から全体設計への段階的アプローチ
関数やテストなどの局所的な補助からはじめるなら『GitHub Copilot Step by Step』を、開発プロセス全体の棚卸しには『AI-Assisted Programming』を選ぶ。
重要な引用
AI にコードを書かせ始めると、次に詰まるのはプロンプトではありません。
生成された変更を誰が受け入れるのか、テストで何を固定するのか、エージェントへどこまでの権限を渡すのかです。
違いは、その責任をどの工程で、どの粒度まで扱うかです。
7冊を時系列の普及順に並べることはしません。ここでは、AIへ委任する範囲と、開発者・チームが設計すべき責任範囲で読み分けます。
編集コメントを表示
編集コメント
本記事は単なる書籍紹介にとどまらず、AI エージェントの権限委譲という実務上の重大課題に焦点を当てている。各ツールや工程に応じた責任設計の視点は、現場の開発者が陥りやすい過信を防ぐための重要な指針となる。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
調査日：2026年9月1日
こんにちは。AlgomaticでソフトウェアエンジニアをしているGo（@53able）です。
AIにコードを書かせ始めると、次に詰まるのはプロンプトではありません。生成された変更を誰が受け入れるのか、テストで何を固定するのか、エージェントへどこまでの権限を渡すのかです。本記事は、AI支援開発をこれから工程へ組み込むソフトウェア開発者向けに、O’Reilly Learningで読める7冊を「どの責任を設計する本か」で読み分けます。
最初に読むなら『Beyond Vibe Coding』です。 AIが出した変更を、どの条件で受け入れるかという判断基準を作れます。
一つの小規模アプリを設計からテストまで進めるなら、『Coding with AI』を選びます。導入するツールが決まっている場合は、Claude Codeなら『Agentic Coding with Claude Code』、GitHub Copilotなら『GitHub Copilot Step by Step』、ローカルLLMなら『AI-Assisted Coding』が対応します。
残る書籍を含む7冊の対象工程と制約は、次節で整理します。
本稿が扱うAI支援には、補完やコード断片の提案、チャットを通じた関数・テストの生成、リポジトリを読み複数ファイルやツールを扱うコーディングエージェントが含まれます。委任範囲が広がるほど、問題は「この関数は正しいか」だけでは済みません。仕様を誰が固定するのか、権限をどこまで渡すのか、差分と副作用をどう検証するのか、デプロイを誰が判断するのかが問われます。
候補7冊は、紹介ページと目次に加え、公式リーダーで各章本文を開いて確認しました。記事の説明に関係する章には、AIの出力をそのまま受け入れず、要件、差分、テスト、レビューのいずれかを人間の判断として残す例がありました。違いは、その責任をどの工程で、どの粒度まで扱うかです。
責任範囲で読む：7冊の位置づけ
7冊を時系列の普及順に並べることはしません。ここでは、AIへ委任する範囲と、開発者・チームが設計すべき責任範囲で読み分けます。
図：AIへの委任範囲と、人が追加で確認すること**
上から下へ、AIに委任する範囲が広がります。横の矢印は、各段階で人が確認する項目を示します。
局所的な補助から始めるなら、『GitHub Copilot Step by Step』が関数、バグ、テスト、レビューを一つずつ扱います。局所作業を設計からテストまで一つの小規模アプリへつなげるなら『Coding with AI』です。AIを使える場所をSDLC全体で棚卸しするなら、『AI-Assisted Programming』から始めます。
AIが出した変更を評価する段階では、生成の速さより検証の設計が重要です。『Generative AI for Software Development』は同じ課題で製品がどこで失敗したかを示し、『Beyond Vibe Coding』はその失敗を受け止めるレビュー、テスト、セキュリティ、運用の原則を扱います。
リポジトリとツールへ接続し、複数の作業を進めるエージェントを導入する場合は、コンテキスト、権限、計画、成果物、担当範囲を設計対象にします。『Agentic Coding with Claude Code』はこの工程化を扱います。クラウドへコードを送らない選択と、それに伴う運用責任まで検討するなら『AI-Assisted Coding』を選びます。
各書を、AIに任せる範囲と人が確認する工程で比べます。
| 書籍 | 主な読者 | 教材形式 | 扱う範囲 | 製品依存 | 読むときの注意 |
|---|---|---|---|---|---|
| Beyond Vibe Coding | AI支援開発の判断基準を得たい開発者 | 原則と失敗パターン | レビュー、テスト、セキュリティ、エージェント | 低〜中 | 「70%」は測定値ではない |
| Coding with AI | 一つの開発工程を試したい開発者 | Pythonの通しプロジェクト | 設計、骨組み、実装、テスト、Cursor | 中 | 小規模アプリと単体テストが中心 |
| Generative AI for Software Development | ツールを比較・評価したいリード | 著者による製品比較 | 生成、レビュー、QA、導入事例 | 高 | 単発試行の点数より失敗例を読む |
| AI-Assisted Programming | AIを使える工程を棚卸ししたい人 | 用途別の入門リファレンス | 発想、PRD、実装、テスト、配備 | 中〜高 | 2024年時点の製品情報が多い |
| Agentic Coding with Claude Code | Claude Codeを工程化したい開発者 | HookHubを使うハンズオン | コンテキスト、計画、MCP、サブエージェント、Skill | 高 | 操作手順は公式文書との照合が必要 |
| GitHub Copilot Step by Step | Copilotを初めて日常利用する開発者 | 短いPython演習の反復 | 指示、デバッグ、テスト、レビュー、PR | 高 | 大規模変更や組織統制には進まない |
| AI-Assisted Coding | クラウドとローカルを比べたい開発者 | 複数言語の実例集 | チャット、IDE、改善、文書、Ollama | 高 | モデル名、UI、設定は古くなりやすい |
最初の1冊：『Beyond Vibe Coding』
『Beyond Vibe Coding』が繰り返すのは、AIが最初のコードを速く書けても、完成責任までは引き受けないという原則です。
「70%問題」を扱う第3章では、AIは定型処理や既知のパターンを短時間で組み立てる一方、最後に境界条件、設計、性能、保守、運用が残ると説明します。追加依頼だけで残りを埋めようとすると、一つ直して別の問題を増やす悪循環や、正常系だけが動く「デモ品質の罠」に陥ります。70%は厳密な測定値ではなく、後半ほど人間の判断が必要になる状況を表す言葉です。
著者はAIとの協働を三つに分けます。AIに初稿を作らせる、対話しながら進める、人間が書いたコードをAIに点検させる、の三つです。どの方法でも、要件を具体化し、AIによる変更をGitで分離し、通常のコードレビューを通し、理解できないコードをマージしません。
生成コードを理解する第5章では、コードを説明できること、保守しやすく書き直せること、単体・結合・E2Eテストで挙動を固定できることを、「自分のコード」として引き受ける条件に挙げます。AIが生成したテストも網羅性を保証しないため、人間が境界値や失敗経路を追加します。
セキュリティと信頼性を扱う第8章は、認証・認可、依存パッケージ、セキュリティ検査、ファジング、ログ、段階的リリース、切り戻し、事後検証まで踏み込みます。自律型エージェントについても、第10章で計画→実行→検証→報告を基本形にし、並列で動かす場合は担当モジュールやファイルの境界を与えます。
定量的な実験書ではありません。代わりに、AIを使うほどソフトウェア工学の基礎が必要になる理由を、失敗パターンと運用手順から説明します。特定製品の操作より、長く使える判断基準を先に得たい人に向きます。
一つのアプリを完走する：『Coding with AI』
『Coding with AI』では、設計からテストまで同じプロジェクトを進めます。AIは単発のコード生成器でも設計責任者でもなく、発想と実装を助ける相手です。
題材はアマチュア無線の資格試験用Pythonアプリです。設計を扱う第3章で、解く問題を一文にし、設計文書とユーザーストーリーを作ります。AIがReactやNode.jsのような有名な技術を過剰に勧めても、要件に対してFlaskだけで十分なら、人間が単純な構成を選びます。
最初のバージョンを作る第4章では、完成品を一度に生成しません。ファイル構成、クラスやメソッドのシグネチャ、空の関数からなる骨組みを作り、アプリが起動することを確認してから機能を埋めます。AIに任せる単位を、実行して確認できる大きさへ抑える方法です。
テストを扱う第8章も、いきなり大量のテストを作らせません。まずテストの骨組みを生成し、AIが対象コードを正しく理解しているかを確認します。その後、種類を一つずつ増やし、境界条件を明示し、期待値を見直し、共通の前処理を整理して、実行結果を確認します。著者は、テストは文脈が狭く定型処理が多いため、コード本体よりAIの費用対効果が高いと考えています。
Cursorでvibe codingを試す第10章では、自然言語からレトロゲームを作ります。ただし適用先は試作品、未知技術の探索、壊れても影響の小さい内部ツールです。本番環境や機密データを扱うシステムに、そのまま持ち込むことは勧めていません。
同じアプリを設計からテストまで追えるため、工程がどうつながるかを確かめられます。Pythonの小規模アプリと単体テストが中心なので、大規模リポジトリや組織的な統制より、まず一連の工程を経験してAIとの役割分担をつかみたい場合に合います。
ツールの失敗を比較する：『Generative AI for Software Development』
『Generative AI for Software Development』は、同じ課題を複数製品へ与え、どこで失敗するかを比べます。製品ごとの点数より、評価項目の作り方と失敗例に価値があります。
コード生成を比較する第1章で、著者はChatGPT、Gemini、Copilot、Cursor、Windsurfを試します。小さな2次元配列の課題は全製品が解けました。しかしKanban／ToDoアプリでは、APIキーの直書き、入力検証・認証・rate limitの欠落、Reactの描画失敗、依存関係での行き詰まり、既存のOpenAI連携を削除する変更が起きます。小問の正解は、複数ファイルと外部APIを含む作業の成功を保証しません。
コードレビューを比較する第3章では、著者がSQL injection、XSS、memory leak、非効率なloopを埋め込んだExpress handlerを、Codacy、Snyk/DeepCode、CodeRabbitへ与えます。同書で報告された試行では、セキュリティ問題は検出した一方、3製品ともmemory leakと性能問題を見逃しました。AIによるレビューは「問題がないことの証明」にはなりません。
QAを扱う第4章は、既存のテスト基盤を持つ大規模チーム向けのKatalonと、自然言語から始めやすい小規模チーム向けのtestRigorを比較します。変更に追従するself-healing testは保守負担を減らせますが、複雑な作業手順では制御力が不足します。AIがテスト実装を省力化しても、対象の流れ、境界条件、ユーザー受入テストは人が決めます。
この比較は各製品1回、著者一人による採点で、モデル能力とIDE体験も分離されていません。現在の製品ランキングとして読むべきではありません。一方、秘密情報の直書き、入力検証不足、壊れた依存関係、性能問題の見逃しは、社内評価のチェック項目へ転用できます。
SDLCを棚卸しする：『AI-Assisted Programming』
『AI-Assisted Programming』は、発想、ペルソナ、PRD、SRS、設計、実装、テスト、デプロイ、顧客からの反応までを横断します。本記事では、同書が横断する工程を、入力・処理・検証可能な出力の単位で棚卸しする読み方を採ります。
計画と要件を扱う第7章では、発想から市場調査、PRD、SRS、インタビューの文字起こし、ホワイトボード、TDD、ワイヤーフレームまで進みます。ただし市場規模の回答には異なる数値も混在し、一次資料の確認手順は十分ではありません。AIの回答を調査結果ではなく、調査項目の叩き台として扱う必要があります。
コーディングの第8章では、アーキテクチャやファイル構成を相談し、フレームワークのversion、内部API、データ形式を渡して、小さなmoduleを一つずつ生成・実行します。説明と修正の往復に時間がかかるなら、自分で書く方が速いという判断も含まれます。
デバッグ、テスト、配備を扱う第9章では、従来のデバッガを先に使い、LLMにはerror、期待した動作、実際の動作、関連コードを渡します。単体テストでは通常値、ゼロ、負数、極端な値、非数値、nullを列挙し、PR説明、切り戻し、無停止デプロイ、クラウドのログ、問い合わせ分類まで広げます。
確認した章のテスト例は入門的ですが、7冊の中でも扱う工程が広い本です。2024年時点の製品一覧にはCodeWhispererやDuet AIなど旧称も含まれるため、現在の製品選定表には使えません。最新の操作を学ぶ本ではなく、導入候補の工程を洗い出すための本として読むと価値が残ります。
Claude Codeを工程化する：『Agentic Coding with Claude Code』
『Agentic Coding with Claude Code』は、Claude Codeをチャットとして使う段階から、エージェントを動かす基盤として設計する段階へ進みます。一文の指示を磨くより、コンテキスト、権限、成果物、ツール、エージェントの境界を整えます。
コンテキスト設計を扱う第1章は、文脈操作を「書く・選ぶ・圧縮する・隔離する」に分けます。CLAUDE.mdには常に必要なアーキテクチャとコーディング規約だけを置き、領域別の詳細を別ファイルに分離します。
計画と複数エージェントの第6章では、Planモードで読み取り専用の調査を行い、仕様書を保存して人間が承認します。その後、依存しないtaskだけを並列化し、担当ファイルを指定して、最後にgit diffを確認します。サブエージェントの第7章は重い作業を別のコンテキストへ隔離し、Skillの第9章は繰り返す手順とscriptを必要なときだけ読み込む構成にします。強制したい規則はSkillの文章だけに頼らず、権限、hook、CIへ置きます。
設計思想は一貫していますが、操作手順は現行の公式文書と照合して使う必要があります。たとえば同書の第7章は/agentsの対話的な作成wizardを前提にします。しかし、2026年9月1日に確認したClaude Code公式文書では、v2.1.198以降の/agentsはwizardを開かず、サブエージェント用ファイルの場所を案内すると説明されています。また第4章が論じるMCPのコンテキスト負荷について、現行の機能比較ページは、通常はsession開始時にツール名だけを読み、完全なschemaは利用時に読むと説明します。MCPの設定や導入形態によっては、この挙動を前提にできません。
したがって、本書は操作をそのまま転記する手順書ではなく、Claude Codeを再利用できる開発工程へ組み直すための設計書として読みます。画面、コマンド、設定値は導入時点の公式文書で確認してください。
Copilotを反復練習する：『GitHub Copilot Step by Step』
『GitHub Copilot Step by Step』は、短い説明、指示、出力、チェックリスト、演習を繰り返すドリル型の本です。目的、入力、出力、制約、ライブラリ、version、既存コードを伝え、一度に一関数、一bug、一観点へ絞ります。
デバッグの第5章では、error、期待動作、実際の動作を渡し、一度に一つだけ修正します。表面的なpatchで止まらず、5 Whysで「なぜテストされなかったか」まで掘り下げます。
テストの第6章は、framework、正常・異常・境界条件を指定し、fixture、mock、parameterizeを使います。同時に、Copilotが割引計算の期待値を誤る例を示し、「生成されたテストもテストする」必要を説きます。レビューと協働の第7章では、代替案を正しさ、複雑度、可読性、メモリ使用量、チーム規約で比べ、採用理由とAI利用をPRへ残します。
短いPython演習なので、Copilotを日常作業へ入れやすい本です。一方、確認した章では大規模な差分、CODEOWNERS、セキュリティ検査、組織的なエージェント運用は深掘りしていません。『Coding with AI』が一つのアプリを完走する実習なら、本書はCopilotを使った短問反復です。
ローカルLLMまで比べる：『AI-Assisted Coding』
『AI-Assisted Coding』は、クラウドのチャット、IDE支援、ローカルモデルを同じ開発フローで扱います。方針検討はチャット、局所的な実装はIDE支援と使い分け、生成物を小さい差分にして静的解析、テスト、手動レビューへ戻します。
リファクタリングの第4章では、SonarQubeなどで全体を把握してから、AIにはコードスメルの分析と局所変更を一つずつ行わせます。外部仕様を変えず、各段階にcommitとtestを置きます。それでもAIは、責務過多や不自然なオブジェクト間依存を見逃しました。
文書化の第6章は、inline comment、JSDoc、OpenAPIを扱います。生成されたOpenAPIのpathが誤る例や、Copilotが更新時に説明を削りすぎる例があり、Swagger UIなどでの実行確認を求めます。
ローカル言語モデルの第9章は、Ollama、Docker、Continue、REST APIを接続します。ローカル運用では、privacyやvendor independenceと引き換えに、hardware、latency、license、patch、network securityを自ら負います。Ollama APIは認証なしで利用できるため、外部公開時には認証proxyなどが必要です。
著者らの環境ではローカルモデルがクラウドより遅く、回答品質も低かったと報告されていますが、測定条件が十分でなく一般化はできません。この章を読むと、クラウドへコードを送らずに済む利点と、その代わりに増える運用責任を一緒に比べられます。
自分の工程から読む順番を決める
本をツール名で選ぶと、UIやモデル名が変わったときに学びが古くなりやすくなります。先に、自分のチームがAI支援開発のどの段階にいるかを決めます。
図：最初の一冊を、いま不足している目的から選ぶ****
特定のツールをすでに使っている場合は、本文と比較表で対応する本を選びます。
本を選ぶ前に、次の変更でAIに任せる範囲を一つ決めます。関数・バグ修正・テストのような局所作業なのか、設計からテストまでの一つの小規模アプリなのか、複数ファイルの変更やコマンド実行を伴うエージェント作業なのかを分けます。次に、要件、差分、テスト、レビュー、権限、切り戻しのうち、まだ人が確認する手順を持たない項目**を一つ選びます。
受入条件、差分、テスト、レビューの手順が定まっていないなら、『Beyond Vibe Coding』を先に読みます。AI支援を使い始める段階で、生成物を受け入れる判断基準を作るためです。受入手順があり、Pythonの小規模アプリをCursorも含めて設計から単体テストまで試すなら、『Coding with AI』を選びます。関数、バグ修正、テストのような局所作業をGitHub Copilotで反復したいなら、『GitHub Copilot Step by Step』が対応します。
AIをどの工程へ入れるか自体が未整理なら、『AI-Assisted Programming』でSDLC全体を棚卸しします。社内評価や導入判断で失敗の見つけ方を設計したいなら、『Generative AI for Software Development』を読みます。製品の順位を借りるのではなく、秘密情報、入力検証、依存関係、性能、テスト設計の失敗を、受け入れ基準へ翻訳するためです。
複数ファイルの変更やコマンド実行をエージェントへ任せるなら、コンテキスト、計画、サブエージェント、Skillを工程として設計するために『Agentic Coding with Claude Code』を選びます。クラウドへコードを送らない運用を検討し、ハードウェア、認証、パッチ、ネットワーク保護まで引き受けるなら、『AI-Assisted Coding』が適しています。
選んだ本を読んだら、次のAI生成変更について「任せる範囲」と「人が確認する証拠」を一組書きます。そこで確認手順が不足した工程が、次に選ぶ本です。
評価・大規模開発・本番運用を補う4冊
7冊はAIを使って開発する工程を学ぶ本です。一方、最後に残る「同じ条件でどう評価するか」「大規模なコードベースをどう維持するか」「本番の安全性と復旧をどう設計するか」には、AI支援開発の本だけでは足りません。以下の4冊を補完として加えます。ここでの4冊は書籍ページの説明と目次で適合性を確認した候補であり、本文の代表章まで読んで比較した7冊と同じ評価段階ではありません。
評価設計とモデル選択：『AI Engineering』
『AI Engineering』は、基盤モデルを使うアプリケーションについて、モデル、データセット、評価benchmark、指標を選ぶ枠組みを扱います。特に、モデル利用が増えるほど評価が重要になること、open-endedな出力を評価する方法、提供時のlatencyとcostを論じる点が重要です。
同一リポジトリ、同一の受入条件で手順を比較したときの開発時間や欠陥率は、既存7冊だけでは測れません。この本を足すと、少なくとも比較対象、評価データ、指標、コストという測定設計の語彙を補えます。コーディングエージェントのbenchmark手順そのものではないため、実験計画と実行は別途必要です。
大規模コードベースと組織の統制：『Software Engineering at Google』
『Software Engineering at Google』は、プログラミングと、長期に変化するコードベースを維持するソフトウェア工学を区別します。時間による持続可能性、組織規模で成り立つ実践、設計判断のトレードオフを中心に据えています。
大規模リポジトリにAI支援を入れる際は、生成品質だけでなく、レビュー、依存関係、所有権、変更の広がりを扱う必要があります。本書はエージェント固有の操作を教える本ではありません。既存のソフトウェア工学の中で、それらをどう統制するかを考える土台になります。
本番の安全性と復旧：『Building Secure and Reliable Systems』
『Building Secure and Reliable Systems』は、セキュリティと信頼性を別々の品質ではなく、設計・実装・運用を通じて扱う本です。設計戦略、コーディング・テスト・デバッグ、インシデントへの準備・対応・復旧、組織横断の協働を扱います。
AIが作った変更を本番へ入れるなら、コードレビューだけでは不十分です。段階的リリース、観測、切り戻し、インシデント対応までを受入条件に含める必要があります。規制産業で必要になる個別の法令解釈は扱いませんが、安全性と信頼性を運用可能な設計へ落とすための補助線になります。
LLM固有の境界と脅威：『The Developer’s Playbook for Large Language Model Security』
『The Developer’s Playbook for Large Language Model Security』は、LLMを使うシステム固有の脅威、信頼境界、脆弱性、対策を扱います。OWASP Top 10 for LLM Applicationsの知見を背景に、リスクの特定と防御の設計を主題にしています。
コーディングエージェントであっても、外部ツール、MCP、リポジトリ、秘密情報に接続すれば、権限と入力の境界が攻撃面になります。本書は、prompt injectionや過剰な権限を含むLLM固有のリスクを、エージェント導入時の脅威モデルに組み込むために読みます。一般的なアプリケーションセキュリティや組織固有のコンプライアンス審査を置き換える本ではありません。
未評価の早期公開候補
以下はO’Reilly上で閲覧できますが、表示刊行日が調査日より後でした。代表章を読んだ7冊とは分け、現時点では未評価の候補として扱います。
- 『Evals for AI Engineers』：表示刊行日2026年10月。error analysis、synthetic data、LLM-as-a-judge、production monitoring、cost optimizationを扱うため、評価設計の残る課題に最も直接的に関わります。
- 『AI-Native Software Engineering』：表示刊行日2027年2月。仕様駆動開発、エージェントのworkflow、MCP、governanceが主題です。
- 『Claude Code: Up and Running』：表示刊行日2027年1月。CLAUDE.md、権限、MCP、CI/CD、複数エージェントを扱います。
- 『Agentic Engineering at Scale』：表示刊行日2027年7月。legacy system、harness engineering、guardrails、エージェント群の連携が主題です。
調査範囲と限界
O’ReillyのGenerative AIカテゴリと、「AI-assisted software development」「vibe coding」「AI coding assistants」「generative AI software engineering」「AI-driven development」の検索結果から、AIアプリの構築そのものではなく、AIを利用したソフトウェア開発を主題にする本を選びました。検索時点の件数や並び順は変動するため、本稿の選定根拠には使いません。
7冊は書誌・目次に加え、公式リーダーで各章本文を開いて確認しました。本記事は書籍内容の比較であり、掲載コードの再現実行は検証範囲に含めていません。本文中のツール比較は書籍著者による試行の要約であり、本記事での再現結果ではありません。製品の現行仕様は一部だけ公式文書と照合しました。
この記事は書籍本文の比較であり、最新の製品ランキングや再現可能なbenchmarkではありません。操作、価格、モデル、UIは導入時に再確認する必要があります。
まとめ：確認できない工程から選ぶ
AI支援開発の本は、いまAIに任せたい作業ではなく、生成物をまだ自力で確認できない工程から選びます。受入条件、差分、テスト、レビューの手順が不足しているなら『Beyond Vibe Coding』を先に読みます。工程全体を試す、評価を設計する、特定ツールを工程へ組み込むといった次の課題は、その手順を持った後に選びます。
最初の一冊を読んだ後は、次のAI生成変更について、AIに任せる範囲と人が確認する証拠を一組書きます。その一組を作れない工程が、次に読む本を決めます。
エンジニアを募集しています！
ここまで読んでいただきありがとうございました！
Algomatic では、「AI革命で人々を幸せにする」をミッションに、変化の速い領域でも 学びや試行錯誤を続けられる エンジニアを募集しています。
もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！
Sources
関連記事
News to Guide
ニュースの次に確認する
発表内容を、現在の料金や仕様と照らし合わせられる関連ガイドです。
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み