tison
@tison1096
Co-Founder @scopedbio
Board Director & Incubator Mentor @TheASF
GitHub:
145 正在關注 10.4K 粉絲
本文首先简述智能体编程的优势，然后说明人在智能体编程的循环中如何发挥自身价值，从而可靠地交付智能体编程所产生的代码。
我一直说，LLM AI 一个很值得期待且现在已部分落地的好处，就是把软件工程的最佳实践低成本的落地。
比如大家都听说过 Git 等版本管理工具的一大好处就是能做版本管理✍🏻✍🏻✍🏻
这个是什么意思呢？在个人开发的环境下并不凸显。但是换到 AGENT 加持下的开发速度甚至 AGENT 自驱开发，这就很重要了。
一方面你可以真的放手让 AGENT 干，只要是无状态的应用或者外部状态额外保护，随时干爆了都可以恢复到上一个工作的版本重来，不至于出现严重的服务不可用。
另一方面是很多迭代的历史可以记录下来，我时常让 AGENT 从（别的）项目的历史里翻找一个决议或者实验结果。
这些最佳实践一直都有，甚至工具一直都有，但是实际有几个人跑过 git bisect 呢？
跟引用推文的关系在于，要想适应 AGENT 的速度，你需要这些实践经验和趁手工具，不然效率不足。完全放开也区分你是有信心的放开，还是不管了赌一把吧。
顯示更多
此前我一直觉得 AI 不行，就是 AI 会犯一些人来做不会犯的错误，结果我给 AI 纠错的时间超过我自己写的时间。
现在大部分情况下 AI 只会在我自己没想好的地方犯错，成本天平突破某种临界点了。当然也跟我在这期间跟 AI 对话学习了很多具体的领域知识，更多知道自己要干嘛有关。
顯示更多
数据库领域有一篇经典的博文叫 MapReduce: A major step backwards，核心观点在于索引、查询优化和数据库管理是有用的，今天丢掉未来还是要捡回来，事实也是如此。
编译器也类似。直接生成二进制，token 成本首先就成问题，其次写代码不只是为了得到二进制，更是多年来对业务建模的一套模式语言。
顯示更多
还有最近另外一个事，就又被重新提起来，说你不 review 编译器的输出，所以你也不应该 review AI 的输出。
这个有另外一个反论的论点，就是你不 review 编译器的输出，其实你二进制是不会 check in 到你的版本管理系统里面的，你就 check in 代码，因为你只要 review 代码，你就不需要 review 二进制，它大体是可控的。当然我知道编译器没有那么确定性。
但是你如果说你不用 review AI 的输出，那它的输入是什么呢？它是你随便说的一句话吗？你把这个 Chat 都丢进去，我就不说能不能确定性的生成相同的内容了。你连让 AI 生成这些东西的什么 Chat 复现的方式，哪怕有百分之多少的一样的东西复现的方式都没有，那你说个啥呢？
顯示更多
文章没有直接提及，但是挺重要的一点是，我现在之所以能够图文并茂娓娓道来这些故事，正是因为开源工作都公开可审计。
写作本文的时候，很多故事细节我其实早就记不清了。但是凭借关键词 + AI，我都能找到当年的案发现场，把整个故事还原出来再讲一遍。
这或许也是开发者都喜欢做开源工作的原因吧。
顯示更多
我好像有点懂了，那些说自己现在不看代码的人，他们其实原本就是软件的消费者，他们本不应该成为生产者。
我为什么会有前两条推那种感受？因为我在做的是框架、工具库或者基础服务。对我来讲，交付软件本身就是目标，所有软件工程的事也仍然存在。
但有些人他纯粹就是要实现业务逻辑的，对他来讲，能不写代码实现业务逻辑就最好。选型哪个框架跟他也没关系，他本来就不应该写代码，是低代码的受众。对他来讲，不用写代码就是一种优化。这好像也合理。
顯示更多
我对“不看代码”这个事情，尤其是震惊体，一直很疑惑。
1. 手写代码的目的是为了实现特定逻辑，或说让软件呈现出特定的形态。没有 IDE 补全还得一个一个字母敲咯，理想情况当然就是想到哪直接就实现到哪，不用动手。
2. 读代码的目的是理解现有逻辑和设计，看看新的设计实现怎么做比较好。
3. Review 也是方向正确就差不多，不要有硬伤就风格任选。你总不是 blind apply，以前主要是写逻辑就写累了，不想写测试或者 bench，现在 AI 写 report 不会累，review 起来更高效就用咯，反复出现的问题再单独看一下。
难道不是一直都是这样的吗？
顯示更多
我现在基本可以确定有一帮码奸，明明偷偷在古法编程修订项目/模块的框架和给 AI 收拾残局避免熵增，却在社交媒体上装模作样说很久没看过代码或者全都是 AI 做的。
哪怕是大规模的 Rust 重写或者全力蹬 Agent 写成的项目，没人监督分分钟冲向外太空。没有例外。
顯示更多
