一位 Rust 开发者为什么仍然害怕用 AI 写代码

Rust 开发者 NikTimf 在 Habr 撰文说，自己仍然害怕用 AI 写代码，原因不是生成质量差，而是生成量太大、后续没人真正看懂。他列举了具体代价：多个智能体之间要反复传递上下文，答案冲突时还得自己判断谁对；公司只允许本地或自研模型时，用惯强模型的人很难退回；同事充当 meat proxy 转发 AI 答案，理解任务和推进实现的活仍落在自己身上。

Ожидает перевода

Sebastian Raschka@rasbtОценка ИИ3636

Sebastian Raschka 用 Paint UI 复刻同一张图，对比 GPT-5.6 Astra 与 Qwen3.8 Max 的计算机使用（视觉）能力：Astra 默认用几何图形分层绘制，Qwen 则逐像素还原，后者结果天然更接近原图、得分会更高。但他认为不能据此断定 Qwen 的计算机使用或视觉理解更强，这恰恰说明只看最终结果的 benchmark 有多不可靠。

Ожидает перевода

Boris Cherny：Claude 写的生产代码应有比人类更高的门槛

Anthropic 的 Boris Cherny 表示，Claude 编写的生产代码应比人类编写的代码有更高门槛。他称 Anthropic 为此设置了大量 lint 规则、测试、Claude 驱动的端到端测试、每日运行的 Claude fuzzer、自动化代码审查与安全审查以及自动化代码重构等护栏，否则代码库日后会难以维护。

Ожидает перевода

Thorsten Ball 谈 AI 写代码：是代码真的差，还是评审者的“天真干预”偏见

Thorsten Ball 在 Register Spill 的 Joy & Curiosity #98 中借用《反脆弱》里的扁桃体切除研究，提出工程师对 Sol、Fable、Astra 等模型输出的“代码差、注释蠢”评价，可能源于“天真干预主义”偏见——AI 已在 20 分钟内端到端完成前后端改动、内外部文档和测试，并在无头浏览器中跑完全流程、附上录屏为证。

Ожидает перевода

过早的错误处理暴露了 Agent 把功能建错了顺序

作者在评审数千个编码 Agent 的改动后发现，过早加入 rescue 块、兜底逻辑和日志，往往说明功能构建顺序错了。Agent 倾向横向铺开数据库、服务、API、校验和 UI，提前设想完整系统，这与 SWE-bench 只衡量补丁能否解决限定问题并通过测试的评估方式相符。

Ожидает перевода

Joy & Curiosity #92：Amp 推出订阅与智能体间通信

Amp 现已推出订阅服务，可与 ChatGPT 订阅搭配获得无限 GPT-5.6 token；同时 Amp 上线智能体间通信，智能体能在任意 Amp 实例或 orb 中派生其他智能体并互发消息与文件。作者还分享了新一季 Raising An Agent 播客、与 Evan Phoenix 等人的对谈，以及 antirez 关于“控制想法而非代码”的观点。

Ожидает перевода

Agent 写出的 Pull Request 比人类更好

作者评审了一个 Agent 提交的 Pull Request，认为它又快又好，原因不在模型有多聪明，而在于质量门槛被写进了循环内部。这个 PR 在请求人工介入前就说明了改动了什么、刻意没动什么、该重点审查哪里、遵循了哪些规范，并附上了已运行的验证证据。作者由此提出，给 Agent 一个明确的完成定义和必须自证的标准，它就会为通过标准而优化，速度不是靠降低门槛换来的。

Ожидает перевода

结对编程能否解决 AI 代码 PR 审查瓶颈？

结对编程被一些团队用来把同行评审嵌入开发过程，让评审在工作进行时完成，从而缓解 AI 辅助交付带来的 PR 审查瓶颈。其机制在于评审信心产生于编码过程中，而非事后检查；AI 智能体产出代码更快更多，若判断全部堆到 PR 阶段，瓶颈只会加剧。应对之策是把标准、质疑和判断前移到工作本身，让证据随 PR 一起到达。

Ожидает перевода

你的 AI 代码审查工具来得太晚了

让 AI 智能体先写代码、再用 CodeRabbit、Greptile 这类审查工具事后清理，可能已经太晚：等审查工具看到 PR 时，智能体早已定下实现形态、假设和测试策略。昂贵的错误通常发生在 PR 之前，比如误读系统、切片过大或沿用错误模式，事后打磨无法纠正方向。审查工具应作为检查环节而非交付模式，把结果、约束、验收标准和验证前置到工作流程中。

Ожидает перевода

AI 代码评审：别再增加评审者，先修好输入

Johnny Butler 转述 Google 云 AI 总监 Addy Osmani 的观点，认为 AI 代码评审的出路不是增加评审者，而是让代码在进入评审前就值得评审。

Ожидает перевода

Software Dark Factory：让治理适配 AI 辅助开发流程

Software Dark Factory（SDF）提出治理应适配开发流程而非接管流程，目标是让 AI 辅助产出的改动仍以可识别的 PR 形式接受审查，并让证据随手可得。SDF 正围绕一个实际运营问题做 dogfooding：从一个小型受治理改动到可审查的 draft PR 能有多快，同时保持证据齐备、审查体验正常。作者强调要的是可控的速度，而非为流程而流程或事后补上的合规包装。

Ожидает перевода

我绝不会为了智能体速度放弃二十年的交付实践

面对 AI 编程智能体带来的提速压力，作者认为更快的代码生成不等于更快的软件交付，意图、验收标准、风险边界、验证、证据与评审等交付纪律不可让步。智能体只有在既有工作流内运作才能参与其中，工作越交给智能体，可评审性就越重要。这是 Software Dark Factory 背后的核心理念：智能体应强化而非取代经过验证的交付实践。

Ожидает перевода

Vibe coding 是原型方法，不是交付流程

作者 Aldrin 认为 vibe coding 适合用自然语言做低成本探索，比如脚手架、陌生 API、UI 变体和测试思路，但快速可见的草稿不等于功能可以被团队接手。

Ожидает перевода

智能体时代的生产函数变了：实现不再稀缺，验证才是

作者认为，软件组织一直把人的实现时间当作稀缺投入，智能体打破了这个假设，因此策略必须可执行、验证必须随实现规模扩展。他以在大型 TypeScript 代码库开启 ESLint 的 no-await-in-loop 规则为例，发现 600 处违规，过去这需要昂贵的迁移，现在一个 PR 就能完成修复并补齐测试覆盖。

Ожидает перевода

Greptile 谈 AI 代码审查泡沫：审查智能体应与编码智能体相互独立

AI 代码审查工具已泛滥成灾，OpenAI、Anthropic、Cursor、Augment、Cognition 乃至 Linear 纷纷入局，Greptile、CodeRabbit、Macroscope 等纯审查智能体同台竞争。

Ожидает перевода

Harper Reed：AI 编程让瀑布模型变成 15 分钟一轮

Harper Reed 认为 AI 代码生成正把开发推向"15 分钟瀑布"：先写清规格、让模型生成、再审查，并可同时跑多个智能体分别写功能、文档和测试。他建议团队先用低风险内部项目做小范围试点、轮换成员参与，并把规格和架构文档沉淀到共享仓库。他还提醒 AI 容易过度测试基础逻辑，需频繁提交以便回滚。

Ожидает перевода

AI 代码审查工具为何没解决你的真问题：作者工具与审查者工具的错位

Vibinex 创始人指出，团队采购 CodeRabbit、CodeAnt、Greptile、Ellipsis 等 AI 代码审查工具，主要优化的是作者写代码的质量，而非减少审查者逐行读代码的时间。审查者仍需自行理解改动、识别业务逻辑与架构影响，原有流程一步没少。作者工具与审查者工具应互补，而非互相替代。

Ожидает перевода

用三个 median 函数看 GitHub Copilot 辅助编码的能与不能

Martin Fowler 用 GitHub Copilot 生成 TypeScript 的 median 函数，Copilot 给出三个实现：第一个会修改输入数组，第二个用 slice() 复制后正确，第三个因忽略偶数长度而错误。他还让 Copilot Chat 先生成测试，测试覆盖了奇偶长度、负数与重复值，并让 ChatGPT 指出第三个实现的问题。

Ожидает перевода