生成式 AI 正在改变软件工程的基本形态。代码生成能力变得越来越普遍，单纯依赖“写代码”的工程师价值正在被重新定义。在这期 InfoQ 播客访谈中，连续创业者、Tessi.ai CTO Ben Greene 分享了他对工程师未来角色的判断：手工软件工程师的时代已经过去了，工程师需要把精力从单纯编码转向理解问题、设计系统以及连接真实业务场景。
他认为，未来工程师最重要的能力不再只是技术深度，而是系统思维、业务理解以及与人协作的能力。同时，一种新的能力模型正在出现——工程师需要学会“AI 编排”，让多个 AI 工具与系统协同工作，而不是亲自完成所有代码。与此同时，在自动化越来越强的技术世界里，人类的同理心、沟通能力和对真实问题的理解，反而会变得更加重要。
换句话说，未来最有价值的工程师，不是写代码最快的人，而是能够理解复杂系统、协调 AI 与人类协作、并真正解决现实问题的人。
InfoQ 对访谈进行了翻译并经过不改变原意的编辑，以飨读者，以下为翻译全文：
Shane Hastie：大家好，我是 Shane Hastie，这里是 InfoQ 工程文化播客。今天，我将采访 Ben Greene。Ben，欢迎。感谢你今天抽出时间来接受我们的采访。
Ben Greene：谢谢你邀请我，Shane。很高兴来到这里。
Shane Hastie：我通常的开场白是，谁是 Ben？
Ben Greene：好问题。我也还在试图弄清楚。我曾多次在创业公司担任 CTO，目前正在创办一家名为 Tessi.ai 的新公司。我们利用结合地理空间影像的 AI 技术，帮助人们在自然灾害发生后更快地修复和重建家园。
我也联合创办过其他几家公司。上一家叫 Outcomes4Me，是一家面向消费者的健康科技公司，目前正在进行 B 轮融资。
此外，我还在 Techstars Boston 担任过几年的 CTO，也做过一些创业和技术方面的导师工作。不过现在，Tessi 是我全职投入的新项目。
Shane Hastie：是什么让你成为一个连续创业的首席技术官？
Ben Greene：我一直很喜欢解决问题。那些规模大、复杂甚至有点吓人的问题，反而特别吸引我。我会反复思考这些问题，然后想办法把它们解决。
在这个过程中，我逐渐意识到一件事：如果只看到解决方案的一部分，是远远不够的。你必须能够看到整体。
因为当你构建一个解决方案时，你希望它能够持续运行、不断成长，并最终不依赖于你个人。你不希望自己成为那个必须一直在机器旁边摇动手柄的人，而是希望即使你离开了，这个系统仍然能够继续运转。
某种程度上，这也是我选择通过科技创业来解决问题的原因。
不过我自己其实也是个挺急性子的人。正因为这样，我反而被初创公司这种环境所吸引——它们某种程度上“奖励耐心”。在创业公司里，你永远觉得自己进度不够快，无论已经做了多少事情、走了多远，总感觉还有很多要追赶。
这种节奏其实很符合我的性格。虽然有时压力不小，但我很享受这种状态：总有事情要做，而且通常没有太多繁琐的流程。
“手工软件工程师”的时代已经过去了
Shane Hastie：对于那些考虑进入初创公司环境的工程师，你有什么建议？
Ben Greene：从来没有比现在更好的时机了，这太有趣了。作为工程师，我认为“手工软件工程师”的时代已经过去了。生成式 AI 可以极大地提升生产力，远远超出很多人的想象——前提是你愿意真正去拥抱它。
某种程度上，这是一种类似于管理他人的能力：你需要学会把问题委派出去。很多优秀的工程师其实不太擅长委派任务，因为他们会担心：如果自己还没有完全弄清楚如何完成某件事，就把任务交给别人，结果可能达不到自己心中的标准。
但这是工程师需要克服的一点。你必须学会在不完美的工程条件下工作和管理。所以从工程的角度来看，我认为这是一个伟大的时代。
不过还有一点同样重要：工程师需要意识到，自己不仅仅是在写代码。你不仅仅是在用 0 和 1、用各种功能模块来构建系统。很多时候，你其实是在构建一个业务系统。即使是在非营利组织中，本质上也仍然是在构建一个有输入、有输出的系统。
如果你不去思考你构建的东西如何为这个系统创造价值，又如何受到这个系统的影响——那么你很难真正构建出一个可持续的系统。
Shane Hastie：典型的软件工程师往往不太关心整体格局或人与人之间的关系。之前我们聊天时，你说过一句话：“把规格说明从门缝塞进来，再给我点披萨就行。”听起来这种工作方式现在可能已经行不通了。
Ben Greene：是的，我认为那样的时代已经过去了。
如今，如果软件工程师想真正具备价值，就必须理解自己所交付的更大的成果和目标是什么。
随着生成式 AI 的发展，设计师、产品经理、销售人员以及团队中的其他角色，都开始可以借助 AI 直接接触甚至编写代码。如果一名软件工程师不主动扩大自己的视野，只局限于代码层面，那么他的能力就会显得相对单一。
当然，目前像 Claude Code 这样的工具在高层次工程思考方面还不算特别强，但它们一定会不断进步。而当这种情况发生时，工程师真正的价值在于：不仅知道如何最大限度地利用这些工具，还能够指出它们没有考虑到的问题，并从更高层次去思考整个系统。
现在，当我思考“系统”时，我考虑的已经不仅仅是软件本身，还包括我周围的人——不仅是和我一起工作的同事，也包括合作伙伴和客户。
我依然在解决问题，也依然在构建系统。只是现在我使用的工具不再只有代码、API 和各种托管服务。现在，我处理的是整个世界的模糊性。但从本质上来说，我仍然是在解决问题，而软件依然是其中的一部分，只是不再是唯一的部分了。
抽象层继续上升，但软件本身正在“贬值”
Shane Hastie：在过去几十年里，我们一直在不断增加新的抽象层。这次的变化只是又多了一层抽象，还是说出现了某种不同的变化？
Ben Greene：我认为既可以说是增加了一层新的抽象，也可以说是某种意义上的“抽象层坍塌”。
从编程语言（PL）的角度来看，我们一直在做的一件事，其实就是把一种语言不断翻译成另一种语言。举个例子，从浏览器中运行的语言，到最终变成处理器可以执行的指令，中间可能要经过很多次转换。
具体有多少层，我其实也记不清了。也许是七八层，也可能是十几层。但从更高的层面来看，其实已经没有必要理解所有这些层次。
比如说，我并不了解 V8 引擎，或者 Chrome 现在使用的其他引擎的内部细节，而且坦白说，我也不想了解。我只需要它能够正常工作就行了。
我真正关心的是如何解决我正在面对的问题。尤其是在创业公司里，我们总是试图站在巨人的肩膀上，在已有的技术基础上继续往前走。很多开源驱动的开发模式其实也是这样。
如果现在我们做的事情，只是在描述层面构建系统，甚至不再直接写代码，而是用自然语言，比如英语来描述需求，那其实也没有什么问题。
但从更宏观的角度来看，这对软件意味着一件事：仅仅依靠软件本身，已经很难像过去那样创造大量价值了。你必须与现实世界建立更紧密的联系。因为简单地移动比特、处理 0 和 1，已经不像过去那样稀缺或独特了。
Shane Hastie：这么看来，软件工程师的角色正在发生很大的变化。如果回顾大多数工程教育体系，其实并没有为这种变化做好准备。
Ben Greene：确实如此。最近出现了一个很有意思的趋势：所谓的 “前线部署工程师”（Frontline Deployment Engineer）。不知道你是否注意到，现在有不少公司开始招聘工程师，让他们直接到客户的办公室工作。
这些工程师既是自己公司平台的专家，同时也逐渐成为客户系统和业务问题的专家。他们会直接嵌入到客户的环境中，与客户团队一起工作。
我其实很喜欢这种模式，因为这是学习如何把技术真正应用到实际问题中的最好方式——你就坐在那些正在面对问题的人身边。
其实，多年来我们一直在这样建议产品经理：不要只通过访谈了解用户，而是要真正走进他们的办公室，观察他们如何工作，观察他们是如何与你的产品互动的。
而现在，我们开始让工程师也这样做。我很喜欢这种变化，因为工程师应该停止那种“我只是坐在键盘前写代码”的思维方式。工程师也应该走出去，与人交流，理解他们正在面对的问题。
换句话说，同理心这种能力——也许过去很多软件工程师并没有真正去培养和使用——现在变得非常重要。而且说实话，我对这样一个未来感到很兴奋：一个人们愿意花更多时间去理解他人的世界。我认为这会是一个非常积极的变化。
Shane Hastie：那我们应该如何在组织中培养这种文化呢？
Ben Greene：我真希望自己有一个完美的答案，但说实话，我也还在不断摸索。
不过有几件事我觉得非常重要。首先，就是要经常谈论你的客户，并花时间与他们相处。仅仅坐在办公桌后面是不够的，你必须走出去，真正去看他们是如何工作的，甚至亲自参与到他们的工作中。
同时，你也需要在公司内部建立一种共识：客户所做的事情是重要的，客户本身也是重要的人。
举个例子，我们目前有一个合作伙伴，是一个在灾害发生后参与救援工作的志愿者组织。他们所做的事情非常令人敬佩，说实话，要理解和认同他们的工作其实很容易。
但我认为，不管你的客户是谁，你都需要意识到：在 B2B 软件场景中，你可能只是销售一个分析平台，但在另一端，使用这个平台的是一个具体的人，他们希望通过你的软件获得更好的业绩，或者推动某个项目成功。
如果你不了解你的软件将如何帮助他们在工作和职业发展中取得成功，那么你其实并没有真正理解他们为什么会使用你的产品。因此，你需要在人的层面上去帮助他们，也需要从人的角度去思考问题。
对于消费者产品来说，这一点可能更容易理解。但即使是在企业软件领域，人们同样希望获得成功、得到认可，甚至获得晋升。他们的这些目标是合理的，而你的软件也应该帮助他们实现这些目标。
Shane Hastie：根据我的经验，这种视角与大多数软件工程师刚进入行业时的想法其实很不一样。你之前也提到过产品经理、销售人员等角色，现在似乎每个人都在“写代码”。
Ben Greene：目前来说，还是要打个引号的“写代码”。
工程师真正的竞争优势：系统思维
Shane Hastie：那么在这样的环境下，作为一名工程师，我应该如何体现自己的价值？工程师真正独特的竞争优势是什么？
Ben Greene：我认为软件工程师最大的优势之一是系统思维能力。
比如在会议上，当有人提出一个新功能时，工程师往往会立刻想到各种可能出问题的地方，因为我们习惯去思考各种边界情况和潜在风险。
这其实是一种非常宝贵的能力。坦白说，我们应该把这种能力从单纯的软件开发中带出来，用在更广泛的业务和组织系统中。
举个简单的例子：如果客户打电话到呼叫中心，但双方说的不是同一种语言，会发生什么？软件工程师通常会很自然地想到这些问题。
我们可以帮助组织中的其他团队，让他们的流程和系统更加稳健，减少漏洞，提高整体可靠性。因为在构建系统这件事上，工程师拥有大量经验。
当然，未来仍然会有很多复杂的问题需要工程师去解决，只不过这些问题会更加具有创新性。它们不会再是那些我们已经反复构建过无数次的标准 SaaS 功能。那些事情完全可以交给生成式 AI 去完成——说实话，这其实是一件好事，不是吗？
我们真的还想继续一遍又一遍地重复构建这些功能吗？
不如把精力放在真正新的问题上：探索以前没有人解决过的问题，把新的理论和新的思考方式带入软件工程领域，同时让那些更常规的工作由自动化工具来完成。
Shane Hastie：回到你作为连续创业 CTO 的经历，当你创建一家新的创业公司时，你通常是如何设计组织文化的？
Ben Greene：有几件事情对我来说一直都很有效。
在设计组织结构时，我通常会参考一些基本原则。比如 康威定律（Conway’s Law）：系统的结构往往会反映组织的结构。
所以我通常会从系统设计反推组织结构。我会先思考：我希望最终的系统是什么样的？系统的接口应该在哪里？哪些部分需要能够独立扩展？哪些模块可以保持松耦合，从而实现独立发展？
在明确这些之后，我会尝试把组织结构设计成能够自然支持这种系统架构的形式。这是从结构层面来看。
而从文化和团队协作的角度来看，我通常会先思考一件事：有哪些行为是我希望团队成员能够模仿的。因为在创业初期，我往往是工程团队里的第一个人，我的行为会直接影响团队成员之间的互动方式。
某种程度上，企业文化其实只是沟通方式长期积累的结果。文化本质上是人与人互动所形成的产物。
在我之前创办的 Outcomes4Me 公司里，有一件事情我一直非常重视：代码质量，尤其是代码的可读性。
这对我来说非常重要。因为当你从 0 到 1 创业、寻找产品市场契合（product-market fit）的过程中，你一定会不断调整产品和系统。如果团队成员无法理解代码为什么这样写、当初是如何设计的，那么后续修改系统就会变得非常困难。久而久之，代码库里就会出现很多没人敢碰的地方，人们只能绕着这些代码走。
于是就会出现一种情况：当有人提出一个听起来很简单的功能需求时，你却不得不说，“这个功能可能需要三个月时间”，因为你必须非常小心地绕开那些自己也不完全理解的代码。
那么，如何避免这种情况？
在代码评审时，我有一条非常明确的原则：在保证代码正确的前提下，始终优先考虑阅读代码的人。
如果代码评审者说：“我看不懂这段代码”，那通常就说明代码本身存在问题。此时就应该修改代码，直到评审者能够轻松理解它。
目标是在任何时候都尽量降低代码的认知负担。不过这里还有一个挑战：工程师往往不太愿意承认自己看不懂某些东西。我们很多人都会受到“冒名顶替综合症”的影响，没有人愿意显得自己不够聪明。
所以我在团队里采取的一种做法是：主动示范这种行为。
我其实并不介意让自己看起来有点傻。有时候我会直接说：“这个我没听懂。”而且很多时候我也确实是真的没听懂。
当团队看到 CTO 也会坦然承认自己不理解某件事时，大家就会意识到：原来不懂某件事是可以接受的，请别人解释也是正常的，甚至要求别人把事情讲得更简单一些也是合理的。
这种氛围会逐渐形成一种文化：承认不懂是可以的，提问是被鼓励的。
AI 时代的新工程师能力模型
Shane Hastie：随着初创公司不断成长，你也需要引入新的工程师。最近我们经常听到一种说法：刚毕业的工程师甚至很难找到工作。在这样一个快速变化、不断增加抽象层的行业中，我们应该如何帮助新人进入这个领域？
Ben Greene：我认为首先需要改变的是：我们对工程师岗位的理解。
我现在招聘软件工程师，并不是为了让他们来写代码，而是为了让他们参与构建产品和系统。
如果我招聘一位有 10 年经验的工程师，而他希望加入团队后负责把所有代码都写出来，那我可能不会录用他。
相反，如果我在寻找的是一个能够真正把事情做出来的人，而某个刚毕业的学生已经掌握了一种方法，可以利用 AI 智能体来协调其他智能体完成任务，那么我会非常愿意把他招进团队。
当然，这样的人其实并不多见。但如果有人已经找到了一种稳定的方法，能够持续地产生可靠的结果，那么我们就必须认识到：这是一种新的技能。
未来我们真正需要寻找的能力，是 AI 编排（AI orchestration），而不仅仅是写代码。
当然，对代码本身的理解仍然非常重要。但在招聘时，我始终最看重的一点是：速度。
在创业公司里，我们通常并不完全确定自己要解决的问题是什么，也无法确定最终会使用哪些技术。
我当然希望能找到熟悉相关技术的人，但现实往往是：我们最终使用的，很可能是之前从未接触过的新技术。
因此，我更希望找到这样的人：他们喜欢学习，不害怕学习，而且会主动学习。我认为很多刚毕业的工程师，其实正好具备这样的心态。
Shane Hastie：在软件工程领域，目前有没有一些你认为大家还没有充分意识到的重要趋势？
Ben Greene：我认为我们需要更清晰地讨论一个问题：哪些问题适合用基于智能体的推理来解决，哪些问题仍然需要通过传统代码来实现。
现在有很多公司在销售各种基于 AI 智能体推理的解决方案，它们往往宣称系统可以达到 95% 的可靠性。但在很多工程场景中，95% 的可靠性其实意味着彻底失败。
我认为，在当前大家都在争相采用生成式 AI、AI 推理和 AI 智能体的热潮中，同时工程师也在努力理解这些新工具、保持自身价值的情况下，我们其实并没有认真讨论这些工具什么时候适合使用、什么时候不适合使用，以及如何负责任地使用它们。
也许其中一个原因是，我们往往不太愿意展开这种讨论。市场营销的声音太多，很容易淹没这些更理性的判断。但我认为，工程师应该更多地参与到这种讨论中来。
Shane Hastie：对于处于职业生涯中期的专业人士，你有什么建议吗？
Ben Greene：我不确定自己是不是有什么特别有用的建议。某种程度上，我现在也正处在那个阶段。
对我来说，我通常只是去寻找那些能够真正让我投入大量精力去追求的事情。很多时候，我更多是凭直觉做决定。
这在一定程度上也与创业有关。创业是一件非常艰难的事情，所以我总会问自己一个问题：我对这件事情是否有足够的热情，能够支撑我投入几年时间去做它？如果答案是肯定的，那我通常就会去尝试。
我认为，如果你能够找到自己真正想投入其中的事情，你就会拥有足够的动力去克服过程中遇到的各种问题。
从更大的角度来看，软件工程本身其实是一门创造性的学科。我们实际上是在从无到有地创造新的能力、新的可能性，甚至新的“世界”。因此，我们需要保持这样的想法：不断思考如何把这些技能应用到全新的领域和问题中。
如果有一天我再也不用写 CSS 或 HTML 了，我一点也不会难过，这对我来说并不重要。但一想到我们可以构建更好的解决方案，让更多人能够用得起以前难以负担的技术，帮助他们更高效地工作，甚至改善他们的生活，这些事情会让我非常兴奋。
所以，找到真正让你有热情的事情，并持续投入其中。其他很多事情，往往也会随之慢慢展开。
Shane Hastie：还有什么重要的问题是我没有问到，但你希望传达给听众的？
Ben Greene：我觉得，从技术发展以及社会变化的方式来看，有一点非常值得我们重视：人与人之间的沟通能力需要被放在更重要的位置。
技术和社会其实是紧密交织在一起发展的。因此，我们需要更加重视人与人之间的互动，以及与他人协作所需要的各种能力。人与人之间的交流非常重要。同时，我们也需要学会如何与 AI 有效沟通，以及如何通过代码与计算机沟通。
这三种沟通方式——人与人、人与 AI、人与计算机——虽然形式不同，但都同样重要。
因为从某种意义上说，我们每个人都只是一个更大系统中的一部分，而系统中各个“节点”之间能否有效沟通，往往决定了整个系统的运行效果。
如果我们回头看看技术的发展，就会发现：计算机与计算机之间的沟通会越来越高效。
但在社会层面，真正的薄弱环节反而是人与人之间的沟通。所以，我们需要认真对待这一点，并努力去改善它。
Shane Hastie：那我们应该从哪里开始？
Ben Greene：我认为答案其实很简单：从同理心开始。也就是试着去理解坐在桌子另一边的人是谁，他们正在面对什么样的处境。
很多年前我听过一句话：在工作中、在街道上、在商店里，你遇到的每一个人，生活中都可能正承受着某种你完全不了解的困难。你不知道那件事情有多严重。也许是一场悲剧，也可能只是某种烦恼。但总有一些事情正在影响他们的生活，而这些事情你并不知道。如果你带着这样的假设去与人交流，你往往会变得更加善良、更体贴，也更有同理心。
而如果你是一个解决问题的人——我认为真正的软件工程师本质上都是解决问题的人——当你意识到每个人都在面对自己的问题时，你会突然发现，这个世界其实有很多地方可以产生积极影响。
软件和计算机技术仍然拥有巨大的潜力。它们可以让世界变得更好，可以让企业运作得更高效，可以让社会运转得更加顺畅，甚至能够帮助改善民主机制。我们其实有很多事情可以去做。但前提是：我们必须真正关心这些问题。否则，我们甚至不会意识到这些机会的存在。
Shane Hastie：我们确实需要关心这些事情。Ben，非常感谢你今天抽出时间与我们交流。在结束之前，如果听众希望继续与你交流，他们可以在哪里找到你？
Ben Greene：LinkedIn 可能是最好的方式。我通常都会回复消息。如果有人向我发送连接请求，也可以顺便给我发一条信息。一般来说，如果我没有与某个人面对面聊过，我不会主动联系对方。但如果有人主动说：“我想和你聊聊”，那我通常会很乐意安排时间。
事实上，有一次我在 QCon 做完演讲后，有位听众没来得及和我交流，他后来在 LinkedIn 上联系了我。我们在美国感恩节后的第二天通了一次电话，聊得非常愉快。
希望下次我去德国的时候，还能见到他，一起喝一杯。所以，如果有人想交流，我随时欢迎。
原文链接：
https://www.infoq.com/podcasts/beyond-code-engineers-evolve-ai-era/
