Scarf が Haskell から Python へ移行し、AI 主導の開発を最適化

AI エージェントがソフトウェア開発の経済性を変えた

Scarf は新しい API 開発を Haskell から Python に移行しました。これは、大規模言語モデル（LLM）や AI コーディングエージェントの台頭により、コンパイル時間の遅さが開発サイクルの支配的なコストとなったためです。Haskell は 7 年間本番環境で信頼性と強力な型安全性を提供してきましたが、AI が生成するコードの速度が Haskell コンパイラの速度を上回り、エージェント主導の並列実験を妨げるボトルネックが生じました。

ボトルネック: コールドスタートと並列ワークフロー

従来の人間中心のワークフローでは、長いコンパイルサイクルは煩わしいものの、コードを書く時間が長いため許容されることが多いです。しかし、AI エージェントは数分で妥当な変更を下書きできます。開発ループに 15 分のコールドビルドが含まれると、コンパイラが生産性の主な制約となります。

この問題は並列ワークフローでさらに顕著になります。Scarf が目指すワークフローは次のとおりです:

• 複数の worktree を同時に立ち上げる。
• 各エージェントが探索できるように、異なる作業ラインをフォークする。
• 結果を迅速にレビューし、破棄する。

Haskell 環境は Nix やリモートビルダーを介した複雑なキャッシュ設定や高メモリ使用が必要になることが多く、新しい作業スレッドを開始する「税金」が増大します。インクリメンタルビルドは高速になり得ますが、エージェント中心のワークフローで頻出するコールドスタートや大幅な変更ケースは依然として許容できないほど遅いままです。

移行戦略: インクリメンタルマイグレーション

Scarf はリスクの高い「ビッグバン」カットオーバーを避け、既存の Haskell API と並行して Python API サーバーをデプロイしました。移行は以下のルールに従います:

• 新機能: すべての新しい API ルートは Python で実装する。
• 既存機能: Haskell のコードは、該当機能が触れられ、移植されるまでそのまま動作し続ける。
• 移植プロセス: 既存の Haskell ロジックを Python に移植する際に LLM を活用しました。このプロセスは、手動での移植に比べて格段に速く、簡単でした。

同社は、ツールチェーンに費やしていた時間が機能のリリースやテストカバレッジの拡充に再配分されたと報告しています。その結果、バグ修正がサポートコールが終わる前にライブになることさえある、より高速な「顧客からデプロイまで」のパイプラインが実現しました。

Haskell エコシステムに対する「AI 時代」課題

Scarf は、Haskell が AI を第一級ユーザーとして最適化しなければ危機に瀕すると主張しています。著者は、コミュニティが型システム研究（例: 依存型）に注力しすぎており、産業ニーズを優先すべきだと提案しています:

• コールドビルド時間とプロジェクトのブートストラップ摩擦を削減する。
• 実践的でコピー＆ペースト可能な例を用いたドキュメントを充実させる。
• エージェントに優しいエラーメッセージを提供し、LLM がコードを迅速に修正できるようにする。
• 高品質な学習データを増やし、モデルが Haskell のパターンをよりよく理解できるようにする。

コミュニティの視点と反論

Python への移行は開発者間で大きな議論を呼び、AI が言語選択に与える影響に関する分断が浮き彫りになりました。

AI 時代における強い型の必要性

一部の開発者は、LLM が生成する「ジャンク」を防ぐために、強い型システムは むしろ 重要になると主張しています。

"LLM が生成するすべてのジャンクを捕まえるために、優れた型システムがない言語は想像できません。" — @noelwelsh

他の開発者は、Scarf が Python のような動的型言語ではなく、OCaml や Go のように型安全性と高速コンパイルの両方を提供する言語に移行すべきだったと指摘しました。

生産性とイテレーション重視の立場

逆に、あるエンジニアは、イテレーションループが十分に速ければ静的型はそれほど重要でないと述べています。ある開発者は、Elixir に移行したことで、生産性が向上したと述べました。なぜなら、型不一致によるバグが減り、キュー長や API エラーといった運用上のバグが主な課題となったからです。

運用上の懸念

Python への移行を批判する声は、コンパイルは速くなるものの、Python は依存関係管理や OS 間のバージョン管理といった独自の摩擦をもたらすと指摘しています。

「バイブコーディング」批判

一部の観察者は、この移行を「バイブコーディング」へのシフトと捉えています。コンパイラの厳密さがエージェント主導の高速イテレーションと、型システムが防いでいたエラーを捕まえるための大規模テストスイートへの依存に置き換えられた、と評価しています。