Todo el mundo lleva días hablando del MCP. Creo que ni merece la pena decir qué cosa es.

MCP es un mecanismo para empoderar agentes. Para los primeros que creé utilié CrewAI pero he migrado a LangChain porque:

• A CrewAI le encantan las dependencias tochas: para cualquier trivialidad crea entornos de varios GB.
• CrewAI está diseñado para un tipo de agentes muy concreto —agentes a los que se delega enteramente el control del flujo del proceso— que no son exactamente los que más me interesan ahora –que suelen incluir un elemento de control por mi parte—.

Aunque todo el mundo habla de LangChain y CrewAI, hay algunas innovaciones interesantes, entre las cuales:

Arranco con un experimento mental: A lleva un chaleco antibalas. B le dispara, la bala atraviesa el chaleco y lo hiere de gravedad en el pecho. Varios sujetos distintos examinan lo sucedido:

• La policía determina que B (y el disparo que realiza) es la causa de lo sucedido.
• Los médicos que reciben a A en el hospital encuentran que la bala incrustada en su pecho es la causa de su estado.
• El técnico de la empresa que fabrica los chalecos antibalas especula que el inusual calibre de la bala y el ángulo de impacto son la causa de que atravesase el chaleco.
• Incluso, uno puede especular que gente que conoce a B (p.e., su siquiatra, su familia o sus amigos íntimos) aventuren otras causas para lo sucedido.

En el mundo, realmente, ha sucedido lo que ha sucedido y nada más: hay, a lo más, razones. La razón de que A se debata entre la vida y la muerte es que tiene una bala en el pecho. Pero determinados sujetos identifican causas que los apelan en tanto que son lo que son y que los mueven a la acción: unos a detener e interrogar a B, otros a intubar a B, etc.

Uber ha desarrollado H3, una retícula global de hexágonos para georeferenciar puntos y objetos. Cada hexágono tiene asociado un único ID y el sistema está concebido para poder correr de manera eficiente los algoritmos habituales: vecinos próximos, ruta más corta, etc.

OpenTimes es un sistema para mostrar el tiempo de viaje (en distintos medios) entre ubicaciones de EEUU. Tiene precalculados los miles de millones de valores de la correspondiente matriz y lo particular de la cosa es que almacena y sirve los datos desde R2, un sistema de Cloudfare similar al archiconocido S3 de Amazon pero orientado a la distribución eficiente de información para aplicaciones web.

Muchos fenómenos tienen una periodicidad intrínsecamente semanal (p.e., el tráfico). Eso puede motivar el uso la semana como unidad temporal de referencia en determinados análisis en lugar del mes o el día.

Existe gente que tal vez no esté al tanto de que existe un estándar ISO para definir y representar las semanas sin ambigüedad, el ISO 8601. Sus principales características son

• Las isosemanas comienzan el lunes y terminan el domingo.
• La primera isosemana del año es la que contiene el primer jueves del año.
• Un año contiene típicamente 52 isosemanas, aunque algunos (entre ellos, 1903, 1908, 1914, 1920, 1925, 1931, 1936, 1942, 1948, 1953, 1959, 1964, 1970, 1976, 1981, 1987, 1992, 1998, 2004, 2009, 2015, 2020, 2026, 2032, 2037, 2043, 2048, 2054, 2060, 2065, 2071, 2076, 2082, 2088, 2093, 2099) contienen 53.
• Las isosemanas se representan con el formato YYYY-Www (e.g., 2025-W10 para la décima semana de 2025)

Hoy en día no merece la pena que indique cómo calcular ni manipular isosemanas en los lenguajes de programación más usuales: casi cualquier LLM lo sabe y lo puede ayudar a uno a crear funciones como

I.

Tiene Andrew Gelman una entrada en su blog, Rubinism: separating the causal model from the Bayesian data analysis, que es, según se mire, relevante o trivial. Esencialmente distingue entre el RCM (modelo causal de Rubin) y el análisis bayesiano (de datos):

• El RCM (o modelo de los efectos potenciales en inferencia causal) lo resume como un modelo en el que se entiende que los datos proceden de una muestra en la que, en el mejor de los casos, se ha visto el efecto de un tratamiento dado en cada sujeto.
• El análisis bayesiano como un marco más amplio que puede servir para analizar el RCM (aunque hay alternativas) o para otras cuestiones.

A todo esto, el RCM se llama también modelo de Neyman-Rubin. Neyman (el de los intervalos de confianza) introdujo una versión limitada del modelo en su tesis de maestría de 1923 y muchos años después, en los 70, Donald Rubin lo extendió y generalizó en una serie de artículos como este.

Tiene Ripley, el gran Ripley, un artículo de hace 20 años titulado Selecting Amongst Large Classes of Models donde discute la cuestión —la del título de esta entrada— y dice:

Deberíamos preguntarnos por qué queremos seleccionar un modelo. Parece ser un error extendido que la selección de modelos trata de “seleccionar el mejor modelo”. Si buscamos un modelo explicativo, deberíamos tener presente que puede haber varios modelos explicativos (aproximadamente) igual de buenos: lo aprendí de David Cox cuando era un profesor novato en el Imperial College tras haber hecho muchas selecciones informales de modelos en problemas aplicados en los que me hubiera resultado útil haber podido presentar soluciones alternativas.

Creo que vamos a oír hablar bastante en los próximos meses sobre el uso de algoritmos en la administración. Civio abrió fuego hace casi un año con el caso de BOSCO y vuelve a la carga con Las prisiones españolas usan un algoritmo sin actualizar desde 1993 para decidir sobre permisos de salida, un artículo que permite muchas lecturas y algunas de ellas, desafortunadas.

La noticia anterior da pie, sin duda, a

Un lenguaje de programación es un lenguaje que media entre el que nos es familiar a los humanos y el que reconocen las computadoras. Los lenguajes de alto nivel nos resultan más cómodos; los de bajo nivel, más crípticos. Todos conocemos, pienso, el trade-off.

Ahora todo el mundo programa en Python. Pero los hay que lo hacen de una manera rara:

Hay un nuevo tipo de programaciónn que llamo [Andrej Karpathy] “programación de vibraciones”, en la que te entregas por completo a las vibraciones, adoptas exponenciales y te olvidas de que el código existe. Es posible porque los LLM (por ejemplo, Cursor Composer con Sonnet) se están volviendo demasiado buenos. Además, solo hablo con Composer con SuperWhisper, por lo que apenas toco el teclado. Pido las cosas más tontas como “reducir el relleno en la barra lateral a la mitad” porque soy demasiado vago para buscarlo. “Acepto todo” siempre, ya no leo los diffs. Cuando recibo mensajes de error, simplemente los copio y pego sin comentarios; generalmente, eso lo soluciona. El código crece más allá de mi comprensión habitual, tendría que leerlo realmente durante un tiempo. A veces, los LLM no pueden corregir un error, así que simplemente busco alternativas o pido cambios aleatorios hasta que desaparece. No está tan mal para proyectos de fin de semana intrascendentes, pero sigue siendo bastante divertido. Estoy desarrollando un proyecto o una aplicación web, pero en realidad no es programación: solo veo cosas, digo cosas, ejecuto cosas y copio y pego cosas, y en general funciona.

Las dos noticias del siglo de la semana en el mundo de los LLMs:

• Un análisis en profundidad (aunque presumiblemente prematuro) sobre el nuevo Grok 3.
• Sobre el Deep Research de Perplexity.

Aquí, The Economist argumenta que los LLMs no nos igualarán sino lo contrario, que contribuirá a separar aún más el desempeño socioeconómico de los individuos en función de su capacidades cognitivas (separate the best from the rest, en su formulación original).

Escribí en 2016:

Corría el año 2009 cuando comencé mi segunda aventura bloguera (nadie, yo incluido, quiere rememorar la primera) cuando Raúl Vaquerizo tuvo la caridad de aceptarme como colaborador en Análisis y Decisión.

En diciembre de aquel año escribí cómo utilizar R en una cosa que entonces comenzaba a sonar: la nube y, en concreto, el servicio EC2 de Amazon.

El resultado, probablemente totalmente desfasado, fue este.

Material de hemeroteca, alimento de melancolías.