诺达·达内利亚，Shuttle CEO 和联合创始人 – 采访系列

诺达·达内利亚，Shuttle CEO 和联合创始人 – 采访系列：诺达·达内利亚自 2019 年创立公司以来一直担任 Shuttle 的联合创始人和 CEO，领导公司从早期的 YC Summer 2020 初创公司成长为面向开发者的平台工程公司；在加入 Shuttle 之前，他曾在 Provenance Technologies Ltd 担任首席风险官，负责量化对冲基金策略，并曾在伦敦和谷歌担任技术和数据角色。

Shuttle 是一个开源云基础设施平台，通过从代码注释中推导基础设施来简化后端开发和部署，使开发人员可以专注于编写 Rust 或其他代码，而无需管理单独的配置文件或复杂的云设置；该平台支持快速部署、开箱即用的资源预配和无缝扩展，并被数万名工程师使用，拥有超过 130,000 次部署，旨在将其零配置、AI 辅助体验扩展到所有语言，并与 GitHub Copilot 和 Cursor 等工具集成。

是什么时刻或沮丧最终促使您联合创立 Shuttle，您最初试图解决什么问题？

转折点出现在我领导交易团队的量化对冲基金期间。我们拥有优秀的工程师 – 博士、资深平台人员、机器学习研究人员 – 但即使拥有这样的天赋，云基础设施仍然是持续的瓶颈。构建交易模型或后端服务并不是难点。问题在于部署：安全地将其投入使用、扩展它、连接云服务。这就是一切变慢的地方。在某个时候，我们的工程团队中有超过一半的人都在做 DevOps 工作，只是为了让系统继续运行。

留在我脑海中的不是代码或数学的复杂性。它是看着高能力的人浪费大部分时间与云基础设施斗争，而不是构建真正重要的东西。没有人想做那项工作，但它是不可避免的。这种摩擦 – “我构建了某事物”和“它可靠地运行”之间的差距 – 正是 Shuttle 被创建来解决的。

Shuttle 于 2019 年成立，在今天的 AI 编码工具浪潮之前。您的原始愿景如何随着 AI 辅助开发成为主流而演变？

核心问题保持不变，但 AI 以戏剧性的方式放大了它。当我们开始时，基础设施已经成为强大工程团队的限制因素。当像 Copilot、Cursor 和 Claude 这样的工具出现时，那个瓶颈变得无法忽视。

突然，开发人员可以在几分钟内生成完整的应用程序，但这些应用程序立即遇到了障碍。AI 可以编写代码，但它无法可靠地配置和管理云资源。我们正在解决的差距变得更宽、更紧急。现在，数百万人正在构建原型，但只有很小一部分最终进入生产。

愿景从“让基础设施对开发人员更容易”演变为“让基础设施为整个新一代构建者工作” – 单独的创始人、小团队和 AI 代理，它们可以创建后端代码，但对与云配置搏斗没有兴趣。我们不再只为传统工程师服务。受众已经爆炸式增长。

像 Cursor 和 GitHub Copilot 这样的 AI 工具改变了开发人员编写代码的方式。从您的角度来看，软件生命周期的哪些部分改进得最多，团队仍然在哪里挣扎？

代码生成已经取得了巨大的进步。这个部分几乎已经解决了。你可以描述一个功能，AI就会为其创建框架。前端尤其受益，因为模式已经被很好地理解 – 组件、样式、布局。

团队苦苦挣扎的部分是代码生成之后的所有事情：部署、基础设施、运营。AI 可能会生成一个 API 端点，但它不能自动创建数据库、存储、队列、网络、权限或部署管道来使其成为现实。后端基础设施没有跟上代码生成的步伐。

结果是进展不均衡。事情并没有从头到尾变得更简单，新的压力点出现了。团队可以在几分钟内生成整个后端，但在尝试安全地部署它们时却会卡住数天。有时，AI 使情况变得更糟，因为它会产生比团队实际运行或维护的代码更多的代码。那就是真正的摩擦现在存在的地方。

部署通常被描述为 AI 生成应用程序的最大瓶颈。是什么具体使得这些系统的生产化如此具有挑战性，相比于生成代码本身？

问题在于可靠性和后果。代码生成是宽容的 – 如果 AI 犯了一个错误，你会立即看到它并修复它。基础设施错误则不同。一旦配置错误、资源选择错误或对成本或安全性做出错误的假设，你就会制造出一个真正的问题，这个问题可能不会立即显现出来。

早期，我们尝试让 AI 自由地从应用程序代码中推断基础设施。演示看起来很棒。在真正的系统中，它却崩溃了。AI 会自信地产生设置，几乎是正确的，但不完全正确 – 权限太宽泛，资源选择奇怪，配置会悄悄地变得昂贵。

这教会了我们一些关键的东西：在生产环境中，智能如果没有界限就会制造问题。AI 不需要更多的自由。它需要更好的轨道。你必须设计系统，使 AI 可以建议和加速，但不能肆意运行。那是使生产化 AI 生成的应用程序比生成代码本身更具挑战性的技术难题。

Shuttle 最近推出了 Neptune 作为其平台的下一个演进。Neptune 被描述为通用 AI 平台工程师——这对开发人员从原型到生产就绪后端的意义是什么？

Neptune 作为代码和生产之间的缺失层。从实际角度来看，这意味着开发人员 – 或 AI 代理 – 可以专注于编写应用程序逻辑，而 Neptune 会处理其他一切：了解所需的基础设施、预配资源、管理机密、处理部署、编排服务。

与其让开发人员将应用程序翻译成云基础设施，Neptune 会理解应用程序并在其周围生成基础设施。代码是蓝图。Neptune 会构建运行它所需的环境 – 无需 Dockerfiles、Terraform 或无休止的配置。

对于从原型到生产的人来说，这意味着你不会遇到需要学习 DevOps 的墙壁。应用程序继续按预期工作，当你扩展它时。Neptune弥合了“构建某事物”和“可靠地在生产中运行”之间的差距。

随着开发人员越来越依赖 AI 生成后端系统，如何平衡速度和抽象与控制、安全性和可观察性的需求？

答案是信任。在基础设施中，信任比能力更重要。一次坏的惊喜 – 安全漏洞、部署失败或巨大的云账单 – 你就会失去人们的信任。

我们很早就学会了，AI 触及的任何东西都需要是可理解和可审查的。即使开发人员没有手动配置某些东西，他们仍然需要看到发生了什么以及为什么发生。因此，Neptune 使用确定性基础设施规则。AI 可以建议和加速，但它所做的一切都以可审查、可预测和可测试的规范为基础。

我们做出的转变是从“AI 决定”到“AI 在约束内提出建议”。这就是有趣的演示和真正重要的东西之间的区别。开发人员并没有花费更少的时间做出决定 – 他们花费的时间更少是输入内容，更多的是决定应该存在什么、什么是可以接受的、什么折衷是有意义的。最好的团队把 AI 当作一个非常有能力的初级工程师：有帮助、有生产力，但不负责。

今天，哪些类型的团队从 Neptune 中获得了最大的价值，无论是单独的开发人员、初创公司还是更大的工程组织？

团队的特征已经发生了戏剧性的变化。最初，在 Rust 方面，我们拥有一个多样化的基础 – 单独的开发人员、早期创业公司、成长中的公司，甚至是汽车、物联网、金融、加密货币等领域的企业团队，它们都需要可靠性和性能。这些团队希望在不需要管理复杂云基础设施的情况下拥有 Rust 的强大功能。

但在过去的一年里，AI 驱动的开发的崛起完全改变了谁在构建软件。现在，我们看到单独的创始人、独立开发人员、AI 代理、小团队和传统软件公司都以前所未有的速度生成后端代码。受众不再仅仅是各个领域的高级工程师。

我们经常看到单独的创始人和小团队在一次会议中就能从一个想法到一个部署的后端，因为他们不需要花费数天的时间来设置。它不仅仅是节省时间 – 它是保持动力，这在早期阶段是至关重要的。那就是最强的价值体现的地方：那些可以构建但不想成为基础设施专家的人，只是想让他们的想法变得生动起来。

从技术角度来看，Neptune 如何处理环境配置、机密管理和基础设施编排，以便将 AI 生成的代码转换为可部署的生产后端？

Neptune 将代码和基础设施视为一个统一的系统。大多数部署工具都像快递服务一样运作 – 你给他们一个容器，他们尝试运行它。这仍然让你负责将云资源、编写配置、处理环境变量、处理机密和预配数据库。

Neptune 反转了这种模式。与其让开发人员将应用程序翻译成云基础设施，Neptune 会理解应用程序并在其周围生成基础设施。它是 DevOps 的 AI 本土方法：代码是蓝图，Neptune 会构建运行它所需的环境 – 包括机密管理、环境配置和资源编排。

关键在于，AI 在确定性基础设施规则内工作。它不能产生任意配置。所有内容保持可审查和可预测，这对于生产环境中的安全性和成本控制至关重要。

展望未来，随着 AI 系统越来越多地构建、部署和管理其他软件系统，您如何看待 Neptune 的角色演变？

我们正在迈向一个想法和可用的产品之间的差距几乎为零的世界。很快，产品不仅会更快地构建，而且会根据人们实际使用它们的方式不断改进自己。

在这样的世界里，软件不会是静态的。应用程序、代理和系统将不断被创建、修改和演化。所有这些仍然需要在某个地方运行。它们仍然需要基础设施、权限、资源和可靠性。

我们的长期目标是成为 AI 辅助 DevOps 的默认系统 – 本质上是 AI 平台工程师。不管代码是由 Cursor 中的开发人员编写还是由 AI 代理自主生成，Neptune 都应该是将其从代码转换为完全运行、可扩展、生产级服务的层。

如果创造力变得无边界，基础设施就不能成为限制。如果 AI 代理和自我演化的产品变得正常，我们的工作就是让与云基础设施的交互变得无缝、可预测和安全。我们专注于使其变得不可见，这样开发人员、创始人和公司就可以专注于创造价值，而不是与基础设施搏斗。

感谢这次精彩的采访，希望了解更多的读者可以访问 Shuttle。