La torre sigue elevándose

• La forma en que el software programado con vibe coding cambia de manera aleatoria e inesperada se parece a la Torre de Babel, cuya construcción se detuvo al perder un lenguaje común, pero en la era de la IA la diferencia es que la construcción continúa incluso después de que el entendimiento se derrumba
• Los límites del software a gran escala no dependen solo de la velocidad con la que una persona produce código, sino de qué tan bien se coordina el entendimiento compartido sobre conceptos, límites, invariantes, propiedad y razones de diseño
• La fricción que surgía al explorar código, hacer preguntas, revisar y coordinarse entre equipos era tanto desperdicio como un proceso para sincronizar el entendimiento mutuo y confirmar el consenso sobre el sistema
• Los agentes realizan en paralelo tareas como agregar OAuth, incorporar caché o reconstruir la base de datos sin conversar; aunque cada cambio sea razonable y pase las pruebas, el modelo común de los humanos puede debilitarse
• En la ingeniería asistida por IA, los agentes interpretan y modifican cada área, manteniendo la construcción sin fallas inmediatas, por lo que es difícil notar la pérdida del lenguaje arquitectónico con el que los humanos razonaban juntos sobre el sistema

---

La fuerza de la Torre de Babel estaba en la coordinación más que en la tecnología

• La forma en que cierto software hecho con vibe coding cambia de maneras algo aleatorias e inesperadas recuerda a The Tower of Babel de Bruegel
• La historia de la Torre de Babel suele interpretarse como una historia de soberbia y ambición, y como explicación de por qué las personas empezaron a hablar distintos idiomas, pero también muestra la unidad que permite el avance tecnológico
• En Génesis 11:3-6 (KJV), las personas logran una mejora tecnológica al usar ladrillos cocidos en lugar de piedra y betún en lugar de mortero, e intentan construir una ciudad y una torre que llegue al cielo
• Lo que Dios vio como problema no fueron los ladrillos ni el conocimiento de fabricación, sino que las personas eran una sola y compartían un mismo idioma, de modo que nada las limitaría
• Cuando las personas combinan su trabajo con un lenguaje común, pueden construir algo que nadie podría crear por su cuenta
• Al desaparecer no los ladrillos ni las técnicas de fabricación, sino la capacidad de entenderse entre sí, la coordinación se volvió imposible y la construcción se detuvo

La torre que sigue subiendo incluso después de que los agentes de IA eliminan la fricción

• La programación asistida por IA da herramientas más poderosas a cada persona, y un desarrollador que usa agentes puede hacer cambios mucho más amplios en una base de código
• Sin embargo, los límites de los proyectos grandes no dependen solo de la velocidad con la que una persona produce código, sino también de qué tan bien las personas coordinan su entendimiento del sistema que están modificando
• El lenguaje común de un proyecto de software no es el inglés ni Python en sí, sino un entendimiento compartido sobre lo siguiente
  • Qué significa cada concepto
  • Dónde están los límites del sistema
  • Qué invariantes son importantes
  • Quién es dueño de qué
  • Por qué el sistema tiene su estructura actual
• Ese entendimiento no queda registrado por completo en un solo lugar; se acumula no solo en la documentación y el código, sino también en revisiones de código, conversaciones, discusiones y en la experiencia de explicar cambios a otras personas
• Antes de los agentes, para modificar la capa de almacenamiento de otra persona muchas veces había que leer código, hacer preguntas y coordinarse con otros equipos que operaban servicios dependientes
  • Ese proceso también tenía desperdicio, pero cumplía la función de transferir el entendimiento de una persona a otra y confirmar si ambas partes seguían de acuerdo sobre cómo funcionaba el sistema
  • Esa fricción sincronizaba el entendimiento de las personas
• Los agentes reducen mucho esa fricción y permiten que varias personas pidan cambios distintos sin hablar entre sí
  • Una persona agrega OAuth, otra incorpora caché, y otra reconstruye la base de datos desde cero y pone la UI en rosa
  • Cada cambio puede ser razonable de forma independiente; el código puede compilar, pasar las pruebas e incluso generar explicaciones cuando haga falta
  • Nadie necesita hablar con otra persona ni adquirir la parte del modelo compartido que antes habría aprendido durante el proceso de cambio
• Los agentes no sienten dolor; solo los humanos lo sienten, y ahora pueden modificar áreas del sistema y bases de código que antes requerían ayuda de otras personas
• Los proyectos de vibe coding que crecen en escala se convierten en bases de código tipo Torre de Babel no porque no puedan comunicarse, sino porque ya no necesitan comunicarse
  • Cada desarrollador tiene un traductor incansable que le explica una zona específica de la torre y ejecuta el cambio local que desea
  • Los cambios siguen incorporándose, pero puede desaparecer el lenguaje arquitectónico que permitía a los humanos razonar juntos sobre el sistema
• En la Torre de Babel bíblica, la pérdida del lenguaje común detuvo la construcción, pero en la ingeniería asistida por IA la construcción puede continuar incluso después de que el entendimiento compartido colapsa
• Como la torre no se derrumba ni falla de inmediato, es difícil notar qué se perdió, y la torre sigue elevándose

[GN⁺]

Opiniones en Hacker News

• Desde hace tiempo pienso que la componibilidad del software debería funcionar como en Tetris: las líneas tendrían que desaparecer al completarse. El uso inmaduro de agentes, o los ingenieros con poca experiencia, tienden a pasar por alto esa limpieza y solo siguen haciendo la torre más alta.
  Se puede hacer que un agente integre repetidamente elementos existentes en mejores abstracciones, pero incluso Fable o 5.6 Sol todavía están muy por detrás de las personas en ese sentido arquitectónico de alto nivel que permite anticipar la evolución sutil del software. Los sistemas actuales no parecen mantener lo suficiente esos modelos del mundo escasos, de alta calidad y con capacidad de acercamiento y alejamiento que manejan las personas, pero el simple hecho de que la brecha ya se haya reducido hasta un nivel tan sutil es esperanzador.

  • No puedo demostrarlo, pero creo firmemente que la lógica y la intuición necesarias para crear abstracciones pensando en cambios futuros no pueden implementarse solo mediante una secuencia de tokens predictivos. Falta algo que no se puede medir.
  • En el pasado, la capacidad de la mente humana era el límite superior de la complejidad de un programa, pero el vibe coding puede romper esa barrera. No porque el problema sea realmente tan complejo, sino porque el proceso de desarrollo no converge hacia abstracciones concisas.
    Esta es la versión con IA del problema de escalamiento que Brooks trató en 《The Mythical Man-Month》: a medida que crece la escala, la explosión combinatoria empeora y aparecen duplicaciones de código que implementan, en la práctica, la misma funcionalidad en distintas partes del proyecto. Necesitamos una forma de hacer que la codificación basada en IA busque la concisión.
  • La ventana de contexto de una persona podría ser mucho más pequeña que la de los LLM actuales. Esa limitación tiene la ventaja de obligarnos a modularizar y abstraer para poder mantener el trabajo en la cabeza; en cambio, los LLM que pueden contener mucha más información de una sola vez no tienen el mismo incentivo, lo que lleva a que los agentes generen código espagueti sin ordenar.
  • Al final es cuestión de tiempo. gpt2 o llama2 son sorprendentemente malos comparados con los modelos actuales y, aun en su momento, eran prácticamente inútiles, pero nos impresionaban.
    GPT3.5 y gpt4, que alguna vez nos entusiasmaron, ahora quedan muy por detrás de qwen27b o gemma31b. Con suficiente tiempo y el aprendizaje por refuerzo (RL) adecuado, los modelos también terminarán construyendo en su cabeza buenos modelos de sistemas de software.
  • ¿No será el resultado de que los LLM fueron entrenados con aprendizaje por refuerzo para resolver tareas de corto horizonte temporal? A diferencia de las tareas de pasar tests, los esfuerzos de varios años, una arquitectura limpia y el buen criterio no son fáciles de maximizar con benchmarks.

• La tesis central de este texto me recuerda a Lisp Curse y a Bipolar Lisp Programmer. El argumento era que Lisp facilita demasiado que una persona construya lo que quiere, lo que reduce el incentivo de los programadores para colaborar y crear resultados generales y complejos, y por eso su ecosistema de software público termina siendo más pobre que el de lenguajes que requieren un esfuerzo considerable.
  Armin parece plantear un argumento muy parecido sobre la codificación con IA: Lisp Curse, Bipolar Lisp Programmer

  • Los programadores en ensamblador también sostenían el mismo argumento. Es una creencia recurrente cada vez que la ingeniería de software atraviesa un cambio de paradigma, y hay personas a quienes la transición les cuesta más que a otras.
  • Me pregunto si realmente es el mismo argumento. Hoy hay mucha gente que cree que ya no hace falta reunirse y colaborar: basta con desplegar un enjambre de agentes para crear cualquier software complejo que uno imagine.
  • Más bien, si TypeScript y Rust no hubieran arrasado el mercado, este sería un buen momento para convertirse en operador de LLM para Lisp. Los agentes de hoy pueden explicar la mayor parte casi sin alucinaciones, así que, si uno tiene la voluntad de entender, la barrera de comprensión prácticamente desaparece; y ese también es el punto central del texto.
  • No está claro el supuesto de que otros lenguajes requieran “muchísimo más esfuerzo” para lograr el mismo resultado. Muchos desarrolladores que no usan Lisp le dan importancia a la sintaxis, pero los desarrolladores de Lisp no; y hay muchas personas que, incluso después de experimentar cómo Lisp expande la forma de pensar, no lo prefieren.
    Quizá haya formas de procesamiento cognitivo distintas entre ambos grupos. Para que Lisp sea tan productivo como otros lenguajes, hay que aprovechar activamente la homoiconicidad (homoiconicity), y el resultado es que los programas serios en Lisp suelen convertirse en conjuntos de lenguajes específicos de dominio (DSL) que solo una o dos personas entienden.

• El límite de los proyectos de software a gran escala no está en qué tan rápido una persona produce código, sino en qué tan bien quienes modifican el sistema coordinan una comprensión común de ese sistema. Es acertado decir que todo se volvió más complejo después del 30 de noviembre de 2022.

  • El software se volvió excesivamente complejo al apilar capa sobre capa, y para lidiar con eso usamos herramientas que generan mucha más complejidad. En los años 90 y principios de los 2000, incluso sin educación formal se podían crear aplicaciones potentes con Visual Basic o PHP, pero hoy el desarrollo web o de escritorio es abrumadoramente complejo, e incluso para usar bien React hay demasiado que saber.
    Introducir IA aquí se parece a cometer el error de sumar otra complejidad encima de la complejidad existente. En el mejor de los casos es un enorme desperdicio de hardware; en el peor, los agentes crean tantos bugs nuevos como los que corrigen y aumenta el software basura vulnerable, al mismo tiempo que la gente deja de aprender tecnología y se debilita la capacidad de la humanidad en su conjunto. El software no tiene por qué ser intrínsecamente tan complejo, y para resolverlo hay que valorar la artesanía.
  • No es nuevo que haya que entender un sistema antes de cambiarlo. Programming as Theory Building, de Peter Naur, ya apareció en los años 80, e incluso si uno no lo leyó, entre desarrolladores experimentados era de sentido común que entender el sistema es indispensable.
  • No todo se volvió más complejo. Las principales bases de datos incorporan herramientas prácticas de alta disponibilidad, los microservicios están en retroceso y las bases de datos estructuradas están volviendo en lugar de NoSQL.
    HTML y el prerenderizado también regresaron junto con HTMx y LiveView, y CSS dejó atrás los extraños rodeos del pasado. Cuando le explico a un colega joven cómo se depuraban páginas web en IE6, siento que pasó toda una era. Algunas cosas se volvieron más complejas, pero otras maduraron lo suficiente como para volverse más simples.
  • No habría que decir “después del 30 de noviembre de 2022”, sino que todo se volvió más complejo desde el año 2022 a. C.. El aumento de la complejidad es, en sí, la historia de la civilización humana.
    Una persona del año 20.000 a. C. buscaba comida y evitaba el frío y los depredadores, pero una del 5.000 a. C. cultivaba, se preocupaba por la lluvia y las enfermedades, y creaba sistemas para gestionar la comunidad y la tierra. Hoy, la mayoría no cultiva sus propios alimentos, sino que gestiona la complejidad de sociedades enormes. Para un desarrollador de los años 70 u 80, incluso el software previo a los LLM ya sería enormemente complejo, y ahora casi nadie programa directamente sobre el hardware sin capas de abstracción. En criptografía también las bibliotecas ocultan la complejidad y se enseña “no lo implementes tú mismo”. Ahora la pregunta central es qué tan rápido pueden los LLM coordinar la comprensión del sistema que se va a modificar.

• El lenguaje compartido de un proyecto de software no es ni el inglés ni Python, sino una comprensión común sobre el significado de los conceptos, sus límites, invariantes, propiedad y las razones por las que el sistema llegó a su forma actual. Pattern Language, de Christopher Alexander, trata precisamente este problema, y su recomendación de crear un lenguaje de patrones adecuado para cada dominio condujo a los famosos GoF Design Patterns.
  Estoy experimentando con una función para que la IA mantenga tres lenguajes de patrones por proyecto —para los dominios de negocio, producto y tecnología—, y funciona muy bien. Al hacer que los consulte durante la planificación y los organice durante la implementación y la revisión, incluso los proyectos programados 100% con IA se volvieron sistemáticos, bien alineados entre dominios y fáciles de manejar.

  • Me gustaría ver un ejemplo real. He oído varias veces que el proceso de maduración del código se parece al crecimiento natural de una ciudad, pero nunca vi resultados concretos.
  • Me pregunto si hay algún ejemplo público en GitHub.

• En la Torre de Babel, cuando se pierde el idioma común, la construcción se detiene; pero en el desarrollo asistido por IA, la construcción continúa incluso después de que se derrumba la comprensión compartida. El autor no dijo explícitamente si eso es bueno o malo, pero claramente lo veo como algo malo.
  Si saber que el tomate es una fruta es inteligencia y no ponerlo en una ensalada de frutas es sabiduría, entonces la IA es la forma definitiva de una inteligencia sin sabiduría alguna y, en la práctica, casi una ilusión de inteligencia. Si no hay nadie que entienda lo que hace la IA, deberíamos detenernos y admitir que nos falta la sabiduría para controlar lo que estamos creando.

  • Me gusta que el autor, en vez de sermonear, haya dejado que la imagen misma transmita el significado. En la historia no hay repeticiones idénticas, pero siempre hay rimas.
  • Es mejor evitar lugares comunes infantiles como “saber que el tomate es una fruta es inteligencia”, salvo que la intención sea confundir. Entender clasificaciones y relaciones de dependencia ya es un problema suficientemente difícil, y según los criterios impositivos de los supermercados o de Nix v. Hedden, el tomate es una verdura.

• Yo también pienso en Babel y en el cuadro de Bruegel, pero lo veo con mucho menos optimismo. Pequeños agentes miopes desarrollan cada uno su parte de un conjunto tan enorme que resulta incognoscible: de un lado hay 50 almenas, del otro una torre saliente extraña, y sin saber por qué construyen sobre el patio un techo de adobe y, junto a él, en el descanso de la escalera, una torre con techo de paja.
  A nivel de diseño individual puede ser razonable, pero al no haber múltiples capas de políticas y criterio que integren todo el emprendimiento, se convierte en un monstruo gigantesco de diseño. Que crear y mantener un lenguaje común en una organización lo suficientemente grande requiere disciplina se ve también en la terminología particular de empresas exitosas y ejércitos. Los “Gastown Mayors”, los “polecats” debajo de ellos y los gólems aún más abajo creen que hablan el mismo idioma, pero solo cuando todo esté terminado se darán cuenta de que la comprensión que creían haber transmitido perfectamente desde el trono en realidad nunca fue compartida.

• Anakin: “Los desarrolladores que usan agentes van a aumentar drásticamente su capacidad de cambiar la base de código”.
  Padmé: “Para mejor, ¿verdad?”
  Anakin: silencio
  Padmé: “Para mejor, ¿verdad?”

• Parece que la razón por la que el vibe coding dice que no leas el código generado es que una vez que ves el horror que acecha dentro de un archivo Python, no puedes olvidarlo. En un sentido amplio funciona como se pidió, pero cada vez que elige cómo alcanzar el objetivo toma decisiones inconsistentes.
  Aplica validaciones extrañas solo a algunas entradas de usuario, reordena o convierte datos a minúsculas repetidamente en tres etapas sin motivo, y hardcodea como strings incluso todos los nombres de columnas de la primera fila del CSV de entrada. La mitad consiste en funciones globales que reciben data classes, y el resto está implementado como clases. Si piensas que algún día tendrás que actualizarlo y mantenerlo tú mismo, es difícil no corregirlo, pero al hacer esas correcciones desaparece buena parte del tiempo ahorrado.

• La programación basada en agentes se parece mucho más a tareas de gestión que a la programación propiamente dicha. Un gerente solo entiende a alto nivel lo que hacen los colaboradores individuales, y muchas veces no tiene el tiempo, la capacidad cognitiva ni las habilidades para comprender todos los detalles.
  Cuanto más software se escriba con agentes, más se parecerá el rol del ingeniero de software a un puesto de gestión que a uno técnico.

  • Lo mismo ocurre con los programadores. La mayoría de los colaboradores individuales no sabe qué pasa por debajo de la capa en la que trabaja, ni entiende la implementación interna de librerías, frameworks, API remotas o llamadas al sistema.
    Como no tienen tiempo ni margen para entenderlo todo, simplemente hacen lo necesario en su propia capa abstraída.
  • Se siente como pasar todo el día revisando el código de un desarrollador junior, así que casi no lo uso; principalmente lo uso solo para encontrar cosas que se me pasaron.

• Antes, una refactorización a gran escala requería mucho esfuerzo, así que hacía falta una buena razón. Ahora, si el prompt es apenas ambiguo y no se revisa bien el resultado, un agente puede reescribir la mitad del código, por lo que el alma del programa puede cambiar mucho cada día. Es algo excelente y, al mismo tiempo, no lo es en absoluto.

  • La mayor barrera para una refactorización a gran escala nunca fue realmente la cantidad de trabajo, sino minimizar el riesgo de bugs, preservar la funcionalidad y garantizar la compatibilidad con el ecosistema existente. La razón por la que en la era de la IA se volvió más fácil es que ya no nos preocupamos por esas cosas.