実験駆動開発

Sun, 04 Aug 2024 00:52:30 +0900

背景

人はAIには勝てず、人は金魚になるべきである
I’m a goldfishで書いた、通り、これはAIの高度な思考方法を目にした自分の結論
AIは、keenな論理的思考法、圧倒的知識のカバー率、デカルトレベルのDoubt、どれをとっても人間は勝てない
AIは数万文字を一瞬で読むのに、論文一つ読ませても、深いレベルで理解して解説できる
人間はオワコンとなっている
しかし、人間もCheckや理解をしないとAIがやっている事が正さがわからない
人間が検証可能かつ正しい解答を出す、AIと伴走する開発の方法論が必要
アイディアのもとはブロックチェーンやGitコマンドにある

実験駆動開発

バイブコーディングの課題

バイブコーディングには次のような課題がある:

AIの労働量が早すぎて、人間のレビューができない
AIの知能に人間がついていけないため、AIと人間だと深い議論になりにくい
AIが言った事、やっている事が高度な時に、人間が後々でそれを学習できない

つまり、「今どうなっているか（結論）」と「なぜそうなったか（追跡）」、「人間の知能やマンパワーが足りない」などが問題。

実験駆動開発とは

実験駆動開発とは、対象を仮説として立て、AIとの1回1回の試行・結果をmdのログとして保持しながら進める開発手法。会話そのものより、仮説と実験の繰り返しの方が本質なので、会話駆動ではなく実験駆動と呼んでいる。

そのためには、AI同士をログを残した状態でdiscussionして開発をする必要がある。

つまり、次を可能にする:

AI同士で議論させる => マンパワー解決
AIの作業記録を残す => なぜそうなったかがわかる
正本管理をする => 今どうなったかがわかる

Lab

Labの作り方

まず、AIとのすべての会話のメッセージをMarkdown化して記録する
lab/というディレクトリの下に、docs/とreports/という2つのサブディレクトリを持つ
形式
- docsはdocs/{3桁連番}_{slug}.mdという形式。番号は作成順の恒久的なIDで、内容は直接書き換えていく
- reportsはreports/{3桁連番}_{slug}.mdという形式。一度作ったら書き換えない
- 連番はdocs・reportsそれぞれのディレクトリ内で別々に管理する
これを徹底して、複数のAIの会話をこのMDに落とし続ける

以下がLabのディレクトリ構成の例。

1
2
3
4
5
6
7
8
9


lab/
├── docs/
│ ├── 001_spec.md # specトピックの現時点の正本（直接書き換える）
│ └── 002_backlog.md # backlogトピックの現時点の正本（直接書き換える）
└── reports/
 ├── 001_dictionary_analysis.md # レビュー依頼
 ├── 002_root_cause_review.md # レビュー依頼
 ├── 003_review_response.md # 002への回答
 └── 004_naming_convention_update.md # docs/reportsの命名規則自体の変更記録

docsという名前は、中身が仮説なのか実験結果なのかbacklogなのかを問わず使える、構造だけを表す名前にしている。仮説（hypo）や実験（exp）のような、用途に特化した名前にすると、別の種類のドキュメントを増やしたくなった瞬間に名前と実態がずれるため、あえて汎用的な名前にしている。

これによって、AIの一切の会話がすべてmdに落ちるので、透明性と追跡性、そして再検証性など生まれる。

docsとreportsの意味

docs（Stack）: トピック（spec、backlogなど）ごとに持つ、常に最新の内容が「今の正本」になる、継続的に更新される生きたドキュメント
reports（Flow）: 1回の試行・結果の時系列ログで、一区切りごとに1ファイルを必ず作成する、時間とともに流れていく情報

両者の違いを表にすると以下の通り。

観点	docs	reports
データ目的	Stock型	Flow型
スタイル	Free Form	IMRaD
可変性	Mutable（直接書き換える）	Immutable（一度作ったら書き換えない）
ファイル名	`docs/{NNN}_{slug}.md`	`reports/{NNN}_{slug}.md`
過去の履歴	git履歴として残る（ファイル自体は最新のみ）	ファイルそのものが履歴になる
役割	今どうなっているか（結論）	なぜそうなったか（追跡）
イメージ	Git HEAD	Git Log

つまり、「今どうなっているか（結論）」と「なぜそうなったか（追跡）」、がわかる仕組み。

mdはIMRaD形式にする

reportはIMRaD（Introduction・Methods・Results・Discussion、結論を加えることも多い）形式を強制する
背景・手法・結果・考察・結論、そして参考文献という形式に蒸留し直す
特に、参考文献に過去のreportやdocs、コードなども引用してもらう事で探すのが楽になる
これらの科学的方法論をベースにすることで、ここの会話で行われた実験の検証性や透明性を担保する

開発フロー

開発フローは、主にinitとloopの2stepsに分かれる。

init: 管理AIとテーマを決める

AI同士に作業させるため、管理用のAIと、やりたいことをまとめたテーマや仮説を先に作る必要がある。

まず、開発でTTPする対象を決める
これは、ある論文の再現だったり、あるシステムだったりする
そして、それを構成要素に分解して、要素ごとに数値化する
その上で、その数値を達成目標にして仮説とする
- これはマイルストーン、検証項目、達成目標などでもOK
- もしくは、REQ-1, REQ-2のような要件を文章化し、その要件文章の文単位で要件IDをふって細かく管理手法もあり
この仮説（正本）を徹底的に管理AIと人間（自分自身）で討論する
この時点で、この仮説を討論したAIは自分の分身となる
なぜなら、仮説について自分レベルで理解しているから

この仮説が開発のバイブルになり、これの理解を徹底的にしている事が大切。

loop: 作業AIと実験する

作業AIを別途用意して、先程作った管理AIと仮説を使って実験を進める。

アルゴ:

作業AIを用意して、作業AIに仮説を渡す
作業AIには実験が終わったらreportを残してもらう
そのreportを管理AIに渡して指示をもらう
管理AIのレスポンスを作業AIに渡す
その繰り返し

つまり、人間はメッセンジャーになる。

subissue: 別のテーマ化する

進捗が悪い時は以下の対処方法で対応する

クリティカルパスじゃない場合:
- backlogに追加してfuture workとする
クリティカルパスの場合:
- そのissueを別途テーマとして切り出す
- 別package（フォルダ）で、独立した別Agentに、そのテーマを考えさせる
- つまり、ゼロベースでその問題に特化して対応してもらう

まとめ

LabはAIとの会話を、docs/（Stack）とreports/（Flow）という2つのサブディレクトリに分けてMarkdown化する記録方法
docs・reportsは用途に特化しない汎用的な名前で、仮説・実験だけでなくbacklogのような別の内容にも使い回せる
docsは常に最新の内容が正本になるドキュメントで、番号は恒久ID。reportsは追記のみの時系列ログで、番号は作成順。連番はそれぞれのディレクトリ内で別々に管理する
人間の役割は自分で考えることではなく、何をdocsに据え何をreportとして残すかを判断して中継するメッセンジャーになる
本質は会話そのものではなく、仮説と実験の繰り返しなので、実験駆動開発と呼んでいる

Lab on M1KE BL0G

実験駆動開発

背景

実験駆動開発

バイブコーディングの課題

実験駆動開発とは

Lab

Labの作り方

docsとreportsの意味

mdはIMRaD形式にする

開発フロー

init: 管理AIとテーマを決める

loop: 作業AIと実験する

subissue: 別のテーマ化する

まとめ

参考文献