Buenas, esto es BIMPRAXIS, el podcast donde el
Download transcript (.srt)
0:10
0:15
0:20
0:23
0:26
0:28
0:37
0:38
0:42
0:44
0:45
0:48
0:49
0:51
0:52
0:54
0:57
0:59
1:00
1:02
1:05
1:10
1:12
1:14
1:14
1:17
1:20
1:23
1:26
1:28
1:29
1:31
1:34
1:37
1:39
1:43
1:44
1:44
1:45
1:48
1:51
1:52
1:54
1:57
1:58
2:00
2:03
2:05
2:07
2:10
2:12
2:14
2:17
2:20
2:23
2:25
2:28
2:29
2:30
2:33
2:35
2:37
2:39
2:39
2:41
2:42
2:45
2:46
2:48
2:51
2:52
2:54
2:55
2:56
2:57
3:00
3:02
3:05
3:07
3:09
3:12
3:14
3:16
3:17
3:19
3:20
3:23
3:25
3:28
3:29
3:32
3:34
3:38
3:40
3:43
3:45
3:46
3:47
3:52
3:54
3:57
4:00
4:03
4:04
4:07
4:08
4:11
4:13
4:15
4:18
4:20
4:23
4:26
4:27
4:28
4:30
4:33
4:35
4:39
4:41
4:42
4:43
4:45
4:47
4:50
4:54
4:55
4:57
5:00
5:03
5:06
5:07
5:09
5:11
5:11
5:13
5:15
5:18
5:21
5:22
5:24
5:26
5:28
5:30
5:34
5:34
5:37
5:40
5:41
5:42
5:46
5:47
5:51
5:52
5:55
5:58
6:01
6:02
6:05
6:05
6:08
6:11
6:13
6:15
6:18
6:18
6:19
6:20
6:21
6:23
6:26
6:28
6:31
6:32
6:34
6:36
6:38
6:39
6:42
6:44
6:46
6:49
6:51
6:54
6:55
6:57
6:59
7:00
7:02
7:02
7:05
7:07
7:09
7:12
7:14
7:17
7:19
7:22
7:25
7:27
7:28
7:31
7:34
7:37
7:40
7:43
7:45
7:49
7:51
7:53
7:56
7:58
8:00
8:03
8:04
8:06
8:08
8:10
8:12
8:14
8:16
8:19
8:20
8:23
8:26
8:30
8:31
8:34
8:35
8:38
8:41
8:43
8:45
8:47
8:49
8:51
8:53
8:56
9:00
9:02
9:03
9:06
9:10
9:14
9:17
9:18
9:21
9:24
9:27
9:28
9:29
9:31
9:34
9:35
9:37
9:39
9:41
9:43
9:45
9:47
9:49
9:53
9:54
9:56
10:00
10:03
10:04
10:06
10:08
10:10
10:12
10:14
10:16
10:19
10:21
10:24
10:27
10:29
10:30
10:32
10:35
10:36
10:38
10:39
10:41
10:44
10:45
10:47
10:48
10:50
10:51
10:54
10:54
10:56
10:57
11:00
11:03
11:05
11:06
11:09
11:12
11:13
11:15
11:17
11:21
11:25
11:27
11:30
11:31
11:34
11:37
11:39
11:41
11:44
11:47
11:49
11:51
11:54
11:56
11:58
12:02
12:04
12:06
12:08
12:11
12:12
12:15
12:17
12:18
12:20
12:21
12:24
12:28
12:29
12:32
12:33
12:36
12:37
12:40
12:42
12:44
12:46
12:50
12:52
12:54
12:57
12:58
13:00
13:02
13:05
13:07
13:08
13:10
13:13
13:15
13:17
13:19
13:20
13:22
13:25
13:27
13:29
13:31
13:33
13:35
13:38
13:40
13:41
13:43
13:46
13:47
13:50
13:53
13:56
13:58
13:59
14:01
14:03
14:06
14:08
14:10
14:12
14:13
14:16
14:18
14:22
14:23
14:24
14:26
14:29
14:31
14:32
14:33
14:35
14:37
14:39
14:41
14:42
14:45
14:47
14:49
14:51
14:53
14:56
15:01
15:02
15:03
15:06
15:08
15:09
15:12
15:14
15:15
15:18
15:19
15:22
15:23
15:26
15:28
15:31
15:32
15:33
15:37
15:39
15:42
15:44
15:45
15:47
15:49
15:51
15:53
15:53
15:57
15:59
16:02
16:04
16:08
16:10
16:12
16:14
16:16
16:18
16:20
16:22
16:23
16:26
16:27
16:30
16:31
16:33
16:35
16:38
16:40
16:43
16:45
16:47
16:50
16:52
16:53
16:57
16:59
17:03
17:05
17:08
17:09
17:11
17:13
17:15
17:17
17:19
17:22
17:24
17:27
17:30
17:34
17:46
17:48
17:59
18:01
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 crisis existencial de la
programación.
Y si la inteligencia artificial va a dejarnos
a todos en el paro en cuestión de
meses.
Hola, ¿qué tal?
Y, a ver, es un titular fuerte, pero
es que la ansiedad ahora mismo es real,
o sea, se palpa en el ambiente.
Totalmente.
Imaginemos la situación de alguien que lleva cinco
o seis años dejándose los codos estudiando a
fondo ingeniería de software, algoritmos, estructuras de datos,
patrones de diseño, todo eso.
Sí, sí, una paliza de estudio.
Exacto.
Y de repente una mañana abre su ordenador,
escribe un párrafo en inglés normal y corriente
en plan conversacional y en tres segundos la
inteligencia artificial le escupe una arquitectura perfecta.
Algo que a esa persona le habría costado
semanas enteras.
Claro, y te quedas a cuadros.
Es un vértigo completamente comprensible, ¿sabes?
Porque tendemos a imaginar el progreso tecnológico como
una escalera mecánica.
En plan, sube de manera constante, predecible… Pero
no es así.
¿Qué va?
¿Qué va?
El desarrollo de software avanza a sacudidas.
Da unos saltos bruscos que dejan a muchísima
gente descolocada.
Quienes ven hoy a la máquina programar a
esa velocidad, pues sienten que el suelo desaparece
bajo sus pies.
Y para abordar este miedo, que té la
marinera, hoy tenemos un material de origen excepcional
para nuestro análisis a fondo.
Vamos a desgranar una entrevista reciente del canal
de Pragmatic Engineer a Grady Butch.
¿Palabras mayores?
Para poner en contexto a quienes nos escuchan,
estamos hablando de una auténtica leyenda viva de
la informática, co-creador del lenguaje unificado de modelado,
el famoso UML, y alguien que, literal, ha
estado en la sala de máquinas de cada
revolución tecnológica desde los años 70.
No es un teórico, ¿eh?
No, no.
Es alguien que ha construido los cimientos sobre
los que todos operamos hoy en día.
Y su tesis central en esta entrevista es
brutal para rebajar los humos y la ansiedad
actual.
A ver, cuenta, cuenta.
Pues él utiliza la historia de la informática
para demostrar que no estamos asistiendo al funeral
de la programación.
Que va, con datos históricos en la mano,
argumenta que estamos cruzando el umbral hacia lo
que él llama la tercera edad de oro
de la ingeniería de software.
O sea que este pánico ya lo hemos
vivido antes.
Muchas veces.
Y siempre, siempre, acaba liberando el talento humano
para resolver problemas mucho más gordos.
Vale, vamos a desgranar esto poco a poco.
Porque para aceptar que la IA no va
a destruir la profesión, primero hay que entender
qué narices es exactamente esta profesión.
Hay un malentendido gigante sobre lo que hace
un ingeniero de software, ¿verdad?
Enorme.
La gente se cree que es picar código
a lo loco.
Y Butch nos lleva al origen del término.
Nos planta en los años 60 con Margaret
Hamilton durante el programa Polo de la NASA.
Qué locura de historia la de Hamilton.
Es el pilar de todo.
Ella formaba parte de ese ínfima porcentaje de
personas, casi todas mujeres en aquel entonces, que
escribía los programas para ir a la Luna.
Pero claro, estaba rodeada de hombres que diseñaban
el hardware, los motores, el metal.
Lo tangible.
Eso es.
Y para esos ingenieros tradicionales, el software era
como una tarea de secretariado.
En plan, teclear notas y ya está.
Hamilton tuvo que pelear a brazo partido para
acuñar el término ingeniería de software.
Y que la tomaran en serio.
Y el argumento que usó es brillante, a
ver si estás de acuerdo.
Ella decía que no estaban tecleando comandos sin
más, estaban haciendo ingeniería pura.
Exacto, exacto.
Es que yo lo comparo con un arquitecto.
Si tú diseñas un rascacielos, no te pagan
por apilar ladrillos rapidísimo, te pagan por entender
el presupuesto, la física del suelo, los vientos
y cómo los humanos van a vivir ahí
dentro.
Claro, dice en el clavo.
Ella demostró que los programadores estaban equilibrando fuerzas
complejísimas.
Limitaciones físicas inamovibles, como la memoria minúscula que
tenían los ordenadores del Apolo.
Que hoy en día cualquier reloj tiene más
memoria.
Muchísima más.
Tenían que lidiar con la velocidad de la
luz para transmitir datos a la Tierra, presupuestos
ajustados… O sea, la ingeniería nunca ha consistido
en escribir código.
El código es solo la herramienta.
El código es un subproducto, digamos.
La ingeniería de verdad es equilibrar fuerzas dinámicas
para crear soluciones que no exploten en el
mundo real.
Y entender esta diferencia es lo que nos
abre la puerta a esa primera edad de
oro, ¿no?
Que va desde los años 40 a los
70.
Una época en la que programar significaba literalmente
ir a un armario metálico y enchufar y
desenchufar cables.
Sí, sí, sudando la gota gorda.
El hardware y el software eran la misma
cosa física.
Pero gracias a pioneras como Grace Hopper y
luego la inversión brutal de IBM, logramos separar
eso.
Pasamos del código ensamblador, que estaba súper atado
a los circuitos de una máquina específica, a
la abstracción algorítmica.
Eso es.
Inventamos cosas como COBOL o FORTRAN.
En vez de hablarle a las válvulas de
vacío, empezamos a usar fórmulas matemáticas comprensibles por
los humanos.
Y aquí, según las fuentes, estalla el primer
pánico monumental de la historia de la informática.
Los expertos en ensamblador se aterrorizaron.
¿Normal?
Vieron los primeros compiladores y pensaron que se
iban al paro.
Creían que esos programas, que traducían Fortran a
código máquina automáticamente, iban a hacer que el
ordenador se programara solo.
Y como siempre, el miedo fue infundado.
Esa capa de abstracción no eliminó a los
ingenieros.
Al revés.
Les quitó el trabajo sucio.
Claro.
Al no tener que gestionar ceros y unos
a mano, pudieron levantar la vista y construir
sistemas gigantescos.
Y hay que hablar de quién ponía la
pasta para esto.
Uf, sí, esto me dejó de piedra.
No era el sector privado en su garaje.
Era la guerra fría pura y dura.
Totalmente.
Butch menciona el sistema SAJ, un proyecto de
defensa de Estados Unidos para coordinar radares y
detectar bombarderos nucleares soviéticos.
fue tan masivo, tan bestia, que llegó a
absorber entre el 20 y el 30% de
todos los desarrolladores de Estados Unidos.
Espera, espera.
¿Un tercio del talento de todo un país
en un solo proyecto militar?
Es una locura.
Es que el incentivo era no desaparecer del
mapa.
Con la amenaza nuclear, el presupuesto era infinito.
Satch obligó a inventar el futuro de golpe.
O sea, tuvieron que inventar el procesamiento en
tiempo real, los sistemas distribuidos.
Hasta las primeras interfaces gráficas, ¿no?
Con aquellas pantallas de tubos de rayos catódicos.
Sí, forzando los límites del cerebro humano.
Pero claro, ese éxito tan gigante fue precisamente
lo que rompió la baraja poco después.
Llegamos a los años 70 y el invento
colapsa por su propio peso.
Es que era predecible.
A ver, la demanda para gestionar misiles, bancos,
gobiernos, creció tanto que el cerebro humano ya
no podía rastrear los errores en un código
que era completamente secuencial.
Entramos en la famosa crisis del software.
Sí, acuñado por la OTAN, nada menos.
Entregar un proyecto a tiempo y sin errores
era poco menos que un milagro.
Hay un dato escalofriante en las fuentes.
El gobierno de Estados Unidos se dio cuenta
de que tenían sus sistemas escritos en más
de 14.000 lenguajes de programación distintos.
¡14.000!
Imagínate el caos.
Una base antiaérea no podía comunicarse con la
de al lado porque hablaban idiomas distintos.
Tuvieron que lanzar el proyecto ADA a la
desesperada para unificar eso.
Y esa crisis tan bestial es la que
nos empuja a la segunda edad de oro.
Y ojo, no fue un salto de mejor
tecnología, fue un cambio de mentalidad.
De la abstracción algorítmica pasamos a la programación
orientada a objetos, la famosa OOP.
Exacto.
Y aquí Butch se pone filosófico, que me
encanta.
Nos dice que este cambio refleja un debate
de Platón sobre cómo entendemos la realidad.
O sea, frena un momento.
¿Qué tiene que ver Platón con arreglar un
código desastroso en los 70?
Pues muchísimo.
A ver, tiene que ver con cómo ordenamos
el caos.
Platón debatía si debíamos mirar el mundo como
procesos, o sea, acciones continuas, o como cosas,
objetos con propiedades.
¿Vale?
Hasta los 70 todo era proceso.
Funciones matemáticas larguísimas, modificando datos sueltos, cuando el
programa se hacía enorme, encontrar qué función había
roto qué dato era misión imposible.
Vale, lo voy pillando.
Cambiamos de bando platónico, digamos.
Sí, la orientación a objetos dijo, basta, vamos
a juntar los datos y las funciones en
una caja cerrada.
Un objeto.
Y así ocultas la complejidad.
Un equipo hace el semáforo, otro el coche,
y el sistema no colapsa.
Es brillante.
Pero lo que me parece más flipante es
la mezcla cultural donde nace esto.
En los 80, esta tecnología choca con dos
mundos opuestos.
Sí, es una mezcla rarísima.
Por un lado, tenemos a Silicon Valley, empresas
como Failed Child, fabricando microchips de silicio para
el guiado de misiles balísticos.
Tecnología militar de la dura.
Y por otro lado, esos mismos transistores superminiaturizados
caen en manos de la contracultura hippie de
California.
Me estás diciendo que el ordenador personal nace
de cruzar la guerra nuclear con el rollo
de paz y amor de los hippies.
Es una ironía maravillosa.
Los transistores bajaron tanto de precio que la
gente los compraba en revistas.
Y los hippies dijeron, oye, el poder para
el pueblo, liberemos la información.
Empezaron a soldar placas en los garajes.
Sí, para comunicarse fuera del radar del gobierno.
Así nace The Well, una de las primeras
comunidades virtuales.
Y ahí está el germen del código abierto.
Lo que Grady Butch llama el telar del
dolor.
¡Qué expresión tan poética y oscura!
Es buenísima.
El telar del dolor explica que nuestra historia
siempre ha estado impulsada por el comercio y
por la guerra.
Esa colisión crea el PC y democratiza el
código.
Y ese código abierto es lo que levanta
a los monstruos de la nube actual, como
Amazon Web Services o Salesforce.
Exacto.
Pero claro, todo esto nos lanza de bruces
a la actualidad.
Si en la segunda era agrupamos procesos en
objetos, Hoy, según Butch, usamos inteligencia artificial para
agrupar sistemas masivos.
Y aquí viene la bomba.
Que la tercera edad de oro no empezó
el año pasado con ChatGPT, empezó a principios
de los 2000.
Tiene sentido.
Con Internet y la nube, la cantidad de
bibliotecas, código de terceros, microservicios, ha crecido tanto
que es biológicamente imposible memorizarlo todo.
Imposible.
Las herramientas como Cursor o Copilot no son
magia alienígena.
Son el salvavidas natural que hemos tenido que
inventar para no ahogarnos en tanta complejidad.
Pero claro, aquí hay tortas.
Porque Butch lo ve como una herramienta más,
pero figuras como Dario Amodei, el mismísimo CEO
de Anthrotropic, dicen otra cosa muy distinta.
Ay, Dario Amodei.
Dice que la ingeniería de software humana estará
automatizada casi por completo en apenas 12 meses.
12 meses.
Y Butch es demoledor con eso.
Lo califica literalmente como una reverenda estupidez.
Other bullshit en inglés.
Un término muy técnico, como dice él.
A ver, déjame hacer de abogado del diablo.
Es fácil decirle estúpido a Modei, pero yo
abro Cloud, le pido en español que me
programe una base de datos de usuarios en
Python y me lo escupe en 10 segundos.
Y funciona.
Claro que funciona.
Entonces, ¿por qué se equivoca?
¿Si la máquina saca código que funciona perfecto?
Porque estás confundiendo picar código repetitivo con hacer
ingeniería de verdad.
Butch no niega que la IA escriba código
genial.
De hecho, automatiza a la perfección las operaciones
CRUD de nivel bajo.
O sea, crear, leer, actualizar y borrar datos.
Sí, lo aburrido.
La IA ha visto esos patrones millones de
veces y te los clava.
Pero la ingeniería, volviendo a Margaret Hamilton, requiere
cosas que un modelo estadístico no tiene.
A ver, ponme un ejemplo.
La IA no toma decisiones éticas sobre la
privacidad.
No entiende tu modelo de negocio para saber
qué tiene que ser escalable.
Y no sabe de seguridad frente a hackers.
Solo rejurgita promedios estadísticos.
Entiendo.
La fuente de hecho cuenta que Butch usó
la IA para hacer visualizaciones en JavaScript con
una librería muy compleja, de tres.
Se lo pidió en inglés y listo.
Dice que el inglés es el nuevo código.
Eso es.
Pero le ve una trampa mortal a esto.
Imagínate un directivo sin idea de tecnología.
Lea a Amodei, despide a sus seniors y
se pone a pedirle a la aplicación a
la IA hablando en español o en inglés.
Un desastre garantizado.
Claro, porque el lenguaje humano es poético, es
ambiguo, es súper impreciso comparado con la matemática
pura del código.
La IA le va a devolver una aplicación
que parece que funciona, pero por dentro será
un castillo de naipes lleno de vulnerabilidades.
Los clavado.
Si no sabes pedir pedir exactamente la lógica
que necesitas, la IAs inventa las cosas.
Entonces, ¿por qué los feos como Amodei dicen
estas barbaridades apocalípticas?
A ver, dímelo tú.
Butch lo tiene clarísimo.
Es puro teatro para los inversores.
Tienen unas valoraciones económicas tan infladas que necesitan
prometer que van a sustituir a los trabajadores
más caros del mundo, los programadores.
Para pillar más capital.
Todo por el hype, claro.
Vale, apocalipsis de los 12 meses desmontado.
Pero la audiencia que nos escucha, profesionales o
estudiantes, pensarán, a ver, si la máquina pica
el código aburrido, ¿qué hago yo con mi
vida ahora?
Pues hay dos caminos.
Primero, la explosión de perfiles híbridos.
Butch habla de su vecina contable.
Ah, sí.
Que no sabe programar, pero usa la IA
para hacerse pequeñas aplicaciones de un solo uso
que le automatizan el Excel.
Software desechable, lo llama.
Democratización pura.
Pero, ¿y el ingeniero de verdad?
¿Cuál es su valor diferencial ahora?
Tiene que subir un nivel de abstracción.
Butch da un consejo que te deja un
poco a cuadros, la verdad.
Dice que dejemos de memorizar el último framework
de JavaScript y nos pongamos a estudiar teoría
de sistemas, complejidad y, atención, biología.
No me lo trago.
O sea, ¿me estás diciendo que el creador
de UML nos recomienda sobrevivir a la IA
leyendo sobre el cerebro de una lombriz de
tierra.
Suena broma, pero es súper profundo.
Piensa que la ingeniería de verdad choca con
el mundo físico.
Robótica, redes eléctricas, roverse en Marte...
Vale.
La IA actual es un bicho estadístico en
un servidor.
Pero la naturaleza lleva millones de años resolviendo
flujos de información complejos con poquísima energía.
Y de ahí la anécdota del gusano y
la cucaracha de las fuentes.
Exacto.
Conocemos el mapa neuronal de un gusano nematodo.
Tiene 302 neuronas.
Y si miras una cucaracha reaccionando al peligro,
no tiene un gran cerebro central en la
nube.
Todo está distribuido, ¿no?
Sí, sus reflejos locales actúan antes de que
la señal llegue a la cabeza.
Esto es la famosa teoría de Minsky de
la sociedad de la mente.
Que la inteligencia son muchos agentes pequeñitos cooperando.
Y hacia ahí vamos.
No usaremos una IA gigante para todo.
Tendremos arquitecturas multiagente.
Un agente revisa la seguridad, otro la memoria.
Entender cómo fluye la información ahí sin que
explote todo es biología pura.
Es teoría de sistemas.
La IA no hace eso sola.
Visto así, no es un funeral.
Es una liberación monumental.
Nos quitan el trabajo aburrido y nos dejan
la imaginación pura.
Es que la tecnología verdaderamente exitosa se vuelve
invisible.
Acuérdate del famoso Efecto 2000, el I2K.
Madre mía la que se montó.
poco inquietante.
Si la IA hace el código base y
nosotros nos dedicamos a diseñar la arquitectura desde
las nubes, llegará un día en que perdamos
la memoria muscular de cómo funcionan los engranajes.
Buf, es un riesgo enorme.
O sea, si la sala de máquinas es
invisible y se rompe algo crítico, ¿qué pasará
si ya nadie recuerda cómo coger la llave
inglesa de los ceros y unos?
Es el peligro de la abstracción excesiva.
Alejarnos tanto de los cimientos hará que perdamos
la capacidad de auditar a la propia máquina.
Por eso, entender los fundamentos y tener pensamiento
crítico va a ser la habilidad más cara
del futuro.
Pues ahí dejamos el aviso a navegantes, a
no dejarse llevar por el alarmismo y a
mirar a los gusanos del jardín con más
respeto.
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.
Y hasta aquí el episodio de hoy.
Muchas gracias por tu atención.
Esto es BIMPRAXIS.
Nos escuchamos en el próximo episodio.