Buenas, esto es BIMPRAXIS, el podcast donde el
BIM se encuentra con la inteligencia artificial.
Exploramos la ciencia, la tecnología y el futuro
desde el enfoque de la arquitectura, ingeniería y
construcción.
¡Empezamos!
Muy buenas, bienvenidas, bienvenidos a un nuevo episodio
de BIMPRAXIS.
Hoy os traemos la anatomía de cómo integrar
herramientas de IA en un código de hace
15 años sin destruir el proyecto o en
el intento.
Y a ver, es un desafío que representa,
o sea, el verdadero campo de batalla de
la ingeniería actual.
Totalmente.
Porque, seamos sinceros, generar un bloque de código
desde cero en un entorno aséptico es, bueno,
un truquito que cualquier modelo de IA te
hace hoy en día antes del desayuno.
La fricción real, la de verdad.
Ocurre cuando chocamos con el mundo real, ¿no?
Claro, exacto.
Y por eso nuestra inmersión profunda de hoy
se centra en un caso real.
El que documentó el desarrollador Dan Delimarski y
el ecosistema donde él decide experimentar.
Ojo, no es un lienzo en blanco, es
su propio blog personal.
Un proyecto que lleva vivo y funcionando nada
menos que 15 años.
Que se dice pronto.
Ya te digo, 15 años en el mundo
del desarrollo web no es que sea mucho
tiempo.
Es que es una era geográfica.
Es una era geológica entera.
Han nacido y muerto decenas de lenguajes ahí
en medio.
Sí, sí.
Y la herramienta que utiliza para este experimento
es la línea de comandos, la CLI de
GitHub's PetKit.
Su objetivo sobre el papel es, a ver,
bastante mumbano.
Quiere añadir una nueva funcionalidad a este blog
milenario.
Específicamente quiere una lista de lectura, rollo la
página de libros de la escritora Molly White,
para tener un registro visual de lo que
va leyendo.
Vale, vamos a desglosar.
Vamos a desglosar esto, porque el contexto técnico
aquí lo es absolutamente todo.
El blog de Den usa un generador de
sitios estáticos que es Hugo, emplea Tailwind CSS
y además corre sobre un tema modificado.
Tela, ¿no puedes entrar ahí de cualquier manera?
Claro, para que una IA no entre ahí
como un elefante en una cacharrería, primero necesita
límites absolutos.
Es exactamente igual que invitar a un contratista
a reformar una cocina en una casa centenaria.
Muy buena analogía.
Si antes de mirar a Zulejos, lo primero
que tienes que hacer es sentarte con él
y decirle, oye, estos son los muros de
carga.
Bajo ninguna circunstancia puedes tirar estas paredes, porque
si lo haces, se nos cae el edificio
entero encima.
Es que es tal cual.
Si dejas a un modelo de lenguaje actuar
por libre, su instinto siempre va a ser
añadir la tecnología más moderna con la que
lo han entrenado.
Por eso, el primer paso en SpecKit no
es pedirle que programe, sino usar un comando
que es la barra Constitution.
¡Ostras!
Ahí es donde redacta.
Esta es la constitución del proyecto.
Es un documento que marca esas restricciones inquebrantables.
Y las reglas de DENZ fueron tajantes.
O sea, primera regla, es un sitio estático
puro.
Solo se puede usar Hugo.
Segunda regla, cualquier estilo visual tiene que usar
las convenciones que ya existen.
Pero la tercera regla es la que me
parece clave.
A ver.
Cero dependencias externas.
¿Absolutamente prohibido?
Añadir un nuevo archivo Package .json.
Claro.
Y aquí me quiero detener, porque para la
gente que no está todo el día picando
código, ¿por qué añadir un simple gestor de
paquetes es un pecado capital en este contexto?
Pues porque meter un Package .json es abrir
la caja de Pandora del ecosistema Node .js.
Es invitar al proyecto a ese agujero negro
que es la carpeta Node Models.
Te llenas de archivos sin darte cuenta.
Exacto.
Instalas una tontería para formatear un texto y
de repente ¡pum!
Descargas cincuenta mil pequeños archivos de terceros que
tienes que mantener y vigilar por temas de
seguridad.
Madre mía.
Y el blog de Derm es estático.
Eso significa que no procesa bases de datos
ni lógicas complejas.
Solo entrega un HTML casi a la velocidad
de la luz.
Si añades dependencias externas, te cargas esa pureza
que lleva quince años protegiendo.
Entendido.
La pureza manda.
Pero, revisando esto, hay un detalle que me
dejó, bueno, dándole vueltas.
Durante esta fase de la Constitución, ¿qué es
lo que se puede hacer?
Durante la Constitución, Derm usó Cloud Sonnet 4
y la IA sugerió por su cuenta una
regla ética.
Ah, sí, lo vi.
Decía, en plan, todo el contenido debe estar
escrito por humanos y ser genuino.
Y a simple vista parece una regla fantástica,
¿verdad?
Sí, suena muy bien.
Yo la habría dejado, pero Derm la eliminó
inmediatamente.
¿Por qué rechazar una buena práctica ética así?
Pues porque en el ámbito puramente de ingeniería,
la ética del contenido es ruido.
Ruido puro.
Derm la descartó porque es irrelevante para el
código.
La Constitución tiene que centrarse solo en la
infraestructura.
Zapatero a tus zapatos, vaya.
Exacto.
Si incluyes una directiva filosófica sobre quién escribe,
estás distrayendo al modelo.
La IA está ahí como arquitecto técnico para
construir las estanterías, no para ser descensor literario
de los libros que vas a poner en
ellas.
Vale, tiene todo el sentido.
Mantener el enfoque en los ladrillos digitales.
Entonces, una vez que la IA sabe perfectamente,
lo que no puede hacer, llega el momento
de decirle qué queremos construir.
Y aquí, ¡buf!, la industria del software lleva
décadas tropezando con la misma piedra.
Ya te digo.
Los humanos somos un desastre total detallando requisitos
técnicos.
Totalmente.
Es un problema crónico con los documentos de
requisitos del producto, los PRD.
A nadie le gusta escribirlos, porque tienes que
imaginar las 100 formas diferentes en las que
un usuario podría romper el sistema.
Y siempre nos dejamos algo.
Y aquí es donde… El proceso con SPECIT
da un giro, o sea, ¡brillante!
DEN usa primero el comando SPECIFY para decirle
a la IA, más o menos, que quiere
una ruta alimentada por archivos TOMEL, que es
un formato muy sencillo.
Pero la verdadera magia ocurre cuando ejecuta el
comando CLARIFY.
¡Ostras, sí!
El CLARIFY es brutal porque invierte a los
roles.
La IA deja de generar código a ciegas
y analiza el borrador.
Y usando su conocimiento, empieza a hacerle preguntas
al desarrollador, para iluminar sus puntos ciegos.
¡Es buenísimo!
Leyendo el caso de estudio, de verdad, ¡es
divertidísimo!
La IA de repente se transforma en un
gestor de proyectos súper exigente, interrogando a un
desarrollador que, pobre, claramente no había pensado en
los detalles.
Seguro que le pilló sin tomarse el primer
café.
Seguro.
Vamos a repasar el interrogatorio porque no tiene
desperdicio.
La primera pregunta de la máquina fue, ¿cómo
se van a ordenar los libros?
Una omisión clásica.
Nosotros asumimos que hay un orden.
Pero el ordenador necesita reglas matemáticas.
Den tuvo que decidir ahí mismo que se
ordenarían por fecha de finalización.
Los más recientes, arriba.
Luego, la IA le ataca con el diseño.
Le suelta, ¿cuántos libros deben mostrarse por página?
Claro, la paginación.
Den, pensando rápido, dijo que 20 libros por
página estaría bien.
Y la tercera pregunta fue puramente visual.
Le dijo, ¿cómo se mostrarán las calificaciones?
¿Quieres dibujar estrellas, poner un número, o las
dos cosas?
Y Den optó por estrellas visuales y el
número al lado para que fuera accesible.
Pero la cuarta pregunta, esa es la que
demuestra que estamos ante algo diferente.
La IA le pregunta, ¿qué pasa con los
libros que has empezado a leer pero aún
no has terminado y no tienen fecha de
finalización?
Brutal.
A mí me parece fascinante.
O sea, ¿cómo Narizas sabe la IA que
eso va a ser un problema?
Lo detecta porque estos modelos analizan millones de
repositorios de código.
La IA sabe, estadísticamente, que en bases de
datos con fechas, si dejas un valor vacío
o nulo, el frontend explota.
Te rompe el ordenamiento de la primera pregunta.
Madre mía, qué fuerte.
Y claro, ante eso Den decidió que los
libros inconclusos se quedarían anclados arriba del todo
en una sección de leyendo actualmente.
Una salida muy elegante, la verdad.
Y la quinta pregunta ya cerraba el círculo
de la seguridad.
¿Qué hacemos si el archivo TOM está corrupto
o le faltan datos?
Pragmatismo en vena.
Porque Den le dijo que ignorara silenciosamente la
entrada con errores y renderizará el resto para
no asustar a la gente que visite la
web.
Y es que esta fase interactiva es revolucionaria.
Cuando nos quejamos de que la IA da
código basura, el 90 % de las veces
es nuestra culpa por darle un contexto pésimo.
Si obligas a la IA a preguntar primero,
las reglas quedan perfectas.
Vale.
Con los vacíos lógicos rellenados ya sabemos qué
construir.
Pero saber el qué no es saber el
cómo sin dinamitar el proyecto.
Por eso pasan al comando plan, donde la
IA toma las respuestas y diseña las tareas.
Y aquí te tengo que preguntar.
La IA propuso crear un sistema completo de
tests automatizados, pruebas de código.
Y Den literalmente intervino y se los cargó
todos.
Los borró de un plumazo.
A ver, perdóname, pero como principio de ingeniería,
quitar los tests no es una negligencia.
¿Qué pasa si una actualización le rompe la
lista mañana?
Es una reacción súper normal la tuya.
Desde un punto de vista académico, tendrías toda
la razón.
Pero lo fascinante de esto es que ilustra
por qué necesitamos al humano en el bucle.
La IA no entiende de presupuestos ni de
contexto social.
Claro, va con todo.
Exacto.
Aplica el rigor de una empresa enorme a
todo lo que hace.
Se cree que está diseñando el sistema de
frenado de un tren bala.
Pero Den es un tío manteniendo su blog
personal en su tiempo libre.
¿El contexto empresarial frente al pragmatismo personal?
Eso es.
En un blog estático, montar integración continua y
tests añade una complejidad monumental.
Ralentiza todo para una función que, si se
rompe, bueno, pues no se ve la portada
de un libro, ya está.
Den actuó como freno humano ante la sobreingeniería.
Tiene todo el sentido del mundo.
Agilidad por encima del dogma.
Y esta colaboración se afina aún más en
el siguiente paso, con el comando Analyze.
Spekit revisa el plan contra la Constitución.
Y la IA ahí brilla, porque detecta un
error tremendo de arquitectura.
El plan inicial decía de guardar los datos
en la carpeta config.
Pero la IA salta y dice, oye, las
convenciones de Hugo dicen que los datos van
en la carpeta data, no en config.
Qué nivel de detalle.
Es que ese nivel idiomático del ecosistema es
alucinante.
Sí, sí.
Demuestra que no es un simple lorito repitiendo
texto.
Entiende la semántica de las carpetas de los
frameworks modernos.
Y bueno, con el plan ya pulido, llega
el momento de ejecutar.
El comando Implement.
El choque de realidad, madre mía.
Siempre.
Siempre la teoría es perfecta hasta que abres
el navegador web.
Ya te digo.
Según cuenta Den, ejecuta el comando.
El backend funciona perfecto.
Los datos cargan.
Pero el frontend, la parte visual, es un
desastre absoluto.
En vez de una cuadrícula elegante, le sale
una lista plana y aburrida.
Típico.
Pero a ver, no lo entiendo.
Hablamos de IA que te programa algoritmos de
cifrado en segundos.
¿Y me estás diciendo que no sabe alinear
cuatro cajas en una pantalla con CSS?
Es que es una debilidad estructural gigantesca de
los modelos actuales.
Un LLM es ciego, fundamentalmente.
No ve la pantalla.
No tiene razonamiento espacial.
Ah, claro.
Solo predice texto.
Exacto.
Escribir Python es… … lógica secuencial.
Pero el CSS, especialmente una cuadrícula o flexbox,
es contextual y en dos dimensiones.
La IA puede adivinar qué clases de Tailwind
suelen ir juntas.
Pero no sabe cómo van a colisionar esos
píxeles en la pantalla del usuario.
Siempre hace falta iteración visual humana.
Es como si te hace los planos de
la casa perfectos, pero le tienes que decir
tú si el sofá va a caber por
la puerta del salón.
Tal cual.
Por eso, Den combina Cloud Sonnet 4 y
GPT -5 para ir refinando el diseño.
Le meten unas pastillas visuales muy chulas para
las fechas.
La etiqueta de lectura obligatoria.
Un contador.
Se empieza a ver genial.
Pero ojo que aquí ocurre un pivote técnico
brutal.
¿Te acuerdas de que habían exigido paginación de
20 libros en la fase de clarificación?
Sí, sí.
Parecía inamovible.
Pues desaparece por completo.
Se la cargan.
¿Qué provocó un cambio tan drástico a mitad
de camino?
Pues fue puro pragmatismo.
Lo que podríamos llamar esencialismo de software.
Se dieron cuenta de un conflicto arquitectónico de
fondo.
Si querían paginación real, sin recargar la web
entera, tenían que inyectar código JavaScript.
Y el JavaScript rompe la regla de la
pureza estática que vimos al principio.
Exactamente.
Añadir JavaScript para un triste botón de siguiente
iba en contra de 15 años de rendimiento
extremo.
Así que Den hizo algo dificilísimo.
Priorizó la simplicidad arquitectónica sobre un capricho estético.
Prefirió una sola página larga y súper rápida.
Brillante.
Saber decir no a tu propia idea para
no romper los cimientos.
Bueno, llegamos al éxito.
El código funciona.
Es rápido.
No hay JavaScript ni necesario.
Misión cumplida.
En teoría.
Claro.
El 99 % de la gente guardaría el
código, cerraría el ordenador y a otra cosa.
Pero Den da un último paso.
Y esto transforma un simple experimento en una
lección maestra de ingeniería.
Sí, porque la innovación no acaba cuando la
pantalla se ve bonita.
Durante la iteración, aprendieron cosas.
Por ejemplo, que si no le daban un
ancho fijo a las tarjetas, rebotaban por culpa
del tamaño de los títulos.
O usar emojis específicos para cada estado, claro.
Eso es.
Y Den le ordena a la IA que
coja todos esos descubrimientos empíricos y los escriba
de vuelta en el archivo original de especificaciones,
en el spec .md.
O sea, actualiza el texto con lo aprendido.
Pero, ¿qué significa esto en realidad?
¿Por qué es tan vital hacer esto si
el código ya funciona perfectamente?
Pues porque cambia la perspectiva por completo.
Históricamente, un documento de requisitos era una servilleta
glorificada que tirabas a la basura en cuanto
escribías la primera línea de código.
Ahora, ese documento se convierte en un artefacto
independiente y vivo.
Es la única fuente de verdad.
Exacto.
Es como, a ver, como si extrajera el
ADN de la aplicación para separarlo del cuerpo
físico, ¿no?
Me encanta esa forma de verlo.
Imagina que dentro de cinco años Den se
harta de Hugo y quiere reescribir su blog
en otro lenguaje que aún ni existe.
Si no tuviera el documento, tendría que hacer
ingeniería inversa.
Leer código superviejo y volvería a cometer los
mismos errores con los anchos de las tarjetas.
Claro.
Pero con este sistema, no empieza de cero
ni se pone a discutir la lógica con
la IA del futuro.
Solo le da ese archivo superdetallado y le
dice, esta es la filosofía inmutable de mi
aplicación.
Reconstrúyela con la tecnología de hoy.
Es un cambio de paradigma total.
Pasamos de venerar el código fuente a venerar
el concepto.
O sea, la magia de la IA no
es escupir líneas de código desechable, sino obligarnos
a pensar y documentar con precisión de cirujano.
Y esto nos lleva a una reflexión final
que es, vamos, provocadora.
Si un documento vivo puede preservar la esencia
exacta de un programa sin importar en qué
esté escrito, ¿estamos ante el principio del fin
del código heredado?
El famoso código viejo intocable.
Ese que todo el mundo tiene miedo de
tocar, sí.
Ya no tienes que parchear código frágil de
hace quince años.
Le pides a la máquina que lo regenere
enterito con las librerías de esta semana.
Exacto.
Quizás en el futuro nuestro trabajo no sea
leer código viejo, sino simplemente conversar con la
IA para auditar esa constitución y esas especificaciones.
Las máquinas ya tejerán y destejerán el código
por debajo cada pocos meses.
El código pasa a ser un código.
Es un subproducto efímero.
Y la idea es lo eterno.
Una reflexión alucinante sobre cómo nos vamos a
relacionar con lo que creamos.
Merece la pena darle una vuelta cuando nos
frustremos con un sistema antiguo.
Antes de despedirnos, hasta el próximo programa os
informamos de que las voces que oyes han
sido generadas por la IA de Notebook LM
y que dirigiendo el podcast se encuentra Julio
Pablo Vázquez, un humano que te envía saludos.
En caso de error, probablemente sean errores humanos.
Nos escuchamos.
Hasta el próximo episodio de hoy.
Muchas gracias por tu atención.
Esto es BIM Praxis.
Nos escuchamos en el próximo episodio.