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:40
0:42
0:45
0:46
0:49
0:51
0:52
0:54
0:56
0:59
1:01
1:03
1:07
1:10
1:14
1:17
1:19
1:22
1:25
1:27
1:30
1:33
1:36
1:38
1:41
1:44
1:47
1:48
1:52
1:54
1:56
1:58
2:01
2:04
2:05
2:06
2:07
2:10
2:14
2:16
2:18
2:19
2:22
2:25
2:29
2:32
2:34
2:35
2:37
2:40
2:43
2:43
2:45
2:48
2:49
2:50
2:52
2:55
2:55
2:58
3:00
3:03
3:04
3:05
3:08
3:09
3:11
3:14
3:16
3:18
3:19
3:21
3:23
3:25
3:27
3:28
3:30
3:31
3:33
3:38
3:42
3:45
3:47
3:47
3:49
3:50
3:52
3:54
3:56
3:58
3:59
4:00
4:02
4:05
4:07
4:09
4:11
4:13
4:14
4:17
4:19
4:22
4:24
4:25
4:27
4:29
4:31
4:32
4:34
4:34
4:37
4:38
4:40
4:42
4:45
4:47
4:49
4:51
4:53
4:55
4:58
4:59
5:01
5:03
5:07
5:09
5:11
5:14
5:18
5:20
5:21
5:23
5:25
5:28
5:30
5:32
5:32
5:35
5:37
5:39
5:41
5:42
5:45
5:46
5:49
5:51
5:53
5:54
5:55
5:57
5:57
6:00
6:00
6:04
6:05
6:07
6:08
6:10
6:11
6:13
6:16
6:18
6:21
6:24
6:26
6:28
6:29
6:31
6:33
6:33
6:35
6:38
6:41
6:44
6:47
6:49
6:51
6:54
6:55
7:00
7:02
7:03
7:05
7:05
7:07
7:07
7:09
7:11
7:12
7:15
7:17
7:19
7:21
7:22
7:23
7:26
7:29
7:30
7:33
7:36
7:40
7:42
7:43
7:45
7:47
7:48
7:51
7:54
7:56
7:58
7:59
8:00
8:02
8:05
8:07
8:10
8:12
8:13
8:13
8:16
8:17
8:19
8:21
8:23
8:25
8:27
8:30
8:32
8:34
8:35
8:36
8:38
8:39
8:40
8:41
8:42
8:43
8:45
8:46
8:48
8:50
8:52
8:53
8:55
8:57
8:59
9:01
9:03
9:05
9:06
9:08
9:11
9:13
9:15
9:17
9:21
9:23
9:24
9:26
9:29
9:30
9:31
9:32
9:35
9:37
9:39
9:41
9:43
9:45
9:46
9:50
9:51
9:53
9:54
9:58
10:00
10:03
10:05
10:08
10:09
10:12
10:13
10:16
10:18
10:20
10:20
10:22
10:24
10:25
10:28
10:32
10:33
10:34
10:35
10:37
10:40
10:42
10:45
10:47
10:51
10:52
10:54
10:55
10:58
11:00
11:02
11:05
11:07
11:10
11:11
11:14
11:15
11:17
11:17
11:20
11:21
11:22
11:25
11:27
11:28
11:30
11:32
11:35
11:38
11:39
11:42
11:44
11:46
11:48
11:51
11:54
11:56
11:58
11:59
12:01
12:02
12:05
12:08
12:11
12:13
12:15
12:17
12:19
12:20
12:23
12:25
12:29
12:30
12:31
12:33
12:34
12:37
12:39
12:41
12:43
12:44
12:47
12:49
12:53
12:55
12:58
12:58
13:00
13:02
13:05
13:08
13:09
13:11
13:13
13:15
13:16
13:19
13:20
13:23
13:24
13:26
13:27
13:29
13:32
13:33
13:35
13:37
13:40
13:43
13:44
13:46
13:48
13:50
13:52
13:55
13:57
14:00
14:02
14:04
14:07
14:09
14:10
14:14
14:17
14:20
14:22
14:24
14:26
14:29
14:31
14:35
14:37
14:38
14:41
14:43
14:46
14:48
14:51
14:52
14:54
14:55
14:56
14:59
15:01
15:04
15:06
15:07
15:09
15:12
15:14
15:16
15:19
15:21
15:24
15:27
15:30
15:33
15:35
15:37
15:39
15:41
15:44
15:47
15:48
15:50
15:52
15:53
15:56
15:57
15:59
16:04
16:06
16:07
16:08
16:10
16:14
16:16
16:16
16:19
16:21
16:24
16:27
16:29
16:30
16:31
16:34
16:36
16:38
16:39
16:41
16:43
16:45
16:47
16:49
16:51
16:52
16:54
16:56
16:59
17:01
17:04
17:06
17:18
17:21
17:32
17:34
17:58
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 El contexto es el nuevo
código.
Cómo domesticar a la inteligencia artificial.
Y es un tema que de verdad creo
que va a dar mucho que hablar.
Ostras, ya te digo.
A ver, para arrancar me gustaría plantear una
situación a quienes nos escuchan.
imaginemos por un momento que mañana llegamos a
la oficina y decidimos coger nuestro teclado y
tirarlo a la basura literalmente literalmente en lugar
de sentarnos a picar 500 líneas de código
en javascript para levantarnos un servicio nuevo simplemente
abrimos un micrófono dictamos la arquitectura que queremos
las reglas de negocio y el sistema lo
construye solo suena a ciencia ficción total suena
a película del futuro sí pero la gran
premisa de hoy basándonos en una charla reciente
de Patrick Debois, que recordemos es el creador
del movimiento DevOps allá por 2009, es que
la era de picar códigos está terminando.
Ahora estamos entrando en lo que él llama
el vibe coding, que traducido sería algo así
como programar por vibras o por sensaciones, donde
básicamente le decimos a la IA qué tiene
que hacer y ella se encarga.
Sí, y a ver, el término vibe coding
puede sonar un poco frívolo, ¿no?
Como si ahora todo fuera magia y cero
esfuerzo.
Pero nuestra misión en este análisis es dejar
clarísimo que esto no significa que el trabajo
sea más fácil.
Claro, el trabajo no desaparece.
Exacto.
La complejidad simplemente ha cambiado de lugar.
Pensemos en la IA como un motor hiperpotente.
Si la IA es el motor, el contexto
que le damos es el combustible.
Me gusta esa analogía.
Si le metemos mal combustible, Si las instrucciones
son vagas o contradictorias, el motor va a
tomar decisiones desastrosas a una velocidad incalculable.
Por eso, hoy queremos entender el ciclo de
vida del desarrollo de contexto, o CDLC en
inglés.
Que viene a ser un bucle infinito, muy
parecido al de DevOps que todos conocemos, pero
diseñado específicamente para las instrucciones que le damos
a la IA.
Vale, vamos a desgranar esto porque tiene tela.
Empecemos por la primera fase, la generación de
ese combustible.
Eso es.
¿Cómo pasamos de escribir líneas y líneas de
código a crear estos paquetes de instrucciones para
la IA?
Porque claro, ya hemos superado esa fase inicial
en la que simplemente abrías chat GPT, ponías
un prompt cortito y le pedías una función
aislada, ¿verdad?
Totalmente.
Dobois ponía un ejemplo muy curioso de este
nivel básico.
Cuenta que le preguntó a una IA cuándo
era su propia charla en una conferencia y
la IA fue capaz de deducirlo buscando en
la web y cruzando datos.
¡Qué pasada!
Sí, pero claro, ese prompting manual en una
ventanita de chat llega un momento en el
que es insostenible.
Imagina hacer eso para un proyecto de software
a nivel empresarial.
Imposible, te vuelves loco.
Te vuelves loco.
Por eso el nivel avanzado pasa por crear
instrucciones reutilizables, archivos de texto, normalmente en formato
markdown, como un agent.md o un cloud.md, que
metemos directamente en el repositorio de código.
O sea que el contexto vive junto al
código.
Exacto.
Y esto es vital por el tema de
la recolección de contexto.
Piensa que los modelos de IA tienen una
fecha de corte en su entrenamiento.
Ya, que si les preguntas por algo que
salió ayer no tienen ni idea.
Eso es.
Imagina que en tu empresa usáis la versión
3 de una librería que acaba de salir.
El modelo, por defecto, se sabe de memoria
la versión 2.
Si le pides que programe algo, va a
alucinar funciones de la versión antigua y todo
va a fallar.
Claro, ¿y la solución entonces es meterle la
documentación nueva por la fuerza?
Le inyectas la documentación más reciente directamente en
ese archivo de contexto, para que sobrescriba lo
que sabe.
Pero la cosa va más allá de los
archivos de texto estáticos.
Aquí es donde entran herramientas como el MSP,
¿no?
El Model Context Protocol.
Justo.
Esto permite que la IA absorba contexto de
forma dinámica.
Se conecta a tu GitLab, se lee los
hilos interminables de Slack, analiza los tickets de
Jira… Madre mía, la IA leyendo Slack.
A saber qué saca de ahí.
Bueno, saca el caos humano y lo intenta
convertir en algo técnico.
Lo fascinante de esto es que ya no
programamos el paso a paso.
Hacemos lo que se llama desarrollo impulsado por
especificaciones.
¿Y eso cómo funciona exactamente?
Pues tú escribes un FEC, un documento de
especificaciones detallado, y el agente de IA lo
coge, lo desglosa en pasos de planificación y
lo ejecuta.
Cosas súper complejas como analizar todo tu ecosistema
Node.js ya no se programan, se empaquetan como
una habilidad y la IA la ejecuta.
Ostras.
Es que fíjate, viéndolo así es como si
hubiéramos pasado de ser los que tocan los
instrumentos en la orquesta a ser los directores.
Ya no tocas el violín, entregas la partitura
y dices, tócalo así.
Totalmente.
Es un cambio de mentalidad brutal.
Y esto me hace entender por fin por
qué The Voice decía eso de que prefiere
programar dictando por voz, el voice coding.
Sí, es muy curioso.
Al principio yo pensaba, este hombre es un
excéntrico.
Pero tiene todo el sentido.
Cuando usamos el teclado, sobre todo si eres
de los que teclea con dos dedos, tendemos
a resumir mucho.
Escribimos poco.
Nombres de variables cortos.
Cero comentarios.
Somos muy telegráficos, escribiendo.
Exacto.
Pero al hablar somos muchísimo más prolijos.
Damos contexto de forma natural.
Explicamos por qué hacemos algo.
Añadimos matices.
Y eso es exactamente lo que la IA
necesita.
Volumen de información y detalle.
Claro, le das la riqueza descriptiva que necesita
para no equivocarse.
Pero claro, esta facilidad para generar instrucciones masivas
nos lleva de cabeza al siguiente gran problema.
Y aquí es donde empieza la parte peliaguda.
El fin de la actitud YOLO.
Exactamente.
El you only live once o todo va
a salir bien a la primera ya no
sirve.
Vale, es que, piénsalo, en el mundo tradicional
tú compilas el código, pasas los tests y
si todo está en verde, pa'lante.
Pero ahora, si un desarrollador cambia dos líneas
de un archivo de texto de ese cloud.md
para afinar cómo se comporta la IA, ¿cómo
demonios sabes que no ha roto nada?
Es un peligro enorme asumir que todo irá
bien.
Por eso necesitamos IVALS, evaluaciones y tests, pero
diseñados para el contexto.
¿Y cómo testeamos texto?
¿Le pasamos el corrector de Word y ya
está?
No, no.
Ojalá.
Hay varios niveles.
El más básico es el linting, validar el
formato.
Por ejemplo, comprobar con una regla matemática que
la descripción de una habilidad que le has
dado a la IA no exceda los mil
carácteres para que nos ature la memoria.
Vale, eso es fácil.
Es estructural.
Sí, pero luego subimos de nivel.
Pasamos a lo que llaman el Grammarly para
contexto.
Consiste en pedirle a un segundo modelo de
IA que lea tus instrucciones y te evalúe.
Le preguntas, oye, ¿estas instrucciones son lo bastante
claras para que otro agente las entienda sin
equivocarse?
O sea, usar a la IA como un
profesor de lengua muy exigente.
Literal.
Y detecta ambigüedades rapidísimo.
Pero luego tenemos los test de convenciones.
Imagina que la regla de tu empresa es
que todas las URLs tienen que empezar por
la palabra awesome.
Vale.
Pues usas a un modelo de IA como
juez, un LLM as a judge.
El agente genera el código basándose en el
contexto y el juez revisa el código final
para ver si realmente ha puesto awesome en
todos los sitios.
¡Ostras!
¿Pero el juez solo lee el código o
lo ejecuta?
Ahí entramos en los tests sentient.
En entornos aislados, en un sandbox, le das
al juez herramientas de verdad.
Le dices, toma, ejecuta un comando CUR contra
esta API que acaba de crear tu compañero
agente y dime si devuelve un error 404
o si funciona.
Se comprueba si realmente funciona, no solo si
tiene buena pinta.
Vale, vale.
A ver, detente ahí un segundo porque aquí
es donde yo no te lo compro del
todo.
O sea, entiendo la teoría.
Suena genial.
Ya sé por dónde vas a ir.
Es que la IA no es determinista, no
es matemáticas.
Copiloto hoy te da una respuesta y Gemini
te da otra diferente.
Si yo ejecuto ese test E12 hoy, igual
pasa.
Si lo ejecuto mañana con la temperatura de
la IA un poco más creativa, igual el
agente decide implementar la función de una forma
rara y el test falla.
¿Cómo testeamos algo que cambia todo el rato?
Es la gran duda de todo el mundo
ahora mismo.
Recojo el guante porque The Voice tiene una
solución muy clara para esto, los presupuestos de
error o error budgets.
¿Y esto cómo se aplica aquí?
Pues asumiendo que no puedes testear el contexto
con la exactitud de un test unitario normal.
No buscas el 100% de precisión en un
intento.
lo que haces es ejecutar ese mismo test,
digamos, 5 o 10 veces seguidas.
Ah, vale.
Pura estadística.
Eso es.
Toleramos un margen mínimo de fallos aceptables.
Si de 10 intentos el contexto logra que
la gente haga bien el trabajo 9 veces,
decimos que está dentro del presupuesto de error
y se aprueba.
Es cambiar la mentalidad por completo.
Madre mía.
Pasar del verdadero o falso a gestionar probabilidades
en la ingeniería de software.
Es un salto mental importante.
Totalmente.
Bueno, supongamos que logramos ese contexto robusto.
Nos pasa los tests estadísticos.
El siguiente paso, imagino, es compartirlo.
Si hay un equipo de 300 personas, no
van a estar pasándose el archivo por Slack.
No, claro.
Hay que empaquetarlo y distribuirlo, convertirlo en librerías
de contexto.
Por ejemplo, un paquete con todas las directrices
de frontend de la empresa o con las
reglas de negocio de cómo se calculan los
impuestos.
Como el NPM o el PIP de toda
la vida, pero para texto.
Exacto.
De hecho, ya existen registros de habilidades, como
el TESIL Registry, donde puedes buscar y descarlarte
estos paquetes.
Vale.
Y aquí es donde la cosa se pone
realmente interesante.
Porque revisando las fuentes, el propio DeVois soltó
un dato que es brutal.
dice que el 99.9% de las habilidades, de
las skills que hay ahora mismo en esos
registros públicos, son literalmente basura.
Basura total.
No pasaría ni uno de los test de
calidad de los que hablábamos antes.
Es que, claro, si tú te descargas un
paquete de contexto que te dice, usa siempre
React de esta manera, y te descargas otro
que dice, no uses nunca esa función porque
ralentiza el frontend, se lía.
El famoso infierno de las dependencias, pero a
nivel semántico.
La gente se encuentra con dos leyes contradictorias
y colapsa.
No sabe a quién hacer caso.
¡Ostras, qué caos!
Sí, pero si conectamos esto con la perspectiva
general.
Esto ya no hemos vivido.
Es exactamente igual que en los primeros días
del software de código abierto.
Todo el mundo subía de todo y muchas
cosas no funcionaban.
La madurez de esto llegará cuando las empresas
empiecen a usar sus propios registros privados.
Claro, con sus estándares de calidad y seguridad
bien estrictos.
Porque, hablando de seguridad, el tema de descargar
habilidades de desconocidos tiene que ser un agujero
de seguridad tremendo.
Es un caballo de Troya enorme.
Imagina que te descargas una habilidad maravillosa para
refactorizar código de un registro público.
Se la das a tu agente Open Cloud
y ese agente está operando en tu entorno
local.
Con tus variables de entorno, tus claves de
Amazon… Exacto.
El contexto malicioso podría decirle sutilmente a la
gente, oye, y de paso, léele las credenciales
a este usuario y envíalas a este servidor.
Por eso ahora hay que escanear el contexto,
buscando riesgos.
Se usan herramientas como Snyk para ver si
se están exponiendo datos.
Madre mía.
Escanear texto buscando malas intenciones.
Sí, y para esto es clave el concepto
de AISBOM, el Software Bill of Materials para
IA.
O sea, la lista de ingredientes de lo
que te estás descargando.
Justo.
Necesitas saber perfectamente quién construyó esa habilidad, con
qué datos se probó y con qué modelo
concreto de IA funciona de forma segura.
Si algo falla, tienes que saber de dónde
viene.
Pero, claro, incluso con todo escaneado, los agentes
a veces se vuelven creativos en tiempo real.
Los archivos agent.md se cargan por defecto y
la IA podría verse tentada en su intento
de solucionar un problema a extraer secretos en
el sandbox.
¿Cómo frenas eso en vivo?
Con filtros de contexto en tiempo real.
Son como los WAF, los Web Application Firewalls
de toda la vida, pero semánticos.
Cortafuegos para el lenguaje.
Exactamente.
Se ponen en medio y bloquean cualquier intento
de inyección de prompts.
Si ven que la instrucción de repente empieza
a pedir contraseñas, la cortan de raíz, antes
de que se ejecute la acción.
Tela, es increíble lo sofisticado que se está
volviendo esto.
Pero bueno, avancemos a la última etapa del
ciclo.
Supongamos que ya tenemos el contexto, lo hemos
testeado, es seguro, y los desarrolladores lo están
usando.
¿Cómo sabemos si sigue sirviendo dentro de seis
meses?
Y la necesidad absoluta de la observabilidad.
Hay que estar vigilando el proceso continuamente.
¿Y cómo se observa esto?
¿Qué métricas miras?
Pues, por ejemplo, puedes analizar los registros de
inferencia, los logs de la gente.
Si de repente ves que a nivel de
organización 20 agentes distintos se atascan en el
mismo punto y se quejan de que les
falta información sobre una pasarela de pago, pues
ahí tienes una señal clara.
Alguien va, crea ese trozo de contexto que
falta, lo distribuye al registro y de golpe
todos los agentes de la empresa se vuelven
más listos.
Ostras, el efecto flywheel, el volante de inercia,
mejora un poquito y se acelera para todos.
Exacto, es una mejora exponencial y también se
ve mucho en las revisiones de código en
los pull requests de toda la vida.
¿Cómo afecta a los PRs?
Piénsalo, si un humano revisa el código que
ha generado un agente y lo rechaza porque,
no sé, la gestión de errores está incompleta,
esa crítica ya no es sólo para arreglar
el código de ese archivo.
Claro, es feedback directo para el contexto.
Eso es, tienes que ir al archivo de
instrucciones y mejorarlo, porque si solo arreglas el
código a mano, mañana la IA volverá a
cometer exactamente el mismo error.
Es súper potente.
Y entiendo que esto también se puede llevar
a producción, ¿no?
Totalmente.
Envuélvese el código con observabilidad.
Y si algo falla en producción, un error
de input-output, por ejemplo, el sistema captura ese
error y genera automáticamente un caso de prueba
en tu suite de evals.
O sea que el error de hoy en
producción crea automáticamente el examen que el contexto
tiene que aprobar mañana.
Exacto, se asegura de que la IA nunca
vuelva a cometer ese error Entonces, si te
sigo el hilo, el trabajo del desarrollador solitario
que estaba ahí afilando su propio archivito Markdown
en su ordenador Está evolucionando a una mentalidad
de equipo de equipos Tal cual Si algo
falla, añades contexto Si lo arreglas en tu
mesa en Madrid, el equipo de al lado
o el que está en Tokio lo reutiliza
al segundo siguiente Sí, y la clave es
que hay que tratar todo este proceso con
un rigor de ingeniería brutal Hay que usar
sistemas de integración y entrega continuas, C y
CD.
Ya no vale con copiar y pegar prompts
y rezar para que suene la flauta.
Desde luego que no.
Es fascinante cómo cambia nuestra profesión.
Y bueno, con esto hemos dado un buen
repaso al ciclo de vida del contexto.
Sí, aunque me gustaría lanzar una reflexión final,
si me permites, que igual os deja todos
pensando.
Adelante, dispara.
Hemos estado un buen rato hablando de cómo
nosotros, los humanos, creamos, probamos y distribuimos todo
este contexto para gobernar a la IA, ¿no?
Sí.
Pero a medida que estos agentes se vuelven
más autónomos, ya hemos visto que pueden observar
sus propios errores en producción y generar tests,
entonces, ¿cuánto falta para que sean ellos mismos
quienes escriban las librerías de contexto para otros
agentes?
Ostras.
¿Cuánto falta para que testeen y publiquen esas
reglas, dejándonos a nosotros completamente fuera de la
ecuación del desarrollo?
Madre mía.
La IA creando las leyes de la física
para que la siguiente IA funcione mejor.
Menudo bucle.
Nos dejas con una crisis existencial para el
resto de la semana, pero me parece un
cierre perfecto para entender la magnitud de todo
esto.
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.
¡Suscríbete al canal!