07 de marzo de 2026
Dedicándome a la tecnología, trabajando con software y manteniendo un blog donde me gusta escribir y lo hago menos de lo que me gustaría, resulta casi imposible no hablar de la Inteligencia Artificial. Durante el último año, la IA ha pasado de ser casi ciencia ficción a inundarlo todo.
Este post, más largo de lo habitual, nace de una necesidad personal: la de poner en orden mis propias notas, investigaciones y aprendizajes. Al final, escribir es la mejor forma que conozco de estructurar las ideas y separar el grano de la paja. Mi intención con esta serie no es venderte la última herramienta de moda, sino bajar a tierra lo que está pasando y cómo podemos entender esta tecnología sin que nos explote la cabeza.
A veces parece que hay una especie de "niebla" mental sobre la IA. Parece que estamos ante un oráculo o un cerebro consciente. Lo que veíamos en las películas se ha hecho realidad, y tenemos entre nosotros un Skynet o HAL de verdad. Pero si abrimos el capó y miramos los engranajes, la realidad es mucho más terrenal.
En esencia, la IA es software diseñado para imitar capacidades humanas, pero con una diferencia fundamental respecto al desarrollo tradicional. Si un programa clásico es una receta rígida donde yo, como programador, defino que "si pasa A, haz B", la IA es un aprendiz de patrones. No necesita que le dé todas las reglas por escrito; ella misma encuentra las regularidades en los datos. Pero ojo, no "piensa". Es pura estadística aplicada a una escala masiva.
Algo que solemos ignorar es que las redes neuronales no son una novedad de hace dos años. La idea de imitar las conexiones sinápticas para procesar datos es una teoría que ya se manejaba en los años 50. Entonces, ¿por qué no tuvimos este "boom" hace décadas?
Para que estas redes neuronales "despertaran", han necesitado dos ingredientes que solo coinciden ahora:
Los modelos de lenguaje que usamos hoy son redes neuronales gigantescas entrenadas para una sola tarea: adivinar la siguiente palabra.
Hasta hace nada, la IA se dedicaba a clasificar: te decía si un correo era spam o si en una foto aparecía un gato. Era IA discriminativa. Lo que ha cambiado las reglas del juego es la IA Generativa.
Como su nombre indica, su superpoder es crear contenido nuevo. Ha pasado de organizar carpetas a ser capaz de redactar un texto, generar una imagen desde cero o, lo que a muchos nos interesa, escribir una función de código que funciona a la primera. No es que "sepa" lo que hace, es que sabe qué palabra o píxel tiene más probabilidades de ir después del anterior.
Imagina que quieres enseñarle a un niño a distinguir entre un perro y un gato. No le das un manual de 500 páginas sobre anatomía felina; simplemente ve un perro y le dices: "Esto es un perro", ve un gato y le dices "Esto es un gato". Aprende por repetición y asociación.
Con la IA pasa exactamente lo mismo:
Aquí entra un tema que me parece clave para entender por qué a veces nos frustramos con estas herramientas. En los años 60, Joseph Weizenbaum creó ELIZA, un chatbot básico que imitaba a un terapeuta. Weizenbaum lo programó para imitar a un terapeuta rogeriano (una técnica de psicología que consiste en devolverle al paciente sus propias palabras).
Se quedó horrorizado al ver que la gente se abría emocionalmente con la máquina, creyendo que los entendía.
Tenemos una tendencia innata a humanizar la tecnología (antropomorfismo). Si algo nos responde con lenguaje fluido, nuestro cerebro asume que "hay alguien ahí". Nos enfadamos con el chat o le hablamos con rodeos. El problema es que, al tratarla como a un humano, perdemos la especificidad operativa. Olvidamos que estamos ante una herramienta de cálculo y no ante un oráculo.
Para sacarle partido de verdad a la IA, el primer paso es romper ese espejo: menos charla y más instrucciones precisas. No pienses que "entiende" tu problema, cuando en realidad sólo está haciendo estadística avanzada para darte la respuesta más probable. Entender esto es la clave para saber como sacarle partido, tratándola como lo que es: una herramienta.
En el post anterior hablábamos de que la IA no es magia, sino computación y patrones. Pero para movernos con soltura en este ecosistema y, sobre todo, para no frustrarnos cuando las cosas no salen como esperamos, necesitamos hablar el mismo idioma que la máquina.
Para manejar la IA con criterio, no basta con saber qué botones pulsar. Necesitas entender los mecanismos que definen su comportamiento. Si ignoras estos conceptos, estarás usando la herramienta a ciegas.
La IA no procesa palabras completas como nosotros; trocea el texto en tokens. Un token puede ser una palabra corta, una sílaba o incluso un signo de puntuación.
¿Por qué te importa? Porque todo en este mundo se mide en tokens: desde la capacidad de respuesta hasta lo que te cobran por las APIs. Si entiendes que la IA "trocea" la información, entenderás por qué a veces le cuesta tanto contar letras de una palabra o hacer rimas perfectas: ella no ve letras individuales, ve bloques de datos.
Este es, probablemente, el concepto más crítico. La Ventana de Contexto es la "memoria de trabajo" o la capacidad de atención de la IA en una sola sesión. Imagina que es una mesa de escritorio: cuando la mesa se llena, para poner un papel nuevo tienes que tirar uno de los que ya estaban.
El peligro del truncamiento: Si le pasas un PDF de 200 páginas a una IA que solo tiene capacidad para 50, la IA no te avisará de que no llega. Simplemente cortará el texto sobrante. Tú creerás que ha analizado todo el archivo, pero la información del final (donde quizás estaba la conclusión o la cláusula clave) será invisible para ella.
La pérdida en el medio: Incluso si el texto cabe, se ha demostrado que la IA recuerda mejor el principio y el final de lo que lee. Los detalles que quedan enterrados en el centro del documento suelen diluirse.
Si la Ventana de Contexto es nuestra "mesa de trabajo", los Embeddings son el sistema de archivado inteligente que nos permite no saturarla.
Para que una IA entienda la relación entre las ideas, utiliza estos "embeddings": una lista de números (vectores) que sitúa cada frase en un mapa gigante de miles de dimensiones. Para entenderlo como desarrolladores, bajémoslo a un ejemplo de solo 3 coordenadas: [¿Es software?, ¿Es una base de datos?, ¿Es un animal?]
[0.9, 0.9, 0.0] (Mucho software, mucha DB, nada animal).[0.9, 0.8, 0.0] (Coordenadas casi idénticas; están "pegados" en el mapa).[0.0, 0.0, 0.9] (Vive en un barrio matemático totalmente distinto).¿Por qué te importa esto en la práctica? Piensa en cuando subes un PDF a una IA. La IA no "lee" las 200 páginas cada vez que le preguntas algo. Lo que hace es:
Es la base de lo que llamamos RAG: buscar por "sentido común" matemático para ahorrar tokens y ganar precisión.
La IA Generativa es una máquina de predecir la siguiente palabra más probable. No tiene una base de datos de "verdades".
El riesgo: Como está diseñada para ser coherente y elocuente, cuando no sabe algo, "rellena" el vacío con información que suena muy profesional pero que es falsa. No te miente por maldad; simplemente está cumpliendo su función de completar texto basándose en patrones.
Mi consejo: Nunca la uses como fuente primaria para datos biográficos, leyes o fechas. Úsala para procesar datos que tú le entregues, no para que ella te los traiga de fuera.
Seguro que has oído que X modelo tiene "billones de parámetros". Un parámetro es, básicamente, una conexión ajustable en la red neuronal (como los cables en un cuadro de conexiones).
Más parámetros suelen significar más matices, mejor comprensión de la ironía y más "sabiduría" generalista.
Sin embargo, un modelo con menos parámetros pero mejor entrenado (con datos de mayor calidad) puede ser mucho más eficaz para tareas específicas, como programar, y además será mucho más rápido y barato.
Aunque a veces está oculto en la interfaz, la mayoría de los modelos tienen un ajuste de Temperatura.
Temperatura baja (Cercana a 0): La IA es conservadora y previsible. Es el modo "ingeniero": ideal para código, resúmenes técnicos o datos.
Temperatura alta (Cercana a 1): La IA se arriesga más, elige palabras menos probables. Es el modo "creativo": ideal para lluvia de ideas o escribir ficción.
Seguramente has probado herramientas como NotebookLM o le has subido un PDF a ChatGPT y te has sorprendido: de repente, la IA sabe todo sobre ese documento técnico de 50 páginas y sus respuestas se "acotan" estrictamente a lo que pone ahí. No se inventa cosas de internet, se centra en tus datos.
¿Cómo es posible? ¿Ha "estudiado" la IA tu documento y se lo ha aprendido para siempre? No. Lo que estás viendo en acción es una técnica llamada **RAG (Retrieval-Augmented Generation
Para entender el RAG, olvida la idea de que la IA "aprende". Imagina que la IA es un profesor superdotado que sabe de todo, pero al que le pides que haga un examen sobre un proyecto tuyo que él nunca ha visto.
Sin RAG (Entrenamiento): Sería como obligar al profesor a memorizar tu proyecto antes del examen. Es costoso, lento y, si mañana cambias una frase del proyecto, el profesor ya tiene información obsoleta en su cabeza.
Con RAG: Es como si el profesor fuera al examen con tus apuntes en la mano. No necesita memorizarlos; simplemente, cuando le haces una pregunta, él busca rápidamente en los apuntes, lee el párrafo relevante y te responde usando su inteligencia pero basándose solo en lo que pone el papel.
Cuando subes ese PDF, el sistema hace tres cosas en milisegundos:
Recuperación (Retrieval): Gracias a los Embeddings (los "carnets de identidad numéricos" que vimos antes), el sistema sabe qué párrafos de tu PDF están matemáticamente cerca de tu pregunta. Si preguntas por el "presupuesto", el sistema localiza instantáneamente la página donde están las cifras.
Aumento (Augmentation): El sistema coge esos párrafos y los "pega" en un prompt invisible para ti que dice: "Aquí tienes estos fragmentos de texto. Úsalos como única fuente de verdad".
Generación (Generation): La IA redacta la respuesta. Sigue usando su "cerebro" (su entrenamiento previo) para entender el lenguaje y redactar bien, pero los datos los saca exclusivamente de los fragmentos que le acabas de pasar.
Te habrás fijado en que si le preguntas a NotebookLM algo que no está en tus archivos, a veces te dice: "No puedo responder porque esa información no aparece en los documentos".
Esto no es porque la IA se haya vuelto "tonta" o haya olvidado lo que sabía. Es porque el sistema RAG tiene una instrucción de seguridad muy estricta: priorizar siempre el libro que tiene abierto. Esto es lo que nos da la seguridad de que la IA no va a "alucinar" o inventarse datos basándose en información genérica de internet.
Si has seguido los posts anteriores, ya tienes claro que la IA no es un oráculo, sino un procesador de patrones. Pero aquí es donde la cosa se pone interesante: ¿Cómo es posible que un "Modelo de Lenguaje" (LLM) sea capaz de escribir una función en Python, diseñar un mapa web en Leaflet o generar una imagen de un astronauta a caballo?
La respuesta corta es que, para una IA, todo es lenguaje. Pero vamos a desglosarlo un poco mejor, porque entender esto es lo que te permite pasar de "jugar" con la IA a usarla como una herramienta de ingeniería real.
Para nosotros, programar es crear lógica. Para un LLM, aprender a programar no ha sido muy distinto a aprender inglés o gallego. El código tiene una sintaxis, una gramática y, sobre todo, una estructura previsible.
La IA ha sido entrenada con casi todo el código público que existe (pensemos en el volumen de datos de GitHub). Lo que hace no es "entender" informática, sino entender la secuencia lógica. Sabe que después de un if suele venir una condición y, tras ella, una indentación con una instrucción. Al ser un entorno tan rígido y con reglas tan claras, a la IA le resulta más fácil ser precisa programando que escribiendo poesía.
No es que unos sean "más listos" que otros, es una cuestión de dieta de datos.
Los generalistas: Han leído de todo, incluyendo tutoriales obsoletos y código basura de foros olvidados. Por eso a veces te sugieren soluciones que "huelen" a 2010.
Los especialistas (Fine-tuning): Son modelos que han pasado por un "posgrado". Se les ha entrenado específicamente con repositorios de alta calidad y se les ha refinado mediante humanos que les dicen: "Esta solución funciona, pero esta otra es más eficiente y segura". Es la diferencia entre un aprendiz y un senior.
Aquí es donde ocurre lo que llamamos multimodalidad. Al principio, esto era como un juego de teléfonos descompuestos: tenías un modelo que entendía el texto y le pasaba la orden a otro que generaba la imagen.
Hoy, los modelos más potentes son nativos multimodales. Desde el minuto uno de su entrenamiento, han visto imágenes y han leído sus descripciones simultáneamente. Han aprendido que el concepto lingüístico "atardecer" está vinculado a ciertos patrones de color y degradados de píxeles. Ya no "traducen" de un idioma a otro; entienden el mundo en ambos formatos de forma nativa.
Seguro que has visto esas imágenes con manos de seis dedos. Esto explica perfectamente por qué la IA no tiene un modelo mental de la realidad. Ella no sabe qué es una "mano" ni para qué sirve; solo sabe que en las fotos etiquetadas como "mano" suele haber formas alargadas de color carne. Si estadísticamente el patrón es confuso, el resultado visual también lo será.
A veces te encuentras con modelos que parecen un rayo y otros que escriben a paso de tortuga. Esto depende del número de parámetros (el tamaño del "cerebro") y del hardware que tengan detrás.
Modelos Flash/Mini: Pocos parámetros, muy rápidos, ideales para tareas sencillas.
Modelos de razonamiento: Son deliberadamente más lentos porque están programados para "pensar antes de hablar", verificando sus propios pasos lógicos internamente.
Entender que la IA es un motor de razonamiento estadístico cambia la forma en la que le pides las cosas. Si le pides código, dale la estructura. Si le pides una imagen, describe los patrones. No estás hablando con un artista ni con un colega senior; estás interactuando con un traductor universal de patrones que es tan bueno como la información con la que lo alimentas.
Si has llegado hasta aquí, ya sabes que la IA no te "entiende" en el sentido humano de la palabra; lo que hace es procesar una instrucción y calcular la respuesta más probable basándose en su entrenamiento. Por eso, el "arte" de dar instrucciones (que algunos llaman pomposamente Prompt Engineering) no consiste en ser educado, sino en ser meticuloso.
En mi día a día con el código o los mapas, si una consulta SQL no devuelve lo que quiero, no me enfado con la base de datos; reviso la sintaxis. Con la IA hay que aplicar la misma mentalidad.
El mayor error es tratar el chat como una charla de café. Escribir "Oye, ¿sería posible que quizás me ayudaras a resumir esto si no es mucha molestia?" solo añade ruido innecesario a la ventana de contexto.
La IA no necesita cortesía, necesita parámetros. Pasa de la "charla" a la instrucción operativa. Sé directo. Usa verbos de acción: "Resume", "Analiza", "Escribe", "Extrae".
Para que una instrucción sea robusta, yo suelo usar una estructura de tres capas:
Rol (¿Quién eres?): Dile a la IA cómo debe comportarse. No es lo mismo pedirle algo a un "asistente genérico" que a un "ingeniero senior experto en PostgreSQL". Definir el rol acota el "espacio" de donde la IA sacará la información.
Contexto y Tarea (¿Qué hacemos?): Sé específico. En lugar de "haz un resumen", usa "resume los 3 puntos clave de este texto técnico para un cliente que no sabe de tecnología".
Formato de salida (¿Cómo lo quiero?): Define el output. ¿Quieres un JSON? ¿Una tabla Markdown? ¿Un párrafo de 50 palabras? Si no lo defines, la IA elegirá por ti, y probablemente no sea lo que necesitas.
Como vimos en el post anterior, algunos modelos programan mejor porque "piensan" antes de hablar. Tú puedes forzar ese comportamiento en cualquier modelo usando una técnica sencilla: pídele que razone paso a paso.
Si le lanzas un problema complejo de golpe, es más fácil que alucine. Si le dices: "Analiza el problema, desglósalo en pasos lógicos y, finalmente, dame la solución", la probabilidad de éxito aumenta drásticamente. Estás obligando a la red neuronal a seguir un camino lógico trazable.
A veces, una descripción no basta. Si quieres que la IA escriba con un estilo concreto o clasifique datos de una forma específica, dale ejemplos.
Es la forma más rápida de que la IA capte el patrón que buscas sin tener que escribir un manual de instrucciones infinito que sature los tokens de la sesión.
En el desarrollo de software, raramente algo funciona a la primera versión. Con el prompting es igual.
Dominar el prompting no es aprenderse "fórmulas mágicas", es aprender a comunicarte con una máquina de forma estructurada. Es, en esencia, volver a ser un poco artesano de la palabra para obtener resultados de ingeniería.
Si eres de los que, como yo, empezó usando la IA solo para preguntarle cómo centrar un div o para que te explicara una función compleja de PostgreSQL, tengo que decirte que te estás quedando en la superficie. En los últimos meses, el ecosistema ha dado un salto gigante: hemos pasado de "hablar con la IA" a "integrar la IA en nuestro entorno de desarrollo".
Como ingeniero, siempre busco soluciones que resuelvan problemas reales. Y aquí el problema real es la fricción: copiar código del chat, pegarlo en el editor, ver que falla porque la IA no conoce mi base de datos, y volver a empezar. Para resolver esto, han aparecido tres conceptos clave: Agentes, Skills y el protocolo MCP.
Un chat normal es pasivo: tú preguntas, él responde. Un Agente es un modelo de lenguaje al que le hemos dado un objetivo y autonomía para usar herramientas.
Diferencia clave: Si le pides a un chat "arregla este bug", te dará el código. Si se lo pides a un Agente, él leerá el archivo, ejecutará el código para ver el error, buscará una solución y aplicará el parche.
En resumen: Es un LLM que puede ejecutar un ciclo de: Pensar -> Actuar -> Observar el resultado.
Hace poco escribí en el blog sobre cómo conectar PostgreSQL a un agente de IA mediante MCP (Model Context Protocol).
¿Qué es? Es un estándar abierto que permite que cualquier IA se conecte de forma segura a tus datos locales.
¿Para qué sirve? En lugar de copiar y pegar el esquema de tu base de datos en el chat (con el riesgo de seguridad y el gasto de tokens que eso supone), el agente "habla" directamente con tu base de datos a través de MCP.
Los MCP son, en esencia, canales de comunicación entre los modelos de IA y herramientas externas.
Una de las dudas más comunes es cómo "aprende" la IA a hacer cosas nuevas. Las Skills (o herramientas) no son algo que la IA traiga de serie (aunque algunas sí) por "saber mucho", sino funciones que tú, como desarrollador, tienes que habilitar o programar.
Podemos dividirlas en tres niveles según su origen:
Muchas herramientas de IA (como ChatGPT, Claude o Gemini) ya traen herramientas de serie. Por ejemplo, el acceso a internet, la ejecución de código Python en un entorno seguro (Code Interpreter) o la generación de imágenes.
Aquí es donde entra lo que comentábamos del MCP. Existe ya un ecosistema de servidores MCP creados por la comunidad.
Cómo se instalan: Es muy parecido a instalar una dependencia en un proyecto. Te descargas un servidor MCP ya hecho (por ejemplo, uno para Google Drive, otro para Slack o el de PostgreSQL que mencioné en mi post ).
Configuración: Simplemente editas un archivo de configuración en tu entorno (como el claude_desktop_config.json) y le dices dónde está ese servidor. A partir de ese momento, la IA "ve" esa nueva habilidad.
Los MCP dotan a los modelos de IA de nuevas Skills.
Si necesitas que la IA haga algo muy específico de tu flujo de trabajo (por ejemplo, "publicar este borrador en mi blog de Hugo"), tienes que crear la Skill tú mismo.
Cómo se hacen: No es más que una función en Python o TypeScript.
El "Contrato": Lo más importante no es solo el código, sino la descripción. Tienes que escribir un pequeño texto explicando a la IA para qué sirve esa función y qué parámetros necesita. La IA lee esa descripción y, cuando ve que tu petición encaja, "llama" a tu función.
Imagina que estás trabajando en un mapa con Leaflet. Quieres añadir marcadores desde una base de datos:
mapa.js".Tú solo dices: "Añade al mapa los puntos de la tabla 'eventos' de mi base de datos". El Agente usa el MCP para consultar la tabla, procesa los datos y usa su Skill de escritura para actualizar tu código.
.md y ficheros de configuraciónSi estamos tratando de ser meticulosos y evitar la "charla" innecesaria, no tiene sentido repetirle nuestras preferencias a la IA en cada nuevo chat. Aquí es donde entran los archivos de configuración de contexto, como los ai.md, agents.md o los .cursorrules.
¿Qué son? Son archivos de texto plano que colocas en la raíz de tu proyecto. En ellos defines las reglas del juego: qué librerías prefieres (por ejemplo, Leaflet sobre OpenLayers ), cómo quieres que se estructure el código o qué estándares de seguridad debe seguir.
Instrucciones del modelo (System Prompts): Muchos modelos permiten ahora adjuntar un archivo de "instrucciones personalizadas". En lugar de un prompt efímero, es un contrato permanente. Si en mi blog hablo de usar PostgreSQL con MCP, en mi archivo de agente definiré que siempre que consulte la base de datos, use ese protocolo específico.
La ventaja técnica: Al tener estas instrucciones en un fichero .md, puedes versionarlas con Git. Si cambias tu forma de trabajar o añades una nueva Skill a tu flujo, el Agente se actualiza automáticamente al leer el archivo.
A estas alturas de la guía, ya tienes el entorno configurado y sabes cómo dar instrucciones. Pero te falta lo más importante para el día a día: saber qué modelo elegir. Hoy en día no hay una sola "IA"; hay un catálogo creciente de modelos con especialidades muy distintas.
Si intentas resolver un problema de lógica compleja con un modelo rápido, te dará una respuesta errónea con mucha seguridad. Si usas un modelo pesado para corregir una falta de ortografía, estás matando moscas a cañonazos. Vamos a poner orden en este ecosistema.
Estos son los modelos "lentos" por diseño (como la serie o1 o los nuevos modelos de pensamiento profundo). Su característica principal es que utilizan una cadena de pensamiento interna antes de escribir la primera palabra.
Cuándo usarlos: Problemas de lógica pura, matemáticas, arquitectura de software compleja o cuando necesitas que la IA verifique su propia respuesta varias veces.
La clave: Úsalos cuando el "qué" es difícil de resolver y requiere un plan previo. No esperes velocidad; espera acierto.
Aunque los generalistas programan bien, existen versiones optimizadas para el código (como los que alimentan a Cursor o versiones específicas "Coder"). Estos modelos han tenido una dieta de entrenamiento basada en repositorios de alta calidad y entienden mejor la jerarquía de un proyecto.
Cuándo usarlos: Para refactorizar código, crear tests unitarios o entender cómo una función en db.py afecta a tu mapa en index.html.
El consejo: Úsalos dentro de tu IDE. Son modelos que brillan cuando tienen acceso a tu sistema de archivos.
Son los modelos pequeños (como GPT-4o-mini, Claude Haiku o Gemini Flash). Tienen menos parámetros, lo que los hace increíblemente rápidos y económicos en términos de tokens.
Cuándo usarlos: Tareas mecánicas o de bajo razonamiento. Traducir un texto, resumir un hilo de emails, formatear un JSON o cambiar el tono de un párrafo.
La ventaja: Su latencia es mínima. En el tiempo que un modelo de razonamiento empieza a "pensar", este ya ha terminado la tarea.
Hay modelos específicos que destacan por tener una Ventana de Contexto gigantesca (capaces de leer libros enteros o repositorios completos de una vez).
Cuándo usarlos: Cuando tienes que analizar una documentación técnica de 500 páginas, buscar un bug en un proyecto antiguo con cientos de archivos o cruzar datos de múltiples fuentes.
Ojo con: "Lost in the middle". Aunque puedan leer mucho, recuerda lo que vimos en el Capítulo 2: si el dato importante está en la mitad del texto, es mejor usar un modelo de razonamiento para asegurar que no se le pase por alto.
Después de haber desgranado desde qué es un token hasta cómo orquestar agentes con MCP, toca hacer una pausa y mirar el mapa completo. Escribir esta serie me ha servido para poner orden a mis investigaciones, pero sobre todo para reafirmar algunas convicciones sobre cómo debemos afrontar este cambio quienes nos dedicamos a la tecnología.
Estas son mis conclusiones tras meses de "cacharrreo", pruebas y algún que otro error de concepto:
No basta con saber qué botones pulsar. Entender cómo funciona la IA por dentro, su naturaleza estadística, sus límites de contexto y por qué alucina, es lo que marca la diferencia entre quien se frustra y quien sabe trabajar con ella. Como en cualquier otra rama de la ingeniería, conocer los cimientos te permite construir estructuras mucho más sólidas. Si sabes por qué la IA se equivoca, sabrás cómo corregir la instrucción para que no vuelva a suceder.
Lo que hoy nos parece revolucionario, como el Model Context Protocol (MCP) que os comentaba hace unos días, probablemente sea solo el estándar básico de mañana. Estamos en una fase muy temprana de esta tecnología.
Si algo me preocupa de este "boom" es la tendencia a quedarnos atrapados en un solo ecosistema. Ahora más que nunca, es vital huir del vendor lock-in.
Usa modelos diferentes según la tarea: razonamiento para la lógica, modelos flash para la velocidad y modelos de código para el desarrollo.
Prioriza opciones que te permitan saltar entre proveedores. Herramientas como OpenRouter u OpenCode Zen, o incluso el uso de modelos Open Source en local no son solo una cuestión de preferencia técnica; son una cuestión de soberanía tecnológica. En un mundo donde los modelos cambian de la noche a la mañana, tener el control de tus fuentes de inteligencia es fundamental.
La IA no ha venido a sustituir nuestra capacidad de pensar, sino a amplificar nuestra capacidad de hacer. Seguimos siendo artesanos e ingenieros de la tecnología , y nuestra labor sigue siendo la misma: resolver problemas reales con las mejores herramientas a nuestro alcance. La IA es solo un nuevo martillo, muy potente, pero que requiere una mano experta que sepa dónde golpear.
Espero que esta guía te haya servido para despejar un poco la niebla y empezar a usar estas herramientas con más criterio y menos miedo. Nos vemos en los próximos posts, seguramente probando alguna nueva "skill" o integrando mapas en algún flujo de trabajo que hoy ni siquiera imaginamos.