- AIコーディングツール（ジーニー）に 「Kent Beckのようにコードを書いて」 というペルソナプロンプトを追加するとコード品質が改善するかを実験した結果、テストスタイルと変数命名は改善されたが、アーキテクチャ設計 は変わらなかった
- Ropeデータ構造 を実装するプロジェクトを通じて、ペルソナプロンプトと設計制約条件の効果を比較検証
- ペルソナは ミクロな行動（テスト方式、ネーミング）を改善し、明示的な制約条件は マクロなアーキテクチャ（クラス階層構造）を決定
- 4グループの実験結果では、ペルソナと制約条件を 組み合わせたプロンプト が最も良い結果を示した
- Rich Suttonの "The Bitter Lesson" を引用し、人間の専門性をエンコードするより 計算資源を活用 するほうが効果的であることを示唆
現在のAIコーディングツールの段階
- 現在のAIコーディングツール（ジーニー）は 「馬のいらない馬車」 の段階にあたる
- あらゆる技術革新は、まず既存の枠組みで理解され、その後に根本的な変化が認識される
- 馬のいらない馬車 → 自動車
- 無線電信 → ラジオ
- 電子メール → メッセージング
- 新しい技術の 二次的効果、強化ループと抑制ループを理解するには、十分に長く使う必要がある
実験：Ropeデータ構造
- Ropeデータ構造 は、非常に長い文字列で途中の文字削除を効率的に行うための構造
- 単純な方式では右側の文字をすべて移動させる必要があり、O(n) の時間がかかる
- Rope構造では substringオブジェクト と concatenationオブジェクト を使い、削除を 定数時間 で処理
- 削除時に3つのオブジェクトを割り当て
- 探索はO(演算回数)だが、文字列長より小さく、定期的な圧縮も可能
実験の進行過程
Phase 1: ペルソナ（"Code like Kent Beck"）
- "Code like Kent Beck" プロンプトを追加したときにコード品質が改善するかを検証
- 結果: コードスタイルの改善を確認
- 変数名が改善
- テスト戦略が モノリシックなスクリプトからモジュール化された単体テスト（TDD方式） へと転換
- 予想外の発見: アーキテクチャは変わらない
- 標準的な二分木でRopeを実装
- Kent Beckが使う Compositeパターン は無視された
Phase 2: 設計ガイドの追加
- Controlグループのコードは冗長すぎて、トークン上限超過 により構文エラーが発生
- トークン上限を増やして解決
- 「より多くのコンピューティング」が単純な解決策になり得る
- プロンプトに 明示的な制約条件 を追加
- 「Compositeパターンを使う」
- 「振る舞いを小さく特化したクラスに分離する」
- 結果: 想定どおりの設計を実装
- Substring と Concatenation の分離クラス
- 単一クラスよりシンプルな構造
- 実際にはさらに単純な設計に到達：Null Object（EmptyString）やネイティブ文字列ラッパーなしで、Substring 0..size として処理
Phase 3: 4グループに分けた実験
- どの介入が効果を生んだのかを確認するため、交差実験を設計
- Control: 標準アシスタント
- Kent Beck: ペルソナのみ適用
- Composite: アーキテクチャ制約のみ適用
- Combined: ペルソナ + 制約条件
実験の結論
- 2x2マトリクス効果 を確認
- ペルソナはミクロな行動を決める: 「Kent Beck」プロンプトは テストスタイル と ネーミング を安定して改善したが、構造的な意思決定には影響しなかった
- 制約条件はマクロなアーキテクチャを決める: 「Composite Pattern」プロンプトは クラス階層構造 を強制し、ペルソナがなくても細分化された設計を生成した
- 組み合わせが最善: Combinedグループは正しいアーキテクチャ（Composite）と正しい開発習慣（TDD/Unit Tests）の両方を提供した
The Bitter Lessonの適用
- 隠れた目標: ジーニーが 機能と将来のバランス を取りながら、より良い開発を行えるようにすること
- 試した方法: 慎重なプロンプティング、ジーニーの提案変更を注意深くレビューすること、より小さい/大きいステップなど
- Rich Suttonの "The Bitter Lesson" を引用
- 70年にわたるAI研究が示す教訓: 人間の専門性をエンコードするより計算資源を活用すること のほうが良い結果をもたらす
- スタイルをエンコードしようとしたこと自体が、誰もが犯す 同じ過ち だった
計算活用による効果的な開発スタイルの提案
- 数多くのリポジトリのひどいコードスタイルをコピーする 拙いコーディングジーニー に縛られる必要はない
- 計算活用の方法 を提案
- 大規模リポジトリを選ぶ
- 100万のジーニーが次の機能を実装するが、各ジーニーが 整理方法と整理量をそれぞれ異なる形で選択 する
- 最も低いコスト（時間、トークン、電力、費用など）で機能追加に成功したジーニーを選ぶ
- 多くのジーニー、多くの機能、多くのリポジトリでこれを繰り返す
- 一見するとコーディングを「無駄遣い」しているように見えるが、実際にはそうではない
- Jessica Kerrはこれを "Design Contest" と呼んでいる
1件のコメント
では、ジェフ・ディーンのようにコーディングしろと言ったら、果たして……？！