版本控制将如何发展以应对代理热潮(entire.io)
entire.io
How version control will evolve for the agent boom
https://entire.io/blog/how-version-control-will-evolve-for-the-agent-boom
71 评论
我很幸运地采用了这种方法：
https://github.com/williamcotton/algraf/tree/main/docs
还有一些测试可以确保主站的某些内容是最新的，例如错误代码。
https://github.com/williamcotton/algraf/tree/main/docs
还有一些测试可以确保主站的某些内容是最新的，例如错误代码。
确切地。该规范应该放在 git 注释中，而不是 vcs 中。或者，您可以在 PR 期间将该文档保留在历史记录中，并在审核后或合并前将其删除
完全不同意。该规范至关重要，以便未来的更改继续符合它。规范绝对需要存在于 VCS 中，因为仍然需要它们来保持代码的一致性。它们现在本质上是一种代码形式。代码进入 VCS。
从规模上看，规范仅对其一致性测试的自动化程度至关重要。好的规范应该使用正式的、可运行的验证语言。否则，你会积累一些规格，在发货时是正确的，在 3 个月后就出现微妙的错误，在 6 个月后就出现明显的错误。
但如果设置正确，一致性测试才是代理真正擅长的地方：
* 黑盒测试：编写测试的代理看不到实现，编写实现的代理也看不到测试，他们只同意规范和接口（编写测试所需的最低限度）。
* 使用代码覆盖率评估测试覆盖率，但当发现差距时，根据规范传达这些差距。
好的规范应该是有根据的（完整且不含糊），它们不需要是正式的。当规范与规范的差异发生变化时，您应该能够重新运行代理，并且如果更改发生得很糟糕，您应该让代理介入并对规范提出修复建议。由于代理正在像编译器一样进行确定性代码生成，因此这一切都非常简单。
您还需要考虑公共和内部规范（公共规范用于组件的重用），并且您可以使用测试替身（仅根据公共规范构建）而不是真正的组件本身来测试集成组件。
* 黑盒测试：编写测试的代理看不到实现，编写实现的代理也看不到测试，他们只同意规范和接口（编写测试所需的最低限度）。
* 使用代码覆盖率评估测试覆盖率，但当发现差距时，根据规范传达这些差距。
好的规范应该是有根据的（完整且不含糊），它们不需要是正式的。当规范与规范的差异发生变化时，您应该能够重新运行代理，并且如果更改发生得很糟糕，您应该让代理介入并对规范提出修复建议。由于代理正在像编译器一样进行确定性代码生成，因此这一切都非常简单。
您还需要考虑公共和内部规范（公共规范用于组件的重用），并且您可以使用测试替身（仅根据公共规范构建）而不是真正的组件本身来测试集成组件。
> 好的规格应该有根有据（完整且不含糊），不需要形式化
在我看来，这是一个错误。我想我们之所以这样做，是因为现在没有更好的办法了。用简单的英语编写和维护 "规范 "是很痛苦的。
在我看来，这是一个错误。我想我们之所以这样做，是因为现在没有更好的办法了。用简单的英语编写和维护 "规范 "是很痛苦的。
自然语言具有令人难以置信的表现力，而且相当容易读写。选择你最喜欢的形式规范语言......你只需用它们表达一些属性，而且它们大多是小众语言。如果你把形式语言的表现力提高太多，它就会变成代码，然后你又回到了原点。LLM 在处理自然语言方面也非常精通；也就是说，使用现代 LLM 来编写、维护和使用以普通英语编写的规范实际上是相当可行的。
> 编写和维护通俗易懂的 "规范 "是一件痛苦的事情。
整篇文章的主题是使用代理进行开发。用英语编写规范就是这样做的。如果你不喜欢，那么这篇文章可能不适合你发表评论。
整篇文章的主题是使用代理进行开发。用英语编写规范就是这样做的。如果你不喜欢，那么这篇文章可能不适合你发表评论。
不对。
这是为了确保人工智能在未来进行更改时，不会只查看现有代码并对意图做出假设。人工智能应该始终遵循规范，以确保更改与指定意图保持兼容。
> 否则，你就会积累这样的规范：它们在发布时是正确的，3 个月后就会出现微妙的错误，6 个月后就会出现明显的错误。人工智能不会改变这种动态变化，反而会放大它。
如果你修改的始终是规格，而不是代码，那就不会。这里的关键在于，你要做的不是修改代码，而是修改规格，然后批准 LLM 因此而修改的代码。这样，规范就不会偏离代码。
人工智能绝对会改变动态，使代码不会偏离规范。这就是重点，也是像提交代码一样提交规范的重点。
自动化测试当然也很好，但这并不是全部。它能确保形式上的合规性，但并不能概括为什么要以某种方式进行设计的精神或目的。好的规范就能做到这一点。对于 LLM 而言，目的/动机部分和工程指南是最重要的部分。当需要更改或添加功能时，这些内容可以帮助 LLM 想出修改现有代码的最佳方法。
这是为了确保人工智能在未来进行更改时，不会只查看现有代码并对意图做出假设。人工智能应该始终遵循规范，以确保更改与指定意图保持兼容。
> 否则，你就会积累这样的规范：它们在发布时是正确的，3 个月后就会出现微妙的错误，6 个月后就会出现明显的错误。人工智能不会改变这种动态变化，反而会放大它。
如果你修改的始终是规格，而不是代码，那就不会。这里的关键在于，你要做的不是修改代码，而是修改规格，然后批准 LLM 因此而修改的代码。这样，规范就不会偏离代码。
人工智能绝对会改变动态，使代码不会偏离规范。这就是重点，也是像提交代码一样提交规范的重点。
自动化测试当然也很好，但这并不是全部。它能确保形式上的合规性，但并不能概括为什么要以某种方式进行设计的精神或目的。好的规范就能做到这一点。对于 LLM 而言，目的/动机部分和工程指南是最重要的部分。当需要更改或添加功能时，这些内容可以帮助 LLM 想出修改现有代码的最佳方法。
> 这里的重点是，你不需要更改代码，只需要更改规格、
> 但这并不能概括为什么要以某种方式进行设计的精神或目的。好的规范可以。
规范是元解决方案。它们通过拒绝做出任何会导致附带问题的技术决策来描述解决方案的总体形态，因此只需关注本质问题。因此，它们总是简单化的，因为它们忽略了实施决策的连带效应。
每次使用人工智能生成代码都是在掷骰子。正确的实施是通过做出决定并沿着一条路径前进，必要时在它不再起作用时进行回溯。使用人工智能则会破坏这种连续性，因为他们每次都要从头开始。
> 但这并不能概括为什么要以某种方式进行设计的精神或目的。好的规范可以。
规范是元解决方案。它们通过拒绝做出任何会导致附带问题的技术决策来描述解决方案的总体形态，因此只需关注本质问题。因此，它们总是简单化的，因为它们忽略了实施决策的连带效应。
每次使用人工智能生成代码都是在掷骰子。正确的实施是通过做出决定并沿着一条路径前进，必要时在它不再起作用时进行回溯。使用人工智能则会破坏这种连续性，因为他们每次都要从头开始。
> 规范是元解决方案。它们通过拒绝做出任何会导致附带问题的技术决定来描述解决方案的总体形态，因此只需关注基本问题。
是的，这是功能而不是错误。然后，代码审查确保实际代码以理想的方式做出必要的技术决策。这样速度会快很多。
> 用人工智能生成代码，每次都是在掷骰子。正确的实施是通过做出决定并沿着一条路径前进，必要时在它不再起作用时进行回溯。使用人工智能则会破坏这种连续性，因为它们每次都会从头开始。
错。你只需在最初的时候生成初始代码，然后更新规范，指定（最好是高层次的）缺失的约束条件。但之后，你会让人工智能修改现有代码以满足新规范的要求，而不是从头开始。人工智能不会 "每次都从头开始"，它会采用更新后的规范和现有代码，并更新代码以符合更新后的规范。
这仍然是 "做出决定并沿着一条道路前进"，也就是你所说的正确实施。这才是关键所在。
是的，这是功能而不是错误。然后，代码审查确保实际代码以理想的方式做出必要的技术决策。这样速度会快很多。
> 用人工智能生成代码，每次都是在掷骰子。正确的实施是通过做出决定并沿着一条路径前进，必要时在它不再起作用时进行回溯。使用人工智能则会破坏这种连续性，因为它们每次都会从头开始。
错。你只需在最初的时候生成初始代码，然后更新规范，指定（最好是高层次的）缺失的约束条件。但之后，你会让人工智能修改现有代码以满足新规范的要求，而不是从头开始。人工智能不会 "每次都从头开始"，它会采用更新后的规范和现有代码，并更新代码以符合更新后的规范。
这仍然是 "做出决定并沿着一条道路前进"，也就是你所说的正确实施。这才是关键所在。
人们不屑于使用规范的原因是，它们异常冗长、模棱两可，同时又过于简单。这就是为什么我们发明了形式化的符号，因为它们简短，只有一个定义，即使不能理解为什么，也足以创建整个东西。后者仍然可以用散文来完成。
规范的真正用处在于，它可以让你在构思阶段就对解决方案进行操作，而不会让它沾染上现实世界的问题。但要做到这一点，需要对这些现实世界的问题有大量的了解，这样你的假设才不会是纯粹的谎言。
这有利于迭代。但任何实现都会使你的规范僵化，虽然代码比大多数代码更具可塑性，但到了一定程度，规范就应该被抛弃，而实际的实现才是进一步开发的真理来源。在任何项目中，这都是通过变更请求来实现的，变更请求只概述了变更的特定区域，而假定其他区域是不变的。
> 人工智能不会 "每次都从头开始"，它会采用更新后的规范和现有代码，并更新代码以匹配更新后的规范。
也许你可以举例说明这种工作流程，并提出实际论据来证明它的可持续性。
我曾经编写过规范的正式版本（测试套件），如果说有什么事情会让上述想法变得荒谬的话，那就是在遵循规范的同时又无法使用的回旋余地有多大。
规范的真正用处在于，它可以让你在构思阶段就对解决方案进行操作，而不会让它沾染上现实世界的问题。但要做到这一点，需要对这些现实世界的问题有大量的了解，这样你的假设才不会是纯粹的谎言。
这有利于迭代。但任何实现都会使你的规范僵化，虽然代码比大多数代码更具可塑性，但到了一定程度，规范就应该被抛弃，而实际的实现才是进一步开发的真理来源。在任何项目中，这都是通过变更请求来实现的，变更请求只概述了变更的特定区域，而假定其他区域是不变的。
> 人工智能不会 "每次都从头开始"，它会采用更新后的规范和现有代码，并更新代码以匹配更新后的规范。
也许你可以举例说明这种工作流程，并提出实际论据来证明它的可持续性。
我曾经编写过规范的正式版本（测试套件），如果说有什么事情会让上述想法变得荒谬的话，那就是在遵循规范的同时又无法使用的回旋余地有多大。
The problem I see is that git commit meaaages are not as flexible at storing context information as files. Or easier to retrieve.
We do have --grep to search them but it's definitely not as poweful as all the tools we have to handle files at the OS level.
As verbose as storing specs in files is, I also prefer it
如果我们有一种方法能够准确、详细地向机器描述要做什么就好了！也许是某种语言，我不知道……/s
我发现指导人工智能会话的人对几乎所有事情的价值几乎为零。没有人想知道高级开发人员如何在没有人工智能的情况下得出他所做的结果；他们关心他的交付成果是否高质量并满足现有的任何标准/要求。
所以我不确定为什么人们会说“砍，砍”和“不，让它更红更大”是一个有用的信号。
不，未来是一个复杂的“大门”，它在提交之前检查、权衡和测量一切——本地（或远程）“CI”，但是……更细粒度、更具体，并转向您所从事项目的需求。
所以我不确定为什么人们会说“砍，砍”和“不，让它更红更大”是一个有用的信号。
不，未来是一个复杂的“大门”，它在提交之前检查、权衡和测量一切——本地（或远程）“CI”，但是……更细粒度、更具体，并转向您所从事项目的需求。
> 没有人好奇高级开发人员如何在没有人工智能的情况下得出他所做的结果；他们关心他的交付成果是否高质量并满足现有的任何标准/要求。
我想很多人可能不想考虑的问题是，在人工智能辅助编程时代，我们如何晋升/奖励/解雇开发者。作为代码审查的一部分，我认为询问“你是如何得出代码的”将成为第二天性。
我想很多人可能不想考虑的问题是，在人工智能辅助编程时代，我们如何晋升/奖励/解雇开发者。作为代码审查的一部分，我认为询问“你是如何得出代码的”将成为第二天性。
迫不及待地想因为我与人工智能聊天时的脏话被该公司的反脏话代码自动化功能标记而陷入麻烦。
我认为分享对话是没有意义的，但我确实认为开发人员将需要在对话中提供课程、笔记和检查点。
我认为将会发生的情况是，您将被要求通过公司要求的提示来进行对话，其中包括诸如对话是否包含“更加努力地思考”之类的内容，而不提供任何如何纠正问题的指导。
基本上，开发人员是否将对话视为字面上的老虎机。
我认为将会发生的情况是，您将被要求通过公司要求的提示来进行对话，其中包括诸如对话是否包含“更加努力地思考”之类的内容，而不提供任何如何纠正问题的指导。
基本上，开发人员是否将对话视为字面上的老虎机。
你好！我在整体工作。实际上，我们宣布了另一个称为“Trails”的功能，它可以指示代码更改的置信度、风险和偏差，让维护人员更加确信代码是高质量的。
这些信号中的每一个——置信度、风险、偏差都是由维护人员可以创建的工作流程文件确定的。
每次进行更改时，跟踪都会不断进行评估。
这正是我们正在做的事情……在提交之前检查、权衡和测量一切的大门。
我们捕获代理会话的目的是这样我们可以用它做更多的事情......比如添加验证质量的“门”！
这些信号中的每一个——置信度、风险、偏差都是由维护人员可以创建的工作流程文件确定的。
每次进行更改时，跟踪都会不断进行评估。
这正是我们正在做的事情……在提交之前检查、权衡和测量一切的大门。
我们捕获代理会话的目的是这样我们可以用它做更多的事情......比如添加验证质量的“门”！
但谁会相信分类器呢？我不会。
专业团队会信任他们自己构建的网关（很可能是由人工智能构建的，因为这是一项无聊的工作），该网关适用于他们的组织以及他们拥有的任何奇怪的怪癖和风格。一两年后，当事情变得更加稳定时，将会有数十个子代理，每个子代理都单独测试一个小东西，再加上一堆软件，除了运行测试和短绒检查之外，还会寻找反模式。它将根据真实规范进行测试，而不是中间无聊的废话。
任何时候任何人的会议都不重要。结果计数；而已。
专业团队会信任他们自己构建的网关（很可能是由人工智能构建的，因为这是一项无聊的工作），该网关适用于他们的组织以及他们拥有的任何奇怪的怪癖和风格。一两年后，当事情变得更加稳定时，将会有数十个子代理，每个子代理都单独测试一个小东西，再加上一堆软件，除了运行测试和短绒检查之外，还会寻找反模式。它将根据真实规范进行测试，而不是中间无聊的废话。
任何时候任何人的会议都不重要。结果计数；而已。
分类器由处理存储库的团队确定。不是我们干的！它们是配置文件......就像在 CI/CD 中编写需要通过测试的工作流程文件一样。同样的事情。
当你的人工智能使用过时的文档时，它会给系统带来错误和不正确的行为。代码是唯一真正重要的事实来源。
在代码之外，我没有明确结束日期的唯一工件是用户故事风格的需求文档，我会定期使用 AI 重新访问这些文档，以确保它们是最新的。
我见过人工智能所做的最烦人的事情之一就是不小心引入旧的需求并开始基于它们进行构建。
在代码之外，我没有明确结束日期的唯一工件是用户故事风格的需求文档，我会定期使用 AI 重新访问这些文档，以确保它们是最新的。
我见过人工智能所做的最烦人的事情之一就是不小心引入旧的需求并开始基于它们进行构建。
> 我见过人工智能所做的最烦人的事情之一就是不小心引入旧的需求并开始基于它们进行构建。
这实际上是我想要创建我所说的“大脑检查点”的原因。 在与代理聊天并让它完成发现任务后，我需要一种简单的方法来了解它在任何给定点所知道的内容。 它读取了哪些文件、调用了哪些工具等等。
检查点在 Pi 中工作得非常好，因为您可以创建一个分支，并让代理根据自上次检查点以来发生的更改生成检查点，并且此信息不会污染主要对话，但您可以从令牌缓存中受益。
这实际上是我想要创建我所说的“大脑检查点”的原因。 在与代理聊天并让它完成发现任务后，我需要一种简单的方法来了解它在任何给定点所知道的内容。 它读取了哪些文件、调用了哪些工具等等。
检查点在 Pi 中工作得非常好，因为您可以创建一个分支，并让代理根据自上次检查点以来发生的更改生成检查点，并且此信息不会污染主要对话，但您可以从令牌缓存中受益。
> 我们的假设很简单：会话日志现在是软件开发中最重要的人工制品，应该与代码本身一起存储在版本库中。
Pi.dev 有一个功能，可以将会话导出为 html 文件并在稍后查看。我认为，您可以将其存储在同一个 Git 仓库中，并在与代理的会话中查看特定代码的变化。
我想下一步应该是让编码代理将会话上下文自动保存在 Git 仓库的文件夹中，而不需要人工导出。
这家初创公司似乎也在从事与 tangled.org 类似的工作--将代码库转移到分散的托管环境中。
Pi.dev 有一个功能，可以将会话导出为 html 文件并在稍后查看。我认为，您可以将其存储在同一个 Git 仓库中，并在与代理的会话中查看特定代码的变化。
我想下一步应该是让编码代理将会话上下文自动保存在 Git 仓库的文件夹中，而不需要人工导出。
这家初创公司似乎也在从事与 tangled.org 类似的工作--将代码库转移到分散的托管环境中。
这就是我用 pi 的 pi-brains 扩展所做的事情
https://github.com/gitsense/pi-brains
我将在本周末之前进行另一次更新，其中包含我所说的“大脑检查点”，这将使开发人员更容易调试和理解人工智能推理。
这个想法是在任务完成后，您将提交课程、笔记和“大脑检查点”，这些内容旨在与代码一起使用。
https://github.com/gitsense/pi-brains
我将在本周末之前进行另一次更新，其中包含我所说的“大脑检查点”，这将使开发人员更容易调试和理解人工智能推理。
这个想法是在任务完成后，您将提交课程、笔记和“大脑检查点”，这些内容旨在与代码一起使用。
> 将代码存储库移至去中心化托管环境中
我不清楚去中心化的整体意味着什么。根据他们最近的博客文章（https://entire.io/blog/an-entirely-new-git-hosting-network），他们似乎只是意味着全球分布，但一切都由他们控制。
相比之下，《魔发奇缘》至少提供了一些让你可以拥有自己数据的东西！
我不清楚去中心化的整体意味着什么。根据他们最近的博客文章（https://entire.io/blog/an-entirely-new-git-hosting-network），他们似乎只是意味着全球分布，但一切都由他们控制。
相比之下，《魔发奇缘》至少提供了一些让你可以拥有自己数据的东西！
整个 cli 维护者在这里：整个 cli 正是这样做的，支持代理本机 clis，但也支持 pi 或 opencode。我们获取原始会话日志，将其放入具有指向提交的稳定链接的存储库中，然后您可以在 cli 中呈现它或在 Whole.io 上查看它。
我不认为这会成功。法学硕士的冗长文本绝对具有小说价值；没有人愿意阅读别人与它的对话，当然也没有人愿意阅读长达 20,000 字的多年会话日志。另外，这就是提交消息应该解决的问题！人们查看日志的唯一原因是为了看看出了什么问题，通常平分更容易找到错误的提交，而不是深入研究细节。
我倾向于发现此类会话日志最好采用提交消息的形式。然后是拉取请求中的摘要。我们之前也这样做过。
[延迟]
[延迟]
> 版本控制将随着代理的繁荣而发展
这不就是Yegg的“Beads”背后的想法吗？
这不就是Yegg的“Beads”背后的想法吗？
这更像是将所有代理通信放入具有 git 不可变历史记录的数据库中。 他们仍然使用 git 来编写代码，并使用珠子（好吧，DoltDB 用于存储/版本控制）来执行任务以及一些非关联内存。
关于这个主题，我没有发现太多值得稍后参考的提示，但我总是在会话本地网络服务器上进行搜索代码，以便稍后可以找到东西。线束似乎在这方面做得越来越好，但我为不同的分支创建了大量目录，所以我总是记不住会话是在 de512.main 还是 de1024.main 中
我很幸运地告诉代理搜索旧会话，以编写如何编写文档或草拟出一个 Python 脚本来自动化已经完成了几次的操作。
关于这个主题，我没有发现太多值得稍后参考的提示，但我总是在会话本地网络服务器上进行搜索代码，以便稍后可以找到东西。线束似乎在这方面做得越来越好，但我为不同的分支创建了大量目录，所以我总是记不住会话是在 de512.main 还是 de1024.main 中
我很幸运地告诉代理搜索旧会话，以编写如何编写文档或草拟出一个 Python 脚本来自动化已经完成了几次的操作。
我认为基于问答的方法也可能是捕捉项目背后推理的合适方法。人工智能可以在整个过程中采访开发人员，并将问题和答案保留为项目上下文，而不是事后编写文档。
Matt Pocock 的“grill-me”技能就是这个想法的一个很好的例子：https://github.com/mattpocock/skills/tree/main/skills/product...
Matt Pocock 的“grill-me”技能就是这个想法的一个很好的例子：https://github.com/mattpocock/skills/tree/main/skills/product...
Superpowers 的头脑风暴技巧是另一个（？）经典例子。 Superpowers 综合头脑风暴的好处在于，结果直接进入规范→计划→执行→审查。
https://github.com/obra/superpowers/blob/main/skills/brainst...
https://github.com/obra/superpowers/blob/main/skills/brainst...
[延迟]
看看他在 WeAreDevelopers 上的主题演讲。他在 17:20 左右开始
https://www.youtube.com/watch?v=eSoHzgrhk6Q
他确实暗示要删除拉取请求！
https://www.youtube.com/watch?v=eSoHzgrhk6Q
他确实暗示要删除拉取请求！
> 对于维护者来说，告诉他们自己的代理重新实现同样的想法要容易得多。
这只有在假设原始 PR 只是用最少的人力进行振动编码的情况下才有意义。也许有一天会这样，但我认为我们还没到那一步。
这只有在假设原始 PR 只是用最少的人力进行振动编码的情况下才有意义。也许有一天会这样，但我认为我们还没到那一步。
大规模扫描和合并外部提示的安全影响将会很有趣。
而且它的成本至少是代币数量的两倍，因此 LLM 提供商完全获胜。
挑衅：拉取请求始终是最糟糕的方式。
[延迟]
有没有人尝试教代理使用 jj 或 gitbutler-cli 来实现轻量级分支的想法？ 我一直觉得这对于我正在与代理进行更多合作的多分支开发来说将是一个巨大的胜利，但我还没有进行该实验。
> 有没有人尝试教代理使用 jj 或 gitbutler-cli 来实现轻量级分支的想法？
如果您的编码代理支持像 Pi 这样的钩子，那么这是非常简单的。我有一个演示存储库，它介绍了规则的工作原理，网址为 https://github.com/gitsense/gsc-rules-demos
基本思想是，您始终确保注入有关如何使用 jj 或任何其他 scm 的说明。 LLM 是模式匹配器，他们可以完全映射行为，但由于 git 上的大量训练，他们可能会忘记。
使用钩子，您可以轻松检测何时使用“git”，并基本上告诉代理“如前所述，您必须使用 jj”。因此，它会再次尝试使用“jj”，并且当它尝试使用 git 时，您会阻止代理。
这是一个浪费的回合，但现实是，它不会花费必须，因为您可以利用缓存，并且您只会在无效命令上浪费令牌，而不是在 git 生成的输出上浪费令牌。
如果您的编码代理支持像 Pi 这样的钩子，那么这是非常简单的。我有一个演示存储库，它介绍了规则的工作原理，网址为 https://github.com/gitsense/gsc-rules-demos
基本思想是，您始终确保注入有关如何使用 jj 或任何其他 scm 的说明。 LLM 是模式匹配器，他们可以完全映射行为，但由于 git 上的大量训练，他们可能会忘记。
使用钩子，您可以轻松检测何时使用“git”，并基本上告诉代理“如前所述，您必须使用 jj”。因此，它会再次尝试使用“jj”，并且当它尝试使用 git 时，您会阻止代理。
这是一个浪费的回合，但现实是，它不会花费必须，因为您可以利用缓存，并且您只会在无效命令上浪费令牌，而不是在 git 生成的输出上浪费令牌。
克劳德和jj合作得很好。
最近的和相关的：
前 GitHub 首席执行官推出了新的 AI 代理开发者平台 - https://news.ycombinator.com/item?id=46961345 - 2026 年 2 月（577 条评论）
前 GitHub 首席执行官推出了新的 AI 代理开发者平台 - https://news.ycombinator.com/item?id=46961345 - 2026 年 2 月（577 条评论）
还有人发现法学硕士缺乏版本控制纪律吗？
总体上缺乏工程实践。除非明确要求，否则永远不会进行测试或假设验证。
总体上缺乏工程实践。除非明确要求，否则永远不会进行测试或假设验证。
您是否尝试过为您的代理创造技能以遵循您的模式？
> 还有人发现法学硕士缺乏版本控制规则吗？
不？你如何定义纪律？克劳德代码知道如何读取和写入提交。我的团队一周前刚刚授予它有限的强制推送访问权限。我们已经教它发出更人性化的提交消息。
缺少什么？
不？你如何定义纪律？克劳德代码知道如何读取和写入提交。我的团队一周前刚刚授予它有限的强制推送访问权限。我们已经教它发出更人性化的提交消息。
缺少什么？
我认为这里一个有用的问题是“什么是好的提交？”，特别是在 MR 阶段。我不关心本地机器上的提交是什么样子。
我倾向于将那个阶段的提交视为完整的原子想法。
“此提交是此函数名称的重构”
“此提交定义了我们将使用的所有数据类”
“这次提交编写了新函数及其所有测试”
“此提交使用功能标志将新代码注入旧路径”
“此提交修复了因该更改而中断的测试”
其中一些最好完全作为单独的 MR 来使用；但我想我的想法是正确的。
我倾向于将那个阶段的提交视为完整的原子想法。
“此提交是此函数名称的重构”
“此提交定义了我们将使用的所有数据类”
“这次提交编写了新函数及其所有测试”
“此提交使用功能标志将新代码注入旧路径”
“此提交修复了因该更改而中断的测试”
其中一些最好完全作为单独的 MR 来使用；但我想我的想法是正确的。
我仍然不让我的代理使用 git。
我们需要将 CHOICES 与提交或分支一起存储。不是整个会议。有意识、总结性的选择
我们存储的是整个会话，但提供了查询汇总选择的工具。我们的目的不是让用户坐在那里通读整个会话。
我们真的需要一个新系统吗？仅仅编写详细的提交消息有什么问题吗？
“我们的假设很简单：会话日志现在是软件开发中最重要的工件，应该与代码本身一起存储在存储库中。”
过去几周里不是有一篇关于 HN 的文章讲述了有人实际实现了这一点，而且它只是让每个指标的情况变得更糟？
前人工智能时代的人们定期希望版本控制能够跟踪每次击键，而我和许多其他人都觉得他们从未成功地阐明我们应该从中得到什么。会话历史似乎是同一件事。也许是一段即时的历史。但我不希望人工智能的每一个细节都经过开发者的头脑，就像我不希望每一个最后的迷失都经过开发者的头脑一样，在这两种情况下出于同样的原因：有限的头脑只能容纳这么多东西。
对于有限的思维来说，无论是人类还是人工智能，“把所有东西都塞进去并期望得到改进”并不是一个可行的策略。为了从中获得任何价值，有限的思维需要做的第一件事就是将其提取成一些更小、细节更少的概括版本。这与我们已有的非常接近，只是不需要在流程上消耗人工智能时间。我们花了几十年的时间磨练减少认知负荷的技术。人工智能也从中受益，并使它们比以往任何时候都更加重要，而不是过时。
当然，这不完全是我们今天所拥有的。但我认为这是一个例外在我们脑海中过于突出的例子，正是因为它们是例外。是的，在我的职业生涯中，我遇到过一些案例，我想知道他们在想什么，不仅仅是作为批评，而是作为一个实际的问题。但这种情况很少见，而且最终与“代码在做什么”和“通过代码传递什么来完成这件事”等问题相比，不一定那么有价值。在绝大多数情况下，代码已经是我所需要的。
事实上，我们拥有这个代码工件，它是“意图”无法通过的网关和检查点，这是一件积极的好事，也是人们错过的微妙原因之一，它使得大规模人类软件开发和当前基于人工智能的软件开发趋势成为可能。将所有这些东西修剪成具有极其精确指定功能的工件的高效过程，并且不需要来自人类或过程或历史的外部支持，这是一件令人惊讶的奇妙事情。用大量非常蓬松的数据存放代码库，这些数据很少有用，这是积极的倒退，而不是前进。
过去几周里不是有一篇关于 HN 的文章讲述了有人实际实现了这一点，而且它只是让每个指标的情况变得更糟？
前人工智能时代的人们定期希望版本控制能够跟踪每次击键，而我和许多其他人都觉得他们从未成功地阐明我们应该从中得到什么。会话历史似乎是同一件事。也许是一段即时的历史。但我不希望人工智能的每一个细节都经过开发者的头脑，就像我不希望每一个最后的迷失都经过开发者的头脑一样，在这两种情况下出于同样的原因：有限的头脑只能容纳这么多东西。
对于有限的思维来说，无论是人类还是人工智能，“把所有东西都塞进去并期望得到改进”并不是一个可行的策略。为了从中获得任何价值，有限的思维需要做的第一件事就是将其提取成一些更小、细节更少的概括版本。这与我们已有的非常接近，只是不需要在流程上消耗人工智能时间。我们花了几十年的时间磨练减少认知负荷的技术。人工智能也从中受益，并使它们比以往任何时候都更加重要，而不是过时。
当然，这不完全是我们今天所拥有的。但我认为这是一个例外在我们脑海中过于突出的例子，正是因为它们是例外。是的，在我的职业生涯中，我遇到过一些案例，我想知道他们在想什么，不仅仅是作为批评，而是作为一个实际的问题。但这种情况很少见，而且最终与“代码在做什么”和“通过代码传递什么来完成这件事”等问题相比，不一定那么有价值。在绝大多数情况下，代码已经是我所需要的。
事实上，我们拥有这个代码工件，它是“意图”无法通过的网关和检查点，这是一件积极的好事，也是人们错过的微妙原因之一，它使得大规模人类软件开发和当前基于人工智能的软件开发趋势成为可能。将所有这些东西修剪成具有极其精确指定功能的工件的高效过程，并且不需要来自人类或过程或历史的外部支持，这是一件令人惊讶的奇妙事情。用大量非常蓬松的数据存放代码库，这些数据很少有用，这是积极的倒退，而不是前进。
到目前为止，不必直接使用 Stack Overflow 或 Git，这是 LLM 给我的生活带来的最大进步。
相关公告帖子：
全新的 Git 托管网络
https://entire.io/blog/an-entirely-new-git-hosting-network
(https://news.ycombinator.com/item?id=48833019)
全新的 Git 托管网络
https://entire.io/blog/an-entirely-new-git-hosting-network
(https://news.ycombinator.com/item?id=48833019)
> 但随着代码通过代理变得越来越丰富，“为什么”编写代码背后的上下文变得至关重要：
这就是提交消息。如果标题和差异中有些内容不能立即清楚，您可以将其写在提交描述中，如下所示：
https://cgit.freebsd.org/src/commit/?id=ed7e0ebfa20e7e798d2e...
如果您无法以类似的方式总结您的更改，通常意味着您不理解代码，并且不应该将其推送给其他人。
这就是提交消息。如果标题和差异中有些内容不能立即清楚，您可以将其写在提交描述中，如下所示：
https://cgit.freebsd.org/src/commit/?id=ed7e0ebfa20e7e798d2e...
如果您无法以类似的方式总结您的更改，通常意味着您不理解代码，并且不应该将其推送给其他人。
我认为这没有规模。我们最近一直在进行“规范驱动的开发”，我们正在将规范和提示以及生成的代码一起提交到我们的存储库中。一开始似乎很好：你想改变一些东西，你更新规范并要求机器重新生成代码。简单的。但随着时间的推移，MD 中的规范文件可能会达到数百甚至数千。都是英文散文。存在重复和细微的不一致。搜索规范的各个部分很困难。总而言之，在足够大的系统中，维护英语散文似乎比维护实际代码差得多