Dev Tooling Assumptions Reset

传统开发工具的构建基于一些已不再成立的假设：代码由人类投入精力、凭借专业知识编写，变更稀缺且具备价值，线性工作流具备合理性。当Agent编写90%的代码时，这些工具就会形成瓶颈并产生阻滞。

从第一性原理重新审视开发工具的假设

当Agent编写大部分代码时，变更的感知价值会大幅下降，原本为人力优化的工作流将变得低效。

核心洞察

“我们现有的很多开发工具都不再适用，因为这些工具的设计基于一个核心假设：代码由人类编写，人类为某段代码投入了大量精力、时间和专业知识。”

graph TD
    subgraph Old_Assumptions["旧有假设"]
        A1[人类编写代码]
        A2[代码稀缺/高价值]
        A3[开发者时间紧张]
        A4[变更具有永久性]
    end

    subgraph New_Reality["新现实"]
        B1[Agent编写代码]
        B2[代码充裕/低成本]
        B3[Agent数量无上限]
        B4[变体生成成本极低]
    end

    A1 --> C[线性工单]
    A2 --> D[PR评审 + 表情响应]
    A3 --> E[迭代规划]
    A4 --> F[分支策略]

    B1 --> G[立即派遣Agent]
    B2 --> H[生成10种变体]
    B3 --> I[并行调查]
    B4 --> J[原始候选池]

    style C fill:#ffcdd2,stroke:#c62828
    style D fill:#ffcdd2,stroke:#c62828
    style E fill:#ffcdd2,stroke:#c62828
    style F fill:#ffcdd2,stroke:#c62828
    style G fill:#c8e6c9,stroke:#2e7d32
    style H fill:#c8e6c9,stroke:#2e7d32
    style I fill:#c8e6c9,stroke:#2e7d32
    style J fill:#c8e6c9,stroke:#2e7d32

工单场景示例

旧模式（人类编写代码）：

1. 收到Bug报告
2. 开发者手头繁忙，正在处理其他任务
3. 创建工单，排入下一个迭代周期
4. 下周分配该工单
5. 开发者熟悉业务上下文、搭建开发环境
6. 开发者完成Bug修复

新模式（Agent编写代码）：

1. 收到Bug报告
2. 立即派遣Agent开展调查
3. Agent完成诊断与修复的时间，与创建一张工单的耗时相当

“在人类编写代码的模式下，开发者需要熟悉上下文、搭建环境、切换分支等一系列操作，所以你会采用线性工单流程——毕竟开发者时间紧张。但如今你拥有能无限调用的Agent来排查代码，为什么不在创建工单前就立刻派遣Agent呢？”

代码评审场景示例

GitHub的功能设计基于“变更具有高价值”的假设：

• 表情响应（❤️ 😃）
• 指定评审人
• 合并前的审慎评估

但当Agent编写90%的代码时：

“单一变更的感知价值会完全不同，因为你可以直接对Agent说：‘你完全错了。让你的Agent伙伴启动另一个任务链，生成10种不同的变体。’”

审计工具中的过时假设

| 工具特性 | 旧假设 | 新现实 | 调整措施 | |----------|--------|--------|----------| | 线性工单（Linear tickets） | 开发人员任务繁忙，工作需排队等待 | Agent数量无限制 | 立即派发任务，无需创建工单 | | PR 评审（PR reviews） | 人工会谨慎处理代码变更 | 代码变更成本极低 | 经测试后自动合并 | | 表情符号互动（Emoji reactions） | 围绕代码建立社交联结 | 代码已成为标准化商品 | 移除功能或重新定位用途 | | 分支管理（Branching） | 需谨慎隔离代码分支 | 可并行生成多版本代码 | 直接合并到主干或使用功能开关（feature flags） | | 代码归属（Code ownership） | 由人工负责维护特定代码区域 | Agent掌握全量代码信息 | 动态归属机制 | | 迭代规划（Sprint planning） | 人工处理能力存在上限 | Agent可无限横向扩展 | 持续交付流 |

新工具设计原则

1. 即时执行：无需让任务排队，立即生成Agent启动执行
2. 多版本生成：生成10个代码版本，择优选用
3. 自动化验证：以测试替代人工评审为核心
4. 直接集成：减少人工交接环节，强化自动化流程覆盖
5. 可观测执行：实时监控Agent的操作状态，无需审批每一步动作

“原始汤”隐喻

当Agent持续生成代码时，你面对的不再是一个个独立的代码变更——而是由各类代码变体构成的、不断“沸腾演化”的代码生态系统：

“奎因，用你的话来说，就像Agent与代码构成的‘原始汤’，始终在沸腾、演化、生成新代码……我认为现有的工具完全无法满足这种场景的需求。”

这要求我们建立全新的思维模型与交互界面：

• 摒弃线性工单，采用持续流转的任务流
• 告别PR评审，搭建自动化质量关卡
• 替代迭代规划，实施实时优先级调度
• 打破固定代码归属，采用动态归因机制

优点：

• 消除瓶颈：无需等待人工有空处理
• 迭代速度更快：Agent可即刻开展调研
• 探索能力更强：可并行生成多种解决方案
• 流程更简化：变更相关的管理开销更少
• 可扩展性更佳：Agent使用量增长时表现更优

缺点：

• 可见性缺失：难以追踪实际运行状况
• 集成难度大：现有工具无法适配新模式
• 团队抵触情绪：开发人员习惯于原有工作流程
• 新增风险：自动化程度提升意味着影响范围扩大
• 过渡阵痛：人机混合工作流操作繁琐

重置假设的时机：

• Agent编写的代码占比过半（50%以上）
• 团队能熟练使用自主Agent
• 代码库具备完善的自动化测试体系
• 能够容忍实验与试错
• 领导层全力支持全新工作模式

需从旧工具中保留的核心特性：

• 责任可追溯：记录谁发起了什么请求
• 变更可溯源：明确为何进行本次变更
• 质量标准：测试、代码静态检查（linting）
• 安全管控：访问控制、敏感变更审批机制
• 经验沉淀：事后复盘、文档记录