■ 1. ループエンジニアリングという概念の問題
- 「ループエンジニアリング」という語は普及しやすいが、精度が伴わない可能性がある
- ワンショットプロンプトは本格的なソフトウェア開発には不十分
- エージェントがコードを書いた場合でも、レビュー、判断、コンテキストの継続が必要
- 問題が発見された際はリトライ、方向転換、人間の介入のいずれかを選択する必要がある
- 「ループ」という表現は正確だが、ループ自体は難しい部分ではない
■ 2. 単純な繰り返しはエンジニアリングではない
- 「生成→評価→フィードバック→再試行」というパターンは有用であり、多くの分野で用いられる
- モデル呼び出しを繰り返すだけでは自動的にエンジニアリングプロセスにはならない
- モデルは根本的な誤りを保持したまま、表面的な出力を改善することがある
- 出力を読みやすくすることと設計を改善することは別物
- 重要な問いは「エージェントをループに入れられるか」ではなく「ループを何が制御するか」
■ 3. 欠けているレイヤー
- 通常のソフトウェアチームでは、実装は単一の行為として扱われない
- コード作成・レビュー・テスト・人間の判断という一連のプロセスが変更を制御する
- エージェント開発にも同様のレイヤーが必要
- 実際のコードベースで難しいのはパッチの生成ではなく、そのパッチが適切かどうかの判断
- エージェントは素早くコードを生成できるが、速度だけが関心事ではない
- 「この変更はここに属するか」という問いを立てる仕組みが必要
■ 4. TAKTの位置づけと役割
- TAKTはエージェント駆動開発のオープンな実験的ハーネス
- 「エージェントをループで実行するツール」という位置づけは本質を外れる
- より正確な位置づけは「エージェント駆動の開発作業を包むハーネス」
- TAKTが目指すのは全ステップの自動化ではなく、各ステップの明示化
- 誰が書くか
- 誰がレビューするか
- 何が再試行されるか
- どこでワークフローが停止するか
- ハーネスがなければエージェントワークフローはモデル呼び出しの連鎖になる
- ハーネスがあれば、呼び出しに役割と境界が生まれ、検査・変更が可能になる
■ 5. スローガンよりもオーケストレーション
- 「ループエンジニアリング」というスローガンは適用範囲が広すぎる
- 量的研究ループ、デザイン反復ループ、コーディングループなど異なる文脈で使われる
- これらは関連するパターンだが、同じ仕組みを必要とするわけではない
- エージェントを使ったソフトウェア開発では仕組みそのものが重要
- オーケストレーションの問いが実用性を決定する:
- 次のステップを誰が担うか
- 失敗をどう定義するか
- システムがリトライすべき場面と人間が判断すべき場面の区別
- これらの問いがエージェントワークフローをデモにとどめるか実用に至るかを分ける
■ 6. OSSとしての意義と透明性
- エージェントが実際の開発に参加するならば、周辺システムはブラックボックスであってはならない
- 開発者が確認できるべき事項:
- 役割の定義
- レビューのプロセス
- リトライの処理
- 人間の判断が介入する箇所
- チームごとに異なるレビューポリシー、リスク許容度、ゲートを設定できる必要がある
- ハーネスは開発者が理解・再構成できるものでなければならない
■ 7. TAKTが目指す形
- エージェントを孤立した呼び出しではなく、開発プロセスの参加者として扱う
- 解決すべき問い:
- 作業をどう役割分担するか
- 出力をどうレビューするか
- ステップをまたいでコンテキストをどう維持するか
- 失敗からどう回復するか
- 人間をすべての操作の監視者にせずにどう関与させるか
- これらの問いはより良いプロンプト単体では解決できない
- より大きな改善はエージェントの周囲に構築するシステムから生まれる
- TAKTはそのレイヤーをオープンに構築する試みであり、作業の分担・レビュー・リトライ・停止を可能にする
- 重要なのはループそのものではなく、ループの周りにあるエンジニアリング