El gap invisible: por qué tu código de IA se rompe cuando sale de tu máquina
El lado oscuro del vibe coding: cuando tu app muere en producción
Vamos a ser directos: el vibe coding es una revolución. Le describes a tu AI lo que necesitas, lo ves construir la solución, los tests pasan en verde, y publicas. Se siente como magia. Hasta que deja de serlo.
Ese "hasta que" suele aparecer a las 3 de la madrugada. Tu aplicación arranca sin problemas, maneja las primeras solicitudes con elegancia, y luego el reaper de OOM la liquidan sin ceremonia. O abre diez mil file descriptors y se desploma. O funciona perfectamente con tus datos de prueba y se derrumba cuando los usuarios reales aparecen.
El código estaba correcto. Resolvía el problema exactamente como lo especificaste. Solo asumía memoria infinita y file handles infinitos, porque nada en tu prompt decía lo contrario.
El asesino silencioso: las suposiciones que nadie menciona
Este es el punto tricky del vibe coding que nadie menciona en las conferencias. Cuando escribes código tú mismo, cargas modelos mentales de restricciones a todas partes. Sabes que estás corriendo en una laptop con 16GB de RAM. Conoces los límites de file descriptors del servidor de producción. Sabes que ese CSV de 400GB no es algo que puedas cargar entero en memoria.
Pero cuando una AI escribe tu código, esas restricciones no existen. La AI ve "carga el archivo, ordénalo, escribe el resultado" y piensa: perfecto, lo cargo todo. Funciona de maravilla en testing. El archivo de prueba tiene 50KB.
Los code reviews tampoco van a detectar esto. Las líneas problemáticas se ven completamente razonables. Nada levanta alertas cuando buscas errores de lógica, porque no los hay. El bug no está en la lógica; está en la caja invisible donde esa lógica fue diseñada para caber.
¿Y si el compilador supiera de recursos?
Aquí es donde la cosa se pone interesante. Un desarrollador llamado Nicolas Grislain lleva tiempo experimentando con una idea provocadora: ¿qué pasaría si las restricciones de recursos fueran tipos, no comentarios?
En vez de esperar que tu código generado por AI respete los límites de memoria, ¿qué tal si el compilador simplemente se niega a compilar código que los viola? ¿Qué tal si "esta función nunca mantiene más de 100 registros en memoria" y "este programa nunca tiene más de 3 archivos abiertos al mismo tiempo" fueran hechos verificados por el compilador, no oraciones que susurras durante el code review?
Esto no es solo teoría abstracta. El experimento usa Lean 4 — sí, el mismo Lean que ha estado haciendo ruido en matemáticas formales — para codificar presupuestos de recursos directamente en los tipos de funciones. El compilador se convierte en un auditor de recursos, verificando automáticamente que tu código se mantiene dentro de los límites antes de que jamás se ejecute.
Haciendo que los recursos cuenten
El truco central es sorprendentemente elegante: se pasan cuentas de recursos a través del sistema de tipos. En vez de trackear "cuántos archivos están abiertos" como una variable runtime que podría ignorarse, el sistema de tipos lo rastrea como un parámetro fantasma que debe cuadrar.
Cuando abres un archivo, la firma del tipo refleja el cambio: entras a la función con N archivos abiertos y sales con N+1. Cuando lo cierras, vuelves de N+1 a N. El compilador rastrea esto en cada paso, y literalmente no puedes compilar código que abra un archivo sin cerrarlo, o que abra archivos más allá de un límite definido.
La memoria funciona de manera similar, pero con un giro. Los registros no flotan libremente en memoria, viven en un pool acotado con un número fijo de slots. No sostienes un objeto Event; sostienes una referencia a ese pool. El tipo rastrea cuántas referencias activas existen en cualquier momento, y la asignación requiere prueba de que hay espacio.
La magia ocurre en el punto de entrada: el programa debe empezar con cero recursos en uso y terminar con cero. No puedes hacer leak de handles ni refs. No puedes exceder los caps. El compilador simplemente no te deja.
Por qué esto importa para el vibe coding
Este enfoque transforma cómo pensamos al hacer prompting a asistentes de AI. Hoy, podrías añadir una nota como "ten cuidado con el uso de memoria" o "cierra todos los file handles", esperando que la AI preste atención. Con tipos aware de recursos, especificas las restricciones formalmente, y la implementación debe reorganizarse para satisfacerlas.
La AI obtiene la versión sin restricciones primero. Los tests pasan. Luego habilitas los límites. El compilador rechaza inmediatamente la implementación. La AI debe reestructurar su enfoque — quizás procesando el archivo en chunks en vez de cargarlo todo de golpe, o usando un connection pool en vez de abrir archivos directamente.
La implementación no solo happens to work; funciona probadamente dentro del presupuesto.
La realidad práctica
Seamos claros: esto no es tooling production-ready para la mayoría de equipos todavía. El enfoque con Lean 4 requiere setup significativo, y hay overhead en pensar en términos de tipos indexados. Pero la intuición subyacente es valiosa sin importar la implementación.
Cuando haces vibe coding, estás outsourciendo no solo la escritura del código sino el modelo mental de tu sistema. Tu asistente de AI no conoce tu entorno de producción. No sabe que tu container tiene 512MB de RAM. No sabe que tu kernel de Linux limita los file descriptors a 1024.
Mientras esperamos mejores formas de codificar estas restricciones, tenemos algunas opciones pragmáticas:
Sé explícito en los prompts — "El archivo de entrada puede contener hasta 10 millones de filas" funciona mejor que "maneja archivos grandes eficientemente"
Testea con datos a escala de producción — Si tus datos de training son tiny, tu AI no va a aprender patrones de recursos
Usa APIs con límites — La arquitectura que naturalmente limita el uso de recursos (connection pools, streaming en vez de cargar todo) es más difícil de usar mal
Vigila las herramientas aware de recursos — La industria está empezando a explorar formas de hacer las restricciones explícitas en código generado por AI
La línea de fondo
El dirty secret del vibe coding no es que escriba código con bugs — es que escribe código correcto dentro de un espacio de restricciones invisible. Ese espacio incluye tu laptop, tu entorno de test, y tal vez tus primeros mil usuarios. Definitivamente no incluye "producción a escala."
Los sistemas de tipos aware de recursos como este experimento con Lean 4 apuntan hacia un futuro donde "correcto" significa más que "lógicamente right". Significa "probado para mantenerse dentro de los límites que realmente existen."
Ese es un futuro vale la pena construir. Hasta entonces, mantén tus datos de test cerca del tamaño de producción, y quizás añade una nota extra en tus prompts sobre esos límites de file descriptors.
Tu futuro yo de guardia te lo agradecerá.