开发者 Fynn 在 2026 年 3 月 20 日调试 Cursor 的 OpenAI 兼容接口时，返回的模型 ID 为 accounts/anysphere/models/kimi-k2p5-rl-0317-s515-fast，显示 Composer 2 基于 Moonshot AI 的 Kimi K2.5 做强化学习后训练，该推文一天内获得 44.4 万次浏览。
推荐理由：从一次 API 调试串起 Cursor 未披露 Kimi 基座、许可署名争议与中美模型成本格局，呈现行业披露惯例。
Armin Ronacher 用 GPT 6 Astra 跑了一个周末的软件工厂实验，让模型自行管理上下文和子智能体，目标是实现带虚拟线程和词法作用域的 Python。
推荐理由：作者用 35 小时无人值守的软件工厂实验，展示 GPT 6 Astra 为 token 效率牺牲代码可读性的具体证据。
作者 Ryan Lopopolo 提出，智能体是一组能力之上的参数化程序，这些能力包括模型与配置、推理与工具调用循环、计算机、磁盘、上下文、Skills、工具、连接器、运行时、网络策略、身份、IAM、护栏、I/O 通道和系统提示词。
推荐理由：作者用自己构建多个智能体的经历，提出把能力接口与实现解耦的平台架构思路，可供做 Agent 平台的团队参考。
作者提出用 agent 会话记录衡量一次工程决策的下游影响，即 blast radius（影响范围），并用自家 tapes 项目的一次架构决策做验证：设计文档会话花费 57.05 美元，后续引发 4704.74 美元工作量，分布在 70 个人工会话、3 名工程师、8 个仓库和 27 天中，另有 404 个自动化评测会话花费 431.54 美元。
推荐理由：作者用自家一次架构决策的 474 条会话记录，展示如何把决策的下游成本量化成可复用的指标。
Martin Fowler 用 Sonnet 4.6 生成、Opus 4.8 盲评的方式，对小型、中型和较大型三类业务逻辑任务分别跑 TDD 与非 TDD 方案，结论是两者质量没有明显差异，非 TDD 方案在设计和测试质量上还多次略高，变异分数也没有实质差别。
推荐理由：作者用同一批任务对比 TDD 与非 TDD 智能体实现，给出 token 成本与设计质量差异，并反思哪些 TDD 收益在智能体循环里失效。
Augment Code 提出循环工程，即设计从触发、执行、验证到完成结果的智能体循环，让智能体承担中间环节、人类只在需要判断的检查点介入。文章把循环工程与提示词工程、上下文工程分层对比，并给出触发、执行、验证、结果、改进五个阶段，以及代码评审、工单转 PR、漏洞修复、事故响应四种已在生产运行的团队级循环。
推荐理由：Augment Code 把循环工程拆成触发、执行、验证、结果、改进五阶段，并给出四种已在生产运行的团队级循环形态。
Addy Osmani 提出软件工厂由 loop、harness、factory 三层构成，工厂不是更聪明的智能体，而是多个带 harness 的 loop 汇入一个评审门禁、由人掌控外层循环。
推荐理由：作者把软件工厂拆成 loop、harness、factory 三层，并指出验证而非生成才是真正的瓶颈。
作者以在 Stripe 参与首次 code yellow 的经历为例，指出多数 code red 结束后只留下复盘和疲惫的工程师，指标重新无人维护。他认为 code red 应留下一个维护循环，并可用 OpenAI Codex 的 /goal 命令把一次性编码请求变成带明确完成标准的持续目标，让持久化智能体集群持续观察指标、生成干预并请求人工审核。
推荐理由：作者结合 Stripe code yellow 经历，提出用 Codex 的 /goal 把一次性抢修变成长期维护循环，可迁移到 SLO 治理。
Augment Code 调研了 219 位工程负责人，发现其团队约 48% 的代码由 AI 生成，55% 担心团队对代码库失去共同理解，63% 表示工程师向管理者提出了技能相关性方面的担忧，在 201-1000 人规模的团队中这一比例升至 89%。
推荐理由：219 位工程负责人的调研数据揭示了 AI 原生开发中代码评审、技能焦虑与角色定义之间的落差。
Anthropic 的 Claude Code 创建者 Boris Cherny 在红杉 AI Ascent 访谈中称，他整个 2026 年没写过一行代码，每天合并几十个 PR，单日记录 150 个，工作大多从手机完成，常驻 5 到 10 个 session、几百个 Agent，夜里还有几千个在跑深度任务。
推荐理由：Boris Cherny 复盘 Claude Code 从孵化到十亿美元营收的路径，并给出编程被解决、SaaS 护城河被抹平、组织流程才是领先点等判断。
Ryan Lopopolo 认为，AI 让验证问题变得明显，因为每个真实任务都依赖一个我们几乎从不写下来的问题，即怎样才算把活干好。产出和评审都涉及语气、品味、风险容忍度、打磨程度、可接受的捷径和完成标准等大量非功能性决策，过去团队靠组织设计、社交规范、招聘和入职把这些隐含规则传递给人，而模型无法走招聘流程，因此交给它的任务基本都欠规范。
推荐理由：作者以在 OpenAI 做代码智能体的经历说明，非功能性需求不写下来，评审智能体就会陷入无休止的拉扯。
Ryan Lopopolo 以 Symphony 为例提出，代码不应被视为最终产物，规范才是分发物。Symphony 是一个基于 issue tracker 的智能体编排系统，先以 SPEC.md 形式分发，Elixir 参考实现只是衍生产物，README 邀请读者把 SPEC.md 交给自己的编码智能体，用任意语言重建。
推荐理由：作者用 Symphony 的 spec 蒸馏循环说明代码只是可替换产物，为规范驱动开发提供了一条可迁移的路径。
作者认为，软件组织一直把人的实现时间当作稀缺投入，智能体打破了这个假设，因此策略必须可执行、验证必须随实现规模扩展。他以在大型 TypeScript 代码库开启 ESLint 的 no-await-in-loop 规则为例，发现 600 处违规，过去这需要昂贵的迁移，现在一个 PR 就能完成修复并补齐测试覆盖。
推荐理由：作者以开启 ESLint 规则、迁移 600 处违规的亲身实践，说明智能体时代实现成本下降后，约束与验证为何成为新的稀缺环节。
Anthropic 红队研究显示 Claude Opus 4.6 能在 GhostScript、OpenSC 等成熟开源项目中找出 500 多个高危漏洞，其中一些已潜伏数十年。
推荐理由：作者用自己复现的 RCE 案例说明，AI 找漏洞的成本骤降后，无人维护的软件才是真正的风险面。
Jesse Vincent 提出 Latent Space Engineering，即通过提示词把模型推入更有利于完成任务的潜在空间，而非只往上下文窗口塞事实信息。
推荐理由：作者提出用情绪化提示词把模型推入更佳状态，并给出多个可迁移的实操例子。
Martin Fowler 试用 Kiro、spec-kit 和 Tessl 三款自称实现 spec-driven development（SDD）的工具，把 SDD 归纳为 spec-first、spec-anchored、spec-as-source 三个层次，并指出目前所有方案都停留在 spec-first。
推荐理由：作者亲手试用 Kiro、spec-kit 和 Tessl 三款 SDD 工具，给出 spec-first、spec-anchored、spec-as-source 三层划分，并指出小任务被过度规格化的问题。