Introducción
Durante siete años, Scarf utilizó Haskell en el núcleo de su infraestructura de producción. No como un proyecto exploratorio, sino como motor de una plataforma de analítica open source sujeta a exigencias contractuales de disponibilidad. Una apuesta asumida, documentada y defendida por su propio fundador —miembro del consejo de la Haskell Foundation—. Y sin embargo, en julio de 2026, la empresa anuncia su migración progresiva hacia Python. El motivo principal no es falta de fiabilidad, ni deuda técnica acumulada, ni escasez de talento. Es el tiempo de compilación.
El compilador como nuevo cuello de botella
El argumento de Avi Press, fundador de Scarf, es tan económico como técnico. En un flujo de desarrollo potenciado por agentes de IA, el ciclo de build cambia de naturaleza.
La lógica es la siguiente: un agente de codificación puede generar una implementación en cuestión de minutos. Si el ciclo de compilación en frío que sigue tarda un cuarto de hora, el compilador se convierte en el verdadero obstáculo —no el desarrollador, ni la complejidad del problema—. Y cuando se trabaja con varios agentes en paralelo, sobre múltiples worktrees y ramas exploratorias desechables, este coste no se produce una sola vez: se multiplica en cada instancia.
Antes, el ciclo de retroalimentación tenía dos etapas principales: compilación y ejecución. Hoy, la generación de código por un modelo constituye una tercera etapa —previa, rápida y económica—. Esta asimetría recalifica al compilador: donde representaba una fricción asumible en un flujo de trabajo individual, puede volverse estructuralmente incompatible con las cadencias de iteración paralela que los agentes hacen posibles.
Una migración metódica, sin rupturas abruptas
Lo que ilustra la decisión de Scarf, sobre todo, es que una migración de stack puede llevarse a cabo con método en lugar de urgencia. La estrategia adoptada es progresiva: desarrollar las nuevas rutas de API en Python, desplegar ese servidor en paralelo al servidor Haskell existente y migrar funcionalidades a medida que se realizan modificaciones. El código Haskell sigue corriendo en producción. Los nuevos desarrollos se hacen en Python.
La portabilidad del código existente, facilitada en parte por los propios LLMs, no vino acompañada de una degradación en la calidad. La cobertura de tests es, según el equipo, mejor que nunca. Los parches urgentes pueden desplegarse en producción en el tiempo que dura una llamada con un cliente —una métrica concreta que pocas organizaciones técnicas pueden ignorar.
Lo que esto cambia para los equipos técnicos
El caso Scarf no es un proceso contra los lenguajes compilados ni un alegato a favor de Python. Es una ilustración clara de una realidad que los equipos de tecnología deberán integrar en sus decisiones de arquitectura: los criterios de selección tecnológica evolucionan al ritmo de las prácticas de desarrollo.
Durante décadas, evaluar un lenguaje implicaba sopesar su expresividad, su rendimiento en ejecución, la riqueza de su ecosistema y la disponibilidad de talento en el mercado. Estos criterios siguen siendo relevantes. Pero un parámetro adicional se impone a medida que los flujos de trabajo potenciados por agentes se generalizan: la compatibilidad con ciclos de iteración cortos, paralelos y parcialmente automatizados.
Una herramienta que resiste ese ritmo —por sus tiempos de compilación, sus fricciones de incorporación o la ausencia de ejemplos aprovechables por los agentes— queda estructuralmente en desventaja, independientemente de sus cualidades intrínsecas. Haskell no fracasó en Scarf. Fue la ecuación económica la que cambió a su alrededor.
Para cualquier equipo que esté revisando su stack o evaluando una nueva base tecnológica, esta variable merece ahora un lugar explícito en la evaluación: ya no basta con preguntarse «¿es este lenguaje adecuado para el problema?», sino también «¿soporta este lenguaje nuestros modos de trabajo aumentados por IA?». El fenómeno va más allá del desarrollo de software: también en las funciones de soporte, los agentes IA se integran en las herramientas existentes y desplazan el cuello de botella — ya no es la capacidad de ejecución, sino la claridad de los procesos.