Un programador en solitario construyó un compilador de C con ayuda de inteligencia artificial y lo hizo arrancar Linux. La historia nos lleva a principios de octubre de 2026, cuando el proyecto KCC apareció en Hacker News con un titular que parecía exagerado y acumuló debate durante días, según el hilo original. El coste declarado del experimento fue de 100 dólares al mes en llamadas a un modelo, sin agentes autónomos ni equipo detrás.
Un compilador es el programa que traduce el código que escriben las personas a instrucciones que entiende el procesador. El lenguaje C sigue siendo la base del kernel de Linux, así que compilar el kernel con un compilador nuevo es como pedirle a un estudiante que traduzca una novela entera sin perder el sentido. Si la traducción tiene errores, el sistema no arranca o se comporta de forma extraña al primer uso exigente.
KCC ya compila su propio código, supera buena parte de las pruebas estándar y arranca un kernel real, según resumió el blog de Vikrant Sharma el 2 de octubre. Una semana después del anuncio, conviene explicar qué construyó su autor, dónde están los límites y por qué este caso dice más sobre programar con IA que muchos debates abstractos.
¿Qué es exactamente KCC y quién lo hizo?
KCC es un compilador para C17, la versión moderna del lenguaje, desarrollado en solitario con un modelo de lenguaje como copiloto. El autor trabajó por fases clásicas, primero el preprocesador que expande macros, después el analizador que entiende la gramática y al final el generador que emite código x86 de 64 bits. El repositorio, publicado como kcc en GitHub, documenta ese avance paso a paso en el historial de cambios.
El enfoque se describe como programa literario, una técnica donde el código y la explicación conviven en el mismo documento para que otra persona pueda seguir el razonamiento. Está escrito en ensamblador ARM64, una decisión austera que obliga a entender cada detalle de bajo nivel. Esa combinación de herramienta moderna para generar borradores y disciplina clásica para revisarlos es la que define el proyecto.
El dato económico es el que más vueltas dio en los comentarios. Cien dólares mensuales de API sitúan el experimento al alcance de un aficionado con tarjeta y curiosidad, lejos de los presupuestos de laboratorio. No incluye las horas del autor, que fueron muchas, pero rebaja la barrera de entrada a un terreno que pedía meses de manuales.
¿Cómo se demuestra que un compilador funciona?
Decir que compila no basta, porque hasta los compiladores de juguete traducen ejemplos sencillos. La prueba seria combina tres niveles que KCC ya supera en parte. Primero se autocompila, es decir, compila su propio código fuente y el resultado vuelve a compilarlo, lo que descarta errores gordos de traducción.
Después llegan las pruebas de conformidad, donde se mide qué porcentaje del estándar respeta. Las crónicas hablan de alrededor del 80 por ciento de aprobados en las baterías habituales, una cifra modesta para producción pero notable para un proyecto individual. Significa que la mayoría de construcciones cotidianas funcionan, aunque queden esquinas oscuras por pulir.
La tercera prueba es compilar programas reales y exigentes. KCC ya procesó SQLite, la base de datos empotrada que vive en millones de móviles, y el clásico DOOM, además del propio kernel de Linux. Cada uno estresa una zona distinta, desde optimizaciones delicadas hasta ensamblador insertado que pocos compiladores novatos digieren.
| Prueba |
Qué exige del compilador |
Estado en KCC |
| Autocompilación |
Traducirse a sí mismo sin romperse |
Conseguida |
| Conformidad C17 |
Respetar el estándar en casos raros |
Alrededor del 80 por ciento |
| SQLite y DOOM |
Código real con trucos y macros |
Compilan y ejecutan |
| Arranque de Linux |
Ensamblador y reglas de estructuras |
Kernel que arranca |
Artículo relacionado: Ubuntu lleva Rust al corazón de Linux con sus coreutils
¿Por qué arrancar Linux es la prueba reina?
Compilar el kernel es un examen cruel porque el kernel no es C normal. Mezcla macros complejas que generan código, atributos específicos de GCC, ensamblador insertado para hablar con el hardware y reglas estrictas sobre cómo se alinean las estructuras en memoria. Un compilador de juguete suele naufragar en la primera de esas cuatro, así que llegar al arranque demuestra una cobertura sorprendentemente amplia.
El arranque no significa que KCC pueda sustituir mañana a GCC o Clang en distribuciones serias. Significa que maneja lo maldito del lenguaje, eso que rompe a casi todos los proyectos de fin de semana. Para quien programa sistemas, esa diferencia entre hola mundo y kernel que arranca es la que separa el prototipo del instrumento.
Conviene recordar cuándo ocurrió, porque el contexto ayuda a calibrar. El hilo se publicó el 1 de octubre de 2026 y los resúmenes llegaron el día 2, con el código ya disponible para inspeccionar. No hablamos de una promesa de laboratorio para dentro de dos años, sino de un repositorio que cualquiera puede descargar y probar hoy.
¿Qué papel jugó el modelo de lenguaje?
El autor usó el modelo como programador pareja, no como fábrica autónoma. Le pedía fragmentos de código, aclaraciones sobre esquinas del estándar C y ayuda para cazar fallos de segmentación, esos errores donde el programa toca memoria que no debe. El humano decidía la arquitectura, revisaba cada fase y reescribía lo que venía sutilmente mal.
Ese matiz enfada a los dos bandos del debate, lo cual suele ser buena señal. Quienes temen que la IA sustituya a programadores ven aquí un contraejemplo, porque sin criterio sobre compiladores el proyecto no avanza. Quienes creen que la IA no sirve para software serio ven otro, porque el ritmo de iteración se multiplica cuando alguien propone borradores incansablemente.
Lo que no publica el repositorio es igual de interesante. Faltan los registros de indicaciones, cuántas veces el modelo inventó un nombre de registro o propuso una codificación x86 incorrecta. Esa suciedad del proceso ayudaría a otros a repetir el camino sin tropezar en las mismas piedras. Ojalá futuros experimentos documenten también sus callejones sin salida.
Un experimento que todavía flojea
La conformidad parcial implica que uno de cada cinco casos exigentes puede fallar de formas sutiles. En C, un error sutil no siempre rompe la compilación, a veces genera un binario que falla meses después en producción. Por eso la cifra del 80 por ciento debe leerse como punto de partida y no como sello de calidad.
Tampoco conocemos el comportamiento en optimizaciones agresivas, donde los compiladores modernos ganan velocidad reordenando operaciones. Ni la calidad de los mensajes de error, que es lo que más ayuda a un principiante. Ni el soporte para arquitecturas distintas de x86 de 64 bits, que es donde viven móviles y servidores eficientes.
El escepticismo sano se aplica también a la cifra económica. Cien dólares de API no miden las horas del autor ni su experiencia previa, y repetir el proyecto sin base de sistemas costaría mucho más tiempo. El titular vende baratura, pero el mérito sigue siendo humano y considerable.
Artículo relacionado: NixOS, Silverblue y MicroOS, el Linux inmutable explicado
Un compilador casero que invita a construir
KCC no va a desbancar a GCC esta década, y su autor tampoco lo pretende. Su valor está en demostrar que una sola persona curiosa, con un presupuesto mensual modesto y un modelo como ayudante, puede levantar infraestructura de verdad hasta arrancar Linux. Esa imagen, un kernel arrancando desde un compilador nacido en casa, resume bien el momento que vive la programación en octubre de 2026.
Si te apetece seguir el caso, clona el repositorio, compílalo y prueba sus ejemplos antes de fiarte de titulares. Ejecuta primero la batería de pruebas incluida y anota qué casos fallan en tu máquina, porque esa lista es tu mapa de aprendizaje.
Cuando dentro de unos años alguien pregunte cuándo programar con IA dejó de ser truco, proyectos como este aparecerán en la respuesta. No por sustituir a nadie, sino por devolver a una persona la capacidad de construir herramientas grandes.
