Scarf Migrates from Haskell to Python to Optimize for AI-Driven Development
Scarf Migrates from Haskell to Python to Optimize for AI-Driven Development
AI Agents Have Shifted the Economics of Software Development
Scarf has transitioned its new API development from Haskell to Python because the rise of Large Language Models (LLMs) and AI coding agents has made slow compilation times a dominant cost in the development cycle. While Haskell provided reliability and strong type safety for seven years in production, the speed of AI-generated code now outpaces the speed of the Haskell compiler, creating a bottleneck that hinders parallel, agent-led experimentation.
The Bottleneck: Cold Starts and Parallel Workflows
In a traditional human-led workflow, a long compile cycle is an annoyance but often tolerable because the human spends significant time writing the code. However, AI agents can draft plausible changes in minutes. When the development loop includes a 15-minute cold build, the compiler becomes the primary constraint on productivity.
This issue is magnified in parallel workflows. Scarf's desired workflow involves:
- Spinning up multiple worktrees simultaneously.
- Forking different lines of work for various agents to explore.
- Rapidly reviewing and discarding results.
Because Haskell environments often require complex cache setups (via Nix or remote builders) and high memory usage, the "tax" of starting new threads of work multiplies. While incremental builds can be fast, the cold-start and deep-change cases—which are common in agent-heavy workflows—remain prohibitively slow.
Transition Strategy: Incremental Migration
Scarf avoided a risky "big bang" cutover by deploying a Python API server alongside the existing Haskell one. The migration follows these rules:
- New functionality: All new API routes are written in Python.
- Existing functionality: Haskell code continues to run until the specific functionality is touched and ported.
- Porting process: LLMs were used to port existing Haskell logic to Python, a process that was significantly faster and more straightforward than manual porting would have been historically.
The company reports that the time previously spent wrestling with the toolchain has been reallocated to shipping features and increasing test coverage. The result is a faster "customer call to deployment" pipeline, where bug fixes can sometimes be live before a support call ends.
The "AI Era" Challenge for the Haskell Ecosystem
Scarf argues that Haskell is in danger if it does not optimize for AI as a first-class user. The author suggests that the community's focus on type system research (e.g., dependent types) should be deprioritized in favor of industrial needs:
- Reducing cold build times and project bootstrap friction.
- Improving documentation with copy-pastable, realistic examples rather than just abstract types.
- Enhancing error messages to be more agent-friendly, allowing LLMs to repair code faster.
- Increasing high-quality training data for models to better understand Haskell patterns.
Community Perspectives and Counterpoints
The decision to move to Python sparked significant debate among developers, highlighting a divide in how AI affects language choice:
The Case for Strong Types in the AI Era
Some developers argue that strong type systems are more important when using LLMs because they act as guardrails for the "junk" AI often produces.
"I can't imagine using a language without a good type system to catch all the junk the LLM produces." — @noelwelsh
Others suggested that Scarf could have moved to a language that offers both type safety and fast compilation, such as OCaml or Go, rather than moving to a dynamically typed language like Python.
The Case for Productivity and Iteration
Conversely, some engineers find that static types are less critical when the iteration loop is fast enough. One developer noted that moving to Elixir increased their productivity because bugs related to incompatible types became rare compared to operational bugs like queue lengths and API errors.
Operational Concerns
Critics of the move to Python pointed out that while compilation is faster, Python introduces its own set of frictions, specifically regarding dependency management and versioning across different operating systems.
The "Vibe Coding" Critique
Some observers characterized the move as a shift toward "vibe coding," where the rigor of a compiler is replaced by the speed of agentic iteration and a reliance on extensive test suites to catch errors that the type system previously prevented.