Introducción — la ilusión de las especificaciones en inglés
- Inspirado por el texto "una especificación suficientemente detallada es código". Las especificaciones en inglés parecen intuitivamente precisas, pero cuando intentas implementarlas, la ambigüedad sale a la luz
- "Todo es vago hasta que intentas hacerlo preciso" — Bertrand Russell
- Programar, como escribir, es una actividad iterativa que se va afinando y puliendo mientras se hace (este ensayo también pasó por innumerables borradores)
Vibe coding — por qué funciona y por qué es peligroso
- Como la IA convierte cada vez más rápido y mejor el inglés en código ejecutable, ahora se puede crear código a partir del nivel de "sensación" (vibe) del inglés
- Reaccionando al resultado que produce la IA — "mueve el botón para allá, hazlo más azul" — en un proceso que se vuelve cada vez más preciso
- La expresión "vibe coding" es perfecta precisamente por eso: mantiene el vibe del inglés mientras afila el pensamiento a través de lo que produce la IA
- Problema clave: el vibe da la ilusión de ser una abstracción precisa. Cuando aumentan las funciones o crece la escala, la abstracción empieza a filtrar (leaky abstraction) y bugs inesperados te arruinan el día entero
Caso real — la app de vibe coding de Dan Shipper
- La app de editor de texto que Dan Shipper hizo con vibe coding se volvió viral → el servidor se cayó
- La causa: la "colaboración en tiempo real (live collaboration)" parece intuitivamente simple, pero en realidad tiene una complejidad de pesadilla
- Como todos hemos usado Google Docs y Notion, sentimos que "colaboración en tiempo real" es algo especificado con precisión. Es extremadamente difícil darse cuenta de antemano de por qué no lo es
- El propio autor, hace 10 años, también vivió una pesadilla de complejidad inesperada al intentar construir un editor colaborativo. ¿Qué era lo difícil? ¡Ni siquiera lo recuerda! Ese es parte del problema: la complejidad es aburrida, no queremos pensar en ella y es difícil recordar los detalles y los casos límite
- Ejemplo: el clásico diagrama de flujo de Slack para decidir si debe enviar una notificación — ese nivel de complejidad está escondido detrás de una frase aparentemente simple como "enviar una notificación"
Abstracción — la única herramienta para lidiar con la complejidad
- Límite fundamental del cerebro humano: solo puede manejar 7±2 elementos a la vez
- La única forma de manejar más de 7 es comprimir varios en uno. Como esto puede repetirse recursivamente hasta el infinito, los humanos podemos tratar con complejidad infinita. Ese paso de compresión es justamente la abstracción (abstraction)
- "El propósito de la abstracción no es ser vago, sino crear un nuevo nivel semántico en el cual uno pueda ser absolutamente preciso" — Dijkstra
- El caso en que Sophie Alpert refactorizó el infame diagrama de flujo de notificaciones de Slack y lo simplificó muchísimo con una abstracción inteligente
- La mejor parte de programar: conquistar la complejidad creando abstracciones cada vez mejores, como hicieron ReactJS y TailwindCSS en sus respectivos ámbitos
- Que un editor de texto colaborativo sea inherentemente complejo solo significa que hay que seguir buscando mejores abstracciones
AGI — aun así, el buen código no va a desaparecer
- Si imaginamos 1, 2, 5, 10 o 100 años en el futuro: la IA se vuelve cada vez mejor / más rápida / más barata, y en algún momento llega a una inteligencia de máquina indistinguible de la humana (AGI)
- El mundo de la AGI podría parecerse al mundo del vibe. Si pudieras tener a 100 genios al nivel de Karpathy por $1000 al mes, ¿por qué preocuparte por esos detalles molestos?
- "Esto es una auténtica tontería." Ese tipo de idea solo parece posible antes de que la tecnología llegue, cuando aún existe solo como abstracción
- Si tuviéramos acceso a ese nivel de inteligencia, el porcentaje de gente que la usaría para producir más slop sería 0%. Por supuesto que no
- La razón por la que nos confundimos: pensamos (equivocadamente) que el código existe solo para producir software. El código en sí también es un resultado central. Cuando está bien hecho, es poesía
- "Nadie habla de 'vibe writing', ¿verdad?" — nadie cree que ChatGPT vaya a reemplazar a los grandes novelistas o periodistas. Con el código pasa lo mismo, pero la "magia" de que el código se ejecute nos hace caer en la ilusión
- La IA produce código malo (cada vez menos malo). Todos lo sabemos. Usamos IA a pesar de que produce mal código, no por eso
- Cita de Simon Willison: "La IA debería ayudar a crear mejor código"
- Lo primero que haríamos cuando llegue la AGI: resolver los problemas de abstracción más difíciles. Crear mejores abstracciones para entender y conquistar mejor la complejidad
- ¿Que mientras más inteligente sea la IA menos necesitaremos buen código? Decir eso es lo mismo que decir que con ChatGPT vamos a producir más slop
- Caso real: Opus 4.6 resolvió de un solo tiro un problema pendiente al crear el framework full-stack de React de Val Town (
vtrr). El resultado fue una demo de app full-stack en un solo archivo y de 50 líneas
Conclusión — el código apenas comienza
- Parece que el 99% de la sociedad está de acuerdo con que "el código murió". Ayer mismo escuché al podcaster Sam Harris decir con toda seguridad que "todos están de acuerdo en que programar murió, nadie necesita aprender a programar"
- "Esto es triste. Es como decir 'murió el storytelling' cuando se inventó la imprenta. Idiotas, el código apenas comienza. La IA será una bendición enorme para la programación."
- Citas finales:
- "No deberíamos ver la obligación de usar símbolos formales como una carga, sino como un privilegio. Gracias a eso, los estudiantes pueden hacer cosas que antes solo podían hacer los genios" — Dijkstra
- "Poder usar la lengua materna 'de manera natural' no significa más que poder producir con facilidad oraciones cuyo sinsentido no es evidente" — Dijkstra, "Sobre la necedad de la programación en lenguaje natural"
- "Hay dos maneras de construir un diseño de software: una es hacerlo tan simple que obviamente no tenga deficiencias, y la otra es hacerlo tan complicado que no tenga deficiencias obvias" — Tony Hoare
- "La cantidad de significado comprimido en un espacio pequeño mediante notación algebraica facilita el razonamiento que realizamos a través de ella" — Charles Babbage
7 comentarios
Antes de siquiera hablar de edición colaborativa, implementar bien un solo editor para uso individual ya está lleno de complejidades inesperadas, como el manejo del cursor, la pila de deshacer/rehacer y la entrada por IME. Como señala el artículo, hay pocos tipos de software donde se vea tan bien la trampa de las "especificaciones que se sienten intuitivamente precisas" como en los editores. Al final, lo que parece fácil no es realmente fácil; simplemente se abstrajo bien esa complejidad para ocultarla.
De hecho, la razón por la que Anthropic hizo un compilador de C como demo probablemente fue también porque los compiladores tienen especificaciones precisas y casos de prueba bien preparados. Al mismo tiempo, también parecen tremendamente difíciles.
He hecho algunos compiladores y ahora también estoy trabajando en uno; desde la perspectiva del vibe coding también he intentado con editores, pero los compiladores se sintieron más fáciles. Como dijiste, siento que las especificaciones son menos precisas y que hay muchas más variables por parte de los usuarios. También es más difícil hacer pruebas.
Aunque la especificación se vuelve más importante, desde hace tiempo pienso que es imposible escribirla toda en detalle y cubrir todas las situaciones. También creo que, por ahora, sigue siendo mejor ir puliendo la especificación mientras se trabaja, igual que el código, aunque me pregunto si no se podría hacer que varios agentes hicieran eso entre ellos. Pero, al final, sin intervención humana no pueden salirse de las situaciones y conocimientos con los que fueron entrenados, así que me parece que sería difícil enfrentarse a situaciones y funciones completamente nuevas.
Me da la misma sensación que cuando salieron por primera vez las aspiradoras robot y decían que había que hacer una "limpieza simple" recogiendo las cosas del piso para el robot. Escribir especificaciones detalladas para la IA también es bastante trabajo, y parece que uno termina trabajando para la IA.
¿IDE y PR ya murieron todos, pero el código resucitó?
El código es, en los sistemas simples, la especificación más precisa desde el punto de vista lógico.
Pero la trampa es que el mundo real es un sistema complejo... al final, los datos son la especificación más precisa que existe.
Parece que hay que ver si puede reemplazarse por otros métodos de validación. Cuanto más cerca esté del frontend, probablemente se pueda verificar que funciona bien solo con E2E mediante el comportamiento del navegador. Pero cuanto más cerca esté del backend y de la infraestructura, más imprescindible será la revisión de código. De lo contrario, será difícil validar efectos secundarios como transacciones invisibles que se abren y cierran o llamadas a la API que se disparan.
En el navegador hay montones de problemas que ni siquiera se pueden detectar con E2E.