几十年来，工程师们一直明白，大型代码审查比小型的更困难。出于礼貌和希望获得更好的代码审查，我们学会了将大型更改分解成更小的部分。一些工程师甚至更进一步，用结对编程取代了代码审查。但后来出现了大语言模型，似乎所有人都忘记了这些经验。如果你愿意反对默认设置并稍微改变你的思维方式，现在仍然可以应用这些经验。当然，这并没有帮助，因为整个行业都在说服我们，最大化令牌消耗是完成任务的唯一方法。我明白这可能听起来像极端的观点，但如果你有人认同这一点，我可以在这里写得更多：https://philbooth.me/blog/agentic-coding-and-mental-models
源讨论自动化让我退出了开发原帖 85 条评论 · 导入时统计有趣的是，尽管它比我现在所做的要详细得多，流程和程序也更多——我现在更像是版本0，但同时进行——我们最终得出了同样的问题：代码审查和质量保证。 我签署我合并的代码，这是公司政策的一部分，也是为了确保它确实不错。但审查已成为真正的瓶颈：即使堆叠的PR，如果总共有5-6k行代码，这并不是5分钟的工作。即使我进行了头脑风暴并制定了计划，这对我来说目前无法扩展。但作者对此非常谨慎：要么更改不是很大，要么他们足够信任流程，可以更随意地进行审查。作为同样不信任的人，我做不到……
完整原文把你的经验，加入这段讨论。
我完全同意这个观点。我认为推动更多自主性是使用大语言模型的完全错误方向。 我想要更少的代码需要维护，而不是更多我甚至完全不理解的代码。 我认为研究和高度监督的编码，加上很多限制措施，才是真正从这些工具中获得生产力的方法。
完整原文我认为这很合理。我唯一的不满是，很多时候进行小规模的修改，手动操作比等待大语言模型思考更快，所以我发现这实际上带来的速度提升很小。
完整原文> 现在仍然可以使用编码代理来实现它们，只要你愿意反对默认设置并稍微改变你的思维方式。当然，整个行业都在说服我们，最大化令牌消耗才是完成任务的唯一方式。 是的，问题在于我们周围的高管和经理们要求我们尽可能快速地推出大量功能，而我喜欢有工作，而且在这个市场上换工作让我感到恐惧...
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。