Introduction
For seven years, Scarf ran Haskell at the core of its production infrastructure. Not as an exploratory side project, but as the engine of an open-source analytics platform subject to contractual uptime requirements. The choice was deliberate, documented, and championed by a founder who himself sat on the board of the Haskell Foundation. Yet in July 2026, the company announced a gradual migration to Python. The primary reason was neither lack of reliability, nor accumulated technical debt, nor a shortage of skilled engineers. It was compilation time.
The Compiler as the New Bottleneck
Avi Press, Scarf's founder, frames the argument in economic as much as technical terms. In a development workflow augmented by AI agents, the nature of the build cycle fundamentally changes.
The logic runs as follows: a coding agent can produce an implementation in minutes. If the cold build cycle that follows takes a quarter of an hour, the compiler has become the real bottleneck — not the developer, not the complexity of the problem. And when you're running multiple agents in parallel, across multiple worktrees and throwaway exploratory branches, that cost doesn't hit once: it multiplies with every instance.
The old feedback loop had two main steps: compilation and runtime. Today, code generation by a model adds a third step upstream — fast and cheap. This asymmetry reframes the compiler's role: where it once represented acceptable friction in an individual workflow, it can become structurally incompatible with the parallel iteration cadences that agents make possible.
A Methodical Migration, Without the Big Bang
What Scarf's decision illustrates above all is that a stack migration can be conducted with discipline rather than under duress. The strategy is incremental: build new API routes in Python, deploy that server alongside the existing Haskell server, and migrate features progressively as modifications arise. The Haskell code continues to run in production. New development happens in Python.
Porting the existing codebase — facilitated in part by LLMs themselves — has not come at the cost of quality. Test coverage is described as better than it has ever been. Urgent fixes can now be shipped to production within the span of a client call — a concrete metric few engineering teams can afford to ignore.
What This Means for Technical Teams
The Scarf case is not an indictment of compiled languages, nor a pitch for Python. It is a clear illustration of a reality that technical teams will need to factor into their architecture decisions: technology selection criteria shift as development practices evolve.
For decades, evaluating a language meant weighing expressiveness, runtime performance, ecosystem richness, and talent availability. Those criteria remain relevant. But an additional variable is asserting itself as agent-augmented workflows become the norm: compatibility with short, parallel, and partially automated iteration cycles.
A tool that resists this pace — through build times, onboarding friction, or a lack of agent-usable examples — becomes structurally disadvantaged, regardless of its intrinsic qualities. Haskell didn't fail at Scarf. The economic equation around it changed.
For any team revisiting its stack or evaluating a new technical foundation, this variable now deserves explicit weight in the assessment: no longer just "is this language suited to the problem?" but "does this language support our agent-augmented ways of working?" The phenomenon reaches beyond software development: in back-office functions too, AI agents plug into existing tools and shift the bottleneck — no longer execution capacity, but process clarity.