Scarf 从 Haskell 迁移到 Python 以优化 AI 驱动的开发

AI Agent 已改变软件开发的经济学

Scarf 已将其新的 API 开发从 Haskell 迁移到 Python，因为大语言模型 (LLMs) 和 AI 编程 agent 的兴起使得缓慢的编译时间成为了开发周期中的主要成本。虽然 Haskell 在生产环境中提供了七年的可靠性和强大的类型安全性，但现在 AI 生成代码的速度已经超过了 Haskell 编译器的速度，从而造成了阻碍并行、由 agent 领导的实验过程的瓶颈。

瓶颈：冷启动与并行工作流

在传统的以人为核心的工作流中，漫长的编译周期虽然令人烦恼，但通常是可以忍受的，因为人类在编写代码上花费了大量时间。然而，AI agent 可以几分钟内起草出合理的变更。当开发循环中包含 15 分钟的冷启动构建时，编译器就成了生产力的主要约束。

这个问题在并行工作流中被放大。Scarf 期望的工作流包括：

• 同时启动多个 worktrees。
• 为不同的 agent 分叉出不同的工作线以供探索。
• 快速审查并丢弃结果。

由于 Haskell 环境通常需要复杂的缓存设置（通过 Nix 或远程构建器）和高内存占用，启动新工作线程的“税收”会成倍增加。虽然增量构建可以很快，但冷启动和深度变更的情况——这在以 agent 为中心的工作流中很常见——仍然慢得令人望而却步。

迁移策略：增量迁移

Scarf 通过在现有的 Haskell 服务器旁边部署一个 Python API 服务器，避免了风险巨大的“大爆炸式”切换。迁移遵循以下规则：

• 新功能： 所有新的 API 路由都用 Python 编写。
• 现有功能： Haskell 代码将继续运行，直到特定的功能被触及并移植。
• 移植过程： 使用 LLMs 将现有的 Haskell 逻辑移植到 Python，这一过程比历史上的人工移植要快得多，也更直接。

该公司报告称，之前在与工具链搏斗的时间已被重新分配到交付功能和增加测试覆盖率上。其结果是实现了更快的“从客户反馈到部署”的流水线，有时甚至在支持电话结束前，Bug 修复程序就已经上线了。

Haskell 生态系统面临的“AI 时代”挑战

Scarf 认为，如果 Haskell 不针对 AI 进行优化以将其作为一类用户，那么 Haskell 将面临危险。作者建议，社区对类型系统研究（例如，依赖类型）的关注应降低优先级，转而支持工业需求：

• 减少冷启动构建时间和项目引导摩擦。
• 改进文档，提供可直接复制粘贴的、真实的示例，而不仅仅是抽象类型。
• 增强错误消息，使其对 agent 更友好，从而允许 LLMs 修复代码更快。
• 增加高质量的训练数据，以便模型能更好地理解 Haskell 模式。

社区观点与反论点

转向 Python 的决定引发了开发者之间的激烈辩论，突显了 AI 如何影响语言选择的差异：

为 AI 时代下的强类型支持

一些开发者认为，在利用 LLMs 时，强类型系统变得更重要，因为它们可以作为 AI 经常产生的“垃圾”内容的护栏。

"I can't imagine using a language without a good type system to catch all the junk the LLM produces." — @noelwelsh

其他人建议 Scarf 可以转向一种既提供类型安全又提供快速编译的语言，例如 OCaml 或 Go，而不是转向像 Python 这样的动态类型语言。

为生产力与迭代速度

相反，一些工程师发现，当迭代循环足够快时，静态类型就不那么关键了。一位开发者指出，转向 Elixir 增加了他们的生产力，因为与队列长度和 API 错误等运行问题相比，与不兼容类型相关的 Bug 变得非常罕见。

运维操作层面的关注点

对转向 Python 的批评者指出，虽然编译速度更快，但 Python 引入了它自己的摩擦点，特别是关于不同操作系统上的依赖管理和版本控制。

“Vibe Coding” 批评

一些观察者将此举描述为为向“vibe coding”转变，即编译器的严谨性被 agentic 迭代的速度和对广泛测试套件的依赖所取代，依靠测试套件来捕捉之前由类型系统防止的错误。