標準的なAIエージェントは、次のように動作します。プロンプトを受け取り、ドキュメント(あるいはセカンドブレイン)を読み込み、ソースファイルをgrepして、利用可能なデータからコンテキストを組み立てようとし、最善の推測に基づいて解決策を生成します。
AITM(AI Task Manager)は、これとは異なる方法で動作します。コードベースに関する、継続的に更新される独自のナレッジベースを保持し、作業が始まる前にそれをエージェントに渡します。
エンタープライズプロジェクトの罠 大規模なプロジェクトに拡大すると、個々の部品(モジュール、ソースコード、ドキュメント)はやがて限界に達します。開発は遅くなり、次のような罠に陥ります。
• AIが集めた情報が、不完全だったり、断片的だったり、最悪の場合はまったくの誤りだったりする。
• AIが誤ったデータを信じ、あなたがAIを信じる。
• コードがドキュメントと一致しなくなる。
• 正しく書かれたプロンプトでさえ、すべてが順調だという幻想のもとで動き、現実はまったく別のところにある。
そこにハルシネーションが少し加わると、最終的な成果物は期待から大きくかけ離れていきます。
AITMのナレッジには、4つの確かなレイヤーがあります。
- コントラクト
AIのための重要な情報を結びつける論理的な単位です。単体テスト、ソースファイル、他のコントラクトへの参照、ドキュメントへのリンクが含まれます。
Business Logic & Contracts のドキュメントで詳しく確認できます。
- DOM要素
すべてのUI要素は、ビジネスロジックや振る舞いのロジックに結びついた、固有のAITMタグを持っています。AITM Dev Toolsを使えば、これらの要素をプロンプトに直接挿入できます。AIは、どの要素を変更しているのか、そこからどのイベントが発生するのかを正確に把握します。
DOM Explorer のドキュメントで詳しく確認できます。
- 振る舞い
ユーザー向けの機能を定義します。ユーザーがどのような操作をでき、何がそれを妨げるのか(たとえば、このボタンをクリックするとバリデーションが実行され、その後に保存関数が呼び出される)。必要に応じて、抽象的な説明から、関数、クラス、ファイルへの直接の参照まで幅があります。
- ビジネスロジック
そのままでは開発者の頭の中にしか存在しないルールと依存関係です。
AITMが真実を守り、矛盾を解決する方法 AITMでは、Task(ソフトウェアが何をすべきかの定義)を作成します。システムはそこから、コード、ドキュメント、コントラクト、テストを生成します。
情報が矛盾した場合はどうなるのでしょうか。
ユーザーの要件が常に最優先されます。
ドキュメント、コントラクト、生成されたコードは、タスクに照らして相互にチェックされます。
不整合が生じた場合(たとえば、要件がシステムアーキテクチャと衝突する場合)、AITMは自動的にBugを記録します。
最終的に、決定を下す唯一の権限は人間にあります。AIは矛盾を指摘しますが、何が正しいかを決めるのは人間です。
個人的な経験:コードを1行も手で書かずに作る 私はAITMを、AITMの中で作っています。コードは100%AIが書いたものです。開発者である私は、コードに手作業で触れたことがありません。私の役割は、アーキテクチャ、設計パターン、運用ルールを定義することだけです。
AIのおかげで、厳密に分離されながらも深く結びついた、はるかに抽象的で複雑な構造を設計できます。
重要なポイント:AIが書くコードには、新しいアーキテクチャとパターンを考案する必要があります。人間には複雑に見えても、AIにとって非常に読みやすいものです。AIを使えば、制約となるのは技術的な限界ではなく、アーキテクチャを設計し管理するあなた自身の能力だけです。
私が他と違うことをしている点と、今後について これまでの記事で取り上げた内容は、ほとんどのAIオーケストレーターに同じように当てはまります。ここから、私たちは差別化を始めます。
今後の投稿では、AITMにおける具体的な違いを詳しく解説します。どう違うのか、なぜこの道を選んだのか、どのような利点があるのかを説明します。
現在、AITMは50万行を超えるコードに達しており、この規模でも、私は1人の開発者として全工程を管理できています。結果は格段に優れており、緩くつながったエージェントやプラグインに頼る既製のセットアップとは違って、何かが制御不能になることはありません。
