GitHubは新しい世界には形が合わない

AIエージェント向け：サイトインデックスが/llms.txtで利用可能です。このサイトのドキュメント、ブログ、変更履歴、顧客URLに.mdを付けると、そのマークダウンソースを取得できます。Depotの使用方法と、キャンペーンからどのサインアップがあったかを理解するためにクッキーを使用しています。クッキーを拒否するクッキーを受け入れる⚡️ Depot Metalを発表⚡️ Depot Metalを発表Depotサインイン始めるメニューブログ > パースペクティブGitHubは新しい世界には形が合わないKyle Galbraith著2026年7月29日公開共有Twitterで共有LinkedInで共有Hacker Newsで共有ループにとどまる新しい投稿を公開したときに通知を受け取る。購読するGitHubの全体的なパフォーマンスと信頼性には多くの注目が集まっています。それは当然のことです。しかし、より興味深いのは、GitHubで使用されているパラダイムを問うことだと思います。それは、今日のソフトウェア開発のやり方には形が合わず、新しい需要に応えるためのより良いツール、ワークフロー、インフラストラクチャープリミティブが必要です。ソフトウェアエンジニアリングは変化しましたこの声明は「水は濡れている」と言うようなものです。私たちは今日、ソフトウェア開発のために根本的に異なる世界に生きています。見慣れたものはありますか？間違いなく。過去のものからこの新しい世界で使えるものはありますか？絶対に。コードは結局コードです。メンターが私に説教していたように、バイトイン、バイトアウトです。私たちが過小投資してきたボトルネックは、ソース管理からCI/CD、コードレビュー、さらにはデプロイメントまで、まだ存在しています。今、それらは私たちが得た新しい速度を殺しています。これらのボトルネックの苦痛は、誰もがコードに貢献できるようになったため、増幅されています。コードはエンジニアリングチームの外に広がり、セールス、サポート、マーケティングなどの他のチームにも及んでいます。つまり、10分間のビルドは、ごく一部の人のだけでなく、文字通り会社中の全員が感じています。これは、私たちが当然のこととして受け入れてきた仮定や事柄に疑問を投げかける深遠な影響を与えます。まだ答えられていない疑問を投げかけます。コードの所有者は誰ですか？あるいは、別の言い方をすれば、デプロイされるコードに責任があるのは誰ですか？コードをどのように信頼しますか？この新しいコードのすべてをどのようにレビューしますか？ある場所のコードを別の場所のコードと連携させるにはどうすればよいですか？トークン支出のコストと高品質な機能の出力をどのように比較しますか？これらの5つの質問を5人の異なる人に尋ねると、おそらく5つの異なる答えが得られるでしょう。これが、ソフトウェアエンジニアリングが変わったという意味です。LLMやエージェントが5文のプロンプトから機能全体を生成できるということだけではありません。それは私たちが使っているツールです。それは、ソフトウェアエンジニアリングを取り巻くパラダイム全体が劇的に異なり、私たちが追いつけないほどの速度で動いているということです。私たちが立てた仮定は、リリースごとに崩壊しています。私たちはパラダイムと使用しているツールを再考しなければならないと信じています。私たちは既存のツールと人間中心のパラダイムをこの新しい世界に曲げています。これは間違ったアプローチです。コラボレーション対インフラストラクチャ実際、このブログ記事のタイトルは「GitHub、GitLab、Bitbucket、その他は新しい世界には形が合わない」のようになるべきです。しかし、それは長すぎるので、GitHubと言うときは、それらすべてを読んでください。私はGitHubをコラボレーションツールと考えています。Google Docsは、テクニカルライティングチームとこのブログ記事を共同で執筆できる場所です。GitHubは、Depotを構成するコードについて、他のエンジニアと共同作業できる場所です。私はGitHubと共に育ちました。実際、ソフトウェアエンジニアになったとき、私はGitHubで働きたかったのです。私のすべての筋肉の記憶は、GitHubが私に使うように促したパラダイムに基づいています。ブランチでコードを書く。変更がレビューされる準備ができたらプルリクエストを開く。すべてが機能することを検証するためにCIとチェックがパスするのを待つ。コードレビューコメントとPRでのアイデアのやり取り。すべてがグリーンになり、同僚が承認したら、変更をマージします。このワークフローには派生形があります。このパラダイムの有効性については、大きく異なる意見があります。しかし、どのエンジニアに聞いても、彼らはそれを熟知しています。LLMが登場し始めたとき、既存のパラダイムにそれらを接続するのは自然なことでした。それらはブランチでコードを書いたり、プルリクエストを開いたり、人間（または別のエージェント）からコードレビューを受けたり、PRを使用してコメントを通じて共同作業したり、既存のCIパイプラインを通じてテストを実行したり、最終的にコードをマージしたりできました。それは論理的でした。システムは存在し、当時のエージェントはまだ人間の速度で動いていました。それからすべてが変わりました。最新世代のモデルを搭載したエージェントは信じられないほど優秀になりました。異常に優秀です。私たちは、良いコードを得るためにJengaブロックを元に戻す必要があることが多かったモデルから、十分なコンテキストがあれば一貫して正しいコードを生成するモデルへと移行しました。より良いモデルの正味の結果は何でしょうか？より多くのコード、より多くのブランチ、より多くの並列作業、そして既存のぎこちない人間駆動型パラダイムへのより多くの負担。私たちのコラボレーションパターンとそれを支える基盤となるシステムが、現在主なボトルネックとなっています。すべてのエンジニアリングチームは、GitHub自体、CI、コードレビュー、プルリクエスト、セキュリティスキャン、さらにはデプロイメントにおけるボトルネックを感じています。私たちのツールと構築したいものの間には、インピーダンスミスマッチが生じています。GitHubを中心に構築された既存のコラボレーションパラダイムは、現在、実際にソフトウェアを構築する方法と対立しています。私たちはソフトウェア配信のためのパラダイムを再考しなければなりません。人間中心のコラボレーションのレンズを通してではなく、高スループットのインフラストラクチャープリミティブを通して。高スループットのソフトウェア配信新しいソフトウェア配信パラダイムを構築するには、過去10年間使用してきた人間中心のプロセスから一歩引く必要があります。ソフトウェア配信を、一連の人間のアクションとしてではなく、システムによって駆動される継続的な自動化プロセスとして再考します。その世界を想像し始めると、ソフトウェア配信の問題は、コラボレーションツールというよりもインフラストラクチャのように見え始めます。ここでインフラストラクチャとは、すべてを構築できる少数のプリミティブを意味します。クラウドネイティブ技術を採用した方法からインスピレーションを得ることができます。コンピューティングはVMというプリミティブになりましたストレージはオブジェクトストアになりましたネットワーキングはロードバランサーになりましたソフトウェア配信に必要な基本的なインフラストラクチャープリミティブについて考える必要があります。ソース管理：コードの進化の耐久性があり、不変の履歴実行：ビルド、テスト、変更の検証のための分離された高性能コンピューティング成果物：システム間で移動できる再現可能な出力キャッシュ：決定論的な作業の再利用ID：コードを生成した人物または実体を証明するポリシー：品質、セキュリティ、コンプライアンスのための機械強制ルールこれらは開発者ツールの機能ではありません。それらはインフラストラクチャープリミティブです。個々のサーバーのプロビジョニングについて考えるのをやめ、コンピューティング、ストレージ、ネットワーキングを構成可能なビルディングブロックとして考えるようになったのと同じように、ソフトウェア配信も同様のシフトが必要です。次の10年で勝者となるのは、より良いプルリクエストを構築するのではなく、コード生成、検証、デプロイメントをマシン規模で実行できるようにするインフラストラクチャを構築する企業でしょう。関連投稿エージェントエンジニアリングでCIに求めるものボトルネックはコードの記述から統合へとシフトしましたAI時代にコードベースの制御を維持するKyle GalbraithCEO兼共同創業者Depotプラットフォームエンジニアで遅いビルドを嫌い創業者になった。フランス在住の駐在員🇫🇷目次ループにとどまる新しい投稿を公開したときに通知を受け取る。購読するRSSフィードを取得するビルドがこれほど速くなったことはありません。始める