ソリューション · Engineering

キューの上位に届かない作業。

各セッションには専用のクラウドコンピューターとブランチが割り当てられます。エージェントはバグを再現し、修正を書き、テストを実行し、変更リクエストを作成します。あなたは差分をレビューします。

kortix/session-9f4c2b7e · retry backoff jitter2ファイル · +7 −1 · 214テスト成功

 packages/queue/src/retry.ts−const delay = base * 2 ** attempt;+// Full jitter. Without it every worker wakes on the same tick and the+// retry storm is indistinguishable from the outage that caused it.+const delay = Math.random() * base * 2 ** attempt;   packages/queue/src/retry.test.ts+test("spreads retries across the window", () => {+  const spread = sample(1_000).stddev / EXPECTED_MEAN;+  expect(spread).toBeGreaterThan(0.4);+});

イラスト。ブランチ名はセッションIDです。セッションブランチとはそういうものだからです。

引き継ぎ

取り組むつもりだと、もう言い訳できなくなったバックログ。

大規模な書き換えではありません。その下にある小さく明確な作業です。再現、依存関係の更新、不安定なテスト、200ファイルにまたがる名前変更。

01
誰も再現できなかったバグ
報告を受け取り、自分のマシンで状況を構築し、失敗するテストか、再現できなかった理由を返します。再現できないセッションはそう伝えます。見ていないバグの修正をでっち上げることはありません。
02
全員が繰り返し実行する不安定なテスト
スイートをループ実行し、実際に失敗するテストと頻度を特定し、その背後にある共有状態やタイミング依存を見つけます。変更リクエストには、変更前後で測定した失敗率が含まれます。
03
ビルドで検証済みの依存関係更新
アップグレード、ビルド、スイート実行、破壊的変更の注記をチェンジログで確認、移動した呼び出し箇所を修正。スイートが失敗しても、失敗内容を説明に記載した変更リクエストを作成し、成功したかのようには主張しません。
04
200ファイルにまたがる機械的な移行
名前の変更、APIの移行、lintルールの有効化。1ファイルなら簡単でも、大規模になると耐え難い変更です。専用ブランチでファイルごとに処理し、レビュー可能な1つの差分として反映します。
05
昨夜の例外をグループ化
その日に発生したエラーを読み取り、メッセージではなく根本原因で分類し、影響を受けた人数で優先順位を付け、最上位の問題をパッチまで仕上げます。
06
コードと乖離したドキュメント
文書化された動作と実際の動作を比較し、コードに合わせて文書を修正するか、誤っているのはコードだと指摘します。ここではどちらも同じ種類のコミットです。すべてがファイルだからです。

成果物

スイート実行済みのブランチ上の差分。

返ってくるのは、作成したマシンですでにテストを実行済みのブランチ上の差分です。新たに読み方を学ぶ必要はありません。

kortix/session-9f4c2b7e · retry backoff jitterChange request

 packages/queue/src/retry.ts
-const delay = base * 2 ** attempt;
+// Full jitter. Without it every worker wakes on the same tick and the
+// retry storm is indistinguishable from the outage that caused it.
+const delay = Math.random() * base * 2 ** attempt;
 
 packages/queue/src/retry.test.ts
+test("spreads retries across the window", () => {
+  const spread = sample(1_000).stddev / EXPECTED_MEAN;
+  expect(spread).toBeGreaterThan(0.4);
+});

2ファイル · +7 −1 · 214テスト成功

イラスト。ブランチ名はセッションIDです。セッションブランチとはそういうものだからです。

報告書ではなく変更をレビュー

エージェントはセッションブランチにコミットし、mainに対する変更リクエストを作成します。レビューに届くのは説明付きの差分。人の同僚が作成するものと同じです。

読む前に実行済み

サンドボックスは実際のLinuxマシンなので、エージェント自身がインストール、ビルド、スイート実行を行います。失敗した変更リクエストは、成功したかのように装わず、説明に失敗内容を記載します。

1ブランチ、1マシン、衝突なし

セッション間で作業ツリーを共有することはありません。20個のセッションを同じリポジトリに対して同時実行しても、それぞれ専用のブランチとコンピューターで動くため、互いに干渉しません。

接続先

リポジトリ、トラッカー、スレッド。

作業の大半は、セッションがクローンしたリポジトリ内で行われます。残りはコネクターが担い、資格情報はマシン内に入らず、こちら側に保持されます。

リポジトリそのもの: セッション開始時にサンドボックスへ新しいブランチとしてクローンされます。エージェントにはシェル、ファイルシステム、完全な履歴があり、bisectやスイートの実行、変更対象の行を導入したコミットの確認ができます。
GitHub: 許可された範囲で、イシュー、コメント、ブランチの状態を読み取り、書き戻します。Kortixが変更リクエスト自体を作成し、コネクターはその周辺の処理を担います。
Linear: セッションの起点となったチケットを取得し、受け入れ条件を読み取り、作業が反映されたら変更リクエストのリンクを投稿します。スコープの正式な情報源はチケットです。
Slack: ライブチャネル。スレッドでボットにメンションすると、そのスレッドがセッションになります。回答と生成されたファイルは同じスレッドに戻ります。Teamsは搭載されていますが、デプロイで有効にするまでオフになっています。
自社サービス: OpenAPIまたはPostmanの仕様、GraphQLエンドポイント、リモートMCPサーバー、またはベアHTTPベースURLをKortixに指定します。ソースを読み取り、認証方法を判断し、各操作をエージェントが呼び出せるツールに変換します。

Easy connectは各サービスのOAuth画面を通じて3,000以上のアプリに対応します。カタログにないものもMCP、OpenAPI、GraphQL、raw HTTP経由で接続できます。内部サービスには通常こちらが正直な方法です。そもそも公開カタログの項目がないからです。

実行方法

今すぐ依頼し、重要なものを見守り、残りは任せる。

同じセッションを開始する3つの方法。トリガーが変わっても、分離とレビューの流れは変わりません。

01オンデマンド
今いるスレッドから
Slackスレッドでバグを説明するか、WebアプリまたはCLIからセッションを開始します。ボットの投稿ではなく、自分のメッセージにリアクションが付き、返信は同じスレッドに届きます。
02人の確認を伴う実行
指定した場所で停止
アクションをAskに設定すると、呼び出し時に実行が一時停止し、アクションと引数が表示されます。承認すると同じ呼び出しが完了し、停止した地点からセッションが再開します。
03自動化
cron、または自分のアラートからの署名付きwebhook
06:00に夜間の例外をトリアージします。あるいはアラートを署名付きwebhookにつなぎ、インシデントのペイロードをプロンプトに含めたセッションをページングイベントから開始できます。

Control

自動でマージされることはありません。

問題はエージェントが何を書けるかではなく、何を反映できるかです。正確な答えを示します。

マージはデフォルト拒否: エージェントはmainへマージできません。権限自体は存在し、管理者はproject.cr.mergeを付与できますが、その許可はkortix.yamlに記載されるため、拡大すること自体がレビュー対象の変更になります。隠れたデフォルト設定はありません。
設定するまで承認ゲートは無効です: 製品出荷時のデフォルトは許可優先です。指定しない限りアクションは実行されます。一時停止するアクションにはAsk、決して実行させないアクションにはBlockを、アクションごとまたは1つのパターンルールで設定できます。より安全だと思い込ませるのではなく、デフォルトを明示します。
各セッションは相互に隔離: セッションごとに、専用ブランチ上の使い捨てLinuxマシンを1台用意します。本当に共有されるのは外の世界だけです。だからこそ、アクセス範囲を決めるのはマシンではなくコネクターです。
コネクタの認証情報がマシンに入ることはありません: サンドボックスにはプロジェクト単位のKortixトークンが1つだけあり、サードパーティのキーはありません。ゲートウェイが実際の資格情報をサーバー側で復号し、送信呼び出しに付加します。意図的に付与したランタイムシークレットは別物です。それはエージェントが読み取れる実際の環境値であり、そのために付与するものです。
すべてのツール呼び出しを記録: 資格情報を解決するゲートウェイが、記録も作成します。アクション、エージェント、セッションの起点となった人またはトリガー、結果、保留中の呼び出しを解除した人が記録されます。

分離の仕組みコネクタの仲介方法

同じプラットフォーム、他のチーム

1つのプロジェクト、1セットのコネクタ、積み重なる1つのメモリ。各チームが自分の仕事に必要なスキルを書き、別のシステムを立ち上げる必要はありません。

すべてのソリューション →

自分で所有する1つのrepoから、会社全体を動かす。

1つの仕事から始め、そこから成長させる。

始める

ソリューション · Engineering

キューの上位に届かない作業。

始めるお問い合わせ

kortix/session-9f4c2b7e · retry backoff jitter2ファイル · +7 −1 · 214テスト成功

 packages/queue/src/retry.ts−const delay = base * 2 ** attempt;+// Full jitter. Without it every worker wakes on the same tick and the+// retry storm is indistinguishable from the outage that caused it.+const delay = Math.random() * base * 2 ** attempt;   packages/queue/src/retry.test.ts+test("spreads retries across the window", () => {+  const spread = sample(1_000).stddev / EXPECTED_MEAN;+  expect(spread).toBeGreaterThan(0.4);+});

イラスト。ブランチ名はセッションIDです。セッションブランチとはそういうものだからです。

引き継ぎ

取り組むつもりだと、もう言い訳できなくなったバックログ。

01
誰も再現できなかったバグ
報告を受け取り、自分のマシンで状況を構築し、失敗するテストか、再現できなかった理由を返します。再現できないセッションはそう伝えます。見ていないバグの修正をでっち上げることはありません。
02
全員が繰り返し実行する不安定なテスト
スイートをループ実行し、実際に失敗するテストと頻度を特定し、その背後にある共有状態やタイミング依存を見つけます。変更リクエストには、変更前後で測定した失敗率が含まれます。
03
ビルドで検証済みの依存関係更新
アップグレード、ビルド、スイート実行、破壊的変更の注記をチェンジログで確認、移動した呼び出し箇所を修正。スイートが失敗しても、失敗内容を説明に記載した変更リクエストを作成し、成功したかのようには主張しません。
04
200ファイルにまたがる機械的な移行
名前の変更、APIの移行、lintルールの有効化。1ファイルなら簡単でも、大規模になると耐え難い変更です。専用ブランチでファイルごとに処理し、レビュー可能な1つの差分として反映します。
05
昨夜の例外をグループ化
その日に発生したエラーを読み取り、メッセージではなく根本原因で分類し、影響を受けた人数で優先順位を付け、最上位の問題をパッチまで仕上げます。
06
コードと乖離したドキュメント
文書化された動作と実際の動作を比較し、コードに合わせて文書を修正するか、誤っているのはコードだと指摘します。ここではどちらも同じ種類のコミットです。すべてがファイルだからです。

成果物

スイート実行済みのブランチ上の差分。

返ってくるのは、作成したマシンですでにテストを実行済みのブランチ上の差分です。新たに読み方を学ぶ必要はありません。

kortix/session-9f4c2b7e · retry backoff jitterChange request

 packages/queue/src/retry.ts
-const delay = base * 2 ** attempt;
+// Full jitter. Without it every worker wakes on the same tick and the
+// retry storm is indistinguishable from the outage that caused it.
+const delay = Math.random() * base * 2 ** attempt;
 
 packages/queue/src/retry.test.ts
+test("spreads retries across the window", () => {
+  const spread = sample(1_000).stddev / EXPECTED_MEAN;
+  expect(spread).toBeGreaterThan(0.4);
+});

2ファイル · +7 −1 · 214テスト成功

イラスト。ブランチ名はセッションIDです。セッションブランチとはそういうものだからです。

報告書ではなく変更をレビュー

読む前に実行済み

1ブランチ、1マシン、衝突なし

接続先

リポジトリ、トラッカー、スレッド。

リポジトリそのもの: セッション開始時にサンドボックスへ新しいブランチとしてクローンされます。エージェントにはシェル、ファイルシステム、完全な履歴があり、bisectやスイートの実行、変更対象の行を導入したコミットの確認ができます。
GitHub: 許可された範囲で、イシュー、コメント、ブランチの状態を読み取り、書き戻します。Kortixが変更リクエスト自体を作成し、コネクターはその周辺の処理を担います。
Linear: セッションの起点となったチケットを取得し、受け入れ条件を読み取り、作業が反映されたら変更リクエストのリンクを投稿します。スコープの正式な情報源はチケットです。
Slack: ライブチャネル。スレッドでボットにメンションすると、そのスレッドがセッションになります。回答と生成されたファイルは同じスレッドに戻ります。Teamsは搭載されていますが、デプロイで有効にするまでオフになっています。
自社サービス: OpenAPIまたはPostmanの仕様、GraphQLエンドポイント、リモートMCPサーバー、またはベアHTTPベースURLをKortixに指定します。ソースを読み取り、認証方法を判断し、各操作をエージェントが呼び出せるツールに変換します。

実行方法

今すぐ依頼し、重要なものを見守り、残りは任せる。

同じセッションを開始する3つの方法。トリガーが変わっても、分離とレビューの流れは変わりません。

01オンデマンド
今いるスレッドから
Slackスレッドでバグを説明するか、WebアプリまたはCLIからセッションを開始します。ボットの投稿ではなく、自分のメッセージにリアクションが付き、返信は同じスレッドに届きます。
02人の確認を伴う実行
指定した場所で停止
アクションをAskに設定すると、呼び出し時に実行が一時停止し、アクションと引数が表示されます。承認すると同じ呼び出しが完了し、停止した地点からセッションが再開します。
03自動化
cron、または自分のアラートからの署名付きwebhook
06:00に夜間の例外をトリアージします。あるいはアラートを署名付きwebhookにつなぎ、インシデントのペイロードをプロンプトに含めたセッションをページングイベントから開始できます。

Control

自動でマージされることはありません。

問題はエージェントが何を書けるかではなく、何を反映できるかです。正確な答えを示します。

マージはデフォルト拒否: エージェントはmainへマージできません。権限自体は存在し、管理者はproject.cr.mergeを付与できますが、その許可はkortix.yamlに記載されるため、拡大すること自体がレビュー対象の変更になります。隠れたデフォルト設定はありません。
設定するまで承認ゲートは無効です: 製品出荷時のデフォルトは許可優先です。指定しない限りアクションは実行されます。一時停止するアクションにはAsk、決して実行させないアクションにはBlockを、アクションごとまたは1つのパターンルールで設定できます。より安全だと思い込ませるのではなく、デフォルトを明示します。
各セッションは相互に隔離: セッションごとに、専用ブランチ上の使い捨てLinuxマシンを1台用意します。本当に共有されるのは外の世界だけです。だからこそ、アクセス範囲を決めるのはマシンではなくコネクターです。
コネクタの認証情報がマシンに入ることはありません: サンドボックスにはプロジェクト単位のKortixトークンが1つだけあり、サードパーティのキーはありません。ゲートウェイが実際の資格情報をサーバー側で復号し、送信呼び出しに付加します。意図的に付与したランタイムシークレットは別物です。それはエージェントが読み取れる実際の環境値であり、そのために付与するものです。
すべてのツール呼び出しを記録: 資格情報を解決するゲートウェイが、記録も作成します。アクション、エージェント、セッションの起点となった人またはトリガー、結果、保留中の呼び出しを解除した人が記録されます。

分離の仕組みコネクタの仲介方法

同じプラットフォーム、他のチーム

すべてのソリューション →

自分で所有する1つのrepoから、会社全体を動かす。

1つの仕事から始め、そこから成長させる。

始める

キューの上位に届かない作業。

取り組むつもりだと、もう言い訳できなくなったバックログ。

誰も再現できなかったバグ

全員が繰り返し実行する不安定なテスト

ビルドで検証済みの依存関係更新

200ファイルにまたがる機械的な移行

昨夜の例外をグループ化

コードと乖離したドキュメント

スイート実行済みのブランチ上の差分。

報告書ではなく変更をレビュー

読む前に実行済み

1ブランチ、1マシン、衝突なし

リポジトリ、トラッカー、スレッド。

今すぐ依頼し、重要なものを見守り、残りは任せる。

今いるスレッドから

指定した場所で停止

cron、または自分のアラートからの署名付きwebhook

自動でマージされることはありません。

同じプラットフォーム、他のチーム

自分で所有する1つのrepoから、会社全体を動かす。

キューの上位に届かない作業。

取り組むつもりだと、もう言い訳できなくなったバックログ。

誰も再現できなかったバグ

全員が繰り返し実行する不安定なテスト

ビルドで検証済みの依存関係更新

200ファイルにまたがる機械的な移行

昨夜の例外をグループ化

コードと乖離したドキュメント

スイート実行済みのブランチ上の差分。

報告書ではなく変更をレビュー

読む前に実行済み

1ブランチ、1マシン、衝突なし

リポジトリ、トラッカー、スレッド。

今すぐ依頼し、重要なものを見守り、残りは任せる。

今いるスレッドから

指定した場所で停止

cron、または自分のアラートからの署名付きwebhook

自動でマージされることはありません。

同じプラットフォーム、他のチーム

自分で所有する1つのrepoから、会社全体を動かす。