/tags/ai-coding/ Recent content in ai-coding on Hugo -- gohugo.io en Tue, 02 Jun 2026 15:00:00 +0800 /reading/google/software-engineering-at-the-tipping-point/ Tue, 02 Jun 2026 15:00:00 +0800 /reading/google/software-engineering-at-the-tipping-point/ Google I/O 2026 上 Adam Bender（Google Principal Software Engineer，长期做 Google 内部开发者基础设施）的一场 talk：Software engineering at the tipping point。核心命题一句话——当 AI 把软件产量推到 10x、100x，今天这套造软件、发软件的基础设施吸收不了这个增量，一定会在某处崩掉。 主张：当下这套，撑不到 10x Bender 的判断是：AI 正在把"软件产出可能放大一个数量级"从思想实验推到现实问题，而现有的构建、测试、版本控制、评审、安全这套基础设施很可能吸收不了这个增量。他的原话： I would bet very good money what we’re doing today doesn’t work at 10x. 他把它定性成 “code-red moment”——不是思想实验，是逼到眼前的现实： Suddenly the measure of 10x growth is not just a thought exercise. It’s a code-red moment for you and your company. You’ll have to figure this out. If not today, certainly within the next 12 months. /reading/affirm/agentic-retooling-week/ Tue, 02 Jun 2026 09:00:00 +0800 /reading/affirm/agentic-retooling-week/ Affirm 工程效能高级总监 Daniel Martin 在 Affirm Tech Blog 复盘了他们如何用一周——内部称 AI Retooling Week——把一个 800 人的工程组织整体推上 agentic 工作流，从需求到提交 PR 全程跑通。核心问题：当已经有几十个工程师被 agentic 工具彻底改变工作方式、并和其余 800 人快速拉开差距时，怎么把这套方式规模化到整个组织。 出发点：差距正在拉大，不能慢慢来 到 2025 年 12 月，Affirm 已经有 80% 以上的工程师每周在用某种 AI 辅助工具。但真正让他们下决心的是另一件事：随着 Anthropic Opus 4.5 这类模型把"搜代码 → 规划 → 写代码 → 跑测试 → 自己修"这条链路打通，已经有几十个工程师在用 agentic 工具，并且工作方式被彻底改变了—— 那几十个用得很好的人，和剩下 800 个人之间的差距，正在快速拉大。 他们选择"集中一周"而不是"慢慢铺开"，本质是一个 forcing function（倒逼机制）：靠自愿、靠"有空就试试"很难迈过那道坎。1 月中旬公司总裁发了一封全员信，把 agentic 开发定为"今后怎么造软件的核心方式"，并定下 AI Retooling Week 的日期：那一周暂停所有非必要会议、推迟交付日期，要求每个工程师和经理都跑通一条完整的 agentic 工作流——从需求到提交 PR。 一周之前：九个人先把"地基"打好 Retooling Week 之前，他们组了一个九人工作组，任务很明确：两周内产出一条可复制的 agentic 工作流，让普通工程师不需要专家知识、不需要定制配置就能自动化掉大部分编码工作。 这个工作组定了三个决定，后面所有事情都建立在这三条上： /posts/keeping-features-out-ai-era-2026/ Sat, 23 May 2026 23:30:00 +0800 /posts/keeping-features-out-ai-era-2026/ 背景：一篇 InfoWorld 的文章让我想起的事 刚看完 Nick Hodges 在 InfoWorld 上 2026-04-29 发的 A new challenge for software product managers。文章不长，核心就一句话： It used to be the hard part was jamming in that extra feature. Now? The hard part will be keeping them out. 作者的论点是给 PM 的：以前 PM 要争时间、争资源把 feature “塞"进版本，现在 agentic AI 让一个 feature “morning conceived, afternoon shipped”——backlog 这个本来给 due diligence 留缓冲的东西也跟着塌缩了，PM 的难点从"怎么加"反转成了"怎么挡”。 但我读的时候一直在想另一件事：这件事不只是 PM 的难题，工程师其实是被同一股压力波及的，而且我们过去赖以否决 feature 的最强武器，正好就是被 AI 拆掉的那个。 这篇是顺手写的延伸笔记，把 Hodges 那个反转放进工程师这一侧再看一遍。不是反驳——我同意他的判断——只是想说，“挡 feature"这个新责任如果只压在 PM 身上，通常挡不住。 /reading/martinfowler/structured-prompt-driven-spdd/ Thu, 21 May 2026 22:00:00 +0800 /reading/martinfowler/structured-prompt-driven-spdd/ Wei Zhang 和 Jessie Jie Xia（两位都来自 Thoughtworks）2026-04-28 在 Martin Fowler 网站发表了 Structured Prompt-Driven Development。核心主张比较干脆：把 prompt 当成与代码同级的工程工件管理——版本化、评审、复用、迭代。这条主张不新，但作者把它具体化成了一组流程、一份七维度模板（REASONS Canvas）和一套配套 CLI（gszhangwei/open-spdd），外加一个完整示例项目（gszhangwei/token-billing）。 SPDD 与 PDD、Spec Kit、PromptOps 这些相邻概念的差别，另起了一篇速写：prompt-driven vs spec-driven：把 PDD、SPDD、Spec Kit 几支理清楚。本文只聚焦 SPDD 这一篇文章本身。 文章主张：prompt 是一级交付物 文章开头给的一句话很直接： Instead of relying on ad hoc chats, SPDD turns prompts into assets that can be: version controlled, reviewed, reused, and improved over time. 这句话把 SPDD 和临时 chat 式交互区分开来：prompt 不只是一次性输入，而是可以被版本化、评审、复用和持续改进的资产。SPDD 想解决的问题文章写得很具体： 模糊的需求被快速翻译成代码，误解随之扩散 评审里要处理的改动越来越多 集成 / 测试问题增加 难以推理生产风险 它给出的答案是：把"意图"从 chat 历史里拎出来，写成可追溯的工件。 /posts/agentic-workflow-engineering-2026/ Sun, 26 Apr 2026 15:30:00 +0800 /posts/agentic-workflow-engineering-2026/ 背景 最近几个月我翻了几份团队内部和合作方写的「AI 辅助开发流程」文档，也在不同项目里反复用了 Claude Code、Codex CLI、Cursor。到目前为止，一个让我印象比较深的现象是：在我接触到的不少团队里，「AI 辅助」仍然更接近 2024 年常见的"对话框 + 复制粘贴"模式——人手动把 PRD、Tech Design 模板、代码上下文一次次拷进 Prompt 框，AI 输出一段文本，人再贴回 Confluence 或 IDE。 而同期一些更早公开分享这类实践的团队，做法已经不太一样： Anthropic 的公开文章展示了多个团队如何把 Claude Code 用到 code review、排障、代码导航等具体场景里（原文）。 Rakuten 的案例文章给出了一组公开数据：TTM 从 24 个工作日降到 5 天，最长一次连续自主编码 7 小时；这些数字来自其官方案例分享，更适合当作参考样本，而不是直接当成通用基线（原文）。 Bessemer Atlas 对 Shopify 工程负责人的采访提到，Shopify 允许 Claude Code、Copilot、Cursor、Codex、Gemini 等工具并存，并用自建 LLM Proxy 做统一接入与治理；这更像一次访谈里的组织实践样本，而不是完整方法论（原文）。 我理解这两种使用方式之间的差距，未必只在于"AI 用得熟不熟"，更像是软件开发流程的工程化程度——前者很多时候还得靠人脑当编排引擎，后者则开始把一部分编排交给 agent，把一部分规则交给 ArchUnit / Hooks / GitHub App。 这篇文章不打算给一份"最佳实践"。模型能力、工具协议、商业模式都在快速演化（Claude 4.x、MCP、AGENTS.md、Spec Kit 都是 2024 下半年到 2026 年 4 月前后仍在快速变化的东西），太早收敛到"标准答案"反而可能束缚团队。我更想做的是：把现实项目里的困惑和当下能看到的公开实践对齐，整理一份自己后续继续学习和落地时会反复回看的方向清单。 后续落地的细节会另起一篇，先把方向理清。 Agentic 与「贴 Prompt」的真实差距 「AI 辅助开发」是一个被严重过载的词。要把后面的讨论建立在共同语境上，先把两种使用模式区分清楚。