# The Cost of the Compiler in the Age of AI > Source: > Published: 2026-07-11 02:02:50+00:00 [Dev Tools](https://sourcefeed.dev/c/dev-tools)Article # The Cost of the Compiler in the Age of AI Scarf's migration from Haskell to Python reveals how agentic workflows are rewriting the rules of language selection. [Lenn Voss](https://sourcefeed.dev/u/lennart_voss) When a company rewrites its backend, the story usually follows a predictable arc. A startup outgrows its dynamic scripting language, runs into concurrency bottlenecks, and migrates to a statically typed, compiled language like Go or Rust for performance and safety. Scarf, a company building developer tools for open source software distribution, just flipped that script. After seven years of running [Haskell](https://www.haskell.org) in production, Scarf is migrating its core web API to [Python](https://www.python.org). This is not a case of a team struggling with a language they do not understand. Scarf's co-founder and CEO, Avi Press, serves on the board of the Haskell Foundation. The company's engineering team knows the language's ecosystem intimately. They successfully used Haskell to build a high-performance redirect and proxy layer, Scarf Gateway, directly on top of WAI, alongside a main API using Servant and Beam on PostgreSQL. Yet, they are walking away from Haskell for their main API. The reason is not a sudden failure of Haskell's type system or runtime performance. Instead, it is a fundamental shift in the economics of software development brought on by artificial intelligence. Their decision offers a stark, practical lesson for teams evaluating their technical stack in an era where code is increasingly generated by machines rather than written by hand. ## The New Bottleneck: Cold Starts and Disposable Contexts Historically, developers evaluated compilers on a simple axis: how much safety do they provide versus how much time do they take? Haskell sits at the extreme end of this spectrum. Its advanced type system, lack of null values, and compile-time guarantees catch an entire class of bugs before code ever hits production. The tax for this safety is a notoriously slow, resource-intensive compilation process. For a human developer working on a single task, a long compile cycle is a known, manageable friction point. You write code for an hour, kick off a build, grab a coffee, and let the compiler do its work. Large language models and coding agents change this dynamic entirely. When an AI agent can draft a plausible bug fix or a new feature in seconds, the human is no longer the bottleneck. The compiler is. If an agent takes two minutes to write a change but the project takes fifteen minutes to build from a cold start, the feedback loop is broken. This friction multiplies exponentially when you move to parallel, agentic workflows. Modern development is shifting toward spinning up multiple worktrees in parallel, letting different agents explore distinct implementation paths, running tests on those branches, and discarding the ones that fail. In this workflow, cheap, disposable execution contexts are the primary currency. This is where Haskell's tooling fell short for Scarf. While tools like [Nix](https://nixos.org) and remote build caching help optimize the best-case scenario (small, incremental changes), they require significant engineering overhead to maintain. When an agent makes a deep change to core parts of a build plan, or when a new worktree requires a cold build, the caching layers break down. The cost of setting up, caching, and running these heavy environments across multiple parallel agent threads became an unbearable tax. ## The Radical Trade-Off: Haskell to Python Moving from Haskell to Python is a massive architectural leap. You are trading one of the most sophisticated type systems in existence for a dynamic language where runtime errors are a constant risk. For Scarf, the migration is pragmatic and hybrid. They are not touching Scarf Gateway, their performance-critical routing layer. That remains in Haskell, where its speed and low-level control are still required. But for the general-purpose web API, they deployed a Python API server alongside the Haskell one, routing new endpoints to Python and gradually porting old ones over. This transition highlights a major shift in how we think about code correctness. Historically, errors were caught in two places: compile time or runtime. Now, there is a third: code generation time. Because LLMs are trained on vast amounts of Python code, they are highly proficient at generating working Python implementations that avoid common syntax and logical errors before the code is ever executed. Furthermore, porting existing Haskell logic to Python is a highly structured task that LLMs handle with high accuracy. However, the trade-offs of this migration are real, and they should give any developer pause: **The Testing Tax:** In Haskell, the compiler acts as a massive test suite. In Python, you must write exhaustive tests to catch the type mismatches and null pointer exceptions that Haskell would have blocked at build time. If your test suite grows too slow, you simply trade slow compile times for slow test runs.**Ecosystem Gaps:** While Scarf previously struggled with Haskell's immature library ecosystem for things like OAuth and payment processing, Python has the opposite reality. It has a library for everything, but maintaining dependencies in Python comes with its own well-documented packaging headaches.**Type Safety vs. Velocity:** Python's modern type hinting helps, but it is not a replacement for Haskell's compiler. Teams making this move must accept that they are trading absolute compile-time correctness for raw development velocity. ## What This Means for Language Selection Scarf's decision is a warning shot for languages with slow compilers and complex tooling. It is not just Haskell that faces this challenge; Rust, with its notoriously slow compile times, and Scala, with its heavy JVM build chains, are also vulnerable. If the ultimate metric of engineering efficiency is the speed of the entire development feedback loop, languages that prioritize fast startup times and cheap execution contexts will win. This explains the enduring appeal of Go, which combines static typing with incredibly fast compilation, and OCaml, which offers a powerful type system with a highly efficient compiler. For language communities, the lesson is clear. The battle for developer adoption is no longer just about language features, type system research, or runtime performance. It is about how easily the language, its compiler, and its tooling can be integrated into automated, agentic workflows. If a language community ignores build times, onboarding friction, and disposable environment setup, it risks being left behind by teams that prioritize AI-driven velocity over academic perfection. ## Sources & further reading - [After 7 years in production, Scarf has reluctantly moved away from Haskell](https://avi.press/posts/2026-07-10-after-7-years-in-production-scarf-has-reluctantly-moved-away-from-haskell.html)— avi.press - [After 7 years in production, Scarf has reluctantly moved away from Haskell - Links - Haskell Community](https://discourse.haskell.org/t/after-7-years-in-production-scarf-has-reluctantly-moved-away-from-haskell/14380)— discourse.haskell.org - [After 7 years in production, Scarf has reluctantly moved away from Haskell | Lobsters](https://lobste.rs/s/t4f6jt/after_7_years_production_scarf_has)— lobste.rs - [Haskell in Production: Scarf - Serokell](https://serokell.io/blog/how-scarf-uses-haskell)— serokell.io [Lenn Voss](https://sourcefeed.dev/u/lennart_voss)· Cloud & Infrastructure Writer Lenn writes about cloud platforms, Kubernetes internals, and the infrastructure decisions that quietly make or break engineering organizations. Based in Berlin's vibrant tech scene, they have a talent for turning dense platform-engineering topics into prose that people actually finish reading. ## Discussion 0 No comments yet Be the first to weigh in.