自2025年8月以来，超过一半进入Ashby生产系统的新代码是AI生成的，但客户问题依然相对稳定。见下图。更多客户，更多AI编写的代码，天空并没有坍塌。每年3月和4月我们都会有一个小波动；这些周期性模式在这里不需要解释。Cursor提供了关于我们的代码中有多少是由AI生成的统计数据。我们还没有看到代码质量、速度或工程师入职时间的回退（从经验上看，我们已经看到对代码库的理解有所提高！）。这不是一个玩具项目。Ashby是一套人才获取软件，每周拥有超过100,000个活跃用户，每周有数百万的候选申请，其功能类似于整家公司所需的产品（如Calendly和Looker）。我是Colin，Ashby的EMEA工程部负责人。我想与您分享Ashby工程如何看待AI及其对我们工作的变化。我将假设您是一名工程师。我们的理论是，生产代码的成本正在趋近于零。AI并不是要取代我们的工作，而是要替代其中的机械部分：语法、胶水代码和敲击键盘的细微动作。那些不太有趣、不太具挑战性的部分。对工程师来说重要的部分——您的判断、您的品味、您对客户的理解——正变得越来越重要，而不是减少。您作为工程师的价值始终在于您的判断。每一次高质量代码生产效率的提升都让这一角色向前发展。AI将是一次比我们之前见过的更大的转变。这一转变已经到来了。“我几乎所有的PR现在都是完全由AI编写的。我通过AI实施了整个数据摄取……大约40个PR”——我们的工程师Tom。像任何新兴技术一样，行业正在摸索如何有效利用AI来构建软件。什么时候信任它，何时覆盖它，以及我们的系统中需要改变什么，以确保“快速行动”不会变成“鲁莽行动”。这是一个共享的思维模型，我预计它会随着我们的学习而不断发展。基本原则随着我们更多地使用大语言模型（LLMs），以及我们周围的世界发生变化，我们认为有两个基本原则：同理心无法被AI替代；您对所交付的产品负责。 同理心无法被AI替代构建产品是人类的努力。LLMs没有品味。它们不知道我们的客户。它们无法感受到使用劣质产品的挫败感或使用优质产品的愉悦感。这仍然需要判断，并且在构建一个功能性产品的速度极快的世界中，构建一个出色产品的能力更为重要。我们还重视个人专注，因此当我们合作时，有效的方式非常重要。我们不进行无脑的站立会议。我们不进行计划扑克。我们确实编写文件供我们的同事阅读和理解。我们会请求协助审查变更。同理心意味着要记得为将要阅读这些文档的人写下它们。LLMs可以帮助写作。但是，在没有指导的情况下，LLMs会写出看似令人信服但对于人类而言难以阅读的文档，充满无关紧要的细节，缺乏乐趣和智慧。这里有一段我让LLM写的PR描述的摘录：1 增加了.github/workflows/pr-relevant-test-coverage.yml：2 - 在pull_request（不包括master）和3 workflow_dispatch时触发，带pr_number。4 - 解析PR号，收集更改的文件，并请求5 Claude输出最多15个相关测试文件。这所有的信息我们只需阅读PR就可以轻易得出，而完整的描述接近30行。最有用的一行仍然未达标：1 覆盖范围故意不是完整套件覆盖；它2 仅反映Claude选择的与3 更改的文件相关的测试。为什么？为什么这不运行完整套件覆盖？这个描述没有尊重我们同事的时间。它缺乏对我们作为评审者和未来维护者的同理心。1 覆盖范围故意不是完整套件覆盖。2 完整套件的覆盖需要数小时才能运行。我们是3 用作为给工程师提供关于风险所在的指导。记住，是什么赋予我们的同事帮助我们的能力。不要把为人类写文档的责任交给LLMs。您对所交付的产品负责LLMs可能是美妙却错误的。自信地不正确。无缘无故的粗心大意。AI带来的最大风险不是它是错误的。是它听起来是正确的。“我并不是故意删除tar-stream包的——这是我在编辑backend/package.json时的意外结果……”——Claude代码。您对所交付的产品负责。无论每一行是手动书写的还是由LLM生成的整个PR。您有责任理解代码的作用，原因以及在出现故障时会发生什么。随着我们更多地使用LLMs，怀疑态度必须增加，而不是减少。询问替代方案。询问边缘案例。要求它自我批评。在接受输出之前理解推理。思考