Coroidの適用範囲

「AIコーディングツール」には実際にはいくつかの異なる製品が含まれます。これらは同じ用途を競合するものではなく、カテゴリーを誤ることは、同一カテゴリー内で製品を誤って選ぶよりも高くつく間違いです。

4つのカテゴリー#

最初の2つは開発者の隣でモデルを動作させます。エージェントセッションは作業を開発者のマシンから切り離しますが、それでも人が各タスクを選び、指示し、結果をテストして完了を判断します。プロトタイピングツールは新しいものを素早く作成します。Coroidはこれらのいずれにも当てはまりません。すでに運用中のコードベースに対するあらゆる変更に対し、一度設定したプロセスを実行するのです。

セッションとファクトリーは異なる課題です#

エージェントセッションが最も近い比較対象です。なぜなら同様にプルリクエストで終わるからです。違いはプロセスを担うものにあります。

セッションはそれを操作する人の上で動作します。誰かが作業内容を決め、プロンプトを記述し、プレビューを開いて不具合を発見し、フォローアップを記述し、完了を判断します。結果の質はその日のその人の注意力に依存し、これらすべてをこなせる人のみがセッションを実行できます。実務上は開発者です。

ファクトリーは一度設定したプロセスの上で動作します。Coroidは手順をシステム内に保持します——仕様、受け入れ基準に基づくQA、レビュー、品質ポリシーおよび承認ルールを含め、あらゆる変更に適用します。プロセスが依頼者の役割ではないため、誰でも依頼できます。

セッションは探索に適しています。エージェントと共に未知の問題に取り組んだり、進めながら形を整えたい変更を行ったりする場合です。毎回一定の基準を満たす必要がある作業はCoroidで処理しましょう。両者はpull requestで結びつきます。GitHubアプリを使えば、開発者が自身のエージェントで作成したプルリクエストに対してもCoroidが同じチェックとレビューを実行できます。詳細はプルリクエストのレビュー。

プロトタイピングと本番環境は異なる課題です#

この区別を明確にしておくことが重要です。なぜならプロトタイピングツールは非常に優れており、同じ手法が本番環境の作業にも適用できると簡単に考えがちだからです。

プロトタイピングは目に見えるものができるまでの速度を重視します。何もない状態から始め、守るべき既存のアーキテクチャも、通過させるべきテストスイートも、準拠すべき規約もなく、まだ誰も結果に依存していません。制約はかえって作業を遅らせるだけなので、これらのツールはほとんど制約を設けません。

本番環境の作業はほぼすべてが制約で成り立っています。コードはすでに存在し、そこには既に決定事項が組み込まれています。他の要素がそれに依存しています。通過させるべきテストがあり、準拠すべき規約があり、セキュリティやコンプライアンス要件があり、出荷前には満たすべきレビュープロセスも存在します。

Coroidはこれらの制約を回避するのではなく、それらを中心に構築されています。

互いにうまく連携する#

これは二者択一の話ではありません。両者は自然に連携します：

何を作るかを決めるためのプロトタイプ作成アイデアの検証やUIの試作、今週中にステークホルダーに見せるものを作る場合、プロトタイピングツールの方がCoroidよりも優れており、ぜひ利用すべきです。

その後、保守する場所で構築するアイデアが固まったら、実際に運用するコードベースへと作業を移し、そこには自社の規約やテスト、レビュープロセスが適用されます。これがCoroidの役割です。

プロトタイプが答えるのはこれを作るべきか。Coroidが答えるのは既存のシステム内で適切に構築すること。

Coroidを使わないべきケース#

機能一覧よりも率直に説明する方が役立ちます：

• アイデアを検証する段階であり、本番リリースするわけではありませんプロトタイピングツールを使ってください。Coroidは実際のコードベースへのレビュー済みの変更を生成しますが、明日には破棄されるかもしれないものにとっては不要な負担です。
• 数分以内に視覚的な結果を見たい場合Coroidはプルリクエストを生成しますが、ライブデモではありません
• ペアプログラマが欲しい場合エディタ内でモデルと並行して行単位で作業したい場合は、IDEアシスタントを利用してください。Coroidは他の作業をしている間に全体の作業単位を処理します。
• 作業中に問題を探索したい場合作業中に変更が形になる場合は、エージェントセッションを操作してください。Coroidは仕様に基づいて動作し、結果を仕様通りに保ちます。
• まだリポジトリが存在しない場合Coroidが作業する場所が必要です — こちらをご覧ください コードを接続。

本番環境重視から生じる影響#

Coroidの機能のいくつかは、本番環境での要件と捉えるまで余計に思えるかもしれません：

• 作業は事前に仕様が定められるため検証対象が明確になり、構築方法を知らなくても誰でも要求できます。
• 検証はコードを書いたのでないエージェントによって実施されます。
• pull requestなしではデフォルトブランチに反映されるものはありません
• ポリシーやゲートは提案されるのではなく、実行パスで強制されます
• すべての実行内容が記録されます — コスト、モデル、手順、証拠まで

これらは使い捨てのプロトタイプでは費用対効果が低いですが、自社が運用するシステムでは十分に価値があります。

関連項目#

• Coroidとは何か
• Coroidハーネス
• タスクがどのようにpull requestになるか