Even if you are as averse to semver as I used to be in the course of my programming activity, you can still think of open source software distribution as something that used to follow a fixed number of steps. There is a branch where developments happen, and this branch oftentimes happens to be not really ready for reliable work. Then you freeze the developments for a certain amount of time (even if, in the meantime, the work can continue on some new unstable branch), fix bugs, ask people to test it. At some point the number of bug reports starts to drop, your team and your users start to believe there are no longer obvious critical flaws that are easy to discover in the next few weeks: then you call the branch 2.4 or whatever, and that's it.

However now, with AI coding, it's not just development that has changed, but also the act itself of using software is affected: it is not just you that can ask an AI to do certain changes to the software, but also the recipient of the software itself. This is obvious in the domains where a piece of software has its main user base among programmers, but this is also true in general, as more and more technologically inclined users have AI access and coding agents.

Because of this change, the idea of just having a stable branch with everything polished, and an unstable branch where everything is a work in progress, may no longer be the right way to do things. A code repository can also be a finished product, but could be even more useful if it is a template for how to do things around a given problem. Maybe the user will modify the code in order to specialize it for a specific set of requirements, hardware, specific problems to solve. Also, what is too unstable or unproven for the general public may be the right thing for another set of users.

Take the example of Redis. For weeks now I have been iterating on a PR that provides strong memory savings for sorted sets. This work, if accepted, will hit every user of Redis, from people that don't have any idea about how Redis works, to users that maybe even contributed code in the course of years. From use cases that are trivial to use cases where a 50% memory saving on sorted sets could mean cutting a big slice of the cloud bill every year. For this last kind of user, having the final product (after all the testing and changes of design I'm doing to refine something that "just works", with the risk that maybe it will not even enter the code base) may be less interesting than having a 95%-ready branch since day zero. It is code they can test, adapt, iterate on, even specialize more for the problem at hand.

Maybe DwarfStar is an even more telling example of how code repositories should be good examples more than finished products covering every piece of the features matrix. With local inference you have, in the specific case of DwarfStar, many kinds of GPUs, models, server mode, agent mode, CLI, SSD streaming, tensor and pipeline distributed execution. To test everything everywhere is complicated. Yet, once you have two solid examples of tensor parallel graph execution, a strong coding agent can infer how to implement the same thing for other backend/model pairs. Similarly, once you have an engine that supports two models well enough, a third can be implemented in an almost automatic way, using the existing code base as a guardrail for coding agents in order to guide the implementation.

This does not mean that a project like DwarfStar should not work out of the box, but that it could focus on supporting very well a set of features that can be extrapolated to a larger amount of possible situations that the users can cover themselves. It also means another thing: that main and unstable are no longer enough. Many experimental branches could be an integral part of the project. For instance, yesterday the Laguna S.1 model was released. It looks interesting on paper, however: will it really be good enough? Will the new DeepSeek v4 Flash checkpoints make it not really relevant for DwarfStar? It is too early to say. However, to collectively form an idea, publishing a branch with this model implementation is a good middle ground: people will try it, will refine it with their coding agents, and the community can collectively form an idea about how merge-worthy it is. Moreover, today I noticed how, thanks to the rails formed by the corpus of the code inside DwarfStar, the implementation was written in about two hours by GPT 5.6 Sol automatically. Implementing DS4 and GLM5.2 cost me a lot of steering, reading the model card and the details of the implementation of the attention of those models. Now it just worked. GPT 5.6 is more powerful but it also found a lot of good examples inside the existing source code.

Software today is more malleable than ever. In some way this means that it can be released in a more fluid way. Also, it means that the documentation itself should not be just good for humans, but also for coding agents to understand how to change the system. How this will evolve exactly, and what the right point of balance between the different dimensions of stability, usability, and features will be, is not clear to me, but I believe we developers need to keep our eyes open to see where all this is headed.

即使你像我过去在编程生涯中那样反感语义化版本控制（semver），你仍然可以将开源软件的发行视为曾经遵循固定步骤的事务。有一个分支用于开发，而这个分支往往并不真正适合可靠的工作。然后你会冻结开发一段时间（即使在此期间，工作可以在某个新的不稳定分支上继续），修复漏洞，请人们测试。在某个时刻，漏洞报告的数量开始下降，你的团队和用户开始相信在接下来的几周内不再有容易发现的明显严重缺陷：于是你将该分支命名为 2.4 或其他版本号，就这样了。

然而现在，随着 AI 编程的出现，不仅开发过程发生了变化，软件的使用行为本身也受到了影响：不仅你可以让 AI 对软件进行某些更改，软件的用户本身也可以。这在软件主要用户群体是程序员的领域尤为明显，但总的来说也是如此，因为越来越多懂技术的用户已经能够使用 AI 和编码代理。

由于这一变化，仅仅拥有一个经过打磨的稳定分支和一个一切都在进行中的不稳定分支，可能不再是正确的做法。一个代码仓库也可以是一个成品，但如果它能成为解决特定问题的模板，那就更有用了。也许用户会修改代码，使其专门适用于一组特定的需求、硬件或特定问题。此外，对普通公众来说过于不稳定或未经验证的内容，可能正适合另一类用户。

以 Redis 为例。几周以来，我一直在迭代一个为有序集合提供强大内存节省功能的 PR。这项工作如果被接受，将影响到每一个 Redis 用户，从完全不了解 Redis 工作原理的人，到多年来可能贡献过代码的用户。从微不足道的使用场景，到那些在有序集合上节省 50% 内存意味着每年大幅削减云服务账单的场景。对于后一类用户，拥有最终产品（经过我所有测试和设计改进，以完善出“开箱即用”的东西，同时也冒着它可能根本不会被纳入代码库的风险）可能不如从第一天起就有一个 95% 完成度的分支更有吸引力。这是他们可以测试、调整、迭代甚至针对手头问题进一步专门化的代码。

也许 DwarfStar 是一个更具说服力的例子，说明了代码仓库更应该成为好的范例，而不是覆盖功能矩阵中每一个角落的成品。以 DwarfStar 为例，在本地推理中，你会有多种 GPU、模型、服务器模式、代理模式、CLI、SSD 流式传输、张量并行和流水线分布式执行。要在所有环境下进行测试非常复杂。然而，一旦你有了两个可靠的张量并行图执行示例，一个强大的编码代理就能推断出如何为其他后端/模型对实现同样的功能。同样，一旦你有一个引擎能足够好地支持两个模型，第三个就可以几乎自动地实现，利用现有代码库作为编码代理的护栏来指导实现。

这并不意味着像 DwarfStar 这样的项目应该无法开箱即用，而是说它可以专注于很好地支持一组功能，这些功能可以推广到更多用户自己能够覆盖的可能情况。这也意味着另一件事：main 分支和 unstable 分支已经不够了。许多实验性分支可以成为项目的组成部分。例如，昨天发布了 Laguna S.1 模型。在纸面上看起来很有趣，但：它真的足够好吗？新的 DeepSeek v4 Flash 检查点是否会使其对 DwarfStar 不再重要？现在说还为时过早。然而，为了共同形成一个观点，发布一个包含该模型实现的分支是一个很好的折中方案：人们会尝试它，会用他们的编码代理来完善它，社区可以共同判断它有多值得合并。此外，今天我发现，借助 DwarfStar 内部代码库所形成的轨道，GPT 5.6 Sol 在大约两小时内自动完成了实现。实现 DS4 和 GLM5.2 耗费了我大量的引导工作，需要阅读模型卡片和这些模型注意力机制的实现细节。而现在它直接就能工作了。GPT 5.6 更强大，但它也在现有源代码中找到了许多好的示例。

今天的软件比以往任何时候都更具可塑性。在某种意义上，这意味着它可以更灵活地发布。同时，这也意味着文档本身不仅要对人类友好，还要让编码代理理解如何更改系统。这一切将如何具体演变，以及在稳定性、可用性和功能这些不同维度之间，合适的平衡点在哪里，我还不清楚，但我相信我们开发者需要保持警觉，看看这一切将走向何方。