Sobre Naur, el vibe coding y la gente que no puedes reemplazar con una ventana de contexto

Esta semana he leído Programming as Theory Building, de Peter Naur. Es de 1985, y defiende algo que me parece más relevante ahora que en ningún otro momento de las últimas décadas: que lo que los programadores construyen no es realmente código, sino una teoría del problema que están resolviendo. El código es un efecto secundario. La teoría vive en las cabezas de las personas que construyeron el sistema, y cuando esas personas se van, la teoría se va con ellas. La documentación no te salva. El código no te salva. Puedes leer cada línea de un sistema escrito por otra persona y seguir sin tener lo que ellos tenían.

Si no habéis leído el ensayo, no es largo y merece la pena.

Puede parecer una obsesión extraña para 2026, pero en realidad es más importante ahora que en cualquier otro momento de los últimos cuarenta años. Quiero escribir sobre esto porque parece que estamos llevando a cabo un experimento en el mundo real sobre la hipótesis de Naur, y los resultados no van a ser… agradables.

Los despidos no son lo que parecen

Microsoft, Meta, Capgemini, Salesforce, Oracle. El razonamiento tras un despido a gran escala, cuando lo hay, es alguna variante de: la IA nos hace más productivos, así que necesitamos menos gente. A veces es más sincero y dice algo como “queremos que nuestra cotización en bolsa suba”. En cualquier caso, el resultado es el mismo: las personas que construyeron los sistemas se van, y la suposición es que lo que dejan atrás (el código y la documentación y las páginas de Confluence y los tickets de Jira) es suficiente para que alguien (o algo) retome el trabajo donde lo dejaron.

Naur se habría reído de esto. En su ensayo explica que eso es exactamente lo que no puedes hacer. Puedes entregarle a alguien una base de código completa y documentación completa, y aun así no podrá mantenerla como lo hacía el equipo original. Juzgará mal qué cambios son seguros y cuáles son peligrosos, y probablemente reinventará cosas que el equipo original ya probó y descartó. Las peticiones de funcionalidades que rompen invariantes que nadie documentó serán aceptadas porque, para las personas que construyeron el sistema, esas invariantes eran demasiado obvias como para dejarlas por escrito.

Esto era verdad en 1985. Es verdad ahora. Lo único que ha cambiado es que hay un nuevo actor en la sala (el LLM) y una nueva creencia sobre lo que ese actor puede hacer. En las secciones siguientes trataré de explicar por qué los LLMs no nos pueden salvar de las malas decisiones.

Lo que un LLM carga realmente

Esta es la versión optimista de la historia, la que creo que la mayoría de los ejecutivos tienen en la cabeza aunque nunca lo digan en voz alta: el equipo original construyó un sistema y escribió algo de documentación. Ya no están, pero un LLM suficientemente capaz puede leer toda la base de código y toda la documentación en unos pocos segundos y actuar como sustituto de la teoría perdida. Los ingenieros que quedan pueden hacerle preguntas al LLM y el LLM les responderá. La productividad se preserva. El coste se reduce. Todo el mundo que lleva corbata gana.

Esto es incorrecto, y la forma en que lo es importa.

Lo que un LLM carga cuando lo apuntas a una base de código es el artefacto, el código en sí. El artefacto es el residuo de la teoría. Es lo que queda después de que la teoría ha hecho su trabajo. Leer el artefacto te da un modelo del artefacto, que es útil para algunas cosas, pero no es lo mismo que tener el modelo que produjo el artefacto. El modelo productor es el que sabe qué peticiones de funcionalidades son razonables y cuáles son una mina antipersona esperando ser pisada. Es el que sabe por qué una función determinada existe en un lugar determinado, aunque podría haber vivido en otro, porque hace tres años un cliente reportó un bug que nadie más recuerda. El LLM no tiene acceso a esto. Nadie lo tiene, salvo las personas que se fueron.

Hay un ejemplo famoso de este desfase, y es anterior a los LLMs por veinte años. Cuando el código fuente de Quake III Arena se publicó en 2005, los programadores encontraron una función llamada Q_rsqrt que calculaba una raíz cuadrada inversa usando una secuencia de operaciones que parecía un sinsentido. Las raíces cuadradas inversas se usan en todas partes en los modelos de trazado de rayos porque son la operación que empleas para normalizar vectores, calcular ángulos y otras incontables operaciones de álgebra vectorial. Las líneas relevantes de la función eran estas:

i  = * ( long * ) &y; // evil floating point bit level hacking
i  = 0x5f3759df - ( i >> 1 );  // what the fuck?
y  = * ( float * ) &i;

Los comentarios son del código original, y son toda la documentación. El código reinterpreta el patrón de bits de un float como un entero, le resta una constante mágica (así se llamaba) y reinterpreta el resultado como un float de nuevo, lo que resulta ser una aproximación extremadamente precisa de 1/√{entrada}. Funciona gracias a una explotación inteligente de cómo los números en coma flotante IEEE 754 están dispuestos en memoria, pero saber eso no te dice nada sobre por qué la constante es concretamente 0x5f3759df, ni quién la inventó, ni cómo. El código era completo, estaba comentado y en pleno uso, pero la teoría (el modelo mental en la cabeza del programador) seguía faltando.

La comunidad pasó años tratando de entender esto, y hubo algo de literatura académica sobre el tema. Chris Lomont escribió un artículo derivando una constante óptima a partir de primeros principios y encontró un valor ligeramente diferente, y luego intentó ubicar al autor/a de la constante original y no dio con nadie. La procedencia de la constante se remonta, probablemente, a través de una cadena de “yo lo aprendí de alguien que lo aprendió de alguien” que acaba en William Kahan, pero esto fue reconstruido históricamente. El código no lo contenía.

(Cualquiera que haya hecho algo de programación en un contexto científico o experimental conoce esto. Pasas unas horas estudiando un método numérico particularmente útil para descubrir que la implementación es en realidad un bucle while, un producto de matrices y una tabla de constantes que un francés calculó en el siglo XVIII. El modelo mental es donde está la sustancia; el código no es más que el residuo de ese modelo).

Eso es de lo que hablaba Naur. El artefacto está ahí, completamente legible y comentado. La teoría que produjo el artefacto falta, y por mucho que te quedes mirando el artefacto no recuperas la teoría. Un LLM moderno apuntado al código fuente de Quake III puede darte una explicación fluida de lo que hace la función, especialmente porque el propio LLM fue probablemente entrenado con la documentación generada durante el interés que despertó esa función. No puede decirte por qué la constante es lo que es, porque esa información no está en el código. Nunca estuvo en el código. Estaba en la cabeza de quien eligió la constante, y esa persona no lo escribió y ahora tiene 92 años y no le interesa nada el debate sobre Quake III.

Escala esto ahora. Un sistema empresarial funcional tiene miles de equivalentes de Q_rsqrt, pequeñas decisiones tomadas por razones que eran obvias en su momento y que nunca se documentaron. La mayoría son menos interesantes que el número mágico, pero en conjunto conforman la teoría del sistema, y esa teoría es lo que te dice si un cambio propuesto va a romper algo tres meses después. El LLM no puede darte eso, porque no está en el input.

Así que lo que obtienes, en la práctica, es una versión reducida de la documentación, pasada por un modelo que la suaviza hasta convertirla en texto que suena plausible, y luego entregada a un mantenedor humano que tiene que hacer su trabajo real usando esta reducción. Hay ahora dos capas de compresión entre la teoría original y la persona que intenta mantener el sistema. La primera capa es lo que logró entrar en la documentación (con pérdidas). La segunda es lo que el LLM produce cuando se le pregunta sobre esa documentación (también con pérdidas, y de una manera diferente). El mantenedor está aguas abajo de ambas.

Naur no anticipó los LLMs, pero anticipó exactamente este problema. Solo pensaba que la segunda capa eran los libros de texto y los cursos de formación, pero el mecanismo es el mismo.

El problema de la legibilidad

Esta es la parte a la que no dejo de volver, y la parte que creo que la mayoría de la gente que escribe sobre esto no está mencionando: no importa si los equipos potenciados con IA producen software de peor calidad. Seguramente sí, por los motivos anteriores. Lo que importa es si la degradación es visible para las personas que aprueban los presupuestos.

Para la mayoría del software empresarial, la calidad es casi invisible hasta que ocurre algo catastrófico. El sistema funciona, y algunos números suben. Un dashboard está en verde. Los clientes abren tickets a un ritmo más o menos constante, la mayoría de esos tickets se cierran, y los que no se cierran pasan a engrosar un backlog que todo el mundo conviene en llamar “deuda técnica” y que nadie va a revisar por el momento. Nada de esto cambia cuando el equipo que construyó el sistema es reemplazado por un equipo más pequeño más un LLM. No puede cambiar, porque las cosas que realmente se han degradado (el juicio, el gusto, la capacidad de reconocer que un cambio propuesto va a causar un problema dentro de seis meses) no aparecen en los dashboards. Aparecen más tarde, cuando llega la catástrofe, y para entonces la cadena causal que lleva de vuelta a la decisión de personal es demasiado larga para que nadie la rastree.

Este es el escenario pesimista para la calidad del software en los próximos cinco años. No que las empresas hundan su software de manera visible. Lo hundirán de manera invisible. El puente no se caerá, pero irá siendo gradualmente menos seguro para cruzarlo, y en algún momento te darás cuenta de que llevas un rato caminando por él sin fiarte del todo de tus pasos.

Tenemos un ejemplo reciente de cómo se ve esto, y es X (antes Twitter). Cuando Musk despidió a la mayor parte de los equipos de ingeniería y de seguridad a finales de 2022, la predicción de los críticos más estridentes era que la plataforma caería en cuestión de semanas. No cayó. El sitio siguió funcionando. Los tuits siguieron cargando. Desde fuera, en los primeros meses, los agoreros parecían equivocados y los que decían “¿ves?, no necesitabais a todos esos ingenieros” parecían tener razón.

Lo que ocurrió realmente tardó más en hacerse visible. Los bots inundaron la plataforma, sin nadie que frenase el aluvión de contenido falso. El algoritmo de recomendación empezó a promocionar cuentas con verificación azul (de pago) de una manera que hizo que la timeline pareciese de un producto diferente. Grok, la IA propia de la plataforma, fue pillado generando imágenes sexualizadas de menores y repitiendo argumentarios neonazis tras un cambio chapucero en el prompt maestro. La moderación se degradó hasta el punto de que el tipo de persona que se quedaba en la plataforma cambió, lo que a su vez cambió lo que la plataforma era, lo que a su vez ahuyentó a más personas cuya presencia la había hecho valiosa. (En mi caso, escribí sobre el tema aquí cuando decidí abandonar la plataforma). Aunque Mastodon y Bluesky no hayan entrado todavía en el mainstream, el éxodo de Twitter (¿X-odus, a la Brexit) es un hecho innegable. Ninguno de estos hechos individuales es “la plataforma cayó”. Todos son el sistema siendo gradualmente menos seguro para cruzarlo.

El caso de X también es instructivo por lo que nos dice sobre la legibilidad. Desde un dashboard puro de uptime e ingresos, probablemente se podría argumentar que los recortes fueron bien: la plataforma siguió activa, los costes bajaron, alguna métrica subió en algún sitio. Al final, la degradación fue real, pero del tipo que no aparece en una revisión trimestral hasta que lleva dos o tres años acumulándose, momento en el que las personas que tomaron la decisión o ya se han ido o han construido una narrativa en la que el declive es culpa de otro. Esto es, más o menos, lo que espero que ocurra en cada gran empresa que decida que su departamento de ingeniería es en su mayor parte prescindible ahora que los LLMs son “suficientemente buenos”.

Lo que siempre fue verdad, y lo que es nuevo

No quiero exagerar la originalidad de lo que está pasando. La hipótesis de Naur, tomada en serio, implica que las empresas siempre han vivido de tiempo prestado con respecto a su software. Los despidos y la rotación siempre han destruido teoría. La gente se jubila, cambia de trabajo, tiene un accidente, gana la lotería. El equipo que escribió la versión original de cualquier sistema que lleve unos pocos años en funcionamiento suele estar desperdigada, y el mantenimiento lo llevan personas que heredaron el artefacto y fueron construyendo alguna aproximación imperfecta de la teoría a través de años de contacto con él.

Lo que es verdaderamente nuevo es tanto la velocidad de la destrucción como la creencia de que la destrucción es recuperable.

Generaciones anteriores de managers y gerentes sabían, de alguna forma vaga, que perder al equipo que construyó X significaba que X era ahora una caja negra. No despedían al equipo que mantenía el mainframe, ni dejaban jubilarse al tipo del COBOL sin un traspaso largo, ni se deshacían de los expertos en paradigmas antiguos que seguían moviendo la actividad de las empresas. No asumían, en general, que podías sustituir a las personas sin consecuencias para el artefacto. Estoy seguro de que se equivocaban en muchas cosas, pero no en esto.

En su mayoría, la generación actual parece actuar bajo la suposición de que un LLM puede recuperar la teoría a partir de los artefactos. Esto es un delirio muy específico y merece ser nombrado: la creencia de que la relación entre una base de código y la teoría de esa base de código es recuperable del mismo modo en que la relación entre una frase y su significado es recuperable. No lo es. La teoría es lo que produjo el código. No puedes invertir la flecha leyendo el código detenidamente, y no puedes invertirla alimentando el código a un modelo que lo lee muy rápido.

Los juniors son el siguiente problema

Hay una consecuencia a más largo plazo de todo esto que creo que no será visible hasta dentro de unos años. Ahora mismo, los juniors son los perdedores evidentes en el mercado de la consultoría. Muchas de las cosas que solían hacer (resolución rutinaria de problemas, monitorización, documentación de soluciones existentes) pueden encargarse a una persona de nivel medio más un LLM y la matemática cuadra. Las empresas están haciendo esa matemática. La contratación de juniors está colapsando en muchos sitios.

El argumento que quiero hacer es que esto no es simplemente malo para los juniors actuales, como un problema aislado. Si la tendencia actual continúa, podría ser catastrófico para todo el mundo en 2035.

Los juniors siempre han sido valiosos porque son la siguiente generación de portadores de teoría en formación. La razón por la que un consultor senior tiene buen juicio no es que haya nacido con él, sino que pasó algunos años confundido, cometiendo errores, observando a personas senior tomar decisiones y entendiendo poco a poco por qué esas decisiones eran las correctas. Ese proceso es el aprendizaje. El resultado del proceso es el senior. No hay atajos.

Si se salta ese paso durante una década, porque consultores de nivel medio más LLMs pueden hacer el trabajo que los juniors hacían antes, en 2035 no habrá seniors, porque nadie pasó por la confusión formativa que construye el tipo de juicio del que hablaba Naur. La teoría que vive en las cabezas de los seniors en 2035 tiene que venir de algún sitio, y ese sitio son los años de contacto con sistemas reales y equipos reales que esos seniors tuvieron como juniors e ingenieros de nivel medio entre 2025 y 2030.

Las empresas no van a descubrir esto hasta que los seniors que existen ahora empiecen a jubilarse y la escasez se vuelva dolorosamente obvia. Para entonces, la cadena de producción no se podrá reparar en ningún plazo razonable. No puedes pasar de cero juniors a un senior con diez años de experiencia en menos de diez años. Puede que las personas que deberían preocuparse por esto ya lo sepan, pero en una época de euforia casi enfermiza por la IA es posible que les resulte más fácil pensar que el futuro es tan brillante que nada puede salir tan mal.

El desplazamiento, y lo que creo que nos pasa al resto

Para los consultores de nivel medio, el panorama es más confuso. El trabajo que antes era rutinariamente de juniors va a caer sobre ellos. Esto no es todo malo. Hay productividad real que ganar pasando las cosas repetitivas a un modelo y revisando el resultado. Yo lo hago con frecuencia, sobre todo cuando el gasto de energía asociado a la tarea va más vinculado a la repetición que a aplicar algún tipo de creatividad. Funciona.

Pero el trabajo cambia. Pasas más tiempo validando el output del LLM y menos tiempo haciendo cosas tú. Absorbes la carga cognitiva de dos o tres roles, con una herramienta que ayuda con el volumen pero no con la responsabilidad. Los modelos mentales que necesitas para hacer esto bien son exactamente los que tardan años en desarrollarse, lo cual no es un problema para los consultores de nivel medio actuales, pero va a serlo para quien se supone que debe reemplazarlos (los mencionados juniors que no existen).

Tampoco creo que esto resulte más barato para las empresas a largo plazo. Los ahorros nominales (menos salarios) son reales, pero los costes de transición no son gratuitos, y a medida que todo el mundo adopta las mismas herramientas, la ganancia de productividad deja de ser un diferenciador y se convierte en la nueva línea base. Acabaremos haciendo más trabajo por el mismo dinero, con equipos más pequeños, riesgo más concentrado y una peor cadena de personas que sustenten el resultado. Las empresas que lo descubrieron primero parecerán estar en cabeza durante unos trimestres. Las que lleguen después simplemente estarán igualando la nueva línea de base.

Responsabilidad

Hay una frase a la que no dejo de volver, de un manual de formación de IBM de 1979:

Es una de las afirmaciones más limpias que se me ocurren sobre por qué los humanos necesitan estar en el bucle. Puedes construir cualquier sistema que quieras, pero al final de la cadena tiene que haber una persona o una organización que se haga cargo de las consecuencias. Esa titularidad es lo que hace al sistema digno de confianza. Es lo que hace ejecutables los contratos, lo que permite a los reguladores hacer su trabajo, lo que le da a los clientes a alguien a quien llamar cuando algo va mal.

Solía pensar que este era el argumento más sólido para explicar por qué el número de empleados no podría colapsar del todo. Alguien tiene que ser responsable; el LLM no puede serlo. Así que como mínimo necesitas una persona en cada nivel en que se toma una decisión.

Ya no estoy tan seguro. Lo que tienen las corporaciones es que se han vuelto extremadamente buenas en distribuir la responsabilidad de modo que ningún individuo sea responsable de nada. Ocurren fallos catastróficos y la autopsia concluye que fue un “fallo de proceso”, o que “se han extraído lecciones”, o que la persona relevante se jubiló seis meses antes y ahora le apasiona la cría de palomas. Justo ayer, The Register informaba sobre la pérdida de la base de datos de una startup impulsada por Claude, y los resultados fueron exactamente los que cabía esperar. Así que añadir un LLM al funcionamiento diario de una corporación no es más que una capa más en un sistema que ya estaba diseñado para asegurarse de que nadie pueda ser culpado de nada demasiado grave.

La regla de IBM sigue describiendo lo que debería ser verdad. Un ordenador no puede ser responsable; por tanto, un ordenador nunca debe tomar una decisión de gestión. Pero la regla no se aplica sola. Quienes la aplican son los reguladores, las demandas, la presión pública y una cultura de trabajo dentro de la empresa que se toma en serio la titularidad. Todo eso es más débil de lo que era. Así que la regla va a ser puesta a prueba, y no creo que la prueba salga bien.

Lo que creo que deberíamos hacer

Me da cierto reparo terminar un post así con una lista ordenada de recomendaciones, porque no tengo ninguna de la que esté seguro. Las fuerzas en juego aquí son grandes y las personas que podrían cambiarlas tienen otras prioridades. Pero si tuviese que decir algo para aminorar un poco el dolor que se desprende de todo este nuevo paradigma:

• Documenta la teoría, no el código, que se documenta solo. Lo que no se documenta solo es por qué el código tiene el aspecto que tiene, qué se intentó y se descartó, qué invariantes da por sentadas el equipo, cómo se ven los modos de fallo en la práctica. Escríbelo. Escríbelo aunque parezca una tontería. Escríbelo para la versión de ti que existirá dentro de tres años y lo ha olvidado todo, porque lo más probable es que lo olvides. Yo lo olvido.

• Trata a las personas senior como portadoras de la teoría y actúa en consecuencia. Si un senior se va, el coste que hay detrás es teoría que sale por la puerta. Intenta retener talento. Si eso falla (inevitablemente fallará en algún momento), paga traspasos apropiados. Paga solapamientos. Si la dirección no quiere pagar estas cosas, eso es una señal de cuánto se toman en serio que sus sistemas estén bien mantenidos.

• Contrata juniors de todas formas. Sé que la matemática no cuadra a corto plazo. Sé que un nivel medio + un LLM puede sacar el trabajo de varios consultores. Contrata juniors de todas formas, porque la alternativa es una cadena de producción seca dentro de diez años, y diez años no es tanto tiempo.

• Sé escéptico cuando alguien te diga que el LLM ha leído la base de código y la entiende. El LLM ha leído el artefacto. La teoría nunca estuvo en el artefacto.

Eso último es lo que Naur nos decía hace cuarenta y un años. Entonces tampoco lo escuchamos, pero el coste era menor porque no creíamos tener una salida. Ahora creemos tenerla, y probablemente estamos a punto de descubrir que no es así.