Chris Lattner creó LLVM en 2000, una infraestructura de compilación que, 25 años después, sigue impulsando Rust, Swift, , Julia... Su enfoque dice algo esencial sobre el vibe coding, la deuda técnica y lo que distingue a los desarrolladores que perduran de aquellos que simplemente sobreviven.
Hace unos días escuché una conversación entre Jeremy Howard (fast.ai) y Chris Lattner, el creador de LLVM, Swift y Mojo. Una hora de conversación serena y sensata. Sin diapositivas ni exageraciones. Solo dos ingenieros que se niegan a dejarse llevar por el pánico generalizado.
La escuché entera de una sentada. Eso casi nunca me pasa.
Porque lo que dice Lattner me llegó de lleno. No como una conferencia lejana sobre «el futuro del desarrollo». Más bien como un espejo ante 18 años de decisiones de diseño, refactorizaciones y aplicaciones mantenidas, abandonadas o reescritas desde cero.
La pregunta central que plantean es sencilla. Casi trivial.
¿Cómo se construye un sistema que dure más de seis meses?
La respuesta no tiene nada de sencilla.
LLVM: el compilador que nadie pidió
Navidad del año 2000. Chris Lattner, estudiante de doctorado, empieza a escribir LLVM por su cuenta. No para resolver un problema concreto. No para responder a un encargo. Sino para responder a una pregunta fundamental: ¿qué debería ser, en esencia, una infraestructura de compilación?
Veinticinco años después, LLVM está en todas partes. Rust, Swift, Julia: lenguajes enteros se han construido sobre él. Clang, el compilador de C/C++/Objective-C que creó el propio Lattner, es el frontend oficial, el que funciona dentro de Xcode desde 2013, detrás de cada compilación de cada aplicación para iOS.
No es suerte. Es arquitectura.
Y para entender por qué se mantiene tan bien, hay que comprender un concepto clave del diseño de LLVM: la representación intermedia, o LLVM-IR.
La idea es elegante. En lugar de compilar C++ (o Swift, o Rust) directamente a código máquina —lo que obligaría a reescribirlo todo para cada procesador y cada arquitectura—, LLVM introduce un paso intermedio universal. Cada lenguaje se traduce primero a LLVM-IR. Después, LLVM transforma esa IR en código máquina optimizado para el destino: un iPhone, un Mac con Apple Silicon o un servidor Linux.
Piensa en ello como un traductor que utiliza una lengua puente. Hablas francés, inglés o español: da igual. Todo pasa primero por el esperanto y, desde ahí, se traduce al destino final.
Este proceso de tres etapas —código fuente → IR → código máquina— es lo que permitió que Rust existiera sin tener que reescribir un compilador completo, que Swift funcionara en el iPhone desde el primer día y que Xcode utilizara LLVM en producción durante años. Conecta un nuevo lenguaje por delante. Conecta un nuevo procesador por detrás. El núcleo no se mueve.
Eso es partir de los primeros principios. No una solución para hoy. Una base para lenguajes que aún no se han inventado.
«Los sistemas que se derrumban bajo su propio peso lo hacen porque su arquitectura estaba mal planteada desde el principio. Los que perduran lo hacen porque alguien se tomó el tiempo necesario para entender qué estaba construyendo y por qué». — Chris Lattner
Reconozco esta forma de pensar. Es exactamente lo que distingue una aplicación para iOS que aguanta dos años de otra que estás reescribiendo desde cero a los seis meses. No se trata de la calidad del código en el sentido sintáctico. Se trata de la calidad del razonamiento previo al código.
La arquitectura es lo que no se ve, pero lo que lo decide todo.
Vibe coding: síntoma de una época
Hoy el mandato está claro: lanza rápido, lanza a menudo, utiliza la IA para ir diez veces más rápido. Hay directores ejecutivos que presumen públicamente de que sus equipos generan 10.000 líneas de código escrito por IA al día.
10.000 líneas al día.
Lattner tiene una expresión para eso: una métrica inútil. O peor aún, peligrosa.
«No soy un director ejecutivo que presume del número de líneas generadas por IA. Lo veo como un pasivo, no como un activo. Lo que importa es: ¿está mejorando el producto? ¿Entiende la gente lo que está construyendo?»
El vibe coding —poner en marcha un bucle de agentes y esperar que salga algo útil— es apostar disfrazado de productividad. Howard lo expresó exactamente así: «Es como tirar de la palanca de una máquina tragaperras. Pierdes y vuelves a tirar. Pierdes y vuelves a tirar».
La historia que me dejó helado
Lattner cuenta un caso concreto. Se notifica un error, un ingeniero sénior pone en marcha un bucle de agentes y se genera una PR. La PR supera las pruebas. El error «desaparece».
Pero no había desaparecido. Se había ocultado el síntoma. Bajo la superficie, la base de código acababa de absorber una bomba de relojería: código en el lugar equivocado, haciendo algo que no debía y a punto de crear tres errores nuevos más sutiles que el primero.
El código se había fusionado sin que nadie entendiera realmente qué hacía.
Eso no es un problema de herramientas. Es un problema cultural. Una cultura que ha aprendido a hacer desaparecer los síntomas en lugar de comprender las causas.
Qué significa esto para un desarrollador de iOS
Llevo creando aplicaciones para iOS desde 2007. He visto ir y venir paradigmas: Objective-C, ARC, Swift, SwiftUI, MVC/MVVM/TCA. He reescrito aplicaciones enteras. He mantenido otras durante años.
Y puedo decirte una cosa: la deuda técnica nunca duerme.
Espera. Se acumula. Y despierta en el peor momento: cuando tienes una fecha límite, cuando Apple lanza una nueva versión de iOS, cuando un usuario informa de un error que ya no entiendes porque la persona que escribió ese código ya no está. O fuiste tú, hace tres años, y ya no recuerdas el razonamiento.
La IA no ha cambiado esa realidad. La ha acelerado.
Con Onyria, tomé una decisión consciente: utilizar la IA como acelerador, no como arquitecto. Las decisiones estructurales —cómo gestionar los créditos de los usuarios, cómo orquestar las llamadas a la API de Reve, cómo sincronizar datos entre dispositivos mediante SwiftData sin un servidor externo— son mías. La IA puede ayudarme a escribir código repetitivo, explorar alternativas y detectar casos límite. Pero no puede comprender por mí las restricciones del ecosistema de Apple.
Eso son 18 años de experiencia hablando. Y eso no se automatiza.
La bifurcación
Howard hace un diagnóstico que me dejó paralizado:
«Va a haber dos grupos. Quienes hayan desarrollado indefensión aprendida, quienes ya no sepan realmente qué hacen sin la IA. Y ese grupo más pequeño sobre el que todos se preguntarán: “¿Cómo sabe tanto esta persona? Es increíble”».
Ya lo estamos viendo. Los tiempos de revisión de la App Store se están alargando porque el volumen de envíos se está disparando, pero la calidad no. Apple está endureciendo sus directrices (4.1, 4.2, 4.3) contra las aplicaciones clonadas generadas mediante prompts. El listón está subiendo.
Para los desarrolladores que realmente entienden lo que están construyendo, son buenas noticias. El ecosistema se está depurando. La competencia profesional se convierte en una ventaja competitiva real, no solo teórica.
La pregunta que Lattner hace a cada ingeniero es directa:
«Cuando se calme la euforia —y siempre se calma—, ¿dónde estarás? ¿Habrás crecido? ¿O habrás pasado dos años tirando de palancas, esperando que la IA te hiciera mejorar por ósmosis?»
Cómo utilizo realmente la IA
Lattner utiliza la IA. Habla de un aumento de productividad del 10–20 %. Pero mantiene lo que denomina un bucle de iteración corto: editar, compilar, ejecutar, depurar. En todo momento sabe qué está haciendo su código.
Ese es exactamente mi enfoque.
La IA me ayuda a:
- Explorar una API con la que aún no estoy familiarizado
- Generar código repetitivo que no quiero escribir a mano
- Cuestionar mi arquitectura antes de comprometerme con ella
- Detectar casos límite que podría haber pasado por alto
Lo que no hace por mí:
- Decidir la arquitectura
- Comprender las restricciones del negocio
- Mantener la coherencia a lo largo del tiempo
- Validar que el resultado tenga sentido en el contexto general
La diferencia entre ambas cosas es la diferencia entre una herramienta y una muleta. Una herramienta amplifica lo que ya sabes hacer. Una muleta compensa lo que no sabes y te impide aprender.
Con qué me quedo
La entrevista de Lattner no es un manifiesto contra la IA. Es un recordatorio de que los fundamentos no están obsoletos.
Arquitectura. Comprensión. Oficio.
Los mismos principios que han permitido que LLVM siga funcionando 25 años después de su creación. Los mismos que hacen que una aplicación para iOS bien diseñada resista, evolucione y sobreviva a los cambios de plataforma.
La IA es una herramienta extraordinaria. Pero las herramientas nunca han sustituido al criterio.
Y el criterio se forja en las trincheras: en los errores que tardaste tres días en comprender, en las dolorosas refactorizaciones que llevaste hasta el final, en las decisiones arquitectónicas de las que te responsabilizaste a lo largo del tiempo.
Lo que define tu valor como desarrollador no es lo que genera la IA. Es lo que entiendes de aquello que genera.
La entrevista completa está disponible enfast.ai_. La recomiendo encarecidamente.
Aquí tienes el vídeo.
_