/tags/agentic/ Recent content in agentic 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/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 辅助开发」是一个被严重过载的词。要把后面的讨论建立在共同语境上，先把两种使用模式区分清楚。