诺达·达内利亚，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 代理，它们可以生成后端代码，但不想与云配置作斗争。我们不再只服务于传统的工程师。受众已经爆炸性增长。

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

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

团队仍然在挣扎的方面是部署、基础设施、运维。AI 可能会生成一个 API 端点，但它无法自动创建数据库、存储、队列、网络、权限或部署管道来使其成为现实。后端基础设施还没有跟上代码生成的步伐。

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

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

问题在于可靠性和后果。代码生成是宽容的 – 如果 AI 犯了一个错误，你会立即看到它并修复它。基础设施错误则不同。一个错误的权限、一个错误的资源配置、一个关于成本或安全性的错误假设，可能会在以后才显现出来的问题。

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

这教会了我们一个关键的东西：在生产环境中，智能但没有边界会产生问题。AI 不需要更多的自由。它需要更好的轨道。你必须设计系统，让 AI 能够建议和加速，但不能任其胡作非为。那就是使生产就绪 AI 生成的应用程序比生成代码本身更具挑战性的技术难题。

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

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

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

对于从原型到生产就绪的人来说，这意味着您不需要学习 DevOps。您构建的应用程序在扩展时仍然可以工作。Neptune弥补了“构建”和“可靠运行”之间的差距。

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

Neptune 将代码和基础设施视为一个统一的系统。大多数部署工具都像一个递送服务 – 您给它们一个容器，它们会尝试运行它。这仍然让您负责将云资源、配置、环境变量、密钥和资源分配拼接在一起。

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

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

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

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

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

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

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