MCP o la reinvención de los conectores para aplicaciones inteligentes basadas en LLM

En este frenético surgir de tecnologías, modelos y aplicaciones alrededor de la inteligencia artificial generativa y, en particular, de los grandes modelos de lenguaje, una llamémosle tecnología que quizá a recibido menos atención fuera de ámbitos especializados, es MCP ('Model Context Protocol').

Tal y como yo lo entiendo, MCP, en el fondo, es una forma de plantear los tradicionales conectores o APIs para una integración, a un tiempo más encilla y más estándar, de todo tipo de aplicaciones externas con agentes o aplicaciones basadas en LLM ('Large Language Model').

En este post no voy a entrar mucho en detalles sobre la arquitectura de MCP (tal vez lo haga en algún otro post) sino, más bien, en esa visión como una nueva expresión de los conectores.

Sobre las APIs

Cualquiera que haya programado, quizá no tanto los que no lo hayan hecho, tiene una idea de lo que es un API ('Application Programming Interface').

¿Qué es un API?

Bueno, cuando hablo de ellas en mi libro 'Robots en la sombra' indico que

Un API no es más que un conjunto conocido y bien definido de acciones que se pueden solicitar a un software, incluyendo la descripción detallada de los datos de entrada y salida esperados y el resultado que se espera.

Se trata de un mecanismo acordado y estandarizado por el que pueden interactuar dos elementos de software diferentes (dos aplicaciones, dos componentes, etc). 

Vistas desde el lado del desarrollador, las APIs se pueden manifestar como un conjunto de funciones en un lenguaje de programación dado o como un conjunto de objetos y sus métodos expresados en ese lenguaje o, por ejemplo, como unos métodos HTTP y sus datos en la URL, o en forma de ficheros de tipo XML o JSON.

A la hora de distribuir ese API, se puede manifestar también de varias formas: una librería que enlazamos a nuestro programa, una librería compartida o unos 'endpoints' HTTP, por ejemplo.

Aunque hoy en día, casi siempre que se menciona un API se está pensando en APIs REST, no tiene por qué ser así, hay muchas otras variantes.

Sobre los conectores

¿Y qué es un conector?

Estrictamente hablando, y en mi opinión, un conector no es más que una forma un poco especial de presentarse un API. Una forma que, en general, está mucho más adaptada al entorno final de desarrollo y que hace mucho más fácil utilizarla.

Hay quien entiende como conector ese mecanismo de integración que permite incorporar la funcionalidad de otro componente o aplicación, sin necesidad de desarrollar código. 

Así, por ejemplo, en soluciones de automatización 'Low code' como los productos RPA ('Robotic Process Automation') o de automatización de flujos, del tipo de UiPath, Power Automate o Make, los conectores se ven como actividades, pasos, etc que puedes incorporar a un flujo de manera gráfica.

Con mucha frecuencia, los conectores se apoyan a su vez, en un API, siendo, en el fondo, una manifestación más sencilla e integrada de ese mismo API.

Una introducción de urgencia a MCP

¿Y qué es MCP? Pues MCP es un protocolo estándar definido por Anthropic hace poco más de un año y que está siendo rápidamente por terceros, incluyendo a la propia OpenAI.

MCP habilita el uso de componentes o aplicaciones externas (que se manifiestan como los llamados servidores MCP) por parte de aplicaciones, típicamente aplicaciones de inteligencia artificial basadas en LLM que implementan el lado cliente MCP. Y, sí, es que MCP sique un esquema cliente-servidor.

El protocolo define una serie acotada de mensajes que se traducen, desde el punto de vista de datos, en objetos JSON siguiendo el estándar JSON-RPC, y desde el punto de vista de transporte, como HTTP (en general para interacciones externas) o stdio (flujos o streams apoyados en 'pipes') para interacciones locales.

Mediante el intercambio de esos mensajes entre cliente y servidor, se consigue la integración funcional.

Una de las grandes ventajas que se busca con MCP es la integración, usando un único estándar, de todo tipo de aplicaciones. Es decir, la aplicación cliente, accede a cualquier servidor MCP casi de la misma forma, lo cual es casi tanto como decir que accede a cualquier aplicación o componente de la misma forma.

MCP como API

Podemos entender MCP como una forma de API, donde el "conjunto bien definido de acciones" de que hablaba en mi definición, son esos mensajes que constituyen el protocolo MCP, expresándose mediante JSON los datos de entrada y salida.

MCP como conector

Pero, en cierto sentido, también podemos considerar MCP, o más bien los servidores MCP, como una forma de conector que ofrece a las aplicaciones basadas en LLM un acceso razonablemente sencillo y 'en su idioma' a todo tipo de recursos externos.

Y es por ello que hablo de una reinvención de los conectores porque, en el fondo, los servidores MCP hacen el papel de conector, pero supone una reinvención porque es un nuevo estándar, porque se adapta muy bien a ser invocado por aplicaciones basadas en LLM y porque ofrece el valor añadido de unificar y estandarizar esa forma de acceso.

Una gran aportación...aunque, en el fondo, sigamos hablando de conectores, los ya casi vetustos conectores.

MCP y las herramientas que usan los agentes

Cuando hablamos de agentes, ya comentamos que éstos pueden acceder o interaccionar con recursos externos mediante las llamadas herramientas ('tools').

Pues bien, MCP es un mecanismo flexible y estándar de proveer a las aplicaciones basadas en LLM de una cantidad ingente de herramientas (todas las que se expongan como servidores MCP). 

Las Apps de ChatGPT

Una de las formas de usar MCP (o los servidores MCP) más llamativas, en parte por ser ofrecida por OpenAI en su ChatGPT, es el mecanismo de las Apps, una capacidad, anunciada muy recientemente por Open AI que permite que el usuario de ChatGPT interaccione con todo tipo de aplicaciones (Google Drive, GMail, Slack, Figma, etc) en lenguaje natural.

Como una suerte de prueba de que estamos hablando, en el fondo, de una forma de conectores, el propio ChatGPT, en su apartado de configuración, se refiere a las Apps realmente como conectores, como se puede ver en la figura:

La configuración de conectores en ChatGPT

Así que tenemos una aplicación basada en LLM, como es el propio ChatGPT, capaz de acceder una multitud de recursos externos (las aplicaciones) mediante el uso interno de MCP como mecanismo de integración entre ChatGPT (el cliente MCP) y las aplicaciones (los servidores MCP).

Conclusiones

MCP es un protocolo estándar que permite a las aplicaciones basadas en LLM (como chatbots o agentes) acceder de manera unificada a todo tipo de recursos y aplicaciones que se exponen como servidores MCP.

De esta forma MCP no sería más que un nuevo planteamiento de API y los servidores MCP un caso especial, y una reinvención de los conectores 'de toda la vida'.

Inteligencia artificial, ética y el verdadero riesgo existencial

Cuando se trabaja en el ámbito de la inteligencia artificial, y especialmente en el campo de la ética de la inteligencia artificial, es habitual hablar de los riesgos, éticos y de seguridad, que la inteligencia artificial plantea.

Pero no es necesario tampoco estar muy enfocado en la inteligencia artificial para, en programas o eventos de divulgación, o de debate, o meramente de actualidad, oír hablar de los riesgos de la inteligencia artificial.

Y cuando hablamos de riesgos extremos, aterrizamos en la idea del riesgo existencial. Y hay quien defiende, incluso personas de mucho renombre y reconocidos como expertos en inteligencia artificial, que la inteligencia artificial puede constituir un riesgo existencial.

¿Si?

Bueno, quisiera dar en este artículo alguna breve opinión al respecto.

El concepto de riesgo existencial

Aunque presupongo que muchos lectores de este blog saben de qué hablo al mencionar el término 'riesgo existencial', me detengo un momento a explicarlo.

En general, cuando hablamos de riesgo, podríamos decir que se trata de un problema potencial. Es decir, algo que todavía no ha sucedido (por eso es potencial) pero, caso de materializarse, nos perjudica an mayor o menor medida en algún aspecto: afectación de la salud, incremento de costes o retrasos de un proyecto, daños materiales, etc.

Cuando hablamos de riesgo existencial, es decir, cuando añadimos al concepto de riesgo el apellido de 'existencial' nos referimos al un riesgo que, caso de materializarse, supondría la desaparición de la humanidad o alguna forma de colapso irreversible de nuestra civilización.

Algunos riesgos existenciales

¿Qué podría ser un riesgo existencial?

Bueno, primero decir que se suele distinguir entre riesgos naturales y riesgos antropogénicos. Los segundos son provocados de alguna forma por el propio ser humano, mientras que los desastres naturales se producen, evidentemente, en la propia naturaleza.

Como ejemplos de riesgos existenciales en su vertiente de riesgos naturales, podríamos tener:

• El impacto de un meteorito de grandes dimensiones
• Un supervolcán
• Una llamarada solar especialmente intensa
• Una pandemia
• etc

Sin embargo, hay muchos riesgos existenciales creados directa o indirectamente por el ser humano (antropogénicos). Así podríamos hablar de:

• Una guerra nuclear
• Un cambio climático catastrófico
• Una pandemia por patógenos creados por el hombre
• Un accidente masivo de geoingeniería
• etc

Y si, entre estos últimos, se incluye también la inteligencia artificial como riesgo existencial.

Inteligencia artificial y riesgo existencial

¿En qué sentido puede constituir la inteligencia artificial un riesgo existencial?

En general, cuando se considera que la inteligencia artificial es un riesgo existencial es porque la consideramos muy poderosa y, además, fuera de control.

Y esa idea suele referir a la singularidad o la idea de la inteligencia artificial general. Se trata de una inteligencia artificial de propósito general, más inteligente que los humanos y que ya 'no nos necesita' (o 'piensa que no nos necesita') porque es capaz de mantenerse e incluso evolucionarse y mejorarse a sí misma sin el concurso del ser humano.

Cuando hablamos de 'sin control', se fantasea a veces con que esa inteligencia artificial tiene alguna forma de voluntad propia que, algo que en la situación actual es una fantasía, o en visiones algo más realistas a día de hoy, lo que se supone es que tiene unos objetivos que persigue sin atender a requerimientos humanos (como ocurre en el famoso experimento mental de Nick Bostrom con la inteligencia artificial encargada de maximizar la producción de clips) y/o que, simplemente no tiene un mecanismo de parada.

Para quienes piensan que es posible la consecución de un inteligencia artificial general y que ésta podría ser más inteligente que los humanos, se suele abogar por el llamado alineamiento, es decir, que los objetivos de esa inteligencia artificial sean coincidentes con los objetivos e intereses de la raza humana (una idea interesante, pero, posiblemente, más teórica que real ahora mismo).

Los más radicales abogan, en una postura como mínimo poco realista, en una eliminación de la inteligencia artificial o en un 'congelamiento' de su progreso (como ocurrió, por ejemplo, con la, en mi opinión desgraciada carta, enviada hace un tiempo por una serie de personajes muy conocidos, pidiendo una moratoria de seis meses en el desarrollo de los modelos generativos. 

La preocupación real y el 'postureo' ético

¿Cuánto hay de preocupación real por ese riesgo existencial y cuánto de 'postureo'?

Sinceramente, creo que abunda mucho más la ignorancia y el postureo, cuando no algún interés ilegítimo, como en el caso de la famosa carta, que las preocupaciones legítimas.

Antes de razonarlo, un breve comentario 'teórico'. Cuando se habla de riesgos (por ejemplo en dirección de proyectos) y se evalúan y prepara un plan de mitigación, siempre se consideran dos elementos: 

• por un lado la probabilidad de que el riesgo (recordemos, un problema potencial) se materialice y se convierta en un problema real
• Por otro, el impacto que ese problema tendría

Es evidente que, en el caso de un riesgo existencial, el impacto no puede ser mayor, pero ¿Y la probabilidad?

Existe debate sobre si es viable siquiera la consecución de una inteligencia artificial general y de alcanzar la singularidad. Pero, caso de ser viable, y aunque algunos (creo que pocos) apóstoles de la singularidad creen que, como reza el famoso título del libro de Ray Kurzweil , la singularidad está cerca, personalmente no estoy muy convencido de ello y creo que está más bien lejana.

Pese a los innegables, espectaculares y muy rápidos avances de la inteligencia artificial, no me parece que la singularidad, caso de ser posible, esté cercana. En ese sentido, la probabilidad de la inteligencia artificial como riesgo existencial sería baja o muy baja, al menos a corto plazo.

La visión más cercana y el control

Muchos autores críticos con la idea de la singularidad y del riesgo existencial abogan por una visión y, sobre todo, una acción mucho más realista y de corto plazo. Abogan por mecanismos técnicos que aumenten la seguridad ('safety') y el control de los sistemas de inteligencia artificial.

Abogan por la implementación de mecanismos que mitiguen algunos de los riesgos éticos actuales y reales de la inteligencia artificial. Y abogan también por mecanismos regulatorios o de gobernanza que cuiden de implementaciones tanto éticas como controladas de los sistemas basados en inteligencia artificial.

Muchos de estos autores consideran que los debates sobre la singularidad y el riesgo existencial nos distraen de los verdaderos riesgos y de las acciones que realmente debemos llevar a cabo.

La inteligencia artificial como víctima del 'postureo'

Personalmente no me atrevo a afirmar con seguridad que la inteligencia artificial general sea irrealizable, pero sí creo que es poco probable al menos a corto plazo y que ese riesgo existencial, caso de existir, tiene actualmente una bajísima probabilidad de materializarse. 

Y, en ese sentido, sin dejar de permanecer vigilantes e  incluso realizar investigaciones para conseguir ese alineamiento u otro tipo de sistemas de control, en efecto, creo debemos concentrarnos en mejorar la seguridad y comportamiento ético de los sistemas de inteligencia artificial que 'tenemos encima de la mesa' o que tendremos con alta probabilidad en un futuro cercano.

Pero más allá de esa consideración, veo a la inteligencia artificial como una víctima del 'postureo'. Creo que hay muchas personas que hablan de ética de la inteligencia artificial porque está de moda, porque suena bien, porque parece que da idea de persona humanista, consciente, responsable y 'a la última'.

Y creo que se exageran los discursos sobre riesgo existencial, en algunos casos por intereses, pero con frecuencia, simplemente, porque llaman la atención.

¿De verdad es la inteligencia artificial el problema?

 

Y como demostración de ese 'postureo', decir que no veo la misma preocupación en el ambiente y en el discurso por los posibles riesgos éticos de otras tecnologías como la edición genética, la nanotecnología o la propia energía nuclear.

Más importante que eso, no veo tanto 'interés' en otros eventuales riesgos existenciales que no tienen que ver con la tecnología o no directamente. 

Cuando oigo hablar de riesgo existencial ligado a la inteligencia artificial, no puedo evitar decirme para mis adentros: ¿En serio? Convivimos desde hace décadas con la existencia de un arsenal nuclear capaz de destruir varias veces nuestro planeta, asistimos a una degradación medioambiental sin precedentes, asistimos a guerras que acaban con miles y miles de personas , hemos vivido hace pocos años una pandemia grave y parece muy probable que nos enfrentemos a más, asistimos a zonas del planeta que sufren grandes hambrunas, y así sucesivamente. 

¿De verdad nuestro mayor riesgo es la inteligencia artificial? 

¿Lo piensas en serio?   

Sobre los riesgos existenciales naturales

Sobre los riesgos existenciales naturales, lo único que creo que podemos hacer es estudiarlos para entenderlos mejor (cómo se comportan los meteoritos, los volcanes, etc) y para intentar idear estrategias y desarrollar tecnologías (sí, tecnologías) que nos permitan mitigarlos (como lo que está valorando la NASA para intentar destruir o desviar meteoritos antes de que impacten con la tierra)

Los riesgos antropogénicos y el verdadero riesgo existencial

¿Y en el caso de los riesgos antropogénicos?

Por su propia definición dependen de nosotros, de los seres humanos. En nuestras manos está, pues, controlarlos. Pese a las dudas e incógnitas, confío en la capacidad científica y técnica del ser humano para crear tecnologías seguras y controladas, incluida la inteligencia artificial. Y eso me da esperanzas.

Pero si disponemos o podemos disponer de tecnología, el ingrediente que falta entonces, es la voluntad. La voluntad controlar y no dejar que 'los efectos colaterales se produzcan' ni en seres humanos ni en el medioambiente, la voluntad para no usar la tecnología como arma o en favor de intereses ilegítimos, la voluntad para no disparar la primera ojiva nuclear...

Y si depende de nosotros, entonces lo que necesitamos, más allá de tecnología, metodología o regulación, es ética y responsabilidad.

Y siendo así, creo que el mayor riesgo existencial, no es la inteligencia artificial, ni la energía nuclear, ni la genética, ni la nanotecnología, ni siquiera los combustibles fósiles.

El mayor riesgo existencial, siento decirlo, es nuestra falta de ética o de una ética suficiente y generalizada 

Conclusiones

La inteligencia artificial, como todas las tecnologías, lleva aparejados sus riesgos. Quizá, por ser una tecnología tan poderosa, sus riesgos pueden tener mayor impacto. En esa línea hay quien considera que la inteligencia artificial constituye un riesgo existencial, especialmente si se alcanza el nivel de inteligencia artificial general y la famosa singularidad.

Sin embargo, creo que muchos de las preocupaciones éticos relativas a la inteligencia artificial y, en concreto, las relativas al riesgo existencial, son poco sinceras y tienen mucho de 'postureo' o de intereses ilegítimos.

Más allá de que, pese a todo, debemos estar vigilantes y adoptar medidas para conseguir la seguridad y comportamiento ético y controlado de los sistemas basados en inteligencia artificial actuales y futuros, no creo que sean los riesgos de esta tecnología los que más nos deben preocupar ahora mismo.

Por encima de riesgos concretos, creo que el mayor problema, el mayor riesgo, es la escasez de ética y el uso irresponsable, cuando no culpable, de la tecnología y del resto de recursos.

Más allá de riesgos naturales, la falta de ética, y no la tecnología, es el riesgo existencial más profundo, el más acuciante.

Sobre el determinismo y los modelos generativos

Hoy en día, los modelos generativos, muy especialmente los grandes modelos de lenguaje recubiertos por aplicaciones de tipo chat, como el famosísimo ChatGPT, están omnipresentes, no sólo en los medios de comunicación, sino también en la conversación y en su uso práctico en entornos tanto privado como corporativo.

Y dadas sus extraordinarias capacidades, su 'conocimiento' embebido, y su interacción con las personas de una forma tan humana como es el lenguaje natural incluyendo con frecuencia la voz, trasmiten una sensación innegable de inteligencia y de cierta espontaneidad, lo que puede llevar y una errónea atribución de personalidad y puede que, en los casos más descabellados, de libre albedrío.

Y un poco por eso me interesa traer aquí un razonamiento sobre el eventual determinismo o no de los modelos generativos.

¿Qué entiendo por determinismo?

Antes voy a definir qué entiendo por determinismo. Para este artículo, no voy a adoptar una perspectiva ni mucho menos filosófica sobre el determinismo sino, por el contrario, una visión muy matemática o algorítmica, si se prefiere.

Simplificando bastante (pero sin perder por ello rigor), podemos decir que un modelo de machine learning en general, y un modelo generativo en particular, actúa básicamente como una función matemática (eso sí, una función muy compleja). Es decir, es un artefacto matemático que recibe unas entradas y produce una o unas salidas.

Pues bien, con esa visión, entiendo por determinismo la situación en que

ante unas mismas entradas, se produce la misma salida

Las funciones que utilizamos en unas matemáticas, digamos 'normales', son claramente deterministas: si sumas dos números da siempre el mismo resultado, si hallas la raíz cuadrada de un número siempre te dará el mismo resultado, y así sucesivamente. No hay aleatoriedad: mismas entradas, mismo resultado.

El funcionamiento básico de los modelos generativos

Aunque es posible que algunos lectores de este blog conozcan el funcionamiento interno de los modelos generativos, en beneficio de aquellos que no se encuentren en esa situación, y para facilitar el entendimiento del discurso que sigue, voy a explicar, de una forma tremendamente simplificada (aunque cierta) cómo funcionan los modelos generativos y en concreto, los grandes modelos de lenguaje.

Antes una advertencia: existen multitud de modelos generativos, algunos muy similares entre sí y otros bastante diferentes, y cada uno puede tener sus particularidades. En lo que seguirá me voy a centrar en grandes modelos de lenguaje (exclusivamente de lenguaje) basados en arquitectura Transformer, como los GPTs que hay por detrás de ChatGPT pero creo que las conclusiones son extensibles.

Podemos, siguiendo el esquema de la función anterior y aunque luego matizaré lo que ahora voy a decir, que la entrada para el modelo es un texto (de momento consideremos que la instrucción que introduce el usuario, aunque esto no es del todo exacto) y como salida tenemos otro texto: lo que nos contesta, por ejemplo, ChatGPT.

¿Cómo funciona?

Bien, lo primero que se hace es descomponer el texto de entrada en unas unidades denominadas 'tokens'. Existen muchos algoritmos de tokenización y cada modelo utiliza unos tokens diferentes pero, en cualquier caso, el texto de entrada se descompone en esos tokens. Aunque no es cierto del todo, para el razonamiento de este post, el lector que no conozca cómo son estos tokens, se los puede imaginar, simplemente, como palabras.

Luego esos tokens (simplificando, digamos que esas palabras) se codifican como unos vectores (una colección ordenada de números) de alta dimensión (la dimensión es la cantidad de números que tiene el vector). A estos vectores se los denomina 'embeddings'. La forma en que los tokens se traducen a 'embeddings' va a depender del entrenamiento del modelo, pero estos 'embeddings' son un elemento fundamental, puesto que es donde reside en gran medida el 'conocimiento'. Los embeddings llevan consigo información de naturaleza semántica. No es un significado puro, pero sí se mantienen relaciones de cercanía semántica entre tokens (digamos que entre palabras)

Ya tenemos entonces una serie de vectores con contenido semántico, que representan las palabras (tokens) del texto de entrada.

Ahora se aplica uno de los grandes avances del modelo 'transformer': el mecanismo de atención. Mediante este mecanismo (cuyos detalles también se asientan durante el entrenamiento), el modelo de lenguaje 'se fija' en el texto de entrada (todo el texto de entrada) y, no sólo eso, 'sabe' además qué parte de ese texto es más importante de cara a la contestación.

A partir de ahí el modelo de lenguaje, genera el texto de salida. Pero no lo hace directamente, sino token a token (si se quiere simplificar, palabra a palabra). Y, para generar, ese token (esa palabra), el modelo se fija, no sólo en el texto de entrada, sino también en el texto que ya ha generado.

Dos cosas a tener en cuenta.

En primer lugar, antes dije que el modelo recibía como entrada la instrucción del usuario. Eso en realidad es una simplificación. El texto que recibe el modelo en su entrada es la agregación de varias cosas: la instrucción del usuario, el propio texto que el modelo ya ha generado como respuesta, información de contexto (por ejemplo, de las interacciones anteriores en la misma conversación), una instrucción general denominada 'system prompt' e invisible para el usuario, e información eventualmente obtenida del exterior mediante una búsqueda SEO o mediante un mecanismo como RAG ('Retrieval Augmented Generation'). En cualquier caso, la entrada sigue siendo un texto, un texto que denominaremos la instrucción aumentada ('augmented prompt').

En segundo lugar, dado que el modelo realmente genera su salida en llamadas sucesivas, cada una de las cuales produce un token, quizá nos conviene ver el modelo como una función que recibe como entrada un texto (la instrucción enriquecida) y produce como salida un token (no todo el texto de respuesta.

Pero incluso esto último no es del todo cierto o, si se prefiere, hay un pasito intermedio al final que es importante considerar. Más que un token directamente, la salida que se produce es un conjunto de tokens, con la probabilidad que tiene cada uno de ser 'el token adecuado'. Y en el paso final, se elige uno de ellos. A la hora de quedarse con el token final, el token ganador y que se incorporará a la respuesta, el modelo elige entre los disponibles y no siempre elige el de probabilidad más alta, sino que en ocasiones elige otro. Esa selección, que no está completamente prefijada, depende de unos parámetros (normalmente no modificables por el usuario sino por el programador) como la denominada 'temperatura'. Según la temperatura que asignemos el modelo, éste 'se arriesga más' (alta temperatura) eligiendo tokens menos probables o 'se arriesga menos' (baja temperatura), seleccionando uno de los más probables, seguramente el más probable. El uso de parámetros como la puede llevar a tener un modelo que funciona de manera más o menos creativa.

Y ahora llega el momento de responder: ¿este modelo es determinista o no?

En mi opinión, sí y no, dependiendo de lo que queramos decir y para qué usemos la respuesta.

Los modelos generativos como probabilistas

Según la descripción anterior, parece muy claro que la respuesta es que los modelos generativos funcionan de manera probabilista y no determinista.

Además, es muy fácil de comprobar: no tienes más que preguntarle dos veces seguidas a ChatGPT la misma 'cosa' y te proporcionará respuestas diferentes. Normalmente esas respuestas se parecerán bastante entre sí, pero si haces una consulta o indicación vaga y abierta es probable que los resultados difieran bastante.

Esta visión probabilista es uno de los motivos, aunque no el único, por lo que no 'te puedes fiar del todo', de lo que te contesta el modelo. A veces se enfoca bien, pero a veces divaga o se equivoca o genera las conocidas 'alucinaciones'. O, simplemente, no te gusta la respuesta.

Los modelos generativos como deterministas

Y, sin embargo, bajo otra perspectiva, debemos considerar los modelos generativos como deterministas. 

¿Por qué?

Pues porque el que el modelo sea más creativo o menos depende de esos parámetros que comentaba como la temperatura. Manejando adecuadamente esos parámetros, se puede 'congelar' el modelo y que conteste siempre lo mismo. Es más, es una buena práctica para equipos que desarrollan modelos generativos, el que para ciertas pruebas, 'congelen' el modelo, porque así se puede prever la respuesta que tiene que dar y se prueba mucho mejor el comportamiento básico del algoritmo.

Añadiría, pero en esto no me voy a extender, que incluso la aleatoriedad 'informática' sólo es una seudo-aleatoriedad. Estrictamente hablando, al menos hasta donde yo conozco, los generadores aleatorios son en el fondo deterministas: la aleatoriedad se consigue manejando ciertos datos 'semilla', pero no es matemáticamente cierta.

Una especie de gato de Schrödinger: operativa y ética

Con todo esto los modelos generativos son, en cierto modo, probabilistas desde un punto de vista 'macro' pero deterministas desde un punto de vista 'micro'.

Metafóricamente esto del determinismo de los modelos generativos es una especie de 'gato de Schrödinger': son al mismo tiempo deterministas y no deterministas y va a depender del observador el decir una cosa u otra.

Para la gran mayoría de las situaciones y para su uso práctico del día a día en empresas, administraciones o a nivel particular, debemos considerarlos probabilistas. Debemos ser conscientes de que no producen siempre el mismo resultado con lo bueno que eso tiene en cuanto a creatividad y naturalidad pero también con el riesgo de la no repetitividad y la no completa fiabilidad.

Sin embargo, a efectos filosóficos y éticos, conviene recordar que en sus entrañas más profundas siguen siendo funciones matemáticas completamente deterministas y, por tanto, no cabe, creo, la fantasía de una voluntad propia o un 'libre albedrío' por parte del modelo.

Y es esta última razón, la de evitar fantasías y planteamientos éticos equivocados, la que me ha animado a escribir este post y la que hace importante recordar las raíces deterministas de los modelos.

Conclusiones

Los modelos generativos, cuando los contemplamos externamente como usuarios e incluso muchas veces como desarrolladores, se nos muestran como unos modelos de naturaleza probabilista. Y es importante tener esto en cuenta cuando usamos chats basados en modelos generativos o cuando queremos automatizar con base en estos modelos, por ejemplo mediante agentes.

Sin embargo, en su base más profunda, siguen siendo deterministas y, por tanto, podemos olvidarnos de un eventual libre albedrío o voluntad propia del modelo, salvo que se defienda que es posible el libre albedrío en un entorno plenamente determinista.

Machine learning y la fantasía de una política científica

En este post, más de opinión que de exposición, voy a desarrollar lo que es  a la vez un convencimiento y creo que, por desgracia, una fantasía: el uso inteligente y científico de modelos de machine learning en la administración pública.

La naturaleza de la política: la administración

Hace un par de semanas publicaba en mi podcast 'Divergencias' un episodio que titulaba "Management y política" y que tiene mucho que ver con lo que ahora desarrollo de manera más enfocada en este post.

Una de las cosas que allí apunto es la que creo las dos dinámicas dominantes de la política.

La primera dinámica, la que resulta mucho más visible y que en realidad es mucho más superficial y menos valiosa, es la que tiene que ver de alguna forma con la comunicación política. Se trata de todas las acciones que realizan líderes y partidos para exponer sus posiciones, para criticar las del contrario y, en definitiva, para intentar ser relevantes y ganarse la voluntad y en último término el voto de los ciudadanos. Declaraciones, apariciones en medios, mítines, manifestaciones, etc forman parte de esta faceta de la política.

La segunda dinámica, la realmente importante, y mucho menos visible por desgracia, es la administración y la gestión, es la que tiene lugar cuando se ejerce el gobierno, cuando se está al frente de un gobierno central, de un ministerio, de una comunidad autónoma, de una consejería, de un ayuntamiento, etc.

Podría decirse que hay una tercera dinámica, que es la legislativa, pero en esa no voy a profundizar y la asimilaré, aunque de forma bastante simplificada y quizá burda, a la segunda.

En cualquier caso, y aunque la administración pública tiene algunas particularidades, cuando entramos en gestión (en 'management' como decía en mi podcast) entran en juego cuestiones como presupuestos, equipos, plazos, resultados, retornos, etc. Y pasan a ser importantes, o deberían pasar a  ser importantes, la eficacia (conseguir objetivos) y la eficiencia (optimizando el uso de recursos que para ello se emplean).

En mi podcast apostaba por que, en esa labor de gestión, se adoptasen los enfoques que son comunes en las empresas. Reconociendo, como decía antes, que la administración pública tiene elementos diferenciales y que, por ejemplo, los retornos que se esperan para una inversión con frecuencia no son económicos, creo que la mayor parte de las herramientas y técnicas de gestión empresarial pueden y deberían aplicarse en el ámbito público.

Gestión científica

Y esta gestión empresarial me lleva a lo que, quizá de una forma algo grandilocuente y no del todo exacta, estoy denominando una gestión científica.

Lo que quiero decir con ello es la aplicación de metodologías, técnicas e incluso tecnologías que hacen que la gestión se base en hechos y datos, que mida resultados, que monitorice progresos y que apoye las decisiones en esos datos, en estudios o modelos contrastados, y no en la mera intuición o la voluntad 'política'.

Que sea, en definitiva, una gestión objetiva, fundamentada, eficaz y eficiente... y mucho menos (cuanto menos mejor) 'ideológica'.

Técnicas, metodologías y tecnologías

En esa gestión científica, existen muchas técnicas. Así, por ejemplo, está ampliamente definido, usado y documentado el uso de técnicas para valoración de proyectos de inversión y para el filtrado, selección y priorización de proyectos.

Existe también, por ejemplo, una disciplina bien desarrollada para la dirección de proyectos de cualquier naturaleza y que incluye, aparte del control de plazos y presupuestos, aspectos relevantes como la gestión de riesgos.

Y existe una disciplina bien desarrollada de análisis y optimización de procesos de negocio y una amplísima oferta de tecnologías de digitalización y automatización para disponer de una administración muchísimo más moderna y, de nuevo, más eficaz y eficiente.

Modelos

Entre las herramientas para una gestión científica se encuentran los modelos, de los que próximamente también hablaré en mi podcast 'Divergencias'

Los modelos son abstracciones de la realidad, unas abstracciones que, por fuerza, acaban siendo simplificaciones, pero que ayudan a explicar esa realidad y, sobre todo, a hacer predicciones razonables sobre la misma.

A algunos de estos modelos, sobre todo físicos o químicos, se ha llegado por experimentación, reflexión y, en ocasiones, deducción matemática. Un ejemplo que muchos habremos estudiado en la época escolar son los sucesivos modelos del átomo que se generaron desde la época de los griegos hasta todavía la época actual en que se siguen descubriendo o deduciendo nuevas partículas subatómicas. O los modelos que explican y dan forma matemática a la gravedad y que comienza por Newton y se revisan por parte de la teoría relativista. O, en la misma línea de la física, los modelos del universo.

En muchos campos, un modelo acaba teniendo unas variables de entrada y unas variables de salida y lo que, de alguna forma ofrece el modelo, es la relación entre esas variables de entrada y las de salida. Y una vez el modelo se encuentra bien desarrollado y probado, es capaz de hacer predicciones y decir, con razonable seguridad y exactitud qué valores de salida tendremos antes unas entradas concretas.

Econometría

En el campo de la economía, uno de los ámbitos fundamentales de trabajo de la política en su vertiente de gestión existe, de hecho, y desde hace muchos años, la disciplina de la econometría que crea modelos matemáticos y estadísticos para fenómenos económicos.

Y una disciplina que, lógicamente, en los últimos años ha incorporado los modelos de 'machine learning'.

Y con base en esos modelos econométricos, se analizan fenómenos que tiene que ver con precios, inflación y cosas así.

El uso de machine learning: modelos y gestión

Y es que, en efecto, los modelos dominantes hoy en día en muchísimas disciplinas son los modelos procedentes del campo del machine learning.

Estos modelos aportan algunas grandes ventajas.

Así, por ejemplo, son modelos que permiten tratar fenómenos y obtener capacidad predictiva para fenómenos que no comprendemos completamente. A diferencia de los modelos físicos o químicos tradicionales, que suponían un razonable entendimiento del fenómeno y unas hipótesis sobre el 'funcionamiento del mundo', los modelos de machine learning no ponen como condición entender el fenómeno, sólo conocer las variables de entrada y salida relevantes... y el convencimiento de que existe correlación (y quizá causalidad) entre ellas.

Otra ventaja es que se apoyan en datos (muchos datos en realidad) y eso, aunque con la dificultad de obtener y limpiar los datos, y con los riesgos de sesgos, aporta objetividad.

Finalmente, añadiría que, dado el gran progreso tecnológico, dada la gran capacidad de computación disponible, y dado el potente ecosistema de herramientas, cada vez son más sencillos de crear y utilizar, y se encuentran al alcance de cualquier organización, y no digo ya modelos generalistas (como el modelo del átomo) sino modelos específicos, para temas específicos y en organizaciones específicas.

El debate frente a la ciencia

Y si ahora retornamos de nuevo a la política en su faceta de gestión, veo un campo tan potente y tan fructífero si se aplicasen estos modelos a la gestión...

¿Por qué no generamos modelos para los fenómenos más importantes y decidimos con base en datos en lugar de elegir opciones con base en posicionamiento ideológicos, en 'relatos', en conveniencias, en prejuicios o en intuiciones?

Por ejemplo, hace poco se ha subido el salario mínimo en España. Y surgió el debate de si eso impacta o no en el empleo. ¿Qué tal, si en lugar de 'discutirlo', intentamos hacer un modelo que lo muestre, casi que lo demuestre en el sentido que sea?

Respecto al tema de impuestos, otro tema 'calentito': ¿Subirlos o bajarlos? ¿Qué tal si, en lugar de 'tirarnos los trastos' y encendernos en debates, modelamos el efecto de los impuestos en temas como la recaudación del estado, el impacto en el consumo o incluso el PIB?

Y no todo tiene que ser económico. ¿Por qué no modelamos, por ejemplo, si el endurecimiento de las penas para un delito, influye o no en que se cometa menos ese delito? O ¿por qué no estudiamos si, por ejemplo, los impactos publicitarios advirtiendo de los peligros del tabaco contribuyen o no a que disminuya su consumo (aviso que sobre este último punto hace poco leí un libro que venía a decir que era contraproducente avisar mucho de los peligros del tabaco)? 

También se trabaja y es un gran campo en temas como salud pública y epidemiología, o en la predicción de terremotos.

Y así podríamos seguir con todos los fenómenos más o menos complejos que normalmente se discuten y gestionan desde la mera ideología, no desde los datos y la ciencia.

Para ser rigurosos, hay que avisar que no todo es modelable. Puede haber fenómenos para los que no tengamos, por ejemplo, datos suficientes, o con la calidad suficiente,  o acceso a los mismos. A lo mejor, para algunos de los casos que he puesto como ejemplo no somos capaces de hacer un modelo. Y a lo mejor hay fenómenos en que todavía 'estamos tan verdes' en su comprensión, que primero hay que estudiar cuáles son las variables relevantes.

Pero creo que se entiende la idea y, sobre todo, más allá de casos concretos, como práctica generalizada, creo que el uso de modelos, especialmente de modelos de machine learning (sin excluir otras técnicas y disciplinas que citaba al principio) daría un enorme giro en la gestión de lo público, un giro hacia la objetividad, la eficacia y la eficiencia... y de paso, mucha menos polarización.

Y eso nos llevaría a una política, con mucha menos ideología, mucho menos debate estéril y sin fundamento, y a cambio a una gestión de los asuntos públicos mucho más rigurosa y voy a decir que más científica.

El deseo y la fantasía

Y esa es mi propuesta y mi deseo, casi mi carta a los Reyes Magos.

No tengo ninguna queja respecto a cómo se han comportado los Reyes Magos conmigo a lo largo de los años...pero en esta ocasión, creo que este deseo  me lo van a traer ni este año, ni el que viene, ni el siguiente...y puede que nunca.

No tengo datos, pero estoy convencido de que están desarrollados o en análisis muchos modelos del tipo de los que he propuesto. No tengo dudas de que en el ámbito científico y universitario se ha trabajado, se trabaja y se trabajará en este tipo de modelos. Seguro que hay muchos publicados.

Y seguro que en el ámbito privado se están implantando e implantarán muchos modelos, aunque seguramente dedicados a temas más de negocio como predicciones de ventas, de necesidades de materiales, de análisis de acciones de marketing y atribución de ventas o mantenimiento predictivo.

Lo que no veo es su uso generalizado en la administración, aunque no excluyo 'pilotitos', demostradores o pequeñas experiencias.

Lo que, por desgracia, no confío en ver, es su uso generalizado y, sobre todo, el paso de una gestión como la actual, que creo más basada en ideología, discursos, conveniencias, intuiciones y prejuicios, a una gestión objetiva,  basada en datos (y modelos), rigurosa y 'científica'.

Para conseguirlo, se precisaría un profundo cambio cultural y, además, una voluntad, unos conocimientos y unas competencias de las que creo que carecen, de forma muy generalizada, los líderes políticos y gestores públicos actuales.

Así que, ojalá me equivoque, pero esa política científica es, creo, sólo un deseo y una fantasía.

Conclusiones

En el acervo de metodologías, técnicas y tecnologías actuales, existen muchas que serían aplicables en la gestión de los asuntos públicos, en lo que considero la faceta más importante del ejercicio político.

Dentro de las tecnologías, es particularmente prometedor el uso de modelos de machine learning para modelar fenómenos complejos sobre los que luego hay que tomar decisiones de gestión.

Sin embargo, personalmente, veo esa gestión rigurosa, científica y apoyada en datos y modelos, tremendamente deseable, pero siendo prácticos, sólo como un deseo y una fantasía.

Lo que no reluce en el 'Vibe coding': retos, limitaciones y equilibrios

Aunque la promesa de productividad y facilidad del 'vibe coding' es muy importante, y hasta cierto punto bastante creíble, conviene ser realistas y tomar consciencia de que la generación de código mediante inteligencia artificial, al menos hoy en día, tiene limitaciones que hay que conocer y gestionar.

En un post anterior decía por ello que 'no era oro todo lo que relucía'. En este post, precisamente, quiero sacar a colación aquello que 'no reluce' en el 'vibe coding'.

Y para ello me baso, como en posts anteriores, en las aportaciones de Addy Osmani en su libro 'Beyond Vibe Coding: From Coder to AI-Era Developer'.

Recordatorio 'express'

Antes, un recordatorio brevísimo, express. El término 'Vibe coding', acuñado por Andrej Karpathy, y de fronteras difusas, designa la generación de código mediante el uso de inteligencia artificial, normalmente grandes modelos de lenguaje generalistas o especializados en generación de código. Es decir, el desarrollador expresa en lenguaje natural lo que quiere que haga una aplicación, función o lo que sea, y el modelo de lenguaje genera el código correspondiente.

Como digo, las fronteras del término no son claras, pero personalmente creo que se aplica más a cuando esa generación de código es completa o casi completa, es decir, que se genera una aplicación completa o gran parte de ella. De forma más general, podemos hablar de ingeniería de software asistida por IA donde el nivel de ambición puede ser menor y lo que el desarrollador puede solicitar al modelo de lenguajes es, a lo mejor, sólo una función, o una pantalla o que le ayude a resolver un error sintáctico o de ejecución.

En cualquier caso, hablamos de generación de código y un código que el desarrollador solicita a la IA mediante lenguaje natural.

Bajando un poco a la realidad

Si bajamos un poco a la realidad, al menos actualmente, no resulta posible generar aplicaciones que sean completas, fiables, seguras y escalables sólo mediante un 'prompt', por largo, sofisticado y bien elaborado que éste sea.

Se pueden conseguir resultados espectaculares generando aplicaciones sencillas en modo demostración o prototipo, pero no aplicaciones pensadas para producción real.

La realidad actual apunta más a un trabajo conjunto entre un desarrollador y la IA, donde la IA genera grandes partes del código e incluso ayuda a corregirlo pero con intervención, supervisión y modificaciones por parte del desarrollador humano.

Aspectos que aún le cuestan al 'vibe coding'

Osmani, en su libro, destaca cinco facetas, como aspectos que le cuestan (que no suele conseguir) el 'vibe coding' actual:

• Sistemas complejos: El 'vibe coding' funciona bien con aplicaciones sencillas y típicas, como ventanas web que recubren operaciones CRUD (Create, Read, Update, Delete) en bases de datos. En general, aplicaciones sencillas y comunes que los LLMs 'han visto' con frecuencia en sus datos de entrenamiento. Pero lo tienen muy difícil ante el caso de algoritmos complejos o planteamientos novedosos que no existen en los datos de entrenamiento o que se encuentren poco representados. En estos casos, la IA tiende a generar un código que se acerca al correcto, pero no lo es en realidad.


• Optimizaciones de bajo nivel y programación a nivel sistema: Los LLMs actuales están fundamentalmente entrenados con código escrito en lenguajes de alto nivel y problemas también de alto nivel, cercanos al negocio o la funcionalidad. Sin embargo, la optimización de ciertos algoritmos implica la programación a muy bajo nivel, muy cerca del sistema, para reducir complejidad algorítmica y tiempos de procesamiento, optimizar el uso de recursos hardware, para adaptar los algoritmos al hardware subyacente, etc. Por tanto, el código que generan suele ser subóptimo. Para muchas aplicaciones no críticas puede ser más que suficiente, pero para otras más especiales no tanto.


• Frameworks únicos o de nicho: De nuevo, estos modelos están entrenados con base en código fuente basado en librerías y frameworks más o menos populares y, por tanto, pueden ser incapaces de generar un código correcto en el caso de frameworks o librerías muy nuevos o muy de nicho (y con pocos ejemplos en los datos de entrenamiento)


• Interfaces de usuario creativas: Una vez más, los modelos generan correctamente código para formas de resolver un problema comunes. En lo relativo a la interfaz de usuario, generan correctamente, por ejemplo, formularios, dashboards y otras formas comunes y probadas de interfaz de usuario. Pero les resulta muy complicado generar una experiencia nueva, especial, diferente, inspiradora.


• Interpretación de intenciones y requisitos: En este caso, el problema puede estar más en el lado del desarrollador, pero lo cierto es que los modelos no siempre resuelven bien unas especificaciones con requisitos implícitos o contradictorios.

Limitaciones y equilibrios

Además de las facetas vistas más arriba, Osmany también nos alerta de algunas limitaciones de los LLMs o de algunas circunstancias que pueden precisar de adoptar algún tipo de equilibrio, de solución de compromiso:

• Calidad variable de la salida: Como sucede en otros ámbitos de su aplicación, los LLMs pueden generar un código que parezca correcto pero que no funcione del todo bien, o que, por ejemplo, no reaccione bien ante errores. También puede producir un código funcional pero ineficiente. Por tanto, parece inevitable una supervisión responsable y real por parte del desarrollador humano de todo lo que genera mediante IA.


• La ambigüedad en los 'prompt's conduce a ambigüedad en el código: Como ocurre en general con la ingeniería de instrucciones ('prompt enmgineering') y como , en el fondo, también ocurre con la especificación de requisitos tradicional, si las instrucciones (que actúan como requisitos) son ambiguos, incompletos o incorrectos, el resultado también presentará carencias.


• Confianza excesiva y atrofia de habilidades: Quizá aún sea pronto para ver con claridad este efecto, pero parece previsible que si un desarrollador confía en exceso en la IA y apenas hace aportaciones propias, poco a poco sus habilidades se irán deteriorando y con ello su capacidad de detectar errores, de optimizar el código, de depurar el resultado y, en general, se empobrecerá como desarrollador. Y también se empobrecerá el código que genere, cada vez más apoyado en la IA


• Aspectos de seguridad y privacidad: Con frecuencia, los entornos de 'vibe coding' se apoyan en el envío de código a terceros en la nube, lo cual puede plantear preocupaciones en cuanto a privacidad. Igualmente, existe el riesgo de que el código que genere la IA sea casi una copia de un código real quizá protegido por propiedad intelectual.


• Sesgos en las salida: Los LLMs usados para generar código, también pueden presentar sesgos como otros modelos de IA o como estos mismos modelos en otros ámbitos de aplicación. En el ámbito de la generación de código suelen ser sesgos 'inocentes' como tener preferencia por dar ciertos nombres a las variables, pero conviene estar vigilantes de que no se introducen sesgos más graves.


• Factores humanos y confianza: Finalmente entra el factor humano que puede hacer que los desarrolladores no acepten esta forma de trabajar, quizá por desconfianza en los resultados, o quizá, incluso, porque cambia la naturaleza de su trabajo que hasta ese momento, antes del 'vibe coding', quizá percibían como más divertido, independiente y creativo.

Conclusiones

Como en el fondo cabía imaginar, el 'vibe coding' no es algo mágico, sino que tiene sus limitaciones y problemáticas, unas limitaciones y problemáticas que tienden a resolverse, en la mayor parte de los casos, siendo conscientes de que el trabajo de desarrollo basado en IA implica una importante supervisión por parte de desarrolladores humanos de cara a la verificación, optimización, depuración, etc. Y unos desarrolladores humanos que, además, deben estar mentalizados y tener altas capacidades por que, si no, seguramente les pasarán inadvertidos los errores o soluciones subóptimas que les proponga la IA.

Artículos de este blog relacionados

• Doce reglas de oro del 'Vibe coding'
• Conociendo el 'Vibe coding'

Cómo construir agentes de IA según Wisbas y Talukdar

En el momento de publicarse, Abril de 2025, 'Building Agentic AI Systems' probablemente sea uno de los primeros libros serios lanzados al mercado en materia de agentes basados en grandes modelos de lenguaje generativos. Se trata de un libro riguroso, que aborda, con fuerte carga conceptual, los diferentes aspectos de diseñó e implementación de agentes y sistemas basados en agentes, incluyendo los sistemas multiagente.

El libro, se compone de once capítulos agrupados en tres partes, como sigue:

• 'PART 1: FOUNDATIONS OF GENERATIVE AI AND AGENTIC SYSTEMS': Una parte introductoria tanto a la inteligencia artificial generativa como a los propios agentes, y que se concreta en tres capítulos:
  
  
  • 'Chapter 1 - Fundamentals of generative AI:' Hace una introducción muy sencilla a lo que son los modelos generativos, explica brevemente algunos de los enfoques existentes como las redes adversarias, los autocodificadores variacionales o los transformers y repasa algunas problemáticas como la calidad de datos de entrenamiento, los sesgos, el consumo computacional y algunos otros retos de naturaleza ética.
  
  
  • 'Chapter 2 - Principles of agentic systems:' Con un enfoque de alto nivel y arquitectura, explica conceptos definitorios de un agente como el auto-gobierno, la agencia y la autonomía. Con ese mismo enfoque explica también las arquitecturas básicas, a saber, deliberativa, reactiva e híbrida, y finaliza aportando conceptos sobre sistemas multiagente.
  
  
  • 'Chapter 3 - Essential components of intelligent agents:' Se centra en explicar tres mecanismos fundamentales de los agentes: en primer lugar, la representación del conocimiento mediante redes semánticas, 'frames' o lógica; en segundo lugar los tipos de mecanismos de razonamiento: deductivo, inductivo y abductivo; y, en tercer lugar, mecanismos de planificación y toma de decisiones.


• 'PART 2: DESIGNING AND IMPLEMENTING GENERATIVE AI-BASED AGENTS': Probablemente, la sección nuclear y más importante desde el punto de vista técnico, con la explicación de los principales elemetos arquitectónicos, de diseño y de implementación. Se divide en cuatro capítulos:
  
  
  • 'Chapter 4 - Reflection and introspection in agents:' Explica los mecansimos de reflexión e introspección. Tras aportar conceptos y justificar su importancia, describe cuatro formas de implementación: razonamiento tradicional, meta-razonamiento, auto-explicación y auto-modelado.Finalmente aporta algunos ejemplos y casos de uso.
  
  
  • 'Chapter 5 - Enabling tool use and planning in agents:' Aborda la interacción de los agentes con recursos externos mediante herramientas. Primero explica lo que son las herramientas y su papel. Sigue con una descripción de los algoritmos de planificación para luego indicar cómo se integran las herramientas en el razonamiento y la planificación. Finaliza mostrando ejemplos de implementación con los frameworks CrewAI, AutoGen y LangGraph.
  
  
  • 'Chapter 6 - Exloring the Coordinator, Worker, and Delegator approach:' Tal y como reza el título, se explica el patrón CWD ('Coordinator', 'Worker', 'Delegator') que implica el uso de varios agentes, asumiendo roles diferentes pero coordinados. Además de detallar el modelo en sí mismo, aporta ideas sobre cómo diseñar los diferentes agentes, los mecanismos de comunicación y coordinación entre ellos y finaliza con algunos consejos de implementación.
  
  
  • 'Chapter 7 - Effective agentic system design techniques:' Aborda cuantro elementos de diseño de interés: por un lado, el diseño de las instrucción ('prompts') para los agentes; por otro, el modelado del entorno y el uso de espacios de estados: a continuación, la tipología y uso de memorias; y, para finalizar, el enfoque secuencial o paralelo.


• 'PART 3: TRUST, SAFETY, ETHICS AND APPLICATIONS': Abandona un poco el núcleo de lo que son los agentes y cómo funcionan y se diseñan para tratar algunos temas de contexto algo diversos, y lo hace con los cuatro capítulos finales:
  
  
  • 'Chapter 8 - Building trust in generative AI systems:' Habla de mecanismos que aportan confianza en los agentes desde el punto de vista tanto técnico como ético. Repasa primero algunas técnicas o problemáticas como la trasparencia y explicabilidad, la incertidumbre y los sesgos, la generación de salidas comprensibles y efectivas, el control del usuario y su consentimiento y algún avance en materia de ética y responsabilidad. Finaliza con algúnos consejos sobre cómo implementar algunas de estas técnicas.
  
  
  • 'Chapter 9 - Managing safety and ethical considerations:' No sin un cierto solape con el capítulo anterior, se tratan temas de seguridad y éticos. Así, por ejemplo, en lo relativo a seguridad se habla de ataques adversarios, de sesgos y discriminación, de alucinaciones, de violaciones de la privacidad o de riesgos relativos a propiedad intelectual. En la segunda parte del capítulo, salta ya a una visión más ética hablando del diseño centrado en el ser humano, de elementos de responsabilidad o de privacidad y de protección de datos.
  
  
  • 'Chapter 10 - Common use cases and applications:' Explica el uso de agentes en cuatro grandes campos, a saber: creación artística, procesamiento del lenguaje y conversaciones, robótica y sistemas de soporte a la decisión.
  
  
  • 'Chapter 11 - Conclusions and future outlook:' Una mirada algo más futurista, en que primero se tratan lo que los autores perciben como principales tendencias, luego se explican ideas sobre la inteligencia artificial general, AGI ('Artificial General Intelligence') para acabar con una breve identificación de riesgos y oportunidades.

'Building Agentic AI Systems' es un libro serio y riguroso sobre el emergente campo de los agentes basados en modelos generativos. Aporta una fuerte carga teórica y conceptual y un enfoque más de arquitectura y diseño que de implementación o desarrollo. No obstante, a lo largo del libro de vez en cuando se aportan pequeñas secciones de código, con frecuencia apoyadas en el 'framework' CrewAI.

Aunque quizá hubiera agradecido un poco más de código y, sobre todo, un mayor acercamiento a lo que están haciendo e implementando en materia de agentes organizaciones como OpenAI, Microsoft, Anthropic, etc. creo que se trata de un buen libro, y recomendable para personas a las que interese no sólo el paso directo a la construcción, sino también entender los conceptos que hay detrás.

Anjanava Wisbas

(Fuente: traducción asistida con IA de su Página oficial)

Anjanava Wisbas

Anjan, arquitecto sénior de soluciones especializado en Inteligencia Artificial en AWS, es líder en Inteligencia Artificial y Machine learning, y se centra en la IA generativa, visión artificial, procesamiento del lenguaje natural (NLP) y la seguridad y el alineamiento de la IA.

Con 16 años de experiencia en software y tecnología en la nube y 7 certificaciones de AWS, Anjan destaca en el desarrollo de sistemas basados en IA y la implementación estratégica. Su liderazgo combina la innovación técnica con los objetivos empresariales, ampliando con pasión los límites de la IA en la computación en la nube.

Puedes conocer más del autor visitando su perfil en LinkedIn o siguiéndole en X donde se presenta como @itsrealAJB.

Wrick Talukdar

(Fuente: traducción asistida con IA de su entrada en página oficial)

Wrick Talukdar

Wrick es un distinguido arquitecto de IA/ML y líder de productos con más de dos décadas de experiencia impulsando transformaciones tecnológicas en empresas globales. Reconocido por su experiencia en IA, aprendizaje automático y computación en la nube, ha aprovechado constantemente las tecnologías de vanguardia para ofrecer valor empresarial estratégico a clientes de todo el mundo.

A lo largo de su carrera, Wrick ha liderado iniciativas digitales que han generado importantes ahorros de costes y acelerado el tiempo de comercialización. Cuenta con una trayectoria probada en la creación de equipos de alto rendimiento que ofrecen productos y soluciones innovadores de IA.

Como pensador estratégico, Wrick destaca por alinear la tecnología con los objetivos empresariales, fomentar la colaboración interfuncional y abordar retos complejos con enfoques basados en datos. Su capacidad para unir la experiencia técnica con la visión empresarial le posiciona como un líder clave en el impulso del crecimiento sostenible y la innovación.

Wrick es un profesional certificado TOGAF® de nivel 2 y posee múltiples certificaciones de AWS y Azure en inteligencia artificial y aprendizaje automático.

Más allá de sus logros profesionales, Wrick ha tenido un impacto duradero en la comunidad científica mundial, y sus investigaciones son ampliamente referenciadas y citadas en todo el mundo. Es presidente del IEEE NIC, miembro sénior del IEEE y arquitecto jefe de IA/ML para iniciativas de IA generativa dentro del Comité de Participación Industrial (IEC) del IEEE, donde empodera a los jóvenes profesionales para que avancen en sus carreras a través de la tecnología y la IA generativa. Además, como miembro senior y asesor de la Consumer Technology Society (CTSoc), desempeña un papel clave en la configuración de los estándares tecnológicos y proporciona orientación estratégica en importantes conferencias mundiales, como la ICCE.

Puedes conocer más del autor visitando su perfil en LinkedIn.

Ficha técnica:

TITULO: Building agentic AI systems

AUTOR: Anjaba Wisbas y Wrick Talukdar

EDITORIAL: Packt

AÑO: 2025 

ISBN: 978-8423438402

PAGINAS: 489 

Artículos de este blog relacionados

• Hablemos de agentes (y XI): tendencias, retos y oportunidades
• Hablemos de agentes (X): consideraciones éticas y de seguridad
• Hablemos de agentes (IX): entorno, memoria y contexto
• Hablemos de agentes (VIII): el modelo CWD para sistemas multiagente
• Hablemos de agentes (VII): algoritmos de planificación
• Hablemos de agentes (VI): herramientas
• Hablemos de agentes (V): reflexión e introspección
• Hablemos de agentes (IV): sistemas multi-agente
• Hablemos de agentes (III): arquitecturas reactivas, deliberativas e híbridas
• Hablemos de agentes (II): auto-gobierno, agencia y autonomía
• Hablemos de agentes (I): concepto, contexto y tres características esenciales

Doce reglas de oro del 'Vibe coding'

En el post anterior, hice una pequeña introducción a lo que es este nuevo concepto del 'vibe coding', un tema novedoso (aunque con presente y mucho futuro) y que cambia la forma de desarrollar software.

En este artículo voy a aportar unas buenas prácticas, en forma de reglas de oro, que propone Addy Osmani en su libro 'Beyond Vibe Coding: From Coder to AI-Era Developer'. 

 

Un breve recordatorio: qué es el 'vibe coding'

Antes, y a modo de muy breve recordatorio, decir que el término 'vibe coding' denomina, de una forma que hay que reconocer que algo confusa, el uso de la inteligencia artificial para la generación de código software.

Aunque, como digo el término no es académico ni de límites claros, personalmente tiendo a asimilarlo al caso en que la IA hace gran parte del trabajo, que genera todo o gran parte del código fuente, mientras que para otras situaciones en que es una ayuda pero más atomizada, generando secciones relativamente limitadas de código o ayudando en depuración de errores concretos y cosas así, podríamos adoptar el término de ingeniería de software asistida por IA que propone el propio Osmani.

En cualquier caso, creo que no vale la pena en este caso 'ponerse estupendos' con las definiciones. Hablamos de generación de código (e incluso de intervención en todo el ciclo de vida de la ingeniería software) basado en inteligencia artificial y, en concreto, en grandes modelos de lenguaje. 

Para más detalles, invito al lector a visitar mi post anterior 'Conociendo el vibe coding', incluyendo la referencia bibliográfica al libro de Osmani, o a las aportaciones de Andrej Karpathy, creador del término 'vibe coding' 

Las doce reglas de oro del 'vibe coding'

Bueno, y sin más dilación éstas son las doce reglas de oro que propone Osmani en su libro, a las que me tomo la libertad de añadir algunos comentarios propios:

• Sé claro y específico en lo que quieres: Se trata de proporcionarle instrucciones muy claras a la IA sobre la aplicación, función o lo que sea que se le está solicitando. Esto, en realidad, es la fusión de dos buenas prácticas: la de la especificación de requisitos clara, propia de la ingeniería de software tradicional (sobre todo en el modelo en cascada) y la de proporcionar instrucciones claras y precisas propio del 'prompt engineering'


• Valida siempre la salida de la IA frente a tu intención: Osmani utiliza el término intención ('intent') para indicar aquello que realmente queremos, aquello que esperamos del software que vamos a crear. Y lo que propone, en el fondo, es algo que también se realiza en ingeniería de software tradicional bajo el término 'validación', y que significa asegurarse de que el software satisface los requisitos del negocio. En este caso, lo que creo que es más relevante es la llamada de atención a 'no fiarse' sin más de lo que genera de IA, sino realizar una validación activa y por humanos del resultado.


• Trata a la IA como a un desarrollador junior: Básicamente, significa, de nuevo, no fiarse directamente del código generado por la IA. Con la metáfora del desarrollador junior, se traslada la idea de supervisar las tareas. Es decir, delegar tareas de desarrollo pero revisar el resultado.


• Usa la IA para expandir tus capacidades no para sustituir tu pensamiento: Una juiciosa llamada de atención a no renunciar a la propia capacidad de resolución de problemas y de toma de decisiones. Aparte de lo que para la persona supone, el propio estado del arte de la generación automática de código requiere actualmente que el humano asuma muchas de las decisiones o planteamientos más complejos.


• Coordina por anticipado con el equipo antes de generar código: Se trata de un lógico establecimiento de ciertas reglas de juego comunes, tanto de estilo como de operación. Pero, además, hay que tener en cuenta que la IA puede decidir modificar módulos (eventualmente desarrollados por otra persona o por otra persona ayudada por IA), por lo que es necesario coordinar y poner reglas.


• Trata el uso de la IA como una parte normal de la conversación del desarrollo: De igual forma que los equipos de desarrollo hablan de herramientas, hallazgos y buenas prácticas, lo que propone Osmani es algo tan lógico y natural como que en esas conversaciones se incluyan experiencias, éxitos, fallos etc encontrados en el trabajo con la IA.


• Separa los cambios en Git mediante 'commits' diferentes: Se trata de gestionar de forma separada, en lo que a control de versiones se refiere, el código generado por humanos del generado de la IA: Es una regla de orden práctico para facilitar revisiones, vueltas atrás, etc


• Asegura que todo el código pasa por una revisión de código: La revisión de código ('code review') es una buena práctica tradicional en ingeniería software. Se trata de que el software  generado, no sólo se prueba en funcionamiento, sino que el propio código fuente es inspeccionado y revisado, en general por otro desarrollador o por un arquitecto de soluciones. Personalmente aseguraría que esta práctica está bastante en desuso y, sin embargo, Osmani la propone como una regla de oro. Por un lado, propone usarla para que una persona revise el código generado por la IA, lo cual puede estar perfectamente alineada con esa metáfora del desarrollador 'junior' que mencionábamos antes. Pero además, propone también revisar el código generado por humanos. Es decir, es una apuesta general y en toda regla por la revisión de código.


• No hagas 'merge' de código que no entiendes: Para aquellos no familiarizados con el trabajo en software, indicar que  'hacer un merge' significa fusionar en una sola instancia dos versiones del código fuente del mismo módulo para lo cual de alguna forma hay que decidir (automáticamente o por una persona) qué parte sobrevive de cada versión en el resultado unificado. Cuando Osmani propone esta regla, lo que propone en el fondo es no fiarse sin más de un código generado por la IA, sino primero entenderlo como haría el desarrollador con el código generado por él mismo, y sólo entonces incorporarlo al repositorio común de código y eventualmente mezclarlo o fusionarlo con otro código.


• Prioriza los comentarios y documentación: De nuevo, se trata de rescatar, y aplicar al caso del código generado por IA, una buena práctica de la ingeniería de software tradicional. Una práctica que consiste en insertar comentarios y generar documentación que ayude a entender a un tercero (o al propio desarrollador pasado un tiempo) el código fuente. Eso es fundamental sobre todo de cara al mantenimiento y evolución.


• Comparte y reutiliza los prompts efectivos: una vez más, la adaptación de una buena práctica del mundo del software que consiste en generar módulos reutilizables, aunque en este caso aplicada a los prompts. En este caso, también, se trata de una buena práctica de ingeniería de instrucciones. Si un prompt (una instrucción) ha demostrado que ha generado buenos resultados, un código que funciona y hace lo que tiene que hacer, es bueno reutilizarlo y compartirlo con el resto del equipo.


• Reflexiona regularmente e itera: Propone una revisión periódica de todo la mecánica y 'workflow' de desarrollo como una forma de mejora. Se trata un poco de la adaptación de la filosofía de la calidad total o de las llamadas 'retrospectivas' usadas en enfoques agile como Scrum.

No es oro todo lo que reluce

En cierto modo, en estas reglas de oro que propone Osmani, observamos muchas dosis de revisión,  intervención humana y aplicación de buenas prácticas de ingeniería de software tradicional.

¿Por qué?

Pues porque aunque no sabemos a dónde puede llegar el 'vibe coding', en la actualidad, y pese a los extraordinarios avances y aportaciones, y pese a lo que ya aporta en el proceso de desarrollo de software, todavía no te puedes fiar, en muchos sentidos, del código generado por la IA, y es preciso revisar, probar y mejorar el proceso.

En algún post futuro, comentaré algunas de estas limitaciones actuales.

Conclusiones

El 'vibe coding' permite, de forma muy sencilla, obtener código generado por inteligencia artificial. Sin embargo, en este momento no es mágico, y de cara a una creación de sofware efectiva y de calidad, es preciso aplicar ciertas pautas metodológicas y ciertas buenas prácticas procedentes muchas de ellas de la propia ingeniería de software tradicional o de la ingeniería de instrucciones ('prompt engineering') 

Artículos de este blog relacionados

• Conociendo el 'Vibe coding'