一句不太合时宜的话
在 AI 编程工具被广泛采用的当下，公开表达「不用 AI 写代码」需要一点底气。Kotlin 创始人 Andrey Breslav 在近期一次访谈里说了这句话，并且给出了更进一步的判断：AI 会让工程师变成可替换的齿轮。他还提到，宁愿放弃相当大比例的就业机会，也不打算用 AI 来写代码。
这类表态容易被简化成「技术保守派对 AI 的抵触」，然后被迅速归档。但如果把访谈里相关的具体议题抽出来看，会发现它们并不都指向同一个立场，有些甚至是行业已经遇到的现实问题。
他真正说的几件事
其中一件与语言治理有关。访谈里讨论了一个问题：一位创始人投入多年把项目做起来之后离开，语言还能不能继续演进。回答是成功的语言必须能够超越它的创始人。Kotlin 在创始人离开后完成了交接，过程基本没有变成危机，这被归因于它周围已经建立起相对健康的组织体系。
第二件与治理结构有关。当前多数大型编程语言不再由单一决策者定方向，而是由共享的组织结构治理，并与社区共同推进。以 Kotlin 为例，理想状态是基金会、主要采用方与开发者社区三方共同参与，避免任何一家公司单独控制。这个安排背后有具体原因：采用方此前经历过采用由另一家公司控制的技术、随后陷入长期诉讼的情况，因此在正式采用时无法接受这门语言完全由外部掌控。
第三件与开源的负担有关。访谈里提到，开源能带来社区贡献，缺陷与功能会由更多人改进，也能展示工程文化、帮助吸引人才。但维护者同时要面对不友善的问题反馈、偏离项目方向的需求、语言沟通障碍，以及大量低质量的 AI 生成合并请求。结论是开源并不适合所有工程师，也不应成为强制要求；公司也不该为了塑造形象而强迫团队开源。
这三件事与「用不用 AI 写代码」并不是同一层面的问题，但它们共同指向一个判断：当生成代码的成本大幅下降之后，成本会转移到别的位置——审查、维护、治理与判断。
低质量 AI 生成请求为何成为负担
第三件事值得单独展开，因为它是可以观察到的现实。
对一个活跃开源项目来说，合并请求的处理是有成本的。维护者需要理解改动的动机、判断是否符合项目方向、检查边界条件、验证是否破坏兼容性、补充测试与文档。当提交量因为生成成本下降而上升时，这个环节会首先承压。
麻烦在于，低质量的生成式改动往往具备「看起来合理」的外观：代码风格正确、注释完整、结构清晰，但可能误解了需求、忽略了项目的历史决策，或者解决了一个并不存在的问题。这类改动比明显的错误代码更难处理，因为它需要维护者投入与写代码相当的时间去判断。
从项目治理的角度看，这意味着引入生成式工具的同时，需要配套调整提交规范：提高进入门槛、要求说明动机与验证方式、对明显批量生成的内容单独处理。这些措施并不浪漫，但它们是维持项目可维护性的必要条件。
「齿轮」这个比喻指向什么
把工程师比作可替换的齿轮，这个说法之所以引起讨论，是因为它触及了分工问题。
支持 AI 编程的常见论点是：重复性、低创造性的编码劳动被自动化之后，工程师可以转向更有价值的工作，例如理解业务、定义问题、设计架构与验收质量。这套叙事在逻辑上成立，但它依赖一个前提——组织真的会把释放出来的时间用于更高层次的工作，而不是用它来压缩人力。
现实中的变量在于，这两条路径在短期内都可行。企业可以选择用同样的人做更多的事，也可以选择用更少的人做同样的事。哪一种成为主流，取决于市场结构、竞争压力与管理选择，而不是取决于工具本身的能力。Breslav 的表态正是把这个变量摆到了台面上。
另一层含义与「可替换」有关。当一个人的核心产出是代码行数时，他的确更容易被替换。当核心产出是对问题的定义、对取舍的判断与对结果的负责时，替代难度会上升。这个差别并不新，但生成式工具把它放大了——因为前者被压缩得很快，后者的价值反而更容易被看清。
中立思辨
需要辩证看待几件事。其一，「不用 AI 写代码」是一种个人选择，把它推广成行业规范并不合适。同一位开发者在不同场景下的判断可能不同：写原型、写脚本、写一次性数据处理，与维护一个长期演进的库，对代码质量的要求并不一样。
其二，把 AI 带来的变化整体描述为「工程师变成齿轮」过于单向。同一批工具也在降低个体开发者的门槛，让一个人可以完成此前需要团队协作的工作。这两种效应同时存在，只是分布在不同人群与不同岗位上。
其三，语言治理与 AI 编程是两个议题，放在同一段访谈里容易产生混淆。前者讨论的是组织如何避免对个人的依赖，后者讨论的是个体如何使用工具。把两者合并成「技术领袖反对 AI」的结论，会丢失访谈里真正有价值的部分。
其四，低质量生成式提交是真实问题，但把它当成否定工具的理由并不成立。更合理的应对是调整流程：明确提交门槛、要求动机说明、对生成内容做标注、加强自动化检查。工具带来的问题通常需要用流程解决，而不是靠禁用工具。
其五，这类表态本身也有传播属性。强烈立场更容易获得关注，而访谈中的具体论证往往被忽略。读者在引用观点时，值得回到原始材料确认上下文。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
给工程团队的三条做法
把这场分歧拆成可执行的准备，有三条。
把提交门槛写清楚。明确要求每笔改动说明动机、影响范围与验证方式，无论是否由生成式工具产出。这条规则对人工提交同样有效，且能显著降低审查成本。
区分场景设置工具策略。原型、内部脚本与长期维护的核心库，对可读性、测试覆盖与兼容性的要求不同。用一套策略覆盖所有场景，通常会在这两端都做出错误取舍。
把「定义问题」变成可考核的能力。如果团队希望成员从事更高层次的工作，就需要在职责与评价上体现出来。只强调产出速度的考核体系，会把释放出来的时间重新填回代码量。