For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/ja/articles/cursor-origin-is-live-what-the.md.
8月17日は、開発者インフラにとって異例に劇的な日となった。GitHubが大規模な世界的障害を起こし、最初の影響記録から復旧まで7時間47分にわたった。
8月17日は、デベロッパーインフラにとって異例なほど劇的な一日だった。
GitHubは、最初の影響記録から最終解決まで7時間47分にわたる大規模なグローバル障害を発生させた。障害の間、開発者たちはGitHub.comの主要サービス、API、プルリクエスト、リポジトリコンテンツ、認証関連システム、そしてGitHub Copilotにわたって問題を目にした。
ほぼ同時に、Cursorは自社のGitホスティングプラットフォームであるOriginの展開を開始していた。
そのタイミングは、ソーシャルメディアにとってあまりにも完璧すぎた。
開発者界隈の一方はGitHubのステータスページを更新していた。もう一方はCursorの新しいCodebaseタブのスクリーンショットを共有し、リポジトリを移行する時が来たと冗談を言い合っていた。
元記事はこの瞬間を、Cursorが「GitHubを一夜で倒した」と表現している。キャッチーな見出しではあるが、文字通りに受け取るべきではない。
Originが障害を引き起こしたわけではないし、アーリーベータのホスティング製品がGitHubの巨大なエコシステムを一日で消し去ったわけでもない。
実際に起きたことはもっと興味深い。Cursorが、主にAIコーディング環境であることから、ソース管理インフラストラクチャ層へと移行したのだ。
Originは現在、リポジトリを自らホストできる。つまり、Cursorは、エージェントがコードを書き、そのコードが最終的に置かれる場所がGitHubのままであるという現状に満足していないということだ。
Cursorは現在、リポジトリ、プルリクエスト、エージェント、そして開発ワークフローが一つのシステム内に存在することを望んでいる。
CursorのSpaceXによる買収は、すでに8月14日に完了していた。その3日後、Originは有料ユーザー向けにアーリーベータへと移行した。
Originは、Cursor内のGitHubリポジトリの単なるキャッシュコピーではない。
Cursorはこれを次のように説明している：
コードを保存・共有するためのgitフォージ
現在のアーリーベータでは、Originは以下を行うことができる：
これだけの機能があれば、Originは単なるプロトタイプではなく、本格的なGitホスティング製品となり得るだろう。
visualization layer.
この製品は依然として明示的にアーリーベータ版と表示されています。Cursorの発表記事によると、基本機能から開始し、後により多くのエージェントネイティブ機能を提供する予定です。
この境界線は、ベータ版をCursorが今年初めに示したより野心的なOriginビジョンと比較する際に重要です。
Cursorの現在のドキュメントでは、Originコードストレージについて次のように記載されています：
| プラン | Originコードストレージ |
|---|---|
| Free | 利用不可 |
| Pro | 利用可能（段階的に展開） |
| Teams | 利用可能（段階的に展開） |
| Enterprise | 管理者が無効化しない限り利用可能（段階的に展開） |
展開が段階的であるため、有料アカウントでもOriginがすぐに表示されない場合があります。Enterprise組織はオプトアウトも可能です。
Originはネームスペース所有者のプライバシーモードを継承します。つまり、チームは機密コードをこのサービスに置く前に、Cursorのプライバシー設定とリポジトリアクセス構成を確認する必要があります。
基本的なセットアップは意図的に馴染みのあるものになっています。
CursorのCodebaseワークスペースにアクセスします：
cursor.com/codebase
以下を選択します：
+ New
リポジトリ名を選択します。
Cursorはその後、Origin CLIのインストール、リポジトリのクローン、または既存のローカルプロジェクトのプッシュに必要なコマンドを表示します。
ユーザーまたはチームが最初のOriginリポジトリを作成するとき、選択したコードベース名がリポジトリURLの一部になります。
URLは次の一般的なパターンに従います：
https://cursor.com/codebase/{owner}/{repo}
例：
https://cursor.com/codebase/acme-corp/example-repo
Cursorの現在のベータ版ドキュメントでは、ベータ期間中はネームスペースを変更できないと警告しています。慎重に選択してください。
最も重要な採用判断の1つは、Originが開発者にGit自体を放棄させる必要がないことです。
リポジトリでは、以下のような使い慣れた操作を使用できます：
git clone
git pull
git push
新しいブランチからプルリクエストを開くには、Cursorのドキュメントでは標準的なフローを提供しています：
git checkout -b my-change
git push -u origin my-change
ブランチがOriginに配置されると、Webインターフェースからプルリクエストを作成できます。
Cursor Cloud Agentsは、Originリポジトリに対してブランチの作成、コミット、プッシュ、プルリクエストの作成も行えます。
これは、Git互換のフォージを、すべてのローカル開発者ツールを一度に置き換えることなく導入できるため重要です。
すべてのOriginリポジトリにはプルリクエストが含まれます。
現在のPRインターフェースには、4つの主要なビューがあります：
レビュアーは差分を確認し、行にコメントを付け、レビューを残し、要求することができます。
レビュー担当者は、レビューとCI要件が満たされた後にマージします。
より大きな製品コンセプトは、開発者が毎回の変更において、以下の間を行き来する必要がないようにすることです：
Cursorエディター
→ Gitホスティングサイト
→ AIアシスタント
→ CIダッシュボード
→ エディターに戻る
Originは、リポジトリの閲覧とPR作業を、エージェントがすでに活動している同じCursor環境にもたらします。
元の記事では、Originの特に大胆な3つの機能を紹介しています：
これらのアイデアは、Cursorのより広いエージェントスケールのビジョンに適合します。
しかし、これらは現在のEarly Betaドキュメントが実際に約束している内容とは区別されるべきです。
Cursorは現在、以下をドキュメント化しています：
リポジトリ
標準的なGit clone/push/pull
GitHubミラーリング
コードブラウジング/検索
プルリクエスト
レビュー/コメント
チェック
手動マージ
競合の表示
権限
アプリ
自動化
クラウドエージェント
Origin CLI
現在のファーストパーティのOriginドキュメントでは、以下は一般提供としてリストされていません：
ネイティブなスタックPRワークフロー
Originマージキュー
AIによる自動マージ競合解決
Origin固有の構造化レビュー状態API
MCPサーバーとしてのOrigin
Cursorの発表文では、追加のエージェントネイティブ機能は後日提供されると明示されています。
したがって、これらは初期のデモコンセプト、ロードマップの方向性、またはより明確なリリースドキュメントを待っている機能として扱うべきであり、有料のOriginユーザー全員が今日頼りにできる機能ではありません。
比較にはGitHub側の修正も必要です。
GitHubは単一の巨大な人間が読むためのPRリストに限定されていません。
GitHubは現在、以下をドキュメント化しています：
merge_groupワークフローイベントこれにより、GitHubがCursorが追求しているのと同じ製品意味で「エージェントネイティブ」になるわけではありません。
しかし、技術的な違いが以下のようになるわけではないことを意味します：
GitHubにはこれらのプリミティブが全くない
vs.
Originにはすべてがある
より信頼できる違いは製品哲学です。
Cursorは、リポジトリインフラストラクチャを、コーディングエージェントの群れがすでに第一級のアクターとして活動している環境に直接埋め込むことを望んでいます。
Originの最も実用的な移行機能は、劇的な置き換えスイッチではありません。ミラーリングです。
チームは接続できます
以下の内容を日本語に翻訳します：
GitHubからCursorへ、組織とリポジトリを選択し、Originミラーを作成します。
現在文書化されている同期内容は次のとおりです：
| Originに同期 | ミラーの一部として移行されないもの |
|---|---|
| Git履歴 | GitHub Issues |
| ブランチ | GitHub Actionsワークフロー設定 |
| タグ | GitHub Actionsシークレット |
| 閲覧・検索可能なコード | その他のGitHub固有のプラットフォーム設定 |
| プルリクエスト（双方向） | — |
| 継続的なリポジトリ更新 | — |
ミラーされたリポジトリでは、GitHubが当初は**情報の唯一の源泉（source of truth）**であり続けます。
Originリモートを通じたプッシュは引き続きGitHubに送信されます。プルリクエストはOriginからレビューでき、アクティビティはGitHubに同期されます。
これにより、チームは初日からリポジトリの権限を放棄する必要がないため、Originはテストしやすくなります。
Cursorの発表記事によると、ミラーされたリポジトリのプルリクエストは双方向に同期されます。
意図された動作は次のとおりです：
Cursorでコメント
→ GitHubに表示
GitHubで返信またはリアクション
→ Cursorに表示
GitHubでレビューが割り当てられる
→ Cursorから対応可能
Cursorは、これらの更新が数秒以内に反映されると述べています。
これにより、開発者は既存のGitHubコラボレーターが引き続きGitHubを使用しながら、Originのエクスペリエンスを評価できます。
これは、重要なモノレポを即座に新しいベータホストへ移行するよりも、現実的な移行戦略と言えるでしょう。
最も強力な移行ステップは**GitHubからの切り離し（Detach from GitHub）**です。
ミラーされたリポジトリが最初に作成されたとき、関係は次のとおりです：
GitHub
= 情報の唯一の源泉
Origin
= 同期されたミラー
Cursorのリポジトリ設定には、Danger Zoneアクションが含まれています：
Detach from GitHub
切り離し後：
Origin
= 独立したホスト型リポジトリ
= 情報の唯一の源泉
Originリモートへのプッシュは、GitHubには送信されなくなります。
元のGitHubリポジトリは、切り離し操作によって削除または変更されることはありません。
この区別は重要です。
切り離しは同期動作を変更するだけで、GitHub側のコピーを消去するわけではありません。
コードベースには複数のクローンやミラーが存在し得ますが、開発プロセスでは通常、権威あるリポジトリが1つ必要です。
その権威が以下のような問いを決定します：
mainか？ミラーされたOriginリポジトリでは、その権威はGitHubから始まります。
切り離し後、CursorはOriginホスト型リポジトリの情報の唯一の源泉としてOriginを文書化しています。
これが、Originが補助的インターフェースではなくなり、そのプロジェクトの主要なGitホストになるポイントです。
Cursorはまた
OriginをデプロイメントおよびCIエコシステムに接続し始めました。
現在の公式インテグレーションは以下のとおりです。
リポジトリのAppsタブからVercelを接続します。
Cursorによると、各プルリクエストはプレビューデプロイメントを受け取ることができ、チームはマージ前にテストやコメントを行うことができます。
DepotはOriginリポジトリのCIを実行でき、既存のGitHub Actionsワークフローを再利用できます。
Buildkiteは、ネイティブのパイプラインシステムに加えて、既存のGitHub Actionsワークフローも実行できます。
これは、最も困難な移行コストの1つを削減するのに役立ちます。
リポジトリのストレージが移動しても、チームは同時にCI/CDスタック全体を書き直したいとは考えていません。
重要なニュアンスがあります。
CursorのGitHubミラーリングドキュメントによると、GitHub Actionsのワークフローとシークレットは、GitHubプラットフォーム設定としてOriginにミラーリングされるわけではありません。
ただし、DepotやBuildkiteなどのサードパーティのOriginインテグレーションは、既存のGitHub Actionsワークフロー定義を実行できます。
これらの記述は共存できます：
GitHub Actionsプラットフォームの状態
→ リポジトリミラーリングでは移行されない
リポジトリ内のワークフローファイル
→ 対応するCIインテグレーションで解釈可能
チームは、本番リポジトリを切り離す前に、シークレット、権限、イベントトリガー、キャッシュ、デプロイメント認証情報、ブランチ保護をテストする必要があります。
Originに関するより大きな戦略的論点は、エージェント統合です。
CursorのCloud Agentsは、完全な開発環境を備えた分離されたクラウド仮想マシン上で実行されます。
それらは以下のことができます：
Originを使用すると、これらのエージェントは同じプラットフォームでホストされているリポジトリに対して直接作業できます。
ループは次のようになります：
目標
→ Cursorエージェント
→ Originリポジトリ
→ ブランチ
→ コード変更
→ テスト
→ プルリクエスト
→ レビュー
→ マージ
リポジトリは、エージェントワークフローの中心にある外部サービスである必要がなくなります。
OriginはCursor Automationsとも統合されています。
現在のドキュメントには、次のようなリポジトリイベントがリストされています：
自動化により、これらのイベントのいずれかに応じてクラウドエージェントを起動できます。
例えば：
新しいPRがオープン
→ セキュリティレビューエージェントを実行
mainへのプッシュ
→ 変更を要約
PRが更新
→ 新しいコミットを検査
これは、現在すでに文書化されている「エージェントネイティブ」ストーリーの具体的な一部です。
Cursorの8月19日のエージェントアップデートでは、Cloud Agentsがイベントを購読し、CI修正やボットフィードバックなどの作業を目標が達成されるまで継続して進めることができるようになっています。
アイデアを一文で入力するだけで、We0 AI が紹介サイト、ページ、CMS を生成し、公開後の顧客獲得と流入拡大を支援します。
無料登録で完全なプロジェクトを 1 つ生成
1 つの完全な生成フローを試し、最初のプロジェクトのドラフトをすぐに確認するのに最適です。
ソース記事では、Originが「MCPをネイティブにサポート」しており、エージェントがAPIと同じくらい簡単にフォージを操作できると述べています。
製品全体としてのCursorは、エージェントを外部ツールやデータに接続するためにMCPを確実にサポートしています。
ただし、Origin自体を公開する現在のOriginドキュメントページは見つかりませんでした。
（源内容较长，以下为完整翻译）
仓库操作**的 MCP 服务器。
当前的 Origin 集成文档强调：
Origin CLI
Cloud Agents
Automations
Third-party apps
因此，稳妥的说法是：
Cursor 的代理生态系统支持 MCP，而 Origin 当前的 Early Beta 文档尚未明确宣传专用的 Origin MCP 接口。
随着 Cursor 推出其承诺的更多代理原生功能，这一情况可能会发生变化。
Cursor 早期的 Origin 演示强调了对于人类开发团队而言显得过高的吞吐量数字。
报告的演示数据包括：
| 指标 | Cursor 演示声明 |
|---|---|
| 仓库克隆 | 约 296,000 次/小时 |
| 推送 | 约 81,000 次/小时 |
| 单个仓库中的提交 | 22.6 次/秒 |
| 全局同步 | <400 毫秒 |
| 自动故障转移 | <10 毫秒 |
源文章用这些数字提出了一个简单观点：
人类开发人员不需要每秒提交几十次。代理集群可能需要。
这些数字仍应视为供应商演示声明。
Cursor 当前的 Origin 文档并未发布这些数字的完整基准测试方法、生产 SLA、工作负载分布、百分位延迟表或独立验证。
生产团队应先测试自己的工作负载，再将阶段演示的吞吐量视为有保障的服务容量。
代理规模 Git 基础设施的论证并非纯粹假设。
Cursor 在 2 月表示，内部合并的拉取请求中超过 30% 是由在云端沙盒中自主运行的代理创建的。
到 6 月，Cursor 自己的工程文章表示：
我们超过 40% 的 PR 来自云端代理
源文章引用了 35%–40% 的中间数值。
随着代理采用率的提高，确切比例随时间发生了变化。
更重要的趋势是明确的：
2026 年 2 月：
>30%
2026 年 6 月：
>40%
Cursor 的内部软件开发工作流已经产生了足够多的代理编写 PR，使仓库协调成为严重的基础设施问题。
传统仓库工作流假设人类节奏。
开发人员可能会：
代理集群可以以不同方式运作。
十个或一百个代理可以同时：
瓶颈发生了转移。
编写代码初稿可能变得廉价。
协调、验证、审查以及安全合并大量同步变更变得更加困难。
这就是 Origin 瞄准的基础设施问题。
源文章对比了“2008 年 GitHub 工作流”与代理原生的 Origin。
历史框架是有用的，但当前的产品对比更为细致。
GitHub 一直在持续添加
自動化のプリミティブには以下が含まれます：
つまり、問題はGitHubが開発を自動化できるかどうかではありません。
明らかにそれは可能です。
戦略的な問題は、リポジトリと人間のコラボレーションを中心に設計されたプラットフォームが、現在の主要な製品アイデンティティがソフトウェア作業を行うAIエージェントであるプラットフォームと同じくらい迅速に適応できるかどうかです。
Originは、その答えに新しいフォージの余地が残されているというCursorの賭けです。
GitHubの8月17日の障害は現実的で深刻なものでした。
公式のインシデントは次の期間に及びました：
13:28 UTC
から
21:15 UTC
合計で：
7時間47分
この間、ステータス更新ではウェブ/APIトラフィックおよびリポジトリコンテンツへのアクセスでかなりのエラー率が報告され、Copilotも劣化していました。
ローンチの偶然の一致が、抗いがたい物語を生み出しました：
GitHubがダウン
+
CursorがGitホスティングをローンチ
=
CursorがGitHubを置き換える
しかし、運用面ではそうではありませんでした。
実際、Origin自身のGitHubミラーリングパスは、GitHubがソース・オブ・トゥルースであり続ける限り、依然としてGitHubに依存しています。
そして、Cursorのより広範なエージェントも外部のソースコントロールプロバイダーに依存することがあります。
したがって、GitHubの障害は、すべてのCursorワークフローが影響を受けずに継続することを自動的に実証するものではありません。
本当の教訓は集中リスクについてです：あるソースコントロールプラットフォームが開発に深く組み込まれている場合、長時間の障害はリポジトリの閲覧以上のものに影響を及ぼします。
元の記事では、Originのストーリーの隣にMicrosoftの株価スクリーンショットも掲載されており、当日の株価が約3.2%下落したことを示しています。
これは目を引く対比です。
しかし、これだけで次のように結論づけるには不十分です：
Originがローンチ
→ Microsoftが1000億ドル以上を失った
大型株のテクノロジー株は多くの理由で動きます。
原因を特定する証拠がなければ、株価の動きはOriginへの直接的な反応ではなく、当日の市場状況として扱うべきです。
したがって、この記事はMicrosoftの時価総額の変化をCursorのローンチに帰属させるものではありません。
ほとんどのチームにとって、答えは次のとおりです：
一度にすべてではありません。
Originはまだアーリーベータです。
より安全な道は、段階的に評価することです。
以下を選択してください：
本番プラットフォーム全体をデプロイするリポジトリから始めないでください。
GitHubをソース・オブ・トゥルースとして維持します。
以下を評価してください：
これにより、ロールバックパスが得られます。
両側でコメントとレビューを作成します。
以下を確認してください：
Vercel、Depot、
またはBuildkiteを使用している場合は、それらを接続して以下を確認します：
GitHub Actionsのプラットフォーム状態が自動的に移行されるとは想定しないでください。
ミラーリングされたリポジトリ上でCloud Agentsを実行します。
測定する項目：
チェック項目：
リポジトリホストは、セキュリティ境界の一部になります。
以下を使用します：
設定
→ 一般
→ デンジャーゾーン
→ GitHubから分離
チームが意図的にOriginを権威あるものとすることを決定した場合のみ実行してください。
分離後、OriginへのプッシュはGitHubに反映されなくなります。
チームがすでにCursorを頻繁に使用している場合、Originは特に魅力的です。
適したチームの例：
Cursorがすでにエンジニアリングワークフローの中心にある場合、統合の利点は最も大きくなります。
GitHubは、以下に依存するチームにとって、より保守的な選択肢であり続けます：
OriginのEarly Betaドキュメント自体も、GitHub固有のプラットフォーム機能の一部がリポジトリミラーリングでは移行されないことを認めています。
コードホストは単なるGitオブジェクトストレージではありません。それはエコシステムです。
現時点で最も正確な説明は次のとおりです：
Originは本物のGitホスト
+
GitHubミラー
+
PR/レビューサーフェス
+
エージェント統合リポジトリレイヤー
しかし、まだ以下ではありません：
すべてのGitHub機能のドロップイン代替品
この違いは移行計画にとって重要です。
チームはすでにコードを完全にOriginでホストできます。
しかし、それはGitHub Issues、Actions設定、シークレット、マーケットプレイスアプリ、ポリシー、パブリックコミュニティワークフロー、エンタープライズプロセスがすべて自動的に移行されることを意味するものではありません。
ソース記事の最終的な主張は、その見出しよりも強いものです。
Cursorは単にリポジトリストレージについてGitHubと競争しているわけではありません。
ソフトウェア開発の成果が権威を持つ場所を競っているのです。
従来のスタックでは：
開発者
→ IDE
→ GitHub
→ CI
→ デプロイ
Cursorの新しいスタックでは：
人間の目標
→ Cursorエージェント
→ Origin
→ PR
→ 自動チェック
→ デプロイメント統合
もし
エージェントが変更の主要な生産者となる時代において、それらのエージェントを調整するリポジトリプラットフォームは、エディタと同様に戦略的に重要になる可能性がある。
だからこそ、**GitHubからのデタッチ（切り離し）**は、ローンチ当日のジョーク以上に重要なのだ。
ミラーは便利だ。
しかし、新たな真実の源（ソース・オブ・トゥルース）を持つことは、プラットフォームの転換を意味する。
OriginはCursorのGitホスティングおよびコード共有プラットフォームです。初期ベータ版では、リポジトリのホスティング、標準的なGitのclone/push/pull、GitHubリポジトリのミラーリング、コードの閲覧・検索、プルリクエストの作成・マージ、Cursorエージェントおよび選択したサードパーティアプリの接続が可能です。
いいえ。Cursorの現在のドキュメントによると、OriginのコードストレージはPro、Teams、Enterpriseプランで利用可能で、無料プランでは利用できません。ロールアウトは段階的に行われるため、対象ユーザーでもアクセスが遅れる場合があります。
Originは、リポジトリをGitHubからデタッチした後、そのリポジトリの真実の源（ソース・オブ・トゥルース）になることができますが、現在のところGitHubプラットフォーム全体を機能ごとに完全に置き換えるものではありません。GitHub Issues、GitHub Actionsのプラットフォーム設定、シークレット、多くのエコシステム統合は自動的には移行されません。
はい。OriginはGitHubリポジトリをミラーリングでき、Git履歴、ブランチ、タグ、閲覧可能なコード、双方向に同期されるプルリクエストを含みます。リポジトリがミラーリングされている間、GitHubは真実の源であり続け、Originを通じたプッシュはGitHubに反映されます。
GitHubの同期を停止し、OriginのミラーをスタンドアロンのOriginホスト型リポジトリに変換します。Originが真実の源となり、以後OriginリモートへのプッシュはGitHubに反映されなくなります。既存のGitHubリポジトリはそのまま残ります。
Cursorの現在の初期ベータ版ドキュメントでは、ネイティブなスタックPRワークフローやOriginマージキューは一般提供機能として記載されていません。ローンチでは、追加のエージェントネイティブ機能が近日中に提供されると述べられています。したがって、以前のデモやロードマップでの主張は、現在文書化されているベータ版と混同すべきではありません。
現在のOriginのプルリクエストドキュメントによると、Originはマージコンフリクトを表示し、ユーザーがマージ前に解決できるようにします。CursorのCompileデモに関する以前の公開情報では、AIによるコンフリクト解決のアイデアが説明されていましたが、これは初期ベータ版の文書化された保証として扱うべきではありません。
その証拠はありません。Cursorは8月17日にOriginのロールアウトを開始しましたが、その日はGitHubが大規模な障害に見舞われた日であり、非常に目立つ偶然の一致が生じました。Originはそれ以前にすでに発表・デモが行われていたため、障害が製品を一夜にして生み出したわけではありません。
Cloud Agents](https://cursor.com/docs/cloud-agent): Originリポジトリに対して直接作業できるクラウドホスト型コーディングエージェント。
Cursor Originは、もはやCursor内の単なるGitHubブラウザではなく、本格的なGitホスティングプラットフォームとなった。アーリーベータでは、リポジトリのホスティング、標準Gitの使用、GitHubのミラーリング、双方向のプルリクエスト同期、コードブラウズ、レビュー管理、CI/デプロイアプリの接続、そしてCursorエージェントがOriginホスト型リポジトリに対して作業を行うことが可能である。
元の記事では、いくつかのエージェントネイティブ機能がすでに展開されているかのように誇張されている。現在の公式ドキュメントでは、ネイティブのスタックPR、Originのマージキュー、自動AIコンフリクト解決、またはOrigin MCPサーバーは、一般提供されているアーリーベータ機能としてはまだ記載されていない。Cursor自身も、さらなるエージェントネイティブ機能が今後追加されると述べている。
GitHubの8月17日の障害により、Originは異例なほどの劇的なローンチの瞬間を迎えたが、それはGitHubが一夜にして置き換えられたことを意味するものではない。ほとんどのチームにとって賢明な道は、まず重要ではないリポジトリをミラーリングし、同期とCIをテストし、Originが安全にソース・オブ・トゥルースとなり得ることが証明された後にのみデタッチすることである。
本当の競争上の変化は、Cursorが「GitHubを殺した」ことではなく、Cursorが現在、開発ワークフローの全体を所有しようとしていることにある。
AIエージェントがソフトウェアを作成、レビュー、そして出荷するリポジトリレイヤー。
ひとことから始めて、数分で完全なサイトを手に入れましょう。
