GitHub 已无法适应 AI 时代
GitHub is the wrong shape for this new world
我们正生活在一个软件开发的根本性变革时代。虽然代码依然是代码，但 LLM 和智能体带来的速度已让传统工作流不堪重负。过去，GitHub 作为协作工具完美契合人类节奏，但在智能体生成代码的当下，分支、Pull Request 和人工审查已成为主要瓶颈。作者 Kyle Galbraith 指出，GitHub 及其同类产品已不再适合这个新世界。我们需要从以人为中心的协作模式，转向以高吞吐量为目标的自动化基础设施原语。未来的赢家不会致力于优化 Pull Request，而是构建能让软件生成、验证和部署在机器规模上运行的基础设施。
未来十年的赢家不会去构建更好的 Pull Request，而是构建能让软件生成、验证和部署在机器规模上运行的基础设施。
HN 评论区
45- gerdesj
“我把 GitHub 看作一个协作工具。”
嗯，没错，但 git 本身才是你称之为 GitHub 及其同类工具的金字塔基石。看来你确实想让 git 看起来像那些你习惯了的、全是围墙花园的东西。
GitHub 拿过 git，基本上又把它变回了 subversion 之类。与其搞那些无政府主义的“没有哪个仓库是老大”的长发嬉皮士胡扯，你更想要中央集权控制 8) 我也想要，但仅限于我的公司内，所以我们用 gitea（还有其他可供 git 控制狂使用的平台）。
为什么不回归基础，从 git 开始呢？就只是 git。加个沟通渠道——可以是电话、短信、邮件、Slack、旗语甚至烟火信号。然后在基础之上添加其他东西，看看会发生什么。
已经有一个相当大的项目就是这样运作的。你可能听说过 Linux。
或者就继续用 GitHub 这种现成的方案（我有些东西也会用），但要接受如果你把选择权拱手让人，就只能得到别人给你的东西这一事实。
- cortesoft
我觉得这篇文章并没有真正回答为什么这种形态是错误的。CI 耗时太长？还有别的吗？
你可以让 CI 不那么密集，这并不需要另一个 GitHub。一个“形态不同”的平台应该具备什么功能？
- mypalmike
这篇文章既没描述问题，也没提出解决方案。不过看到“范式转移”这个词再次出现还挺有意思的，感觉很有 1998 年的味道。
- firasd
标准 GitHub 工作流中的很多编排（创建分支、发送拉取请求、运行集成测试）都是针对多开发人员、多分支协作的团队。如果你只是想在一个全新的项目上利用 AI 快速推进，那么 commit 和 push 就足够了。
所以 git 的一般基础原语——diffs、提交历史、内容哈希寻址——已经相当优化了。如果你想在任何地方（甚至是一个带撤销功能的笔记应用）实现版本控制，你最终还是会重新发明这些相同的概念。
- mitchjj
“下一个十年的赢家不会构建更好的拉取请求。他们将构建基础设施，使软件生成、验证和部署能够以机器规模运行。”
这很有趣，因为所列出的所有原语以及这种规模的可靠构建基础设施，恰恰就是 Buildkite 的形态。