本周，科技专栏《The Pragmatic Engineer》在跟 Builder.ai 的几位员工沟通之后，发表了一篇辟谣的文章。
大概事实如下：
-
Builder.ai 确实是搭建了一整套服务软件开发周期的 AI 工具，15 名工程师负责这个项目。
-
背后的技术栈是 Python、Ruby、React 、GPT 和 Claude。
-
但有 300 名工程师用于搭建公司内部工具，这些工具本来去直接购买使用。结果却是重复造轮子。
-
还有 500 名左右的工程师承接一些定制软件开发的外包服务，但公司一直不确定自己的重心是 AI 那套，还是定制软件开发服务。收入也不是很好。
-
因为财务欺诈，没有了资金来源，公司本身又没有什么收入，所以就破产了。
听起来，这个故事从创业的角度来看，似乎更合理一些些。我们对文章进行了简单编译处理。
原文：https://newsletter.pragmaticengineer.com/p/the-pulse-137
超 4000 人的「AI 产品市集」社群！不错过每一款有价值的 AI 应用。
-
最新、最值得关注的 AI 新品资讯；
-
不定期赠送热门新品的邀请码、会员码；
-
最精准的AI产品曝光渠道
01
Builder.ai 并未
「用 700 名工程师伪造AI」
过去一周，媒体与社交网络广泛传播着一个引人注目的新闻：Builder.ai 破产的背后，是公司雇佣了 700 名印度工程师「假扮」AI。
-
「微软投资的 AI 初创公司聊天机器人实为人工操作」——Mashable
-
「Builder.ai 雇佣 700 名印度工程师，号称 AI 驱动」——MSN
-
「Builder.ai 用 700 名工程师伪造 AI，如今面临破产与调查」——Business Standard（印度）
经过与多位 Builder.ai 前工程师交流，我可以确认：这一说法并不属实。
但我们不妨做个思想实验，假如真要让 700 名工程师假扮 AI，2024 年能否实现？类似的骗局历史上并非没有先例……
设计挑战：如何让 700 名开发者假扮AI？
假设我们抛开道德，目标就是让 700 名工程师扮成 AI 系统，且完全不用人工智能。我们会怎么做？
最朴素的做法，是让开发者直接写代码，假定不会有超过 700 个并发会话。
但马上就会遇到一个关键问题：延迟。用户若需等待 10-30 分钟才能收到响应，骗局很快就会暴露。要想让客户信以为真，必须大幅降低响应时间——这就类似 18 世纪「机械土耳其人」骗局：
「Mechanical Turk，也被称为自动下棋机，或简称 The Turk，是一台于 1770 年建造的欺诈性下棋机器，它看起来能与人类对手进行高水平的对弈。在长达 84 年的时间里，它被不同的所有者作为一台自动机器进行巡回展出。
这台机器幸存下来，并继续偶尔进行展览，直到 1854 年，一场大火席卷了存放它的博物馆，摧毁了这台机器。之后，机器所有者的一个儿子发表文章，向公众揭示了它的秘密：这是一个精心设计的骗局，虽然有些人曾怀疑过，但在它还存在的时候从未被公开证实过。」
回到 2024 年，若要降低响应延迟，可以考虑让「指定开发者」实时流式输出代码。效果虽有提升，但依旧无法媲美真正 AI 的速度。
若再通过奖金激励开发者 3 分钟内完成任务，并允许他们使用任何工具，这时会发生什么？
我们成功了！我们成功地伪造了一个足够好的 AI。
但等等……开发者究竟是如何在 3 分钟这个随意设定的时间框架内完成任务的？为了找出答案，我们提出了一些问题，这就是我们看到的（记住，现在是 2024 年）：
等等……什么？！「假装是 AI 的开发者会使用 AI 来按时交付成果？」这在 2024 年是合乎逻辑的方法，因为那时的 LLMs 已经完全有能力生成高质量的代码。而这就是为什么在去年，当已经有 LLMs 能做得更好时，雇佣 700 名开发者来假装 AI 是荒缪的，因为 LLMs 能做得更好。
如果你在 2024 年聘请一位有能力的工程师来设计一个接收指令并假装成 AI 的系统，他们可以使用任何他们喜欢的工具，并且项目有 700 名开发者，那么他们构建出来的东西会是这样的：
剧透：Builder.ai 其实也是这么做的！
02
Natasha 的技术栈
Builder.ai 首次展示 Natasha 的概念是在 2021 年，远在 ChatGPT 发布之前。当时，Natasha 的定位是「个人应用构建器」，并且很明显，该解决方案是通过一个「极客网络」来运作的，这些极客会根据规格构建应用：
「你告诉我们你的想法，我 [Natasha] 和我的极客网络会用真正有效的构建模块来把它做出来。」来源：Builder.ai 2021 年
该产品承诺预先提供成本估算和时间表。其理念是，通过承接数千个项目，Natasha 背后的团队可以创建可复用的构建模块，从而加速网站和移动应用的开发。
2023 年 12 月，在 ChatGPT 发布一年后，Builder.ai 宣布 Natasha CodeGen 为「您全天候的软件开发伙伴」。2024 年 4 月，该公司在一系列视频中演示了 Natasha CodeGen，视频中也展示了代码生成的过程。视频中有一个剪辑，当 React 代码生成后，视频才继续播放。我已与该公司的前工程师确认，在后台，系统在完成代码生成前运行了几分钟：
Natasha 在 2024 年 4 月的日志输出。来源：Builder.ai
Natasha 的目标是成为整个软件开发周期的 AI 工具：
-
创意：通过一个可视化的应用 UI 界面来完善创意
-
规划：在专用的 UI 中创建用户故事（任务）。任务包括创建验收标准。
-
代码生成规划：将任务输入 LLM，以规划代码生成的步骤
-
测试：让 AI 首先遵循测试驱动开发（TDD）方法添加测试，并且只有在测试通过时才创建 PR
-
生成代码：创建代码，并根据测试运行它们
-
创建 PR：仅在所有测试都通过时才执行此操作
一个由 15 名工程师组成的团队负责 Natasha Codegen。 大部分工程师常驻英国，约 3 人在印度。在巅峰时期，Builder.ai 的 AI 团队大约有 30 人。除了构建 Natasha，该团队还在构建和维护许多 AI 产品和服务。一位前工程师告诉我，他认为缺乏重点是导致公司倒闭的原因之一。
Natasha 背后的技术栈：
-
Python：用于协调器，安排代理所采取的步骤
-
Ruby on Rails：用于部分后端和前端
-
React：用于大部分前端
-
GPT 和 Claude：用于集成到代码生成步骤的 LLMs
Natasha 的一些网页组件是使用 Ruby on Rails 构建的。来源：Builder.ai
该团队建立了一套编码基准，每当有新模型发布时，他们都会运行这些基准，并选择最适合其用例的模型。
Natasha 的愿景远不止于成为一个代码生成工具：它是 Builder.ai 内部所有 AI 项目的代号，就像微软用「Copilot」来指代其所有 AI 项目，而不仅仅是 GitHub Copilot。其他使用 Natasha 品牌的产品包括：
-
一个聊天机器人，Builder.ai 的客户和开发者可以与其交谈，讨论他们的代码库，或指示其实现某些功能
-
一个知识图谱：一个向量数据库，存储功能、实现这些功能的模块以及客户用例之间的关系
-
ML 模型：用于预测实现客户要求的规格可能需要多长时间
03
那 700 名开发者是怎么回事？
Builder.ai 拥有一个由大约 15 名工程师构建的可行的代码生成器平台，那么为什么还需要在印度雇佣数百名工程师呢？一方面，Builder 雇佣了 300 名内部工程师，并开始构建内部工具，而所有这些工具本可以简单地购买，包括：
-
Builder Home (客户仪表盘)
-
Builder Meet (类似于 Zoom)
-
Builder Tracker (类似于 JIRA)
-
Builder Whiteboard (灵感来自 Figma：设计师将 Figma 设计导入 Whiteboard，然后使用这些设计创建可点击的线框图和原型。后来，Whiteboard 将 React 代码和组件导出到客户项目的工作文件夹中。)
-
Builder Chat (类似于 Slack)
-
SenseiBot (审查和合并 PR，并将应用部署到测试/预发/生产环境)
Builder.ai 未能像告知投资者的那样快速增长收入，其原因之一很可能是由于这种缺乏重点以及重复造轮子，开发那些早已存在而未构建任何新颖东西的工具。
除了 Natasha，Builder.ai 还销售「外部开发网络」服务。大约有 500-1000 名工程师通过 Globant、TatvaSoft 等外包公司受雇。这些开发者分布在越南、罗马尼亚、乌克兰、波兰等国以及印度。去年，该公司正在开发超过 500 个客户应用。这个外包开发者的数量很可能就是「印度 700 名开发者」这一疯传说法的来源。
Builder.ai 的前工程师告诉我，公司内部对于什么是主要产品存在冲突：是包括代码生成器在内的 Natasha 生态系统，还是 Builder.ai 向客户提供的定制软件开发服务？
该公司用一个 20 人的内部开发团队和 Natasha 构建了 Builder IDE，以帮助数百名外包开发者为客户构建应用。Builder IDE 包含面部识别功能，以验证开发者与系统中的个人资料是否匹配。它还有一个监控使用情况的欺诈检测系统。该系统会标记出承包商申报了 8 小时工时，但在 IDE 中活跃时间不足的情况。
据 Builder.ai 前副产品总监 Yash Mittal 称，两年来开发人员实际工时与记录工时的造假现象十分猖獗。他写道：
「（扩大业务的）主要瓶颈在于我们的外部开发者网络。Builder.ai 的另一项开创性努力是，在全球范围内招募开发者，使用我们的 IDE 在我们的平台上定制解决方案。然而，我们没有预料到随之而来的大量欺诈行为，这导致了一场持续近两年、耗费大量资源的『猫鼠游戏』，直到我们最终将其控制住。」
04
因财务欺诈破产
在出现会计欺诈指控后，Builder.ai 破产了。《金融时报》报道称，一旦财务审计揭示该公司显然在收入方面误导了投资者，公司的贷款方就没收了剩余资金：
「据知情人士透露，Builder.ai 向其审计师提交的临时账目显示，其先前的收入预估被大幅下调。
这些数据显示，先前对 2024 年收入的 2.2 亿美元预估已被修正为约 5500 万美元，而先前报告的 2023 年总销售额 1.8 亿美元将被重述为约 4500 万美元，知情人士补充道。」
贷款方撤回资本给公司账目造成了巨大漏洞，而欺诈指控则确保了没有新的投资者愿意向该业务投入资金。公司的命运就此注定。
我与曾在 Builder.ai 工作的工程师交谈过，他们对这次经历感到失望甚至有些痛苦。我交谈的三位工程师对公司的倒闭感到极度失望，并表示他们没有发现任何警示信号。毕竟，Builder.ai 在 2024 年 4 月还从微软那里筹集了资金——这本身就显示了强烈的信任票。一位开发者告诉我，他信任 Builder.AI 的领导层，因为前首席执行官 Sachin Dev Duggal 就在去年还赢得了安永的「世界年度企业家」奖。
一段神奇历程：2024 年的年度企业家，2025 年被指控误导投资者。来源：安永 (Ernst and Young)
这些工程师做了扎实的工作，创造了一个在能力上感觉与 Devin 和 Factory 等产品相当的 AI 系统。不幸的是，关于 Builder.ai 使用人类开发者假扮 AI 的病毒式说法，让他们担心自己的职业前景会受到影响。
这就是为什么我想分享关于 Builder.ai 技术栈的真相：根本不存在欺骗用户，让他们误以为在与尖端 AI 互动，实则是在与 700 名开发者打交道的阴谋。这些开发者做了扎实的工作，公司的倒闭与他们的努力完全无关。
此外，我很难相信，加入当时这家炙手可热的 AI 公司的开发者们，会对公司高管层发生的阴谋有所了解。
05
假扮 AI 的阴谋从而何来？
那么，关于 700 名开发者假扮 AI 的病毒式说法究竟源于何处？《金融时报》将其追溯到了 X 平台一个账户的这条帖子：
这篇帖子来自一位自称加密货币爱好者、没有任何报道记录的用户，后来被证实是虚假的
这篇帖子中的虚假声明引起了人们的注意，包括金融通讯作者 Linas Beliūnas，他将其分享给了他在领英上的 50 多万粉丝，许多出版物也引用了那篇帖子：
耸人听闻的说法传播得很快，即使是不真实的。来源：Linas Beliūnas 在领英 (LinkedIn) 上的帖子
这是一个很好的提醒，告诉我们核实信源的重要性，以及对社交媒体帖子要格外持怀疑态度。这也适用于我，因为上周本刊物也是报道了这一说法的其中之一。这就是为什么我认为承认错误，并通过与曾在 Builder.ai 工作过的人交谈来了解全部真相至关重要。
如果您的团队希望招聘具有构建真实 AI 系统经验的工程师，Builder.ai 的前员工群体很可能是这类人才的绝佳来源。看到 AI 领域的初创公司因欺诈指控而倒闭令人难过，祝愿曾在 Builder.ai 工作的工程师们好运，找到他们的下一个职位。
（文：Founder Park）
印度it搞不起来是有原因的