devlo

devloの中核となる動きは、イシューを完成したプルリクエストに変えることだ。チケットを割り当てると、実装計画をコメントし、コードを書き、テストを含むPRを開く。価値は出発点にある。空のエディタを見つめる代わりに、開発者は実際の成果をレビューして調整する。広範なアーキテクチャ変更よりも、範囲の小さなバグにずっと向いている。チケットは小さく保つこと。大きな書き直しは依然として人間の仕事だ。

すべてのプルリクエストが知的なレビューを受ける。誰かが見ようと思い出したものだけではない。devloは差分を読み、問題を指摘し、その問題のある行にインラインでコメントを残す。汎用のスタイルチェックではなく、AIコードレビュー用に作られている。レビューがボトルネックのチームでは、定型的な問題が人間のファイルを開く前に片付くため、キューが短くなる。待ち時間はない。それだけでリリース週のペースが変わる。

作業を割り当てるのに別のダッシュボードは要らない。GitHubのイシューでdevloにメンションするか、レビューコメントに返信すれば、同じスレッドでタスクを拾う。普通の会話のように読めるので、議論のすべてがチームの追える一つのスレッドに収まる。なぜ重要か。エディタを離れないと使えないツールは、たいてい使われなくなるからだ。これは仕事がすでに起きている場所に現れる。

devloはすでにスタックにあるツールにつながる。コードとイシューはGitHub、チケットはJira、チャットはSlack、加えてブラウザー画面。うたい文句はコンテキストスイッチなし。PMはSlackからタスクを渡せる。エンジニアは同じ成果をGitHubでレビューできる。誰かが新しいタブを開くことなく仕事が進む。単純で、機能する。

既定のアシスタント以外に、特定のワークフロー向けのカスタムエージェントを定義できる。新しいJiraチケットや失敗したGitHubチェックなどのトリガーを設定し、望む結果を定義して、エージェントを走らせる。ワークフローごとに仕立てたAIコーディングエージェントを作っているようなものだ。これは本物の自動化である。devloは誰かがプロンプトを打つのを待たず、イベントに反応する。

ほとんどのチームは、成果のどれだけがAI支援かを言えない。devloはチームの速度を追跡し、AIが牽引した分を切り出すので、管理者は扱える具体的な数字を得られる。自分の貢献を報告するAI開発者アシスタントだと考えればいい。便利である。経営層がこのツールが本当に元を取れるのかと聞いてきたとき、欲しくなる機能だ。

devloはSOC-2 Type-2準拠とデータ保持ゼロを売りにする。つまり処理後にコードを保持しないと主張している。能力の証拠としてSWE-Benchでの順位も挙げる。ホスト型AIツールと自社ホスト型を比べているなら、これらは重要だ。プライベートリポジトリをつなぐ前に、自社の方針と照らして詳細を確認すること。この手順を飛ばさないように。