E081_Minimax-M2.7 vs Claude Opus 4.6

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 el modelo de IA que

se entrena a sí mismo, desmontando el M2

.7 de Minimax.

¡Hola a todos!

Para arrancar, vamos a poner un caso hipotético

sobre la mesa.

Si alguien contrata a un equipo de arquitectos

para construir un rascacielos gigante, pues lo normal

es que empiecen a poner cimientos o a

dibujar planos, ¿verdad?

Claro, es lo lógico.

Pues en lugar de eso, lo primero que

hacen estos arquitectos es inventarse un nuevo tipo

de grúa, y luego diseñan unas hormigoneras más

eficientes y crean un software de gestión de

obras desde cero.

Todo esto solo para poder trabajar más rápido

después.

Esa idea es muy importante.

Esa idea, esa vuelta de tuerca a la

forma de trabajar, es exactamente lo que subyace

bajo el capó del sistema que nos ocupa

hoy, el M2 .7.

Y fíjate que es un cambio de paradigma

que merece muchísimo la pena diseccionar.

Porque el objetivo de nuestra inmersión de hoy

es rascar muy por debajo de esa capa

de marketing deslumbrante que, a ver, siempre acompaña

los lanzamientos de inteligencia artificial.

Ya, siempre lo pintan todo como una revolución.

Exacto.

Queremos entender...

Queremos entender qué significa, a nivel estrictamente técnico,

que una IA ayude a construirse a sí

misma.

Y además, hay que poner a prueba su

rendimiento real frente a los competidores más asentados.

Porque los números prometen mucho.

Prometen una barbaridad.

Pero sobre todo, hay que evaluar si las

limitaciones operativas, esa letra pequeña que siempre esconde

problemas, justifican un coste de uso que, sorprendentemente,

resulta ser muy, muy bajo.

O sea, hay que separar la promesa comercial...

...de lo que realmente se encuentra un ingeniero

cuando conecta esto a su servidor.

Pues vamos a entrar directos a esa afirmación

principal que resulta tan rompedora.

Porque el análisis exhaustivo en el que nos

basamos hoy deja clarísimo que este modelo de

Minimax no es simplemente uno más que resulta

ser un poco más rápido generando texto.

No, ni mucho menos.

O que araña un par de puntos extra

en un examen estandarizado.

La gran baza aquí es que ha tenido

un papel activo en su propio proceso de

entrenamiento.

Ha construido y refinado su propia infraestructura.

O sea, es lo que en el análisis

denominan un Research Agent Harness, un arnés de

agente de investigación.

Eso es.

Y el término arnés, el harness, es fundamental

para entender el salto técnico.

Tradicionalmente, pues vemos modelos que generan datos sintéticos

para entrenar a versiones futuras de sí mismos,

¿vale?

Eso ya es bastante común.

Sí, eso lo tenemos más visto.

¿Qué infraestructura técnica necesaria para ejecutar los experimentos

de aprendizaje por refuerzo?

O sea, la base del entrenamiento.

Totalmente.

Ha estado monitorizando las tuberías de datos, detectando

y depurando errores en el código de entrenamiento

y evaluando si los resultados de cada experimento

eran útiles o no.

Llevándolo a un terreno más cotidiano, es como

un programador que entra a trabajar a una

empresa y al ver que su entorno de

desarrollo le resulta lento o ineficiente, se pone

a reprogramar el propio editor sobre la marcha

mientras sigue escribiendo la aplicación principal.

¿Una analogía?

Perfecta.

Y el análisis técnico describe esto como un

bucle completamente autónomo.

O sea, la IA detecta un fallo, propone

un cambio en su propio andamiaje de pruebas,

ejecuta las evaluaciones pertinentes y, ojo, decide por

su cuenta si mantiene esa modificación o se

vuelve a la versión anterior.

Y este ciclo ha estado corriendo durante más

de 100 rondas.

Más de 100.

Sí, sí, 100 rondas sin que ningún humano

interviniera.

Es que suena a ciencia ficción.

A ver, genera un escepticismo enorme.

Cuesta creer que esto sea un salto técnico

real y no, bueno, pues una narrativa muy

bien empaquetada para vender titulares sobre IA general.

A ver, esa reserva mental está más que

justificada, sobre todo viendo la tendencia que tiene

esta industria a exagerar cualquier automatización, en plan,

ya tenemos inteligencia general.

Ya te digo.

Sin embargo, el valor técnico real de este

hito no reside en que la máquina haya

cobrado conciencia o ni nada parecido.

Reside en la dirección que marca.

Hasta ahora, el cuello de botella en la

evolución de estos modelos ha sido puramente humano.

Claro, el tiempo que tarda la gente.

Exacto.

Se necesitan ejércitos enteros de ingenieros ajustando hiperparámetros,

revisando por qué Naricio es una métrica ha

bajado, corrigiendo el rumbo manualmente.

Al conseguir que un modelo asuma esa carga

de crear y mantener su propia infraestructura de

evaluación, pues se inicia una transición clarísima.

La IA pasa de ser solo el producto

final a ser también la herramienta de desarrollo.

Exacto.

Eso es.

Y validar ese ciclo continuo de más de

100 rondas demuestra que este concepto de autoevolución

ya no es pura teoría en una pizarra.

Es una base operativa o funcional que reduce

drásticamente la fricción humana.

Vale, pero si aceptamos que este modelo es

capaz de montarse su propio taller de trabajo

y optimizar sus herramientas, la duda ofende.

¿Cómo de bueno es el producto final cuando

lo sacas de ese taller y lo pones

a programar de verdad?

Ahí es donde entramos en terreno pantanoso.

Totalmente.

Hay que entrar en la arquitectura técnica y

en esa especie de garra fría de las

pruebas de rendimiento, los famosos benchmarks.

El análisis subraya que el M2 .7 está

diseñado con una obsesión clarísima por los flojos

agénticos.

Que no es lo mismo que un chatbot

normal, claro.

Exacto.

No estamos hablando de un asistente al que

le haces un par de preguntas rápidas, sino

de tareas largas, donde un agente tiene que

planificar una estrategia, utilizar diversas herramientas externas y,

lo más importante, mantener un contexto coherente durante

mucho tiempo.

Y para sostener eso hace falta mucha memoria

a corto plazo, digamos.

Eso es.

Le han dotado de una ventana de contexto

enorme de 243 .800 tokens.

Y en velocidad, la versión estándar escupe 60

tokens por segundo, mientras que la versión high

speed llega a los 100 tokens por segundo.

Bueno, a ver, esas cifras de velocidad y

capacidad de retención, hoy en día son los

cimientos mínimos necesarios para que un flujo agéntico

largo no colapse por pura lentitud.

Ya, es el desde.

Exacto, es lo mínimo que se despacha.

Pero la verdadera prueba de fuego está en

las métricas de programación pura y dura.

Los datos del análisis arrojan un 56 ,2

% de éxito en CWP Bench Pro, un

55 ,6 % en Byte Pro y un

52 ,7 % en MultiCW Bench.

Y aquí es importantísimo hacer una pausa, creo

yo, porque para alguien que esté fuera del

día a día del desarrollo de software, un

56 % de éxito en un test.

Parece un suspenso catastrófico.

Cualquiera pensaría que el modelo es inútil porque

falla casi la mitad de las veces.

Es un matiz crucial, me alegra que lo

saques.

Porque pruebas como SWI Bench Pro no son

exámenes tipo test de universidad.

No es marcar la casilla correcta.

Qué va, qué va.

Consisten en volcar problemas reales, issues sacados directamente

de repositorios de código abierto de GitHub, que

son inmensos y súper complejos.

Un cristo de código, vamos.

Literalmente.

El modelo tiene que navegar por miles de

archivos, entender dónde narices está el problema, proponer

la solución, escribir el código modificado y encima

asegurar que nada más se rompa al hacerlo.

Que una máquina logre resolver el 56 con

2 % de esos problemas de forma totalmente

autónoma es un porcentaje altísimo.

¿Rivaliza con el esfuerzo de un humano?

Rivaliza con el tiempo y esfuerzo que le

tomaría un ingeniero humano señor tirarse días mirando

el código.

Lo cual lo pone cara a cara con

la artillería pesada del mercado.

Igualando o incluso superando en ciertas áreas a

pesos pesados como Cloud 4 .6 Opus, a

Gemini 3 .1 Pro y a los equivalentes

a GPT 5 .4.

Son palabras mayores, sí.

Pero hay otra métrica en el análisis que

resulta fascinante por cómo funciona.

Se trata de ML Benchlight, que es una

evaluación creada por OpenAI.

Compila 22 tareas de Machine Learning inspiradas en

Kaggle.

Y Kaggle no es ninguna broma.

Para nada.

Para dar un poco de perspectiva, Kaggle es

una plataforma donde científicos de natos de todo

el mundo compiten, compiten durante semanas, para crear

modelos predictivos súper complejos.

Pues el M2 .7 no sólo aprueba, sino

que logra un promedio de medallas del 66

con 6 % en estas competiciones.

Que es una barbaridad.

Es una barbaridad, pero lo impactante es cómo

llega a ese número.

Resulta que escala en función del tiempo de

cómputo.

A las 5 horas de procesamiento.

El modelo ronda un 57 % de éxito.

Y si se le deja seguir pensando, esa

cifra continúa subiendo escalonadamente hasta llegar a las

25 horas.

Esto que comentas ilustra un cambio de paradigma

potentísimo en el sector.

Hemos pasado de valorar a los modelos por

su inmediatez, es decir, quién te responde más

rápido en una ventanita de chat, a valorar

el cómputo en tiempo de inferencia.

Permitir que la máquina piense.

Exacto.

Permitir que la máquina piense durante un día

entero si hace falta.

En problemas de ciencia de datos complejos, la

primera respuesta rara vez es la óptima.

El hecho de que el rendimiento del modelo

siga escalando tras 25 horas demuestra una capacidad

de iteración brutal.

Prueba una hipótesis matemática, ve que el modelo

predictivo no alcanza la precisión deseada, ajusta los

pesos de las variables y vuelta a empezar.

Todo esto suena espectacular, verdaderamente.

Pero hay un detalle en las especificaciones del

análisis.

Una especie de letra pequeña que cambia completamente.

La letra pequeña, sí.

Esos 204 .800 tokens de la ventana de

contexto tienen trampa.

Resulta que la fuente subraya que no representan

sólo la cantidad de información que se le

puede dar al modelo como instrucción de entrada,

sino que es un límite combinado.

Suma la entrada más la salida.

¿No significa esto que puede quedarse a medias

y cortar tareas largas?

Ese es el gran cuello de botella estructural,

sin duda.

Es un riesgo altísimo.

Para visualizar el problema, es como si a

un trabajador le dieras un presupuesto estricto de

200 .000 caracteres para usar en una libreta

compartida para todo el proyecto.

Vale.

Si la tarea exige leer un manual técnico

larguísimo que consume, pongamos, 150 .000 caracteres, a

ese trabajador sólo le quedan 50 .000 para

redactar su informe, razonar sus pasos en la

libreta y usar herramientas.

Y 50 .000 tokens vuelan.

Vuelan.

Si el modelo supera ese límite combinado en

medio de un flujo, en medio de un

flujo agéntico largo, sencillamente colapsa.

La tarea se corta de forma totalmente abrupta.

Y claro, esto obliga a los desarrolladores a

llevar una contabilidad de tokens casi milimétrica, lo

cual añade una fricción enorme a la hora

de programar.

Y a esto hay que sumarle una capa

de precaución adicional.

El análisis destaca que las métricas de Minimax,

aunque son impresionantes, se basan en protocolos de

evaluación internos.

Ellos mismos han configurado el entorno de pruebas

y las herramientas que estaban habilitadas para que

el modelo se examine.

A ver, cuando el arquitecto que diseña el

examen y el alumno que lo hace son

el mismo, siempre existe un riesgo inelente de

sobreoptimización.

Que se saben las respuestas, vamos.

No implica necesariamente que los datos sean falsos,

no.

Pero en la industria del machine learning, un

protocolo interno rara vez es 100 % reproducible

por agentes externos, sin que haya variaciones en

los resultados.

Por eso, explican que estos porcentajes estratosféricos deben

tomarse como indicadores orientativos.

¿Orientativos?

Claro.

Sí.

Te indican una capacidad indudable, pero no como

verdades absolutas o una tabla de clasificación inamovible.

Dejando a un lado el entorno supercontrolado del

laboratorio y de los test, la verdadera pregunta

es ¿qué pasa cuando pones esta maquinaria a

funcionar en un entorno real?

El análisis detalla que en ingeniería de software,

el M2 .7 va muchísimo más allá de

un simple autocompletado de código.

Ya no sólo que te termine la frase

de programación.

¿Qué va?

Brilla en diagnósticos de producción, es capaz de

correlacionar múltiples métricas de rendimiento, analizar cronologías de

despliegue, timelines completos y buscar el origen exacto

de una regresión en el código.

Que eso es dificilísimo.

Tela.

Y también destaca en tareas de productividad de

oficina avanzada, lo que el análisis llama GDPAA.

Logra editar documentos de Word, hojas de Excel

y presentaciones de PowerPoint en múltiples rondas de

trabajo.

Sí.

Efectivamente, el tema ofimático lo maneja de maravilla.

Totalmente.

Maneja más de 40 habilidades complejas con un

97 % de adherencia a las instrucciones, obteniendo

una puntuación de 46 ,3 en la métrica

TULSLON.

La versatilidad entre lo que es el código

puro y duro en la ofimática es muy

destacable.

Pero el núcleo de este éxito práctico, el

secreto, reside en una técnica concreta, el tool

use con pensamiento intercalado, el tool use with

interleaved thinking.

Pensamiento intercalado.

Exacto.

Los modelos clásicos tienden a ser monolíticos, es

decir, reciben un prompt inicial y te escupen

una parrafada enorme de una sola vez.

Si se equivocan en el primer paso de

esa parrafada, todo el resto de la respuesta

es basura, es inútil.

El M2 .7, en cambio, rompe ese proceso.

Y ese concepto de pensamiento intercalado cobra todo

el sentido cuando se analiza el escenario estrella

que plantea la fuente de hoy, los agent

teams, los equipos de colaboración multiagente.

El caso de uso que describen, sinceramente, es

para quedarse con la boca abierta.

El del servidor, ¿verdad?

Ese.

Pongamos que hay un incidente crítico en producción

en una empresa tecnológica, una caída de servidores

a las 3 de la madrugada.

Según el análisis, un agente autónomo detecta el

fallo y empieza a correlacionar las métricas de

rendimiento con la cronología reciente de cambios.

Identifica el bloque de código problemático mediante análisis

estadístico.

Y luego, sin consultar al ADIA, accede a

la aplicación.

Encontra la base de datos para verificar su

hipótesis y, finalmente, propone una mitigación directa del

error.

Todo este proceso sin despertar a un solo

humano.

A ver, la idea de que un equipo

de agentes detecte una caída a las 3

de la mañana, busque el error en el

código y lo arregle solo es fascinante, pero

requiere un nivel de confianza ciego en la

máquina que, sinceramente, da terror.

Sí, sí.

Entregar ese nivel de control en producción a

un modelo produce vértigo.

Pero ahí es justo donde el pensamiento intercalado

actúa como… digamos, una red de seguridad técnica.

¿Cómo funciona esa red de seguridad?

Pues, en ese escenario del servidor caído a

las 3 de la mañana, el agente no

intenta adivinar el fallo desde el minuto 1

y cambiarlo todo.

Funciona más como un detective frente a una

pizarra.

Lee la alerta.

Hace una pausa para pensar internamente su próximo

paso.

Vale.

Decide invocar una herramienta externa, como ejecutar una

consulta en el registro de errores.

Lee los resultados de esa consulta.

Y, ojo.

Hace otra pausa para evaluar.

¿Esto confirma mi teoría inicial?

Si la respuesta es no, descarta la idea,

fórmula una hipótesis nueva y busca en otra

tabla de la base de datos.

Va paso a paso.

No se tira a la piscina.

Exacto.

Esta iteración constante, este ciclo de observar, razonar

y actuar paso a paso, es lo que

permite que el modelo navegue por el caos

de un entorno de producción real sin volverse

loco y romper más cosas.

Bueno.

Una vez entendido este enorme potencial.

Y cómo gestiona los flujos agénticos, toca hablar

de la implementación práctica.

Porque promete ser la salvación de la oficina

y el guardián de los servidores de madrugada.

Y, además, promete hacerlo a precio de saldo.

Sí.

La factura es un tema clave aquí.

Analicemos la integración, los precios y, casi lo

más interesante, sus tropiezos más básicos.

A nivel de integración, parece bastante fluido.

Se puede conectar como un proveedor personalizado con

una simple clave de API, una API key.

En editores de código como Cursor .com.

Y también funciona con herramientas de terminal como

Cloud Code.

Todo esto disponible vía Minimax o a través

de Open Router.

La facilidad de conexión es un gancho comercial

fuertísimo.

Obvio.

Pero el verdadero golpe en la mesa, como

decías, es su estructura de costes.

Es agresivísima.

Muy, muy agresiva.

Su modalidad de pago por uso está fijada

en 0 ,30 dólares por cada millón de

tokens de entrada.

Y apenas 0 ,20 dólares por el millón

de servidores.

Si comparamos esto con las tarifas habituales de

los modelos de frontera actuales, es que es

una fracción minúscula del coste operativo.

Es bajísimo.

Es que te sale casi gratis, vaya.

Ya te digo.

Además, plantean suscripciones súper accesibles, que empiezan en

los 10 dólares mensuales para la versión Starter

y suben hasta los 50 dólares en el

plan Max.

La versión High Speed está desde 40 dólares

al mes.

Todo esto democratiza muchísimo el acceso a arquitecturas

agénticas súper complejas.

Y justo cuando parece que estamos ante la

máquina perfecta e imbatible, capaz de arreglar una

infraestructura de red súper compleja, mientras cuesta lo

mismo que tomarse un café, llega el baño

de realidad, el tropiezo del que habla la

fuente.

¡Ay!

¡El tropiezo!

Es buenísimo.

Es que, a ver si lo entiendo, tenemos

un modelo capaz de arreglar una caída de

servidores coordinando un equipo de IAs autónomas, pero

tropieza estrepitosamente al intentar resolver un cifrado César.

Pues mira, este fallo tan absurdo con el

cifrado César es la radiografía perfecta de la

naturaleza de la inteligencia artificial hoy en día.

¿Por qué lo dices?

Porque tendemos a antropomorfizar estas herramientas.

Asumimos instintivamente que si un modelo es un

genio brillante en flujos de trabajo complejos de

programación, pues automáticamente debe ser un genio en

lógica básica o en puzles sencillos, porque así

funciona el intelecto humano.

Si sabes hacer una integral, sabes sumar.

Claro, esa es la lógica que aplicamos.

Pero en las redes neuronales hay una simetría

muy profunda.

Estos sistemas son, al final del día, devoradores

de patrones estadísticos.

El modelo domina los lenguajes de programación porque

ha ingerido millones y millones de repositorios y

entiende perfectamente la estructura estadística de las llamadas

a una API.

Vale, tiene el patrón memorizado.

Las algorítmicas secuenciales, como ir desplazando caracteres uno

a uno, sufren muchísimo porque lo sacas totalmente

de su zona de confort predictiva.

No es estadística.

Es lógica.

¿Por qué?

Es pura.

Es un golpe de realidad muy necesario, desde

luego.

No estamos ante una inteligencia general uniforme que

sirva para todo.

Y creo que este tropiezo encadena perfectamente con

las cuatro limitaciones técnicas clave que detalla el

informe.

Letra pequeña, que todo el mundo debería conocer

antes de lanzar campanas al vuelo.

Fundamental conocerlas, sí.

La primera es un bloqueador directo para muchísimas

corporaciones.

Es un modelo propietario.

No ofrece los pesos abiertos.

Y esto para la privacidad.

La segunda limitación es un bloqueador directo para

las autoridades y las auditorías.

Es letal.

Si una empresa maneja datos médicos o información

financiera confidencial, o necesita someter sus sistemas a

auditorías de seguridad súper estrictas, enviar información sensible

a una API cerrada sencillamente no es una

opción viable.

El cumplimiento normativo no te lo permite.

La segunda limitación ya la hemos diseccionado un

poco.

Ese peligroso límite de tokens combinado de entrada

y salida, que te funciona como una guillotina

silenciosa.

Y te corta el proceso a la mitad

si no tienes cuidado.

Sí.

Te exige estar con la calculadora de tokens

en la mano.

Pero la tercera limitación es, probablemente, la que

más dolores de cabeza genera a los ingenieros

de software a nivel práctico.

La extrema complejidad operativa.

Resulta que, para que el modelo mantenga ese

nivel de brillantez usando el pensamiento intercalado, requiere

que el sistema que lo aloja preserve los

campos de razonamiento de manera impecable.

Las reflexiones internas y las llamadas a herramientas

son muy importantes.

Exacto.

Tienen que preservarse con una fidelidad absoluta en

el código.

O sea, si durante un proceso largo de

varios pasos, el código del desarrollador recorta o

formatea mal accidentalmente una de esas reflexiones internas

que hizo el modelo hace cinco minutos, todo

se desmorona.

Literalmente.

El modelo sufre una especie de amnesia instantánea.

Al perder el hilo conductor exacto de por

qué tomó una rescisión específica tres pasos atrás,

la degradación de su rendimiento se desmorona.

El rendimiento es brutal.

Empieza a alucinar, o a inventarse cosas, o

directamente a repetir acciones en bucle porque no

sabe por qué está ahí.

Y esto exige que la arquitectura de software

de la empresa sea absolutamente impecable.

Y eso es difícil.

Y la cuarta limitación termina de apretar las

tuercas técnicas.

Porque hablamos de topes estrictos impuestos por la

propia plataforma.

Tienen un límite de 500 peticiones por minuto

y un máximo de 20 millones de tokens

por minuto.

Pero el dato que me parece verdadero a

mí es que, en el caso de las

empresas, el más crítico es el comportamiento del

prompt catching.

Uff, ese dato es demoledor.

Ese sistema de memoria a corto plazo, que

guarda las instrucciones iniciales para ahorrar tiempo y

dinero en tareas largas, resulta que caduca en

tan sólo cinco minutos.

¿Cinco minutos?

Exige una disciplina de implementación brutal.

Es que las implicaciones operativas de esa caducidad

tan agresiva son enormes para un flujo agéntico.

El prompt catching es como un camarero que

recuerda el larguísimo pedido de una mesa sin

tener que volver a anotarlo entero.

Buena analogía.

Pues imagínate que el agente autónomo decide consultar

una base de datos externa muy pesada.

Y esa consulta tarda seis minutos en devolver

los resultados.

Pues en ese tiempo, la memoria caché de

Minimax ya se ha borrado por completo.

Madre mía.

O sea, el modelo olvida instantáneamente todo.

Todo el documento técnico de 200 .000 tokens

que le habías proporcionado al principio se esfuma.

Para continuar trabajando, el usuario tiene que volver

a enviar y procesarlo.

El usuario tiene que pasar toda esa cantidad

de información desde cero.

Y esto multiplica el coste económico y destroza

el tiempo de latencia.

En tareas asíncronas complejas, cinco minutos es un

margen de maniobra inasumiblemente corto.

Resumiendo un poco todas estas piezas de la

inmersión de hoy, el panorama que nos pinta

el análisis es un contraste constante entre innovación

deslumbrante y fricción técnica.

Promete una reducción drástica en la intervención humana

y además presenta unos precios súper disruptivos.

Pero, a cambio, exige lidiar con límites de

memoria estrictos, caídas de rendimiento por un mal

formato y un ecosistema totalmente propietario.

La conclusión más sólida a la que se

puede llegar, tal y como dice la fuente,

es que el M2 .7 representa una apuesta

económicamente demoledora por asentar este paradigma de los

flujos agénticos.

Es barato y muy capaz.

Sí, los números están ahí.

Sin embargo, su éxito y consolidación final en

el mercado no es un problema.

No van a depender de que consiga un

puntito porcentual más en un benchmark de programación.

Dependerá enteramente de si los desarrolladores están dispuestos

a rediseñar sus propias infraestructuras para acomodar esta

estricta complejidad operativa y la fragilidad del modelo.

Al final, las tablas de clasificación sirven para

acaparar titulares, pero el mejor benchmark siempre es

el caso de uso real de cada uno

en el barro del día a día.

Totalmente de acuerdo.

Y para cerrar esta inmersión.

Hay una idea latente en todo este análisis

que creo que merece una reflexión profunda.

Si asumimos como cierto que la próxima generación

de inteligencias artificiales ya está invirtiendo su inmenso

tiempo de cómputo en crear, refinar y automatizar

sus propios entornos de entrenamiento para la siguiente

generación, el escenario futuro cambia drásticamente.

Ya lo creo que cambia.

Cabe preguntarse si llegará un punto, a no

muy largo plazo, en el que el verdadero

cuello de botella para el avance tecnológico no

sea la falta de microprocesadores o la capacidad

matemática de la máquina, sino la pura velocidad

a la que los cerebros humanos podamos procesar,

comprender y auditar lo que estas infraestructuras están

construyendo a puerta cerrada.

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 BIM Praxis.

Nos escuchamos en el próximo episodio.