GitHub 已不适配新时代的形态

# GitHub 已不再适合这个新世界 来源：https://depot.dev/blog/github-is-the-wrong-shape-for-this-new-world 人们高度关注 GitHub 的整体性能和可靠性，这很合理。但我认为更值得质疑的是我们使用 GitHub 的方式——它已经不符合当今构建软件的形态，我们需要更好的工具、工作流和基础设施原语来满足新的需求。 ## 软件工程已经改变 我知道这句话听起来有点像“水是湿的”一样显而易见。 如今我们开发软件的环境已经完全不同。还有熟悉的元素吗？当然有。过去的东西还能用吗？绝对可以。毕竟代码还是代码。正如一位导师常对我说的：输入字节，输出字节。 我们投入不足的那些瓶颈依然存在：从源码控制到 CI/CD，再到代码审查乃至部署。只不过现在它们正在扼杀我们新获得的速度。 这些瓶颈带来的痛苦正在加剧，因为现在每个人都能贡献代码。代码早已不限于工程团队，而是扩展到了销售、支持和市场等其他团队。这意味着，一次10分钟的构建，公司里每一个人都能感受到，而不仅仅是少数工程师。 这带来了深远的影响，它质疑了我们习以为常的假设和惯例。它提出了我认为至今仍没有答案的问题： - 代码归谁所有？或者说，谁对部署的代码负责？ - 我们如何信任代码？ - 如何审查所有这些新生成的代码？ - 如何将一个地方的代码与另一个地方的代码连接起来？ - 如何在 token 开销与高质量功能产出之间进行权衡？ 把这五个问题问给五个不同的人，你很可能得到五个不同的答案。 这就是我所说的“软件工程已经改变”的含义。这不仅仅是说 LLM 和代理程序能通过五句话的提示生成整个功能——那只是我们使用的一种工具。 真正改变的是软件工程的整个范式已经天翻地覆，而且速度之快我们根本跟不上。过去我们依赖的假设，随着每一次发布都在崩塌。 我相信我们必须重新思考我们的范式和正在使用的工具。我们正在把现有的人类中心范式强行扭曲到这个新世界里——这种做法是错误的。 ## 协作 vs 基础设施 其实这篇文章的标题本该是“GitHub、GitLab、Bitbucket 等已不再适合这个新世界”，但那样太啰嗦了，所以当我说 GitHub 时，请理解为包括它们所有。 我把 GitHub 看作一个协作工具。Google Docs 是我和文档团队协作写这篇文章的地方；GitHub 则是我和其他工程师协作编写 Depot 代码的地方。 我是用 GitHub 长大的。事实上，刚成为软件工程师时，我甚至想去 GitHub 工作。我所有的工作记忆都围绕着 GitHub 推给我的范式： - 在分支上编写代码。 - 准备好等待审查时，打开一个 Pull Request。 - 等待 CI 和检查通过，验证一切正常。 - 接收同事的审查评论，在 PR 中来回讨论想法。 - 一切通过、同事签字后，合并我的更改。 这种工作流有很多衍生版本，人们对这个范式的有效性也有截然不同的看法。但随便问一个工程师，他们都能了如指掌。 当 LLM 刚开始出现时，很自然地就把它们绑定到了我们现有的范式上。它们可以在分支上写代码、打开 PR、接受人类（或其他代理）的代码审查、通过评论在 PR 中协作、通过已有的 CI 流水线运行测试，最后合并代码。 这很合理：系统已经存在，当时的代理程序仍然基本以人类速度运行。 然后一切都变了。配备最新一代模型的代理程序变得极其出色——简直好得惊人。从我们经常需要像推积木一样微调才能得到好代码的模型，变成了只要上下文足够就能持续产生正确代码的模型。 更好的模型会带来什么净结果？更多的代码、更多的分支、更多的并行工作，以及对我们现有笨重的人类中心范式更大的压力。 我们的协作模式及其底层系统，现在成了首要瓶颈。每个工程团队都能感受到 GitHub 本身、CI、代码审查、Pull Request、安全扫描甚至部署中的瓶颈。 现在，我们的工具和我们想要构建的方式之间出现了阻抗不匹配。我们现有的协作范式（主要围绕 GitHub 构建）已经与当今实际构建软件的方式产生了冲突。 我们必须重新思考软件交付的范式——不是通过人类中心协作的视角，而是通过高吞吐量的基础设施原语。 ## 高吞吐量的软件交付 构建新的软件交付范式，需要从过去十年我们使用的人类中心流程退后一步。将软件交付重新构想成一系列由系统驱动的持续自动化过程，而不是一连串的人类操作。 一旦你开始想象这样的世界，软件交付的问题就不再像协作工具，而更像是基础设施。这里的“基础设施”指的是少量、可以在其上构建一切的原语。我们可以从云原生技术的采用中获得启发： - 计算作为原语，带来了虚拟机 - 存储作为原语，带来了对象存储 - 网络作为原语，带来了负载均衡器 我们应该思考软件交付所需的基本基础设施原语： - **源码控制**：代码演进的持久、不可变历史 - **执行**：用于构建、测试和验证变更的隔离、高性能计算 - **制品**：可在系统之间迁移的可重现输出 - **缓存**：确定性工作的复用 - **身份**：证明代码由谁或什么产生 - **策略**：用于质量、安全和合规的机器可执行规则 这些不是开发者工具的特性，它们是基础设施原语。就像我们不再操心配置单个服务器，转而将计算、存储和网络视为可组合的构建块一样，软件交付也需要同样的转变。 下一个十年的赢家不会构建一个更好的 Pull Request。他们将构建使代码生成、验证和部署能在机器规模上运行的基础设施。 ## 相关文章 - [What we need from CI for agentic engineering](https://depot.dev/blog/ci-for-agentic-engineering) - [The bottleneck has shifted from writing code to integrating it](https://depot.dev/blog/the-bottleneck-has-shifted) - [Staying in control of your codebase in the AI era](https://depot.dev/blog/staying-in-control-of-your-codebase-in-the-ai-era) Kyle Galbraith CEO & Co-founder of Depot 一名厌恶慢构建的平台工程师出身的创始人。旅居法国。