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:44
0:47
0:48
0:49
0:51
0:54
0:57
0:59
1:00
1:02
1:05
1:08
1:11
1:13
1:15
1:17
1:19
1:21
1:22
1:23
1:26
1:29
1:31
1:33
1:35
1:37
1:41
1:44
1:45
1:48
1:49
1:50
1:51
1:54
1:55
1:58
2:02
2:05
2:06
2:08
2:09
2:10
2:13
2:15
2:19
2:20
2:21
2:24
2:27
2:29
2:31
2:33
2:34
2:36
2:37
2:38
2:41
2:44
2:46
2:49
2:51
2:53
2:57
2:59
3:01
3:03
3:05
3:07
3:09
3:12
3:13
3:14
3:15
3:17
3:20
3:21
3:23
3:26
3:28
3:30
3:31
3:32
3:35
3:37
3:39
3:40
3:41
3:42
3:44
3:46
3:48
3:51
3:54
3:54
3:56
3:58
3:58
3:59
4:03
4:06
4:11
4:13
4:15
4:18
4:19
4:22
4:26
4:28
4:29
4:30
4:34
4:36
4:38
4:41
4:44
4:46
4:47
4:48
4:49
4:53
4:56
5:00
5:03
5:05
5:07
5:09
5:11
5:12
5:16
5:20
5:22
5:23
5:25
5:27
5:29
5:30
5:31
5:32
5:34
5:38
5:39
5:41
5:43
5:46
5:49
5:52
5:56
5:58
5:59
6:02
6:05
6:08
6:09
6:12
6:15
6:18
6:19
6:21
6:24
6:26
6:27
6:29
6:31
6:35
6:37
6:40
6:43
6:44
6:46
6:49
6:51
6:54
6:57
6:58
7:01
7:03
7:05
7:07
7:10
7:11
7:13
7:16
7:19
7:21
7:23
7:26
7:28
7:30
7:34
7:36
7:38
7:41
7:43
7:44
7:46
7:47
7:48
7:50
7:53
7:57
7:59
8:01
8:02
8:05
8:07
8:09
8:11
8:13
8:15
8:17
8:18
8:20
8:22
8:25
8:27
8:30
8:32
8:33
8:35
8:37
8:39
8:41
8:43
8:45
8:47
8:48
8:51
8:54
8:57
8:59
8:59
9:02
9:04
9:07
9:09
9:12
9:16
9:19
9:20
9:23
9:25
9:28
9:31
9:33
9:34
9:36
9:39
9:40
9:43
9:46
9:48
9:52
9:54
9:55
9:57
9:59
10:02
10:04
10:07
10:10
10:12
10:13
10:17
10:19
10:22
10:24
10:25
10:27
10:29
10:32
10:35
10:37
10:40
10:42
10:43
10:45
10:47
10:47
10:50
10:50
10:53
10:56
10:59
11:01
11:02
11:04
11:06
11:08
11:09
11:09
11:10
11:12
11:13
11:14
11:16
11:19
11:22
11:23
11:25
11:26
11:28
11:31
11:31
11:34
11:36
11:37
11:39
11:40
11:43
11:46
11:49
11:51
11:54
11:59
12:01
12:04
12:04
12:09
12:11
12:15
12:18
12:19
12:20
12:23
12:27
12:29
12:31
12:33
12:36
12:39
12:42
12:44
12:46
12:49
12:51
12:51
12:54
12:57
12:58
13:01
13:03
13:04
13:07
13:08
13:11
13:13
13:14
13:17
13:21
13:22
13:24
13:26
13:27
13:29
13:32
13:34
13:35
13:40
13:42
13:45
13:46
13:48
13:52
13:54
13:57
14:01
14:03
14:06
14:08
14:10
14:11
14:13
14:16
14:17
14:19
14:22
14:24
14:26
14:28
14:30
14:31
14:33
14:36
14:39
14:42
14:45
14:47
14:49
14:52
14:53
14:56
14:58
15:00
15:02
15:03
15:04
15:07
15:09
15:12
15:13
15:17
15:20
15:22
15:25
15:28
15:31
15:32
15:36
15:38
15:39
15:41
15:44
15:47
15:50
15:53
15:54
15:55
15:56
15:58
16:00
16:02
16:04
16:06
16:08
16:11
16:15
16:18
16:20
16:24
16:26
16:27
16:30
16:34
16:37
16:41
16:43
16:45
16:45
16:46
16:49
16:53
16:54
16:56
16:58
17:01
17:03
17:05
17:07
17:10
17:12
17:14
17:15
17:17
17:20
17:23
17:24
17:25
17:27
17:30
17:30
17:33
17:35
17:37
17:39
17:42
17:44
17:47
17:48
17:51
17:51
17:55
17:57
18:00
18:01
18:04
18:07
18:09
18:11
18:13
18:17
18:19
18:21
18:22
18:24
18:26
18:30
18:41
18:44
18:45
18:47
18:48
18:49
18:53
18:56
18:59
19:02
19:06
19:09
19:11
19:12
19:15
19:17
19:19
19:21
19:23
19:26
19:28
19:31
19:34
19:46
19:48
20:00
20:02
20:26
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 cómo lograr que la IA
hable tu mismo idioma, de Grill Me a
Grill with Dogs.
Y la verdad es que el análisis de
hoy tiene miga, porque vamos a ver cómo
un simple documento de texto plano ha logrado
solucionar, bueno, el mayor cuello de botella de
la inteligencia artificial moderna.
Totalmente.
porque para avanzar hacia el futuro de cómo
interactuamos con las máquinas, resulta que tuvimos que
desenterrar un manual de programación de hace más
de 20 años, que se dice pronto.
Ya, es fascinante y fíjate que la exploración
de estas fuentes no es una clase de
código puro y duro, aunque luego hablemos de
bases de datos o repositorios y tal.
Claro, no vamos a aburrir a nadie con
líneas de código infinitas.
Exacto.
El material base que documenta todo el proceso
de este ingeniero de quien vamos a hablar
hoy en el fondo es un tratado sobre
comunicación humana y artificial.
Así es.
Aborda cómo la falta de, digamos, un diccionario
compartido puede arruinar por completo tanto el trabajo
de equipos humanos enteros como nuestras sesiones diarias
con modelos de lenguaje.
O sea, la fricción pura y dura de
no entenderse.
Eso es.
Pues a ver, el origen de toda esta
evolución se reduce a cuatro frases.
Literalmente.
El protagonista de las fuentes cuenta que escribió
una pequeña instrucción, un prompt de apenas un
párrafo, que acabó siendo el texto más influyente
de toda su carrera.
¡Qué locura que algo tan corto tenga tanto
impacto, ¿verdad?
Es una pasada.
Lo empaquetó bajo el nombre de la habilidad
Grill Me, que traducido vendría a ser algo
así como Interrógame o, no sé, Ponme contra
las cuerdas.
Me gusta mucho ese enfoque.
Y la genialidad de esta aproximación, lo que
lo hace diferente, es que invierte por completo
la carga cognitiva.
O sea, normalmente, quien se sienta frente a
un modelo de lenguaje asume toda la presión,
¿no?
Claro, la presión de tener que formular la
pregunta perfecta.
Exacto.
Estructurar el contexto sin fisuras, prever todos los
ángulos ciegos, es agotador.
Pero con Grill Me le ordenas a la
máquina que sea ella quien te entreviste implacablemente
hasta alcanzar un entendimiento mutuo.
Y el mecanismo interno de esa instrucción es
lo verdaderamente interesante de analizar, porque le exige
el modelo de lenguaje que recorra cada rama
del árbol de diseño de tu idea, ¿sabes?
Que vaya paso a paso.
Eso es, y que vaya resolviendo las dependencias
lógicas una por una.
La IA detecta de inmediato las amigüedades de
tu planteamiento inicial y empieza a lanzar preguntas
estructuradas.
Te obliga a mojarte.
Totalmente.
Obliga a externalizar todas esas suposiciones que la
persona tiene en la cabeza, pero que, bueno,
no ha verbalizado.
Y ojo porque las fuentes mencionan casos de
uso de Grill.me que van muchísimo más allá
de la ingeniería de software.
Hay un ejemplo asombroso de verdad que me
dejó de piedra.
A ver, cuenta.
Alguien utilizó esta dinámica de interrogatorio para que
la IA le hiciera preguntas y así poder
escribir el panegírico para el funeral de su
madre.
¡Ostras!
¡Qué fuerte!
Durísimo, sí.
Pues la inteligencia artificial le fue haciendo preguntas
tan específicas y tan bien hiladas que logró
sacar a la luz historias familiares, anécdotas y
emociones que esa persona tenía bloqueadas por el
duelo.
Madre mía.
Demuestra una capacidad casi empática de la herramienta,
¿no?
Completamente.
Demuestra cómo puede organizar el pensamiento humano cuando
se le da la directriz de investigar en
lugar de simplemente escupir una respuesta genérica.
Sin embargo, y aquí viene el giro, el
éxito desmesurado de Grill Me llevó a su
propio creador a un callejón sin salida en
su trabajo principal.
Claro, el desarrollo de arquitecturas de código complejas.
Justo eso, porque la inteligencia artificial generalista es
brillante, sí, pero adolece de un punto ciego
masivo.
¿Cuál?
Desconoce por completo la jerga específica, es decir,
el dominio concreto del proyecto en el que
trabaja cada persona de forma individual.
Vale, vamos a desgranar esto, porque es vital
entender de dónde nace la fricción.
O sea, la fuente usa una analogía que
me parece buenísima.
La del becario, ¿no?
Esa misma.
Es muy fácil imaginar la enorme pérdida de
tiempo que supone trabajar con un becario que
tiene una capacidad de procesamiento infinita, pero que
sufre de amnesia severa cada mañana al cruzar
la puerta de la oficina.
Ya, ya, es que debe ser frustrante a
más no poder.
Pues el autor ilustra este problema con su
propio día a día.
Él está desarrollando una plataforma educativa y utiliza
constantemente un concepto que denomina Standalone Video, o
sea, un vídeo independiente.
Vale.
En su modelo mental está clarísimo que ese
término se refiere a un vídeo que no
está conectado a un curso ni pertenece a
ninguna lección específica.
específica.
Para él es obvio.
Claro, pero el modelo de lenguaje carece por
completo del contexto para inferir ese significado.
Cero contexto.
Para la IA, Standalone Video es simplemente una
cadena de texto ambigua.
Entonces, al arrancar una nueva sesión con la
instrucción de Grill Me, la máquina topaba con
ese término y al intentar procesar su significado
sin referencias, pues reaccionaba produciendo respuestas excesivamente largas.
Empezaba a divagar.
Literalmente.
Intentaba cubrir todos los posibles significados genéricos de
la palabra vidia y de la palabra independiente.
Generaba una verborrea innecesaria que obligaba a detener
el proceso productivo.
Para tener que reexplicarle todo constantemente.
Eso es, reexplicar la ontología básica del proyecto
desde cero, sesión tras sesión.
Llegaba a un punto en el que, antes
de poder escribir una sola línea de código
útil, tenía que impartir una clase magistral de
media hora sobre el vocabulario de su propia
aplicación.
Una pérdida de tiempo brutal.
Y a veces conseguían afinar un lenguaje compartido
fantástico durante esa ventana de chat.
Pero claro, al cerrar la pestaña, todo ese
progreso semántico se desvanecía en el éter.
La amnesia volvía a atacar al día siguiente.
Exacto.
Pero bueno, el problema de la falta de
retención del vocabulario del dominio no es exclusivo
de la inteligencia artificial.
La ingeniería de software tradicional lleva lidiando con
esta misma colisión semántica durante décadas.
O sea que no es un problema nuevo.
Que va, especialmente a medida que los proyectos
escalan y los equipos se dividen.
La solución que rescató este flujo de trabajo
no proviene de un nuevo avance en redes
neuronales, sino de un libro publicado en el
año 2003.
Ah, el famoso libro azul.
El mismísimo, el libro azul de Eric Evans.
El texto fundacional del Domain Driven Design, o
diseño guiado por el dominio, que en la
industria se conoce como DDD.
Vale, ¿y qué propone este libro exactamente para
solucionar el lío?
Pues el pilar central de esta filosofía es
lo que Evans bautizó como el lenguaje ubicuo.
Su tesis postula que el principal motivo por
el que los proyectos de software fracasan no
es la falta de destreza técnica, sino la
torre de Babel que se forma entre los
diferentes departamentos.
O sea, un problema de comunicación puro y
duro.
Tal cual.
Por ejemplo, el equipo de marketing habla de
campañas, el desarrollador del servidor crea una tabla
en la base de datos llamada eventos-promocionales, y
el diseñador de la interfaz lo llama banners.
Madre mía, el caos.
Y cuando hay un error en una campaña,
el programador pierde horas intentando descifrar a qué
parte de su código se refieren, claro.
Exactamente.
Pues el lenguaje ubicuo busca erradicar esa fricción
de raíz.
Requiere crear un documento o un glosario innegociable
que debe ser utilizado de forma estricta por
tres grupos.
¿Cuáles son?
La base de código, los desarrolladores que la
escriben y los expertos del dominio o negocio,
que son los que saben qué se está
construyendo, aunque no sepan cómo.
O sea, alinear a todo el mundo.
Eso es.
Si esos tres pilares se alinean en torno
a un único término, término.
Cualquier error es inmediatamente rastreable.
El nombre de la variable en el ordenador
es exactamente el mismo que el término que
usa el experto en ventas.
Vale, pues aquí es donde se pone realmente
interesante.
Porque el protagonista de las fuentes, al darse
cuenta del paralelismo, intentó aplicar este concepto de
lenguaje ubicuo a sus sesiones de IA.
Pero al principio lo hizo a lo bruto,
¿no?
Sí, sí, a la fuerza bruta total.
Cuenta que, en mitad de un interrogatorio con
la máquina, cuando notaba que los conceptos empezaban
a difuminarse, interrumpía el flujo.
Le pedía a la IA que generase ahí
mismo un archivo llamado ubicuslanguage.mmd.
Para registrar las definiciones acordadas en ese momento.
Exacto.
Funcionaba, pero era súper tosco.
Claro, era una solución parcheada.
Obligaba a documentar el consenso manualmente, lo cual
es un avance, pero carecía de integración real.
Rompía todo el ritmo de trabajo.
Totalmente.
Rompía el estado de flujo del desarrollador al
exigirle constantes cambios de contexto mental para gestionar
la documentación.
Faltaba una automatización que permitiera a la IA
ingerirse conocimiento desde el milisegundo cero.
Sin tener que andar con recordatorios.
Y de esa frustración nace la fusión definitiva.
Nace la nueva herramienta Grill with Dogs.
El salto evolutivo.
Justo.
Es exactamente el mismo texto de la instrucción
Gilmi, mantiene esa capacidad inquisitiva, pero se le
añade una orden ineludible.
Antes de hacer la primera pregunta, la IA
debe buscar, leer y asimilar un archivo específico
llamado context.md.
Un archivo clave.
Ese context.md actúa como la materialización de lo
que el diseño guiado por el dominio denomina
un bounded context o contexto delimitado.
A ver, explícanos un poco más esto del
contexto delimitado.
Pues que alimenta directamente el mecanismo de atención
del modelo de lenguaje.
En lugar de calcular probabilidades estadísticas sobre qué
podría significar una palabra basándose en todo el
Internet, la IA ancla su red semántica a
las definiciones estrictas de ese documento.
O sea, que limita sus alucinaciones.
Exactamente.
Sus parámetros de actuación acaban de ser acotados
por las reglas de negocio de quien está
frente a la pantalla.
¿Y las mecánicas prácticas de esta fusión son
reveladoras?
La máquina recibe instrucciones para afilar el lenguaje
difuso, debatir escenarios concretos, cruzar referencias con el
código existente y actualizar el glosario en tiempo
real, sin que tengas que mover un dedo
para mantener el documento.
Eso es.
Y el material detalla un ejemplo real que
es perfecto para ilustrar esto.
El estilo Mr.
Beast.
Ah, sí.
El ejemplo del empaquetado de los vídeos.
Es buenísimo.
Sí, sí.
El escenario es que quiere añadir una nueva
entidad al ecosistema de la aplicación.
Hasta ese momento, la plataforma manejaba cursos, lecciones
y vídeos.
Y decide introducir el concepto de pitch.
El pitch, claro.
En el argot de los creadores de contenido,
un pitch engloba el empaquetado inicial de un
vídeo.
El título provisional, la idea de la miniatura,
la premisa general antes de siquiera encender la
cámara.
¿Y quiere integrar esa estructura en su base
de datos?
Y claro, una inteligencia artificial normal, al recibir
esta petición, simplemente habría escupido bloques de código
genérico a lo loco para generar tablas llamadas
pitch, asumiendo que es una función aislada.
Pero Grill with Docs no hace eso.
Analiza la petición contra el archivo context.md y
frena la operación en seco.
le lanza una advertencia de colisión terminológica.
¡Qué maravilla!
La IA detecta una incompatibilidad lógica fundamental.
Le dice algo así como, oye, en tu
glosario actual, un video independiente se define estrictamente
como un video cuyo identificador de elecciones nulo.
¡Exacto!
Y le plantea el dilema.
Si introducimos los pitches, ¿un video independiente sigue
manteniendo esa categoría si tiene un pitch asociado?
¿O la introducción de este concepto nos obliga
a redefinir la frontera de lo que significa
ser independiente en todo el sistema.
A mí me parece fascinante cómo detenerse a
aclarar la semántica de una simple palabra desencadena
una revisión de la interfaz visual y de
la arquitectura de la base de datos completa.
La IA asume el rol de un arquitecto
de sistemas implacable y todo por defender la
integridad del diccionario.
Literal.
Y a partir de ahí la máquina empieza
a lanzarle detalles técnicos que tiene que decidir
sí o sí.
Le pregunta por la cardinalidad de los datos.
Oye, ¿un mismo pitch puede tener múltiples vídeos
de pruebas asociados?
Y le confirma que sí, estableciendo una relación
de uno a muchos.
Y luego profundiza aún más, exigiendo que se
definan las semánticas de estado de esa nueva
entidad.
Le pregunta en qué estados lógicos puede existir
un pitch, inactivo, programado, enviado… O sea, obliga
a definir el ciclo de vida del dato
antes de programar una sola línea.
Y llega hasta la gestión de qué pasa
si se borra.
La IA le pregunta qué debe hacer el
sistema si alguien decide borrar un pitch que
ya tiene vídeos vinculados.
Y él estipula que la base de datos
debe rechazar la acción eligiendo la restricción onDeleteRestrict.
Claro, porque la filosofía de la plataforma prefiere
archivar a borrar cosas, ¿no?
Eso es.
Y lo realmente pragmático de todo esto es
que estas decisiones críticas no se pierden en
un historial de chat infinito.
La IA sintetiza todo este debate y actualiza
el archivo contexto.md automáticamente con las nuevas reglas.
Es una maravilla.
Ahora bien, estandarizar el vocabulario mediante ese contexto
delimitado está muy bien.
Resuelve el problema de la identidad de las
entidades.
Pero claro, en un proyecto hay decisiones que
van más allá del vocabulario.
Totalmente.
¿Qué pasa con las decisiones lógicas y estructurales
que justifican la forma del código?
Cuando el equipo descarta una tecnología en favor
de otra, el glosario no te sirve para
explicar el por qué a un compañero nuevo.
Claro, se queda cojo.
Exacto.
Por eso, el flujo de trabajo incorpora una
última pieza del rompecabezas, una última capa de
blindaje, los famosos ADRs.
Los Architectural Decision Records.
Registros de decisiones arquitectónicas.
Son archivos Markdown muy escuetos que viven ahí,
en el repositorio, junto al código.
Y su único propósito es documentar las decisiones
no obvias.
Entonces, ¿qué significa todo esto?
Porque, a ver, yo me pongo en la
piel de quienes nos escuchan, que a lo
mejor lideran un equipo, y surge una duda
crítica.
Dispara.
¿De verdad tenemos que documentar cada pequeña cosa?
O sea, ¿vamos a hacer un registro notarial
porque hoy elegimos poner el botón rojo en
vez del azul?
Eso suena a una burocracia paralizante brutal.
Ya, es una reticencia muy lógica, pero las
fuentes son súper categóricas en esto para evitar
precisamente esa parálisis que comentas.
Los ADRs solo, y repito, solo, se usan
cuando una decisión cumple unos requisitos muy estrictos.
¿Cuáles?
Es decir, cuando hay un trade-off, un compromiso
donde se sacrifica una cosa por otra.
Vale, entiendo.
Si se trata de elegir entre dos librerías
que son completamente intercambiables y que tardas media
ahora en sustituir, no se documenta absolutamente nada.
O sea, solo se registra lo que, digamos,
sorprendería a otro desarrollador si no tuviera el
contexto histórico.
Exactamente eso.
Si al leer el código alguien va a
pensar, pero bueno, ¿por qué diseñaron esto de
una manera tan raba?
Ahí es donde necesitas el ADR que explique
que, oye, en aquel momento era la única
forma de esquivar un problema.
Claro, tiene todo el sentido.
Ahora bien, toda esta ceremonia inicial, lo de
pulir el lenguaje, crear los archivos, redactar los
registros, tiene que tener una recompensa enorme que
justifique semejante esfuerzo, ¿no?
Los beneficios tangibles son apabullantes, de verdad, y
alteran por completo cómo los modelos de lenguaje
consumen recursos.
Sí, las fuentes destacan que uno de los
beneficios mágicos es que la IA da respuestas
muchísimo más concisas, usa muchos menos tokens.
Claro, al tener un lenguaje compartido precargado, la
IA ya no necesita generar párrafos y párrafos
para confirmar que ha entendido lo que le
pides.
Va directa al grano.
Y al tener ese lenguaje compartido, la máquina
también usa menos tokens para, entre comillas, pensar
internamente.
Optimiza sus procesos porque no pierde tiempo intentando
desentrañar ambigüedades.
Se alinea mágicamente con las intenciones de la
persona que escribe, a veces antes de que
siquiera termine de formular la petición.
Y el resultado es que el código final
es muchísimo más fácil de navegar, porque las
carpetas y las variables se llaman exactamente igual
que los conceptos que tú tienes en la
cabeza.
Es una sincronización perfecta.
Por eso, tras todas estas iteraciones, las fuentes
establecen una regla de oro definitiva que es
súper fácil de recordar.
A ver.
Si tienes un repositorio de código, una code
base en la que trabajar, usa Grill with
Docs.
Está especialmente recomendado al inicio de un proyecto
para cimentar bien el lenguaje.
¿Y si no tienes repositorio?
Si no tienes un repositorio de código, porque
a lo mejor estás explorando ideas generales, definiendo
un modelo de negocio o, como decíamos al
principio, escribiendo un panejírico.
Que vaya tela con el ejemplo.
Pues en esos casos de uso generales, usa
Grillme.
La instrucción original sigue siendo imbatible para eso.
Me parece un resumen súper práctico.
Y además hay un detalle extra de mucho
valor en las fuentes.
Y es que este ingeniero Matt actualiza estas
habilidades constantemente en su newsletter.
Se llama AI Skills for Real Engineers.
Boletín muy recomendable.
Sí, y prometen que es un boletín sin
nada de spam, pensado puramente para mantenerse al
día con los registros de cambios de estas
herramientas que ya sabemos que avanzan a la
velocidad de la luz.
Totalmente imprescindible hoy en día.
Bueno, pues analizar toda la evolución de estas
técnicas deja una evidencia incontestable, ¿no crees?
Desde luego.
Y fíjate, antes de leer la despedida formal,
creo que esto nos deja una reflexión final
muy provocadora para que la gente le dé
una vuelta en casa.
Adelante.
Si crear un simple documento context.md solo para
alinear las definiciones exactas logra una sinergia tan
sumamente perfecta entre un humano y una máquina,
¿No crees que deberíamos empezar a escribir pequeños
archivos con text.md en nuestros trabajos?
Ya sabes, para arreglar los malentendidos diarios que
tenemos entre nosotros, los humanos.
¡Ostras!
Pues sería la solución a muchísimos problemas de
oficina, estoy convencida.
Ojalá lo apliquemos más.
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.
Gracias.