Buenas, esto es BIMPRAXIS, el podcast donde el
Download transcript (.srt)
0:09
0:15
0:20
0:23
0:26
0:28
0:36
0:40
0:41
0:50
1:09
1:11
1:14
1:14
1:16
1:18
1:20
1:21
1:24
1:29
1:30
1:32
1:36
1:38
1:40
1:41
1:43
1:44
1:46
1:47
1:50
1:53
1:56
1:59
2:01
2:03
2:03
2:06
2:09
2:11
2:14
2:14
2:18
2:20
2:23
2:26
2:26
2:29
2:32
2:33
2:34
2:37
2:38
2:40
2:43
2:46
2:47
2:49
2:51
2:54
2:56
3:00
3:02
3:05
3:07
3:10
3:12
3:13
3:13
3:15
3:18
3:20
3:20
3:23
3:25
3:28
3:30
3:32
3:35
3:38
3:38
3:41
3:42
3:45
3:46
3:48
3:50
3:53
3:55
3:56
3:57
4:00
4:03
4:05
4:06
4:09
4:11
4:13
4:16
4:16
4:17
4:20
4:22
4:24
4:26
4:29
4:30
4:35
4:36
4:38
4:42
4:42
4:45
4:45
4:48
4:51
4:52
4:55
4:55
4:58
5:00
5:03
5:05
5:07
5:10
5:11
5:12
5:14
5:16
5:18
5:19
5:21
5:24
5:26
5:27
5:28
5:30
5:32
5:35
5:37
5:39
5:41
5:41
5:42
5:45
5:46
5:48
5:51
5:54
5:55
5:58
5:59
6:01
6:03
6:05
6:08
6:10
6:11
6:12
6:15
6:17
6:18
6:21
6:25
6:26
6:27
6:29
6:33
6:35
6:38
6:39
6:41
6:42
6:43
6:43
6:47
6:49
6:52
6:56
6:57
6:58
7:02
7:03
7:05
7:07
7:11
7:13
7:15
7:17
7:19
7:20
7:23
7:25
7:27
7:28
7:31
7:32
7:34
7:37
7:41
7:42
7:44
7:44
7:47
7:47
7:51
7:52
7:54
7:56
7:58
8:00
8:04
8:05
8:07
8:10
8:13
8:15
8:16
8:17
8:20
8:21
8:23
8:24
8:27
8:28
8:31
8:33
8:34
8:35
8:37
8:38
8:41
8:42
8:45
8:46
8:49
8:52
8:55
8:58
9:01
9:03
9:05
9:06
9:09
9:09
9:10
9:12
9:13
9:16
9:17
9:19
9:22
9:24
9:24
9:25
9:29
9:32
9:34
9:36
9:38
9:42
9:42
9:44
9:45
9:46
9:49
9:52
9:54
9:56
9:58
9:59
10:02
10:06
10:07
10:09
10:11
10:13
10:14
10:17
10:18
10:21
10:24
10:27
10:27
10:28
10:30
10:32
10:33
10:35
10:38
10:39
10:40
10:42
10:45
10:47
10:48
10:52
10:54
10:56
10:57
10:59
11:01
11:03
11:04
11:04
11:07
11:08
11:10
11:12
11:13
11:15
11:16
11:17
11:19
11:22
11:23
11:26
11:29
11:31
11:32
11:35
11:35
11:37
11:40
11:42
11:44
11:45
11:47
11:49
11:50
11:51
11:54
11:55
11:58
12:01
12:04
12:04
12:07
12:08
12:11
12:12
12:12
12:15
12:17
12:19
12:22
12:22
12:23
12:26
12:28
12:30
12:31
12:34
12:36
12:37
12:38
12:39
12:40
12:43
12:46
12:48
12:48
12:53
12:56
12:59
13:02
13:04
13:07
13:09
13:11
13:13
13:15
13:15
13:18
13:20
13:23
13:25
13:26
13:28
13:31
13:34
13:37
13:42
13:43
13:44
13:46
13:48
13:51
13:52
13:53
13:54
13:56
13:59
14:00
14:03
14:03
14:06
14:10
14:11
14:13
14:14
14:15
14:18
14:20
14:21
14:23
14:25
14:28
14:31
14:33
14:34
14:38
14:42
14:44
14:46
14:48
14:51
14:52
14:54
14:56
14:58
14:59
14:59
15:02
15:04
15:06
15:10
15:13
15:15
15:17
15:21
15:22
15:25
15:29
15:32
15:34
15:36
15:38
15:43
15:46
15:48
15:51
15:54
15:55
15:57
15:59
16:02
16:05
16:08
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 SPECKIT de GitHub.
Sí, sí, y sin que un ser humano
tenga que picar ni una sola línea de
código, que se dice pronto.
Exacto.
Es que eso, bueno, ha dejado de ser
una promesa de ciencia ficción.
Esa es la realidad arquitectónica que vamos a
diseccionar hoy aquí.
Y el catalizador de toda esta locura es
el desarrollo guiado por especificaciones, o SDD por
sus siglas en inglés.
Vamos a meterle mano a este concepto a
través de SPECKIT, que, bueno, para quien no
lo conozca, es una herramienta de código abierto
de la gente de GitHub que lo ha
reventado.
O sea, más de 16 ,000 estrellas en
su primera semana.
¡Qué barbaridad!
Totalmente.
El objetivo de hoy es entender los mecanismos
profundos que permiten a los equipos dejar de
lado la improvisación y, básicamente, obligar a la
IA a generar sistemas robustos de verdad.
Porque, a ver, la improvisación es justo lo
que ha dominado la industria este último año,
¿no?
Cualquiera que haya estado trasteando con modelos generativos
para crear apps ha terminado, casi seguro, en
el agujero negro este del vibe coding.
Uf, el famoso vibe coding, ¿sí?
Sí.
Escribirle un prompt de dos líneas en plan,
créame un clon de una red social de
fotos y sentarte a esperar un milagro.
Ya, y el espejismo al principio es brutal,
¿eh?
Porque durante los primeros minutos ves la pantalla
llenarse de componentes, de estilos visuales.
Parece magia.
Parece magia pura, exacto.
Pero el problema del vibe coding es que
no tiene cimientos.
O sea, la tercera o cuarta iteración, cuando
intentas meter, no sé, una pasarela de pago
o tocar el sistema de usuarios, ¡boom!, el
proyecto colapsa.
Claro, te empiezan a salir dependencias circulares, el
diseño se rompe por todos lados.
Y el código acaba siendo un laberinto ilegible.
Para visualizarlo un poco, es como intentar construir
una casa gritándole ideas sueltas a un grupo
de obreros que, además, llevan los ojos vendados,
en lugar de, pues eso, darles unos planos
arquitectónicos en condiciones.
Con placer, de forma estadística, la última petición
que le has hecho.
Claro, te dice que sí.
A todo.
Y si le pides un cambio muy radical,
pues lo intenta meter con calzador y te
destroza la lógica que tenía antes.
Exacto.
Y el problema técnico real detrás de esto
es lo que llamamos la degradación del contexto.
A ver, los LLMs tienen una memoria finita.
Si tú llevas un chat de docenas de
mensajes, el modelo empieza a perder el rastro
de las instrucciones originales.
Claro, prioriza lo último que le has dicho.
Eso es.
Y el vibe coding confía ciegamente en que
la máquina se va a acordar de toda
tu estrategia global, cuando su arquitectura no da
para eso.
Y justo ahí es donde entra la interfaz
de línea de comandos de SpecKit, el CLI
llamado Specify, y lo cambia absolutamente todo.
Y mete un cambio que impone una gobernanza
absoluta.
O sea, es una pasada.
De hecho, mirando el flujo de SpecKit, me
llamó muchísimo la atención que el primer paso,
después de iniciar el proyecto, ignora por completo
el código.
O sea, te exige ejecutar un comando que
es speckit .constitution.
Sí.
Crear un archivo Markdown con la constitución del
proyecto.
Eso es.
O sea, las leyes inmutables del sistema, ¿no?
Volviendo a lo de las físicas que decías
antes, es como en un motor de videojuegos.
Si el motor dice que una pared es
sólida, el muñeco no la atraviesa, por mucho
que aporrees el mando.
La constitución en SpecKit, el archivo constitution .md,
pues hace lo mismo.
Son principios innegociables.
Claro, cosas como estándares de accesibilidad, patrones de
diseño.
O directamente, prohibir tecnologías.
Exacto.
Y fíjate en el caso de Dan Delimarsky,
el mantenedor del proyecto, que lo explicaba construyendo
la web de su podcast.
En su constitución, él puso unas reglas de
hierro.
La web tenía que ser estática, cero bases
de datos y JavaScript puro y duro.
Nada de frameworks pesados.
Y eso es brillante, porque así neutralizas el
sesgo que tiene la IA por defecto.
A ver, estos modelos se entrenan con GitHub
y Stack Overflow.
Así que a la mínima… Te van a
querer meter un React y una base de
datos relacional, porque es lo que más ven,
estadísticamente.
Totalmente.
Pero al fijar la regla de entrega estática
pura en ese documento de constitución, el sistema
inyecta eso en el system prompt de cada
maldita llamada al API.
Es como un ancla.
O sea, si dentro de un mes a
alguien se le ocurre pedir una función para,
no sé, guardar episodios favoritos, y a la
IA le parece súper tentador montar una base
de datos en la nube… La constitución le
dice que ni de broma.
Exacto.
Lo bloquea.
Y obliga a la IA a buscarse la
vida de otra forma.
Yo qué sé, usando el almacenamiento local del
navegador, pero siempre respetando la ley.
Y así te cargas la degradación de contexto
de un plumazo.
Pero a ver, poner restricciones no te construye
el producto.
O sea, evitas que se caiga la casa,
pero no defines la lógica de negocio.
Para eso, el framework tiene otro comando, que
es specit .specify.
Aquí es donde defines el qué y el
por qué, ¿verdad?
Eso es.
Se hace mediante historias de usuario y criterios
de aceptación, pero ojo, con una regla de
oro.
Está terminantemente prohibido hablar de tecnología.
Nada de mencionar Python, ni servidores… Nada.
Cero.
A ver, ¿qué yo tengo que hacer de
abogada del diablo, vale?
Porque, metodológicamente, esto de redactar requisitos súper exhaustivos
y blimbar el diseño antes de tirar una
línea de código… Te suena a cascada, ¿no?
Al modelo Waterfall.
Es un poco paradójico que ahora la IA
nos devuelva eso.
¿No crees?
Ya.
A ver, la comparación es inevitable, lo entiendo.
Pero hay una diferencia mecánica brutal.
El problema del Waterfall era el tiempo.
Que te tirabas meses validando documentos entre departamentos.
Claro, el factor humano.
Exacto.
Specit resuelve esa lentitud con el comando specit
.clarify.
O sea, el sistema no coge tu especificación
y asiente como un tonto.
Activa un motor lógico y busca ambigüedades, fallos
o casos límite que tú… No has pensado.
O sea, no se comporta como un ejecutor
servicial, sino que se pone la gorra de
arquitecto o de product manager.
Eso es.
Si le pides un formulario para subir fotos,
la IA te para y te dice, vale,
¿cuál es el peso máximo?
¿Qué formatos admitimos?
¿Qué pasa si el servidor da un timeout?
Qué bueno.
Te fuerza a tapar los agujeros en minutos.
Y claro, una vez que tienes el qué
totalmente definido y aislado de la tecnología, pues
llegamos a la revelación.
La revelación más loca de todo esto del
SDD.
Que el código fuente deja de importar.
Exacto.
El código pasa a ser, bueno, un subproducto
desechable.
Y esto cuesta asimilarlo, ¿eh?
Llevamos 50 años donde el código era el
rey de la empresa tecnológica.
Pero si toda tu lógica está en un
markdown agnóstico, el andamiaje técnico te da igual.
Te da exactamente igual.
Imagínate que tienes algo montado en Next .js
súper complejo y de repente el negocio pide
ir a toda pastilla con contenido estático.
Hacer eso hoy en día es reescribirlo todo
durante meses.
Ya te digo.
Pero con este paradigma, tu spec .md no
se toca.
Cambias el mandato técnico y el sistema te
regenera la aplicación entera.
El código acaba siendo solo el resultado de
una compilación, ¿sabes?
Como el binario que te escupe, C++.
Lo único que vale oro o aura es
la especificación.
Vale.
Pero bajemos un poco a la tierra, que
aquí hay un salto.
Tenemos la constitución, tenemos las especificaciones.
Pero, ¿cómo pasa?
¿De esos textos lógicos a carpetas con código
real que funcione?
Bueno, esa coreografía tiene dos pasos.
Primero tiras specitplan, que coge tus requisitos y
define la arquitectura técnica formal.
Enrutamiento, estado, dependencias.
Y luego entra el verdadero peso pesado, el
comando specit .tasks.
Que, ojo, no te hace una lista de
la compra de tareas.
Te monta un grafo acíclico dirigido.
Toma ya.
Sí, sí.
Una estructura matemática para matemáticas.
Para mapear qué depende de qué.
Y eso, claro, te evita las típicas condiciones
de carrera, ¿no?
La máquina entiende que no puede montar la
interfaz de la lista de usuarios si antes
no ha diseñado la base de datos de
sus usuarios.
Exactamente.
Te hace una topología perfecta.
Incluso detecta qué tareas son independientes entre sí.
Y les pone una etiqueta de paralelo, una
P entre corchetes.
Pero, ojo, la verdadera magia aquí es cómo
te impone el TDD, el desarrollo guiado por
pruebas.
Uy, el ciclo este de rojo -verde y
refactorizar.
Ese mismo.
El plan exige que la IA escriba primero
el test unitario, lo ejecute y que falle.
Si no hay un test fallando, el sistema
bloquea la escritura del código.
Es un filtro implacable.
Qué maravilla.
Y fíjate, leyendo la documentación de Dan Delimarsky,
menciona una técnica súper interesante gracias a dividir
tanto las tareas.
Como todo va por archivos de texto, tú
puedes pausar la cosa y cambiar el modelo
de IA a mitad de camino.
Ostras, claro.
Optimización pura de costes y capacidades.
Eso es.
Para montar el grafo de dependencias o pensar
la constitución, necesitas un modelo que razones súper
bien a nivel sistémico, tipo un GPT -5,
¿no?
Sí.
Pues usas ese para planificar.
Y cuando ya tienes el archivo de tareas
perfecto, pausas.
Cambias el motor a algo como Clot 3
.5 Sonet, que escribiendo sintaxis pura es un
avión.
Y lanzas el comando final.
El spekit .es.
O sea, usas al mejor arquitecto para pensar
y al mejor albañil para poner los ladrillos.
Tal cual.
Pero oye, sobre ese comando spekit .implement, yo
al principio pensaba que esto mandaba los archivos
a un servidor en la nube y te
devolvía un zip con la app.
Ah, no, no, no, que va.
Esto ocurre en tu propia máquina.
O sea, ¿tiene permisos para ejecutar cosas en
mi terminal?
Sí.
Interactúa con tu sistema de archivos local.
Lanza procesos reales.
Te instala paquetes de NPM.
Te compila la app.
O te corre un lighthouse para ver el
rendimiento en tiempo real.
Todo en local.
Madre mía.
A ver, eso está genial porque mantienes tú
el control y puedes revisar los archivos antes
de hacer un commit.
Pero a nivel de seguridad, tela.
Ahora, también te digo, todo este flujo es
precioso en un entorno ideal, pero las empresas
tienen herramientas muy arcaicas.
Si esto fuera un sistema cerrado, nadie lo
usaría.
Y por eso se llama SpecKit.
Su arquitectura interna tiene un sistema de prioridades
que te permite anular casi...
casi todo mediante dos cosas.
Extensiones y presets.
A ver, las extensiones me las imagino.
Para conectar con el mundo real, ¿no?
Exacto.
Para tirar muros.
La comunidad ya ha montado integraciones con Azure
DevOps con Jira.
Claro, el sistema genera las tareas técnicas y
la extensión te las crea automáticamente, como tickets
en el tablero del proyecto de la empresa.
Eso es.
O extensiones para meter flujos de QA corporativos
automáticos.
Pero luego están los presets, que esto sí
que es...
Es profundo.
No añaden herramientas, sino que le cambian el
cerebro al sistema.
Alteran cómo procesa la información.
Hay presets corporativos para temas legales o financieros,
¿verdad?
Sí.
Te fuerzan a cumplir estándares muy locos.
Pero a ver, los más bestias son los
que la comunidad ha llevado al límite del
absurdo.
O sea, fíjate, en la propia documentación oficial
tienen un preset que se llama Habla Pirata.
Ah, sí.
El Pirate Speak.
Es buenísimo.
Es que es de locos.
Tú activas eso y el sistema sigue programando
perfecto, pero todo el marco conceptual se disfraza
con palabras de corsarios.
Sí, sí.
Las especificaciones pasan a llamarse manifiestos de viaje,
la arquitectura es el plan de batalla y
las tareas son asignaciones de la tripulación.
La IA te monta una app moderna, pero
hablando como un pirata del siglo XVII.
Y, a ver, parece una fricada de programadores,
que lo es, pero demuestra algo vital.
La separación total entre la capa...
...la capa semántica y la capa sintáctica.
Ese es el punto clave.
Claro.
SpecKit obliga a la IA, mediante JSON súper
rígidos, a usar el tono pirata para los
comentarios, los textos, los botones, pero al mismo
tiempo le impone una disciplina brutal en la
sintaxis.
El código en Python o React tiene que
ser matemáticamente perfecto para que compile.
O sea, consiguen que un LLM, que tiende
a alucinar y mezclar cosas, mantenga esa frontera
impermeable entre su creatividad pirata y el rigor
de compilación.
Exactamente.
Eso demuestra un control absoluto.
Y, rizando el rizo, he visto que hay
alguien que ha usado un preset para escribir
libros de ficción.
Madre mía.
Sí, sí.
O sea, han cogido este framework de ingeniería
de software y lo han transformado en un
motor narrativo.
Las funciones de código son los arcos de
los personajes.
La Constitución dicta las reglas de ese mundo
de fantasía y usan el TDD para asegurarse
de que no hay agujeros de guión.
Es que eso te dice lo que es
realmente SpecKit.
No es solo para hacer webs.
Es un motor universal para la resolución algorítmica
de problemas complejos.
Da igual si quieres montar el sistema de
un banco o escribir una novela.
Coges un problema gigante, lo divides en partes
pequeñas, verificables y en paralelo.
Y, uff, a ver, esto nos lleva a
la gran reflexión final, ¿no?
Sí, el futuro del sector.
Claro, si el SDD consigue abstraer por completo
lo que queremos hacer del código máquina, ¿dónde
deja esto a los millones de profesionales que
se han ganado la vida memorizando lenguajes de
programación?
Pues, sinceramente, nos asomamos a una reestructuración total
de la informática.
Hasta ahora, el mercado te pagaba muy bien
por conocer las entrañas de la sintaxis, por
saber dónde poner el punto y coma o
cómo gestionar la memoria.
Ya.
Pero si la IA asune esa ejecución manual,
el valor de picar código cae en picado.
La competencia clave ahora va a ser la
claridad de pensamiento estructural, saber definir arquitecturas, comunicarte
sin ambigüedades y controlar esta automatización.
O sea, pasas de ser un traductor de
instrucciones a un director de orquesta.
Y, bueno, eso deja una pregunta fascinante para
quienes nos escuchan hoy.
Si ahora mismo un texto bien estructurado en
español puede gobernar y generar aplicaciones enteras de
forma predecible, matando el caos este del vibe
coding, estamos en un punto de no retorno.
Da que pensar, desde luego.
A ver, si lenguajes que hoy nos parecen
sagrados, tipo Python, Java o Rust, acaban relegados
al mismo sótano oscuro que el lenguaje ensamblador.
Igual resulta que, dentro de muy poco, el
lenguaje natural bien pensado sea el único lenguaje
de programación que un humano necesite dominar.
Totalmente posible, ¿ya ves?
Que las voces que oyéis 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!