前GitHub CEO携6000万美元再创业！瞄准下一代开发者平台：用Agent管理Agent，IDE和编程语言或将过时？

前GitHub首席执行官Thomas Dohmke离职后的创业动向，近日终于揭晓。其新创立的公司Entire，在秘密运营一段时间后，于两周前正式亮相，并宣布已完成高达6000万美元的种子轮融资，公司估值达3亿美元。

Thomas Dohmke在GitHub任职期间，曾成功推动GitHub Copilot的规模化发展。此次创业，他依然聚焦于开发者工具领域，但选择了一个独特的切入点：当众多公司专注于开发编程AI智能体（Agent）时，Entire的目标是打造一个用于管理和协调大量AI编程智能体的平台。

该平台的核心定位是帮助开发团队管理与理解由AI生成的代码。Thomas Dohmke指出，现有的开发者工具难以应对AI编码智能体的兴起，而Entire正是为那些需要管理大量AI编码智能体、而非亲自编写每一行代码的团队所设计。

他在一份声明中比喻道：“正如汽车公司用流水线取代手工生产系统一样，我们现在也必须为‘机器成为代码主要生产者’的世界，重新构想软件开发生命周期。Entire的目标就是构建下一代开发者平台，让智能体与人类能够协作、学习并共同交付。”

此轮6000万美元融资由硅谷风投公司Felicis领投，据称这是开发者工具初创公司有史以来规模最大的种子轮投资之一。其他投资方包括Madrona、微软旗下风投M12、Basis Set，以及雅虎联合创始人杨致远、Y Combinator首席执行官Garry Tan、Datadog首席执行官Olivier Pomel等个人投资者，以及多位开发者社区领袖。

首个开源项目发布：Checkpoints

作为起步，Entire近期开源了其首个项目——名为Checkpoints的命令行工具。该工具旨在记录AI生成代码背后的逻辑与指令，并将这些信息与代码本身一同保存，从而使团队能够追溯代码变更的缘由与过程，让AI编写的软件更易于审查和审计。

Checkpoints计划支持Anthropic的Claude Code和Google的Gemini CLI等AI编码工具，并逐步扩展对其他主流智能体的支持。此举在开发者社区中获得积极反响，有评论认为Checkpoints在此类工具中堪称“一等公民”。

据悉，Entire目前拥有15名员工，实行完全远程办公，团队遍布全球，成员此前多任职于GitHub、Atlassian等公司的开发者工具部门。公司计划在今年晚些时候推出更广泛的平台，并相应扩大团队规模。

AI原生团队：工作流的根本性变革

当前，AI编程赛道竞争日趋激烈。在近期与Atlassian首席技术官Rajeev Rajan的一次对谈中，Thomas Dohmke分享了他对行业发展的观察。他指出，尽管当前Agent领域存在不少“表演性叙事”，但如Cursor、Claude Code等编程智能体的出现，确实已引发工作流向“AI原生”模式的深刻转变。

最大的变化在于：从零开始进行“绿地项目”开发的开发者，会刻意“避免阅读代码”。他们强迫自己使用提示词（Prompt）、推理过程和“表达意图”的方式来驱动开发。

代码审查也是如此。我不会逐行阅读代码，那会成为瓶颈。我会先让Cursor、BugBot这类工具指出问题。

他进一步展望，AI原生的开发团队将掌握这样一种技巧：让代码审查Agent与编程Agent直接对话，过程中无需人类介入。

同时，Thomas Dohmke也提醒企业关注随之而来的成本变化：开发者效率越高，消耗的AI计算资源（Token）就越多，相关成本也将显著上升。不过，他认为企业不会因此裁员，因为效率提升带来的收益远超成本增加。

积极的一面是，开发工作正重新变得有趣。复杂的创新想法、棘手的构建错误、枯燥的单元测试等工作，现在都可以交由AI智能体处理。此外，Agent对于远程办公团队也是一大利好，它能提供一种“永远在线”的协作支持。

我永远有人在线：代码审查Agent、编码Agent、头脑风暴Agent、研究Agent……

尤其是在发布日，如果团队在同一时区，到点总得下班。但有了Agent，澳大利亚的团队在他们的工作时间可以继续维护Discord社区和开源项目。

未来展望：传统角色“塌缩”，IDE与编程语言会过时吗？

谈及未来，Thomas Dohmke认为，目前编程Agent主要适用于新项目，尚难处理大型遗留系统。下一步将出现审查、自动合并与部署代码的Agent，但其效果可能不尽如人意，容易导致功能堆砌、体验混乱的“霍默·辛普森的车”现象。因此，产品经理、设计师、工程师在架构优秀产品方面的角色依然关键。

但他确信，传统的工程角色将发生“塌缩”：产品经理会转向产品工程师，设计师会转向设计工程师，软件工程师的职责也将演变，三者的职能维恩图将高度重叠。

Atlassian CTO Rajeev Rajan的看法则更为激进。他认为，当前的“人机混合”开发模式将走向“零手写代码”的时代。人类将完全信任Agent完成代码审查，自身则更专注于输入输出验证，确保系统在安全、可靠和性能上达标，而非逐行检查代码。

其激进之处在于，Rajeev Rajan预测，或许两年后，我们甚至不再需要传统的编程语言和IDE，取而代之的可能是某种“AI虚拟机”来处理一切。届时，开发将完全上升到“意图层面”，传统编程形式或将过时。

（因篇幅所限，更多访谈精彩观点梳理如下。）

AI Native 团队的核心

主持人：
五个月前我们策划这场活动时，只是想探讨一些重要问题。当时觉得可能会部分涉及AI，但现在看来，AI已无处不在。

两位在很多方面很相似：都管理或曾管理大型组织，也都打造了深受开发者喜爱的品牌。Thomas，你现在创办了一家全新的公司，从事完全不同的事业。

那么，究竟什么是“AI First”或“AI Native”的团队？Rajeev，请先谈谈你的看法。

Rajeev Rajan：
首先，谢谢邀请，也很高兴看到现场如此热烈的氛围。大家都在谈论AI Native。

什么是AI Native团队？第一是“心态”。你必须真正相信AI Native的工作方式，相信与Agent协作。

在Atlassian，我们有些工程团队仍以传统方式编写代码，因为需要维护遗留系统。但同时，我们也有不少AI Native团队，工程师几乎不写代码——完全是在进行Agent的编排和调度。

我们观察到，产品经理、设计师和工程师之间的界限正在模糊。产品经理在写代码，设计师也在写代码。整体生产力显著提升——团队规模未必缩小，但产出可能是原来的2倍、5倍，创造力也更高。

Thomas Dohmke：
我认为这个问题有多个层面。Rajeev 提到了其中一个。

我们可以将“AI 原生”类比为“云原生”。当 GitHub 在 2008 年成立时，根本没人谈论“云原生”。这个概念是后来人们总结这些公司如何重构部署和开发方式时才提出的。

我认为“AI 原生”也是如此。我们今天称之为“AI 原生”的事物，几年后看起来会完全不同。

我有两个儿子，一个 13 岁，一个 11 岁，他们大部分时间在玩《我的世界》。有时我也会让他们写点代码，但他们绝对是“AI 原生”的一代。

大概一两年前，他们回家给我看手机主页上的一张小狗图片，说是用 Adobe Firefly 生成的。我问：“你们怎么知道这个工具的？”他们回答：“学校里大家都在用。”

这就是“AI 原生”世代。他们从小与智能体一起成长。对他们来说，用智能体代替谷歌搜索将是再自然不过的事。

但如果我们诚实一点，现在存在很多“表演性叙事”，仿佛每天都是 AI 原生，事事都用智能体。实际上，发展还远未到那一步。

作为一名创业者，我大部分时间在处理 HR 系统、月度账务、董事责任险表格……没有任何智能体能帮我做这些。

昨天我们刚宣布公司成立，我就收到了数百封邮件——有投资人想追加天使轮投资，也有拥有 12 年经验的顶级工程师发来求职信。

我现在最想要的，是一个能帮我处理这些事务的智能体：既能礼貌回复，又能明确表达“目前暂不考虑”。

所以，今天 AI 原生团队的核心现实是，我们会用 Claude Code 或其他智能体来编写代码；但我们不会让 3000 名工程师在 Markdown 文档上协作。那将是一场噩梦。

尤其是对于全球分布的团队——德国、西班牙、印度、中国——如果你必须用一种非母语的语言去描述功能需求，那会更加痛苦。

编程语言的优势在于它可能只需要 20 个核心词汇。而用自然语言编写规格说明？要困难得多。这些问题，我们其实还没有真正解决。

主持人：
你们团队现在具体如何使用这些工具？工作流程发生了哪些变化？

Thomas Dohmke：
最大的变化在于——那些从零开始进行绿地项目、使用 Claude Code 的开发者，会刻意“避免直接阅读代码”。

他们强迫自己使用提示词、推理过程，以及“表达意图”的方式来驱动开发。

代码审查也是如此。我不会逐行阅读代码，那会成为瓶颈。我会先让 Cursor、BugBot 这类工具指出问题。

我正在等待一个时刻：让代码审查智能体和编程智能体直接对话。中间为什么还需要人类介入？

目前最具“AI 原生”特质的开发者，是那些已经掌握这种方式的人。这不是“用智能体取代人类”，而是让人类升级，成为智能体的掌控者。

Rajeev Rajan：
在工具层面，我认为有两个主要方向。第一，编写和实现代码的成本几乎趋近于零，瓶颈开始转移到“代码左侧”和“代码右侧”。

左侧是规划与规格说明。我们在 Atlassian 大量使用 Confluence——因为那是编写意图和规格的地方。

确实，主要是英文，Thomas 关于语言障碍的问题说得对。但对于以产品为导向的工程师来说，他们会在文档里撰写大量评论。

我们的智能体会读取这些评论，进入执行循环并解决问题。这非常惊人。

而右侧，则是 CI/CD、部署、事故处理等。我们也正在使用智能体来处理这些环节。

我们是从整个软件生命周期的角度来看待这件事的——从构想到生产部署。我们称之为 AI 原生的软件开发生命周期。

主持人：
Rajeev，谈谈 RoboDev。

Rajeev Rajan：
RoboDev 是一个编程智能体，同时也是我们贯穿整个 SDLC 的品牌名称。我们用它进行代码审查、CI/CD、事故处理等。是的，我们自己构建了这个智能体。

有趣的是，我们使用的是 Anthropic 的模型，但在我们的基准测试中，其表现甚至超过了 Claude Code。

我们是如何做到的？关键只有一个词——上下文。

智能体的智能程度，取决于你为它提供了多少上下文。

在 Atlassian，我们构建了一个名为 Teamwork Graph 的系统。它知道 Thomas 和谁合作、在哪个拉取请求上工作、对应哪个 Jira 问题。这种关系网络的上下文，使得 RoboDev 在处理拉取请求时表现得好得多。

主持人：
Thomas，你刚才提到，你的团队分布在多个时区。对于早期创业公司来说，这其实很少见。传统观点认为：大家在同一个办公室，更容易碰撞想法。

你为什么选择分布式办公？AI 在其中起到了作用吗？

Thomas Dohmke：
首先，我认为每个人都需要找到适合自己的幸福工作方式。就像个人关系一样，公司协作模式也没有唯一正确的答案。

你想在旧金山漂亮的办公室里工作？很好。想采用混合办公模式？也很好。

我喜欢远程团队，因为我喜欢旅行。我也喜欢 24/7 的全天候覆盖：澳大利亚、德国、西班牙、里斯本、英国、美国，不同时区轮转。这让我感到开心。当然，这并不代表其他模式是错的。

但远程团队的现实是：有时会感到孤独。

这不仅是“一个人在家”的孤独，还有“现在谁能回答我的问题”这种孤独。在办公室里更容易判断——比如看到同事只是在刷社交媒体，那我就可以去问他个问题。如果你正在和 Rajeev 开会，我当然不会冲进会议室打断你。

智能体为我们提供了“随时可用的伙伴”。我可以说：帮我一起头脑风暴、我要写一份架构决策记录、帮我解决这个问题。

上周末我在准备产品发布时，发现除了服务条款和隐私政策，还需要 Cookie 政策。我不知道在 React 应用里如何实现，就让 Cursor Composer 帮我写——3 秒钟就搞定了。

远程工作因为智能体而达到了一个新层级。我永远有“人”在线：代码审查智能体、编码智能体、头脑风暴智能体、研究智能体……

尤其是在发布日，如果大家都在一个办公室，到了某个时间点总得回家。但那时澳大利亚团队正好是中午，他们还能继续维护 Discord 社区和开源项目。

从某种程度上说，智能体让远程团队重新获得了优势。在旧金山，很多 AI 公司已经回到了办公室。智能体至少弥补了远程办公的一些竞争劣势。

主持人：
Rajeev，你怎么看？Atlassian 本身也有分布式团队。

Rajeev Rajan：
我们其实在疫情之前就已经大规模采用分布式协作。疫情对我们来说反而很自然。我们的产品本身就是为分布式协作而设计的。

我们不是纯粹的远程公司，我们有办公室——在旧金山、悉尼等地。我们相信“有意的线下相聚”能带来人与人之间的深度连接。但我们不强制要求员工进办公室。我们称之为 Team Anywhere。你可以在任何地方工作。

智能体的确改变了很多。我记得以前凌晨两点在办公室写代码，卡住了只能一遍又一遍地读代码。现在可以直接询问智能体，甚至让它帮你写。

这让分布式协作变得更容易。

主持人：
我们都看到一个趋势：软件工程师的角色在变化，工程管理者的角色也在变化。从你的视角来看，正在发生什么？在 Atlassian，你们是否在重新定义这些角色？

Rajeev Rajan：
我们更多是从“所有权”和“责任”的角度来思考。现在的所有权不再仅仅局限于代码，而是转向了 Confluence 文档、Jira 事项、甚至 Loom 视频这些产出物。

我们收购的 Loom 现在是 Atlassian 产品的一部分。通过视频表达意图，然后提供给智能体，能产生更好的结果。

岗位的所有权和责任都已经发生了变化。代码评审的重点已经转向验证。

责任的重心正在转移。过去，工程师的大量精力耗费在代码评审上。如今，更关键的任务是“验证”：

• 设定边界： Guardrails（防护栏）是什么？
• 确保可靠： 输入与输出应如何校验？
• 判断正确性： 如何确认 AI 生成的代码是正确的？

这已成为新的核心职责。

在团队结构层面，我们并未进行激进的变革，而是更关注：如何让团队更具创造力？如何实现更大的产出？

我们的目标并非“缩减人数”。在一些项目中，生产力确实能实现 10 倍甚至 100 倍的提升。届时，我们会重新配置团队资源。但一切的核心，始终是释放创造力。

主持人：
你提到“生产力提升后重塑团队”，具体指什么？

Rajeev Rajan：
我们进行过一些实验——例如，尝试完全不手动编写代码。这会迫使你以全新的方式组织代码仓库、设定 Agent 规则、提供上下文信息。

如果 Agent 面对的是一个充满遗留代码的复杂仓库，其效果会大打折扣。相反，全新的“绿地”项目更容易贯彻“AI First”的理念。在这些场景下，我们确实看到了巨大的进展。

但对于大型遗留代码库，目前还无法完全放手交给 Agent 处理。这是整个行业正在共同攻克的难题。我相信很快会有解决方案，但目前我们仍需保持审慎。

Thomas Dohmke：
我有两个角度的观察。

第一，我们永远有太多想法。我常开玩笑：单身时，周六早上觉得有无限可能；有了家庭后，周日晚上发现一事无成——因为家庭事务决定了你的行动。

软件项目也是如此。我们通过撰写待办清单、排定产品需求列表来解决优先级问题。但根本矛盾在于——想法永远多于执行能力。

需求列表会越来越长，最终总有人提议“全部推倒重来”，然后又把同样的想法提出来。

现在我们正在做的是，将这一切向前推进一步——把所有想法“喂”给 Agent，让它们生成代码。于是，你会得到堆积如山的待办事项和拉取请求。新的瓶颈出现了：你根本审核不过来。

接下来，将会出现审查代码的 Agent、自动合并与部署流程。最终，你可能会得到一辆“霍默·辛普森的车”——所有想法都被堆砌进去，缺乏流程和产品思维，结果就是功能爆炸、体验混乱。

因此，我们仍然需要产品经理、设计师和工程师来共同架构出优秀的产品。糟糕的产品很容易辨认，而优秀的产品却很难打造。

但我确实认为，传统的工程角色会发生“融合”。产品经理会演变为产品工程师，设计师会演变为设计工程师，软件工程师依然是软件工程师，但三者的技能维恩图将高度重叠。

现在，许多公司已经要求产品经理必须使用编码 Agent 来制作原型，而不仅仅是撰写文档进行交接。更进一步，市场、传播、助理等角色——他们都在使用 Lovable、Replit 等工具来自动化部分工作。

核心问题在于：组织是选择成为那个“阻止上线的拦路者”，还是允许每个人都成为构建者？公司的本质在于团队协作带来的力量。

我们尚未完全解决的挑战是：如何在确保安全与可信的前提下，加速整个开发生命周期，同时赋能团队中的每一个人。

主持人：
那么工程领导者呢？你们在 Atlassian 拥有许多优秀的工程领导者。你如何看待他们角色的变化？Thomas，你未来会如何招聘？Rajeev 先请。

Rajeev Rajan：
最让我兴奋的一点是——工程领导者现在可以重新开始写代码了。我非常享受编码。假期里，我甚至自己去 Apple Store 买了一台笔记本，装上 Claude Code，编写了一个应用和一堆 Python 脚本。

过去，要抽出时间做这些很困难。现在，借助 RoboDev 和各种 Agent，速度可以快得多。参加黑客松、亲自编写代码依然能带来巨大的满足感。

作为领导者，职位越高往往离代码越远。现在，这个距离正在缩短。

另一个变化是管理幅度。

我一直提倡一种极端的扁平结构：400 人的团队，开平方根得到约 20 个直接下属，每人再管理 20 人，仅有两层管理。现实中，许多组织是“二叉树”式结构——每人只带 2 个下属。

我认为未来的管理幅度会扩大。有人提到 33 个直接下属，甚至 40、50 个。经理的数量会更少，但会更贴近代码。这是一件好事。

主持人：
传统的职业路径呢？比如从工程师到资深工程师，再到管理者……

Rajeev Rajan：
每当有人询问职业路径，我的第一个建议总是：不要急于成为经理。

我当年也听从了这个建议，尽量避免担任管理职务。直到我发现有些决策我看不懂时，才决定“加入管理层”。

现在是编写代码的绝佳时代。多使用 Agent，多从事前沿探索。工程师的前景会很好。管理者的数量可能会减少。

如果你愿意亲自动手，会非常精彩；如果固守旧的职业路径，则可能需要寻找新的方向。

Thomas Dohmke：
我有三点看法。

第一，给所有创业者一个建议：当投资人问“你如何防止大公司复制你？”时，你可以说，Atlassian 的 CTO 都得自己掏钱买电脑写代码。这说明即便是敏捷的大公司，也未必能在五分钟内做到你能做的事。

第二，过去两年，Copilot、Cursor、Devin 这类编码 Agent，让许多大银行的 CTO、CIO 重新开始写代码。

我认识的一些人，会在晚上给 Devin 一个任务，第二天早上检查进展，然后继续。两周之后，你会意识到：组织必须做出改变。

以前，许多银行还在使用 Citrix、老旧系统，CTO 甚至没有权限推翻这些，因为安全部门有所顾虑。现在情况不同了。领导者重新“把手弄脏”，亲自体验技术的力量。

Agent 的采用速度前所未有——甚至比云计算还快。许多德国、日本的企业尚未全面上云，但已经在尝试使用 Agent。

第三，关于管理。我第一次真正成为经理，是在创业公司被 Microsoft 收购之后。一个 10 人创业公司的 CEO 其实不算真正的“经理”。

进入大公司后，我才意识到：天啊，管理这件事本身，需要被重新定义。

现在我需要招聘员工，这意味着要撰写职位描述、进行面试、编写绩效评估。你知道，当 ChatGPT 刚出现时，我们突然就会直接让它帮忙起草绩效评估，当然，员工那边也会这么做。

如果你在 Microsoft 工作过，你就知道，员工需要填写大约七个输入字段，然后经理还要对这七个字段逐一回应。

如果你是个有点“偷懒”的技术经理，可能就写一句“我同意你的看法”，员工当然不会满意。于是你就开始“破解”这个系统，直接去问 ChatGPT，反过来让它给你列出刚才那些要点，至少让我知道你是怎么写提示词的。

主持人：
所以，你是带着这种心态成为 GitHub CEO 的？

Thomas Dohmke：
你知道，GitHub 的核心信条，或者说原则、甚至教条，是“开发者优先”。顺便说一句，我们在后台还开玩笑，说下次可能办个“教条峰会”，把所有“教条”都请上台，应该更有趣。

“开发者优先”一直是 GitHub 的原则，无论是产品设计、流程制定还是市场营销。如果我们做得不好，你在 Hacker News 上会立刻看到反馈——那里的开发者非常直接。如果一篇 GitHub 博文、一条推文或一则公告太“企业味”，开发者不会买账。他们不要那种官方套话。给我真话，给我直接的对话，不要营销废话。那一套对其他产品或许有效，但对开发者工具行不通。

我认为，担任团队管理者、工程经理也是一样。你的团队能清楚地分辨，你是在坦诚沟通，还是在粉饰太平。比如员工表现不佳，你却拐弯抹角地暗示“要么改进，要么走人”。

而 AI 正在改变这一点。以前我花一个小时写一段“美化版”的绩效总结，工程师可能会反手把它喂给 ChatGPT，问：“Thomas 到底想表达什么？他是不是用 AI 写的？”

我觉得这其实是好事。比如在 AI 驱动的销售流程里，我根本不想收到销售发来的 AI 生成的推销邮件。我只希望有个 AI 能自动删除这些邮件，并告诉他们永远别再联系我。团队管理也是一样。和团队成员、独立贡献者之间建立基于诚实与信任的关系——就像你在家里和伴侣、孩子之间那样——要舒服得多。

以后，你再也无法通过“写得漂亮”来当那个人人喜欢的好经理，却掩盖团队内部的真实问题。我听前任 GitHub CEO 也这么说过——管理这件事，反而可能会变得更有趣。

未来，开发者甚至可能不再需要直接使用传统的编程语言。

AI虚拟机：编程的终极形态？

主持人：
谢谢你。从你现在的团队来看，已经发生的最大变化是什么？你预计今年还会发生什么？

Rajeev Rajan：
最显著的变化无疑是“智能体驱动编程”（Agentic Programming）的兴起，即利用AI智能体来执行任务。在Atlassian，我们的Rovo Dev工具已被所有工程师采用。

具体到代码审查，每天我都能看到通过AI审查的代码变更（diff）比例在显著上升。工程师们提交的拉取请求（PR）数量增加了89%，问题解决周期缩短了42%，并且现在有51%的安全漏洞由智能体完成修复。我们的生产力核心指标——例如DORA指标——都得到了大幅改善。

但比这些数字更重要的是，产品经理、设计师和工程师之间的协作方式发生了根本性转变。我们开发Jira、Confluence等众多产品，这个协作闭环至关重要。如今，产品经理使用Replit等工具，产出的产品规格说明更接近最终形态，极大降低了工程师的实现难度。因此，变化是深刻而广泛的。

那么未来会怎样？

我认为我们将走向“零手写代码”的产品构建模式。目前是人工编码与智能体辅助的混合阶段，但未来我们可能会完全信任智能体进行代码审查。人类的角色将转向输入与输出的验证，确保系统在安全性、可靠性和性能上达标，而非逐行检查代码。

看得更远一些，也许两年后，我们甚至可能不再需要传统的编程语言和IDE，转而由某种“AI虚拟机”处理一切。毕竟，编程语言的存在，是因为我们不想写汇编语言，需要一种更高效的方式向计算机下达指令。如果AI能直接理解意图并执行，甚至完成调试，那么开发将完全上升到“意图层面”，传统的编程形式或许真的不再必要。这听起来有些极端，但并非不可想象。

企业面临新挑战：飙升的Token成本与重燃的编程乐趣

Thomas Dohmke：
从CEO的视角看，我认为有两个剧烈变化。首先是成本的飙升。任何管理大型团队的人都有固定的运营预算：主要是工资、福利和差旅。现在，突然增加了可变的AI token消耗成本。开发者效率越高，token消耗就越大，成本也就越高。甚至出现了一种反转现象——你不得不考虑让开发者“慢一点”，因为他们消耗了太多token。而他们的反应可能是：“那我就少做点功能。”

创业公司通常在资金耗尽时才面临类似压力。但大型企业的管理者必须与财务团队重新设计预算模型，传统方法已经失效。实际上，你希望团队能更多地消耗token（以提升产出）。今天早上有人提到OpenAI消耗了数十亿token却“不用付钱”，这当然不是真的，他们需要为GPU资源向云服务商付费。但这确实彻底改变了团队管理的方式。

不过，没有人会为了平衡token成本而去裁员——那样做所付出的人力代价，将远高于其收益。

积极的一面是：写代码又变得有趣了。 90年代初，我在Commodore 64上学习编程，后来用带Turbo开关的386 DX40。我记得当时遇到难题，只能翻书，或者每周三去计算机俱乐部求助。常常带着挫败感入睡，期待第二天灵光乍现。

后来有了互联网和论坛，可以向他人求助。而现在，你可以在三秒钟内让AI智能体帮你解决问题。

我们低估了这些智能体的力量。大家总聚焦于“代码生成”，但我觉得更棒的应用场景是：当终端里冒出一个棘手的构建错误或npm报错时，你可以直接把它丢给AI，说：“帮我解决，我不想管这些。”这比过去轻松太多了。

单元测试也是。有谁真的喜欢写单元测试呢？（观众反应）对吧，没几个人。

现在你可以直接说：“给我写单元测试”或者“修复这些测试”。编程重新变得有趣了，它让我们找回了最初学习编码时的那种快乐。

大约一个月前，我拜访了OpenAI。他们向我们展示了新的Codex Mac应用（当时还签了保密协议，现在已发布）。现场有演示，然后大家开始编码。我用SwiftUI构建了三个原生Mac应用，几乎没看一行代码。我还做了一个菜单栏应用——昨天有人在X上说他特别喜欢开发这类应用。

现在这一切真的太容易了。如果你曾尝试自己动手，跑去GitHub、Google或Stack Overflow搜索答案，哪怕只是想用Xcode创建一个项目、隐藏Dock图标并仅显示在菜单栏，往往在第一个构建完成之前，你的耐心就已耗尽，最初的创意火花也早已熄灭。我认为这真的非常不可思议。

无论是对我们当年出于兴趣所做的、并将我们带入这个行业的小项目，还是在Atlassian、ENTIA或GitHub进行的正式工作，这种转变都同样适用。这才是真正令人震撼的地方。

生产力提升当然很棒：CFO、CEO、上市公司的股东都会喜欢。但对我们开发者而言，更重要的是：这份工作又变得有趣了。百分之百。我真的很喜欢这种感觉。

主持人：
太棒了。非常感谢Rajeev，也感谢Thomas，尤其是这样一个精彩的收尾。今天的分享非常精彩。谢谢你们。

参考来源： https://www.youtube.com/watch?v=fYh1CWadxDM

关注“鲸栖”小程序，掌握最新AI资讯