Coderlet、読みやすいコーディングエージェント制御層を公開。ただしサンドボックスと自動テストは未実装

8月10日に公開された Coderlet は新しいモデルを提案するものではなく、コーディングエージェントで最も見落とされやすい部分である harness 制御層を、読みやすく実行可能な Python プロジェクトへと凝縮したものだ。Responses API、ストリーミング、function calling をサポートするモデルエンドポイントに接続し、ファイルの読み書き、精密編集、検索、shell、Web ツールを内蔵している。また、1回のリクエストを、コンテキストの構築、モデルの呼び出し、ツール引数の検証、実行または拒否、observation の返却、記録の保存、そして最後の完了通知という明確な順序で処理する。

設計の中核となるのは、3つの責任境界だ。モデル境界は、コンテキストとツール記述を API リクエストに変換し、テキストおよび構造化された呼び出しをデコードすることだけを担う。実行境界はツール名と引数を検査し、有効なアクションを生成された順に実行する。状態境界は session を JSONL 形式で保存し、古いコンテキストを `PENDING_MEMORY.md` に圧縮したうえで、長期記憶用の `MEMORY.md` に統合する。各ツールの結果には元の call ID が保持されるため、開発者は「モデルが提案済み」「ツールが環境を変更済み」「リクエスト記録が保存済み」という3つの異なる完了状態を区別できる。アクションが成功しても、その後の保存に失敗した場合、復旧フローは最後に確認された段階から再開でき、副作用を伴う可能性のあるコマンドを不用意に再実行する必要がない。

この実装の価値は、SWE-bench の記録を更新することではなく、主に検証可能なリファレンス骨格を提供する点にある。作者は、タスク性能の向上を主張していないと明言している。リポジトリには現時点でコミットが2件しかなく、自動テストも存在せず、単一ユーザーかつ単一ターミナルの session にしか対応していない。さらに重要なのは、ツールが現在のアカウントに付与された完全な権限でファイルを読み書きし、shell を実行することだ。OS サンドボックス、コマンド承認ゲート、ファイルシステム境界、マルチテナント分離はいずれも備えていない。エンジニアリングチームがプロトタイプに使用する場合は、重要なワークスペースへ直接接続するのではなく、まず権限ポリシー、追跡可能な副作用の状態管理、機密情報のマスキング、テストを追加すべきだ。