人们非常关注GitHub的整体性能和可靠性，这是理所当然的。但我认为更有趣的是质疑我们与GitHub使用的范式。这个范式对于我们今天构建软件的方式来说是不合适的，我们需要更好的工具、工作流程和基础设施原语来满足新的需求。软件工程发生了变化。我意识到这句话就像在说“水是湿的”。我们今天开发软件的世界从根本上不同。还有熟悉的事物吗？绝对有。过去的东西能在这个新世界中使用吗？当然可以。毕竟，代码还是代码。正如我一位导师曾经对我说的，那就是输入字节和输出字节。我们没能投资的瓶颈依然存在，从源代码管理到CI/CD到代码审查甚至部署。然而，现在它们正在扼杀我们新找到的开发速度。这些瓶颈带来的痛苦正在加剧，因为现在每个人都可以贡献代码。代码已经扩展到工程团队之外，进入销售、支持和营销等其他团队。这意味着，十分钟的构建大家都能感受到，而不仅仅是一小部分人。这有深远的影响，因为它质疑了我们所接受的假设和常态。它提出了我认为仍未回答的问题：谁拥有代码？或者换句话说，谁对部署的代码负责？我们如何信任这些代码？我们如何审查所有这些新生成的代码？我们如何将一处的代码与另一处的代码连接在一起？我们如何衡量代币支出的成本与优质功能的产出之间的关系？如果问这五个问题给五个不同的人，你很可能会得到五个不同的答案。这就是我所说的软件工程已经改变了。不是说LLM和代理可以基于五句话的提示生成一个完整的功能。这是我们正在使用的一种工具。而是围绕软件工程的整个范式现在截然不同，以一种我们根本无法跟上的速度在发展。我们所做的假设正随着每一次版本更新而崩溃。我相信我们必须重新思考我们的范式和使用的工具。我们正在将现有的工具和以人为本的范式弯曲到这个新世界。这是错误的方法。合作与基础设施 其实，这篇博客文章应该被称为“GitHub、GitLab、Bitbucket和其他工具在这个新世界中形状不对”。但这太长了，所以当我说GitHub时，请把它理解为所有这些工具。我把GitHub视为一个协作工具。Google Docs是我可以与技术写作团队合作的地方。GitHub是我可以与其他工程师协作开发Depot代码的地方。我在GitHub上成长。实际上，我当初成为软件工程师时就想在GitHub工作。我所有的肌肉记忆都是围绕GitHub推动我使用的范式构建的。在一个分支上写代码。当我准备好让我变更被审查时，打开一个拉取请求。等待CI和检查通过以验证一切正常。从同事那里审查评论，在PR中反复讨论想法。一旦一切都通过了，并且我的同事们签字，就合并我的更改。这个工作流程有许多衍生版本。对此范式的有效性有截然不同的看法。但问任何一位工程师，他们都能如数家珍。当LLM首次上线时，自然而然地将它们与我们现有的范式结合起来。他们可以在一个分支中编写代码，打开拉取请求，获得人类（或另一个代理）的代码审查，通过评论一起协作，利用我们现有的CI管道运行测试，最终合并代码。这是合乎逻辑的。系统存在，当时的代理仍然大致以人类的速度移动。然后一切都改变了。配备最新一代模型的代理变得非常优秀，令人震惊的优秀。我们从之前需要小心翼翼地将积木调整到位才能产出良好代码的模型，发展到现在只需给足够的上下文就能产生稳定正确代码的模型。更好的模型的最终结果是什么？更多的代码、更多的分支、更多的并行工作，以及对我们现有笨重的人力驱动范式的更多压迫。我们的协作模式及其背后的系统，现在是主要的瓶颈。每个工程团队都在感受来自GitHub本身、CI、代码审查、拉取请求、安全扫描甚至部署的瓶颈。我们的工具与我们想要构建的方式之间现在存在阻抗失配。我们现有以GitHub为基础的协作范式，现在与我们实际上构建软件的方式发生了冲突。我们必须重新思考我们的软件交付范式。不是通过以人为本的协作的视角，而是通过高吞吐量的基础设施原语。