Los Sistemas de Información Geográfica (SIG) son herramientas increíblemente potentes, pero también complejas. QGIS es probablemente el SIG de escritorio de software libre más completo y usado del mundo, pero su interfaz tiene una curva de aprendizaje pronunciada. Y aunque sepas usarlo bien, muchas tareas son repetitivas (cargar capas, aplicar estilos, configurar layouts).

¿Y si pudieras decirle a un agente de IA lo que quieres hacer y que lo ejecute directamente sobre QGIS? Sin arrastrar capas, sin buscar el botón correcto, sin recordar dónde está cada opción.

Eso es exactamente lo que permite el MCP de QGIS.

Pero como todo lo que merece la pena, la configuración no siempre sale a la primera. En este artículo te explico qué es MCP, cómo se conecta con QGIS con un agente de IA (OpenCode), la configuración paso a paso, problemas reales que me encontré al hacerlo funcionar, y ejemplos prácticos para sacarle partido.

¿Qué es MCP?

MCP (Model Context Protocol) es un protocolo abierto que permite a modelos de lenguaje (LLMs) interactuar con herramientas y sistemas externos de forma estructurada y segura.

Piénsalo como un USB para la IA: igual que el USB estandarizó la conexión de periféricos al ordenador, MCP estandariza la conexión de la IA con el mundo exterior: bases de datos, APIs, sistemas de archivos y, en este caso, QGIS.

Sin MCP, si le pides a una IA que "cargue un shapefile y lo pinte con un gradiente", lo máximo que puede hacer es generarte el código Python y decirte "copia esto en la consola de QGIS". Con MCP, la IA ejecuta las acciones directamente sobre QGIS.

El flujo es sencillo:

1. Haces una petición en lenguaje natural: "Carga la capa de municipios y coloréalos por población"
2. OpenCode envía la petición al modelo
3. El modelo decide qué herramientas del MCP de QGIS necesita usar
4. Las ejecuta directamente sobre tu QGIS abierto
5. El resultado aparece al instante en tu mapa

Cómo funciona el MCP de QGIS

Arquitectura

Antes de pasar a la configuración, conviene entender cómo se conectan las piezas:

opencode ←→ MCP Server (stdio/HTTP) ←→ TCP :9876 ←→ Plugin QGIS ←→ PyQGIS

El plugin QGIS MCP (github.com/nkarasiak/qgis-mcp) de nkarasiak expone más de 100 herramientas de QGIS a través del protocolo MCP. Pero ojo: el plugin no habla MCP directamente. Tiene un socket TCP interno en el puerto 9876 que solo entiende comandos JSON con un formato propio. Para que opencode (o cualquier cliente MCP) pueda hablar con él, hace falta un MCP Server intermedio que traduzca el protocolo MCP a los comandos que el plugin entiende.

Ese servidor intermedio se ejecuta con uvx y es el que realmente configuraremos en opencode.

Herramientas disponibles

El MCP de QGIS expone las funcionalidades del SIG como herramientas que el agente IA puede invocar. Cada herramienta hace una operación específica:

Hay más de 100 herramientas disponibles. La lista completa cambia con cada versión, pero cubre prácticamente todo lo que harías manualmente en QGIS.

Configuración paso a paso

1. Pre-requisitos

Necesitas tres cosas:

• QGIS instalado (cualquier versión reciente vale, incluida la 4)
• QGIS MCP Plugin instalado en QGIS
• OpenCode instalado
• uv instalado (lo usa uvx para ejecutar el MCP Server sin instalar nada)

2. Instalar el plugin en QGIS

El plugin se llama QGIS MCP. Lo instalas desde el menú de QGIS:

Complementos → Gestionar e instalar complementos... → Buscar "QGIS MCP" → Instalar

Una vez instalado, lo activas desde el menú MCP → Start Server. El plugin se queda escuchando en un socket TCP interno en el puerto 9876.

Puedes comprobar que está vivo:

curl -X POST http://localhost:9876/ -H "Content-Type: application/json" -d '{"action":"ping"}'

3. Configurar OpenCode

Aquí es donde la mayoría de la documentación existente se queda corta. El plugin de QGIS no expone un servidor MCP directamente — solo entiende comandos JSON sobre un socket TCP. Necesitamos un proceso intermedio que haga de traductor.

OpenCode se configura en ~/.config/opencode/opencode.jsonc (o en un opencode.jsonc en la raíz de tu proyecto):

{
  "mcpServers": {
    "qgis": {
      "type": "local",
      "command": [
        "uvx",
        "--from",
        "https://github.com/nkarasiak/qgis-mcp/archive/refs/heads/main.zip",
        "qgis-mcp-server",
      ],
    },
  },
}

Con type: "local", opencode lanza el MCP Server como un subproceso cada vez que arranca. El servidor se comunica con el plugin de QGIS a través del puerto 9876 y expone todas las herramientas a opencode vía MCP.

4. Verificar la conexión

Arranca OpenCode en cualquier directorio:

opencode

Si todo funciona, verás el servidor MCP de QGIS en el panel de herramientas de opencode, listo para aceptar comandos.

Problemas y soluciones

Hasta aquí la teoría. Ahora la práctica, con los problemas reales con los que me topé.

Antes de entrar en cada problema, conviene aclarar: el plugin QGIS MCP está bien documentado. Su README en GitHub incluye la configuración correcta para opencode y para otras herramientas (Claude Code, Codex CLI, Gemini CLI, Cursor, etc.). Los problemas que encontré no fueron por documentación incorrecta, sino por dos cosas:

1. La arquitectura no es evidente hasta que la ves. El plugin tiene dos componentes: un proceso dentro de QGIS (socket TCP) y un servidor MCP externo (uvx). Si no sabes que existe esa separación, es fácil asumir que el plugin expone MCP directamente y configurarlo mal.
2. El README asume que el lector conoce uvx. La compilación de dependencias nativas en la primera ejecución no se menciona, y el timeout de opencode (30s) no es suficiente para ese arranque inicial.

Dicho esto, van los problemas.

Problema 1: Conectar al puerto equivocado

Si ya sabes cómo configurar servidores MCP puede que vayas directamente a opencode y lo hagas con type: "url" apuntando a http://localhost:9876, asumiendo que el plugin de QGIS habla MCP directamente. Pero no: el plugin solo entiende comandos JSON sobre un socket TCP, no el protocolo MCP. Es como intentar hablar HTTP contra un servidor que solo entiende el protocolo de Redis. El plugin viene con un configurador para diferentes agentes, incluido opencode.

Solución:
Usar type: "local" con uvx como se muestra en la configuración de arriba. El qgis-mcp-server es el proceso intermedio que traduce de MCP a los comandos JSON que el plugin entiende. O, alternativamente, tener el servidor HTTP ejecutándose de forma persistente (lo explico al final de esta sección).

Problema 2: Timeout en la primera ejecución

La primera vez que opencode ejecuta uvx --from https://github.com/nkarasiak/qgis-mcp/archive/refs/heads/main.zip qgis-mcp-server, uvx descarga el código y compila dependencias nativas como cryptography. Esta compilación puede superar los 30 segundos, que es el timeout que opencode tiene por defecto para la inicialización de servidores MCP.

Solución:
Ejecutar el comando manualmente una vez antes de arrancar opencode, para que uvx descargue y compile todo y lo deje en caché:

uvx --from https://github.com/nkarasiak/qgis-mcp/archive/refs/heads/main.zip qgis-mcp-server

La primera ejecución puede llevar más de un minuto. Las siguientes serán casi instantáneas.

Si aún así quieres más margen, opencode permite configurar el timeout por servidor MCP:

{
  "mcpServers": {
    "qgis": {
      "type": "local",
      "timeout": 120000,
      "command": [
        "uvx",
        "--from",
        "https://github.com/nkarasiak/qgis-mcp/archive/refs/heads/main.zip",
        "qgis-mcp-server",
      ],
    },
  },
}

Ejemplos prácticos

Cargar y visualizar datos

Pídele que cargue archivos directamente desde tu ordenador y los deje listos para trabajar:

Carga el fichero municipios.gpkg que está en mi escritorio, nómbralo "Municipios" y aplícale un estilo graduado por el campo poblacion usando 5 clases con la rampa de color Viridis.

Añade un fondo OSM con el servicio XYZ.

En segundos tienes la capa en QGIS con el estilo aplicado. Sin ir a buscar el archivo en el navegador de capas, sin acordarte de dónde está el estilo graduado.

Manipular datos

Puedes crear campos nuevos, hacer consultas, filtrar, etc. todo en lenguaje natural:

En la capa Municipios, calcula la densidad de población en un nuevo campo llamado densidad.

¿Cuántos municipios tienen más de 50000 habitantes? Dame los nombres.

El agente consulta los datos, los procesa y te responde con la información. No necesitas saber SQL ni recordar la sintaxis de la calculadora de campos.

Análisis espacial

Las operaciones que antes requerían varios clics en el menú Processing ahora se resuelven con una frase:

Haz una unión espacial entre la capa de municipios y la de estaciones meteorológicas, para que cada municipio tenga el nombre de la estación más cercana.

Calcula la altitud media de cada municipio a partir del raster MDT05 y crea un campo nuevo con esos valores.

Crear mapas y layouts

Le dices cómo quieres el mapa y él lo monta:

Crea un layout llamado "Mapa General", tamaño A4 horizontal. Añade un mapa que ocupe toda la página, una leyenda y una barra de escala. Luego expórtalo como PNG.

Configura un atlas con la capa Municipios. Cada página debe mostrar un municipio. Exporta el atlas como PDF.

Trabajar con el proyecto

También puedes gestionar el proyecto al vuelo:

Guarda el proyecto actual como "analisis.qgz" en el escritorio.

¿Qué capas tengo cargadas ahora mismo en el proyecto?

Limitaciones y consideraciones

No es mágico

El MCP de QGIS es tan potente como el modelo que tengas detrás. Los modelos más capaces (Gemini, Claude, GPT-4) entienden bien el contexto geoespacial y saben qué herramienta llamar en cada caso. Los modelos más pequeños pueden confundir herramientas o necesitar prompts más explícitos. Puedes apoyarte en skills o ficheros de memoria de contexto para ayudarles.

Mapas para imprimir

Usar herramientas de procesado es relativamente sencillo para un LLM, incluso si le pides que cree estilos suele ser bastante eficiente. Pero conseguir que te haga un mapa profesional para imprimir ya es otra cosa.

Pueden trabajar con el layout de mapas, pero conseguir que de primeras hagan un buen diseño no es fácil, aquí es donde está más verde. Necesitarás instrucciones detalladas, un buen modelo e incluso crear skills de diseño si quieres conseguir mapas que puedas considerar como versiones finales.

Necesitas QGIS abierto

El plugin MCP de QGIS actúa como servidor, pero necesita que QGIS esté ejecutándose. Si cierras QGIS, pierdes la conexión. Puedes tener QGIS minimizado, pero tiene que estar abierto.

Operaciones destructivas

Herramientas como remove_layer o delete_features están disponibles, pero el plugin las trata con cuidado. OpenCode también te pide confirmación antes de ejecutar operaciones que modifican datos. Aun así, es recomendable trabajar sobre copias cuando hagas pruebas.

Latencia

Cada llamada al MCP viaja de OpenCode al modelo, del modelo de vuelta, y luego se ejecuta en QGIS. No es instantáneo. Para operaciones simples (cargar una capa, cambiar estilo) es rápido. Para geoprocesos pesados (uniones espaciales, estadísticas zonales), el tiempo depende de la carga de trabajo.

Conclusión

Esto está empezando a eclosionar. Estamos viendo cómo la IA se integra en herramientas que antes requerían años de práctica: programas de retoque fotográfico, diseño 3D, edición de vídeo… herramientas complejas que ahora empiezan a entenderse sin conocerlas a fondo.

Con los SIG pasa algo parecido, pero con un matiz importante: para ciertas tareas como retocar una foto es fácil saber lo que quieres aunque no seas fotógrafo, y aún así te quedarás en la superficie, comparado con alguien con experiencia en la profesión. Analizar datos geográficos, crear mapas o interpretar resultados requiere formación. La IA no sustituye ese conocimiento, pero sí acelera los procesos: ejecuta operaciones, prueba combinaciones, genera mapas base que luego puedes ajustar.

Yo sigo pensando lo mismo que meses atrás, cuando todo esto empezó a explotar. Estamos ante el mayor avance en el mundo de la informática después del ratón. La IA está cambiando por completo la forma en la que interactuamos con el software, y eso de por sí, ya es una maravilla.

En esta fase inicial, probar está bien. De hecho, es necesario. El mercado se mueve tan rápido que no sabes qué te va a funcionar hasta que lo usas en el día a día. Pero llega un momento en el que tienes que elegir una como base. No para siempre, no de forma exclusiva, pero sí como herramienta principal en la que invertir tiempo en configurar, aprender y construir un flujo de trabajo alrededor.

Este post es mi justificación personal de por qué OpenCode es esa herramienta para mí.

El problema de elegir

Cada herramienta tiene sus ventajas, pero también un coste de aprendizaje. No me refiero solo al dinero, sino al tiempo que dedicas a entender su funcionamiento, ajustarla a tu forma de trabajar y sacarle partido. Ese tiempo es limitado, y si lo repartes entre varias herramientas diferentes, corres el riesgo de no profundizar en ninguna lo suficiente como para que realmente te aporte valor.

Además, cada vez que cambias de herramienta, pierdes parte de lo acumulado: los atajos de teclado que ya sabías, los ajustes que habías hecho, los flujos que habías optimizado. Empezar de cero con una herramienta nueva no es solo instalarla, es volver a pasar por la curva de aprendizaje hasta que empieza a ser realmente productiva.

En un mercado donde cada semana sale algo nuevo, es fácil caer en el FOMO y estar saltando de una herramienta a otra sin llegar a sacar partido de ninguna. Pero el valor real no está en haber probado muchas herramientas, sino en conocer una bien y haber construido un flujo de trabajo alrededor de ella.

Eso no significa cerrarse a probar cosas nuevas. Significa tener una base sobre la que construir, y a partir de ahí explorar con criterio.

Esta decisión no es tan diferente de las que hemos tomado siempre las personas que nos dedicamos al desarrollo de software al elegir un IDE. Antes era escoger entre VS Code o IntelliJ, y si nos vamos algo más atrás en el tiempo, la guerra Vim o Emacs, y esa decisión definía tu forma de trabajar durante años. La diferencia es que entonces el IDE era una herramienta que comprabas una vez o era gratis, y punto. Ahora la IA viene integrada en el IDE, y con ella llegan las suscripciones mensuales, los límites de uso y los cambios de precio que pueden dejar obsoleta tu configuración de la noche a la mañana. El coste recurrente añade una capa nueva a una decisión que antes era más estable.

Por qué OpenCode

La razón principal es simple: OpenCode es libre. No depende, en exclusiva, de ninguna empresa ni de sus decisiones comerciales. Si mañana OpenAI decide cambiar sus precios, si Anthropic modifica su política de uso, si Cursor elimina el plan gratuito, o los compra alguien, ninguna de esas decisiones afecta a mi capacidad de seguir trabajando con OpenCode. Cambio de proveedor, cambio de modelo, y mi herramienta sigue siendo la misma.

Eso tiene implicaciones prácticas importantes:

• Puedo cambiar de modelo sin cambiar de herramienta. Hoy uso un modelo frontier para tareas que requieren mucho contexto, un modelo específico open-source para codificar, otro para consultas rápidas y baratas. No tengo que adaptarme a un CLI diferente ni aprender otra interfaz.
• Puedo ejecutar modelos locales. Conecto LM Studio, Ollama o el servidor que quiera, y OpenCode habla con él igual que con cualquier API cloud. Ninguna herramienta cerrada te da tanta flexibilidad.
• No hay vendor lock-in. Si un proveedor sube precios o baja calidad, lo cambio sin tocar nada de mi setup. Mi inversión en skills, MCPs y configuración es portable.
• Puedo ver el código, entenderlo y contribuir. No es solo una cuestión ideológica: cuando algo no funciona como espero, puedo mirar el código, saber por qué ocurre y a veces incluso arreglarlo.

Dicho de otro modo: OpenCode es la herramienta que se adapta a mi flujo de trabajo, en lugar de obligarme a adaptar mi flujo de trabajo a ella.

OpenCode en general

Para quien no lo conozca, OpenCode es un agente de IA para desarrollo que se ejecuta en el terminal. Es software libre y está disponible en GitHub. Pero lo que realmente lo diferencia no es solo que sea gratuito, sino cómo está construido.

Arquitectura cliente-servidor

A diferencia de Cursor (atado a su editor) o Claude Code y Codex, con sus aplicaciones específicas, OpenCode separa el servidor del cliente. El servidor gestiona sesiones, proyectos y conexiones con modelos, y los clientes son intercambiables:

• TUI (terminal): la interfaz principal, con navegación por teclado, paneles divididos y una experiencia comparable a un IDE dentro del terminal.
• Interfaz web: opencode web levanta un servidor HTTP con múltiples sesiones visibles a la vez, accesible desde cualquier navegador. Con Tailscale o soluciones similares, puedes conectarte a tu opencode en tu equipo principal desde otros dispositivos, como si estuvieras en local.
• IDE plugin: puede conectarse desde VS Code o cualquier editor que soporte el protocolo.

El resultado es que tienes un único servidor con todas tus sesiones, y puedes conectarte desde donde quieras. Todas comparten el mismo estado.

Agentes

OpenCode tiene dos modos de trabajo que cambian cómo interactúas con el agente, en realidad viene con dos agentes predefinidos:

• Plan Mode: el agente solo explica lo que haría, sin tocar nada. Ideal para tareas complejas donde quieres revisar el enfoque antes de ejecutar.
• Build Mode: el agente ejecuta los cambios directamente.

Cambias entre ellos con TAB, sin comandos ni menús. Si el plan no te convence, ajustas el prompt y vuelves a intentarlo. Si el resultado no es lo que esperabas, /undo revierte los cambios al instante.

Sub-agentes

OpenCode permite definir sub-agentes: instancias especializadas que usan modelos y prompts diferentes para tareas concretas. Puedes tener un agente para revisión de código que use un modelo más lento pero más preciso, otro para scripting rápido con un modelo ligero, otro para documentación. El agente principal delega en ellos según la tarea, todo de forma transparente. Para cada sub-agente puedes definir si tiene permisos de escritura o no, que herramientas puede usar, etc.

A través de la interfaz puedes ir viendo cuáles están trabajando y lo que hacen.

AGENTS.md: contexto que viaja con el proyecto

Cuando ejecutas /init en un proyecto, OpenCode analiza el código y genera un AGENTS.md con la estructura, las tecnologías, las convenciones y los patrones que detecta. Ese archivo se incluye en el contexto del modelo en cada sesión. El resultado es que el agente entiende tu proyecto desde el primer prompt, sin que tengas que explicarle nada.

Sesiones persistentes

Cada proyecto mantiene su historial guardado en SQLite. Puedes retomar una sesión días después y el agente recuerda lo que estabais haciendo. También puedes compartir sesiones con tu equipo mediante /share, que genera un enlace con toda la conversación.

Personalización

Skills, MCPs y system prompts son funcionalidades que OpenCode ofrece igual que otras herramientas, pero con un enfoque abierto: todo se configura con archivos markdown y JSON en ~/.config/opencode/, sin formatos propietarios ni dependencias de servicios externos.

Cómo empezar

La instalación es sencilla y hay varias opciones:

curl -fsSL https://opencode.ai/install | bash
npm install -g opencode-ai
brew install anomalyco/tap/opencode
scoop install opencode
docker run -it --rm ghcr.io/anomalyco/opencode

Una vez instalado, opencode desde tu proyecto arranca el TUI. Con /connect eliges tu proveedor y ya puedes empezar. Si corres /init primero, el agente analizará tu proyecto y generará el AGENTS.md automáticamente.

Gestión de modelos: por qué tener varios

Uno de los aspectos que más valoro de OpenCode es la capacidad de elegir el modelo según la tarea. No uso el mismo modelo para todo, y tener esa flexibilidad cambia completamente la relación coste/beneficio del setup:

• Tareas rápidas y baratas: DeepSeek V4 Flash o Gemma 4 en local para debugging rápido, scripting o preguntas concretas. Casi cero coste, respuesta inmediata.
• Tareas generales de desarrollo: Kimi K2.6,Qwen 3.6 Plus o GML 5 desde OpenCode Go. Cubren el día a día sin preocuparme por el coste.
• Tareas complejas o contexto grande: Gemini 3.1 o Claude Opus desde OpenCode Zen o mi cuenta de Gemini. Solo cuando realmente lo necesito.

Esta granularidad no es posible si tu herramienta te obliga a usar un solo proveedor o un solo modelo. Y el ahorro, tanto en coste como en calidad del resultado, es notable.

Cierre

No estoy diciendo que OpenCode sea la mejor herramienta para todo el mundo. Es importante probar, experimentar y buscar la que te hace tener más comodidad y poductividad en el día a día. Pero está bien mirar un poco más allá de las funcionalidades simplemente y analizar también los modelos que hay detrás, las implicaciones que tiene que las decisiones comerciales de las empresas terminen impactando directamente en tu día a día.

Si valoras la libertad de elegir, la capacidad de adaptar la herramienta a tu flujo de trabajo y no depender de las decisiones comerciales de una empresa, a día de hoy OpenCode es difícil de superar.

En un mercado donde las herramientas de IA cambian cada semana, tener una base libre, flexible y abierta no es un lujo: es una decisión estratégica. Ojalá haya más herramientas que sigan esta filosofía.

Qué es OpenCode Web

OpenCode funciona con una arquitectura cliente-servidor. Cuando abres el TUI en el terminal, estás ejecutando un cliente que se conecta a un servidor local. Ese servidor expone una API HTTP, y OpenCode Web es simplemente otra interfaz para ese mismo servidor.

Para arrancarlo, solo necesitas un comando:

opencode web

Esto levanta un servidor local en un puerto aleatorio y abre el navegador con la interfaz web. Es exactamente la misma experiencia que en terminal: misma sesión, mismos modelos, mismo contexto.

La diferencia está en lo que eso habilita.

Por qué la uso: múltiples proyectos y acceso remoto

La razón principal por la que he empezado a usar OpenCode Web no es estética ni de comodidad en el escritorio. Es la posibilidad de gestionar varios proyectos a la vez desde un único punto.

Cuando trabajas con el TUI en el terminal, cada ventana es un proyecto. Si tienes tres proyectos abiertos, tienes tres terminales, tres pestañas, tres contextos. Con OpenCode Web puedes tener todas las sesiones activas visibles en una sola interfaz, cambiar entre proyectos con un clic y mantener el hilo de cada uno sin perder el contexto.

Pero lo que realmente me hizo empezar a usarla más fue el acceso remoto.

Mi equipo principal es un Mac M1 Pro donde tengo todos mis proyectos, configuraciones, MCPs, skills y recursos. Normalmente trabajo desde ahí. Pero hay situaciones en las que no estoy sentado delante de esa máquina.

Con Tailscale, la herramienta que uso para tener una red privada, me conecto al servidor OpenCode de mi equipo principal desde el navegador de cualquier dispositivo. Abro el iPad, entro en la dirección de Tailscale y tengo acceso a todo: mis sesiones, mis proyectos, mis configuraciones. No es lo mismo que estar delante del terminal principal, pero me ha sacado de más de un apuro.

Configuración básica

Para que esto funcione, necesitas tres cosas:

1. Arrancar OpenCode Web con acceso a la red:

opencode web --hostname 0.0.0.0 --port 4096

El flag --hostname 0.0.0.0 hace que el servidor escuche en todas las interfaces de red, no solo en localhost. Sin esto, solo podrías acceder desde la propia máquina.

2. Proteger el acceso con contraseña:

Si el servidor va a estar accessible por la red, esto es fundamental:

OPENCODE_SERVER_PASSWORD=tu_contraseña opencode web --hostname 0.0.0.0 --port 4096

Por defecto el usuario es opencode, pero puedes cambiarlo con OPENCODE_SERVER_USERNAME. Sin esta protección, cualquiera en tu red podría acceder a tus sesiones y código.

3. Configurar Tailscale (si necesitas acceso remoto):

Tailscale crea una red privada cifrada entre tus dispositivos. Una vez que tu equipo principal y tu iPad o portátil están en la misma Tailnet, puedes acceder al servidor OpenCode como si estuvieras en la misma red local, sin abrir puertos en el router ni configurar nada más.

Lo que no es OpenCode Web

Es importante tener expectativas claras. OpenCode Web no es un reemplazo del TUI para desarrollo intensivo. La interfaz web es más simple, menos pulida y no tiene todas las opciones de navegación por teclado que hace cómodo el terminal. Escribir código largo o hacer tareas complejas en un iPad, por ejemplo, te puede sacar de un apuro, pero no es lo mismo que trabajar con tu setup habitual.

Lo que sí es, y donde realmente aporta, es un punto de acceso ligero. Para revisar el estado de un proyecto, lanzar una tarea al agente, hacer una consulta rápida o continuar un hilo de trabajo que dejaste abierto, funciona perfecto. Y el hecho de poder hacerlo desde cualquier dispositivo con un navegador es una ventaja que el TUI no puede dar por sí solo.

Conclusión

OpenCode Web no es una funcionalidad que necesites si solo trabajas desde tu escritorio y te sientes bien trabajando en la terminal. Pero en el momento en que necesitas flexibilidad, rabajar desde otro dispositivo, acceder a proyectos remotos, o simplemente tener una vista global de todo lo que tienes abierto, se convierte en una pieza clave del setup. También, si quieres tener otra interfaz diferente a un terminal, y poder acceder a varios proyectos a la vez.

Llevo tiempo probando combinaciones de herramientas, modelos y flujos de trabajo. Este artículo es la fotografía de mi setup actual, con la certeza de que dentro de unos meses será diferente, pero también con la convicción de que la estrategia que hay detrás va a mantenerse.

La estrategia: por qué no tengo una sola herramienta

En iCarto tomamos una decisión a la hora de tratar de facilitar la adopción de herramientas de IA: en lugar de comprar una solución de IA corporativa unificada, establecimos un presupuesto individual para que cada persona del equipo explore y decida qué herramientas le funcionan mejor.

Esta decisión tiene una razón de ser. El mercado de la IA se mueve a una velocidad en la que cualquier solución que compres hoy como estándar empresarial puede quedar obsoleta en cuestión de meses. Los modelos, las herramientas y las plataformas evolucionan tan rápido que comprometerse con una única solución ahora mismo es, en mi opinión, un error estratégico. Prefiero que la gente aprenda, experimente y luego compartamos internamente qué funciona y qué no. Este artículo es mi contribución a ese aprendizaje colectivo.

Mi enfoque personal se basa en tres pilares:

1. Una herramienta generalista para el día a día: Gemini, por su versatilidad y ecosistema.
2. Una herramienta especializada para desarrollo: OpenCode, como entorno agéntico donde invierto el tiempo de configuración.
3. Modelos locales para lo que no necesita salir de mi máquina: Gemma 4 y LM Studio, para tareas donde la privacidad importa.

Gemini: el todoterreno de Google

Mi cuenta de Google IA Pro (Gemini) es mi herramienta generalista. No es mi favorita para ninguna tarea concreta, pero es la que mejor cubre el espectro completo cuando no sé por dónde empezar.

Qué hago con Gemini

• Documentación e informes: la generación de texto de Gemini es sólida, pero donde realmente brilla es en la capacidad de procesar documentos largos. Gemini 3.1 maneja contextos enormes sin perder coherencia, algo que a otros modelos les cuesta más.
• NotebookLM: es, para mí, una de las herramientas más infravaloradas de Google. La posibilidad de subir fuentes propias (documentos, PDFs, webs) y construir un asistente que solo responda sobre ese material es increíblemente potente para trabajo de investigación y análisis. La uso mucho combinada con otras herramientas, es casi como poder generar un RAG de forma muy simple.
• Imágenes y exploración: cuando necesito crear imágenes o simplemente explorar una idea sin comprometerme con una herramienta concreta, Gemini es mi punto de partida.
• Contextos muy grandes: en proyectos donde necesito procesar documentación extensa sin perder el hilo, Gemini 3.1 es imbatible. Su ventana de contexto es, hoy por hoy, de las mejores del mercado para uso práctico.

Lo que no me gusta

Google tiene un problema histórico: crea herramientas excelentes de forma individual pero no las integra bien entre sí. El ecosistema Gemini tiene de todo, pero descubrir qué existe y cómo encaja es una tarea en sí misma. No es un problema de calidad, es un problema de cohesión.

En desarrollo, empecé usando Gemini CLI y algo de Antigravity. Con los cambios recientes en Antigravity, si lo uso suelo tirar de su versión sin IDE. Pero no es mi herramienta principal para programar. Para revisión de código sigo usando Visual Studio Code, que he ido ajustando y configurando a lo largo de los años hasta tener un entorno que se adapta a mi forma de trabajar.

OpenCode: el centro de mi desarrollo con IA

Si Gemini es mi navaja suiza, opencode es mi herramienta principal ahora mismo. Es donde más tiempo invierto y donde más rendimiento saco.

La decisión de centrarme en una herramienta de desarrollo con IA no fue trivial. Hay decenas de opciones: Cursor, Windsurf, Claude Code, Antigravity, GitHub Copilot —cada una con sus ventajas. Pero mi filosofía es clara: prefiero conocer una herramienta en profundidad que tener nociones superficiales de varias. OpenCode es la herramienta en la que he decidido invertir, y eso incluye aprender a configurar skills, MCPs, providers y todo el ecosistema que la rodea.

Cómo gestiono los modelos en OpenCode

Tener acceso a una variedad de modelos y poder elegir según la tarea es, para mí, la clave del setup. En OpenCode gestiono esto con dos cuentas complementarias:

OpenCode Go es mi suscripción base. Por $10/mes tengo acceso plano a modelos open-source como DeepSeek V4, Qwen 3.6 Plus, Kimi K2.6 y GLM-5.1, sin preocuparme por el consumo de tokens. Este es mi canal para el día a día: generación de código, revisión, debugging, scripting. Para el 80% de mis tareas, estos modelos son suficientes y no necesito más.

OpenCode Zen funciona con presupuesto prepago. Cargo una cantidad y voy consumiendo según uso. Lo reservo para modelos grandes o muy potentes en casos puntuales donde necesito algo que los modelos open-source no alcanzan. Me permite acceder a Claude Opus o GPT-5 cuando la tarea lo requiere, sin llevarme sorpresas en la factura porque controlo cuánto cargo y cuándo.

La combinación de ambos es lo que hace sostenible el setup: el uso diario va mayoritariamente por Go, y Zen actúa como válvula de escape para cuando necesito potencia extra sin comprometer el presupuesto mensual.

Skills y MCPs

Donde más tiempo he invertido en OpenCode es en la configuración del entorno: skills para automatizar tareas recurrentes y MCPs (Model Context Protocol) para conectar con herramientas externas. Esto es lo que marca la diferencia entre tener un chat con IA y tener un entorno de desarrollo agéntico que realmente entiende tu flujo de trabajo.

La curva de aprendizaje existe, pero una vez que lo tienes configurado, el retorno es inmediato. Puedo lanzar tareas complejas con un comando y el agente sabe qué herramientas usar, qué contexto considerar y cómo estructurar la respuesta.

Modelos en local: Gemma 4 y LM Studio

Aunque el cloud cubre la mayoría de mis necesidades, tener la opción de ejecutar modelos en local es importante. No siempre quieres que tu código salga de tu máquina, y a veces necesitas respuestas rápidas sin depender de la latencia de una API.

Mi equipo es un Mac M1 Pro, que no es ninguna bestia para IA pero mueve modelos pequeños de forma aceptable. He probado varias opciones y mi configuración actual es:

• Gemma 4 como modelo principal para local. Lo muevo a unos 50 tokens por segundo, que es suficiente para tareas de análisis y edición de código que no requieren respuestas largas.
• LM Studio para servir el modelo. Levanta una API compatible con OpenAI en local, y OpenCode se conecta a ella sin configuración adicional.

El matiz importante: usar un modelo local como chat es relativamente sencillo si tu equipo lo aguanta. Pero conseguir que funcione bien como entorno agéntico —donde el modelo tiene que hacer llamadas a herramientas, interpretar resultados y mantener el contexto— es mucho más exigente. He tenido que tunear el system prompt varias veces hasta encontrar un equilibrio que funcione. Los modelos locales no están al mismo nivel que las soluciones comerciales, que unen a estos un entorno de trabajo ya pulido, y es justo reconocerlo.

Aun así, tener esta opción disponible me da flexibilidad. Para tareas sencillas o cuando necesito privacidad, es una alternativa que funciona.

Lecciones aprendidas

Después de meses probando combinaciones, estas son mis conclusiones principales:

Los modelos open-source cubren la mayoría del trabajo diario. Con una buena ventana de contexto y habilidades bien configuradas, modelos como DeepSeek V4 o Qwen 3.6 rinden a un nivel que hace un año habría sido impensable para código abierto. La inversión en configuración —skills, prompts, MCPs— es lo que realmente marca la diferencia.

Los modelos frontier siguen siendo necesarios, pero como recurso puntual. Gemini Pro, Claude Opus o GPT-5 tienen capacidades que los open-source aún no igualan en tareas muy específicas. Tener acceso a ellos sin comprometer el presupuesto mensual es cuestión de diseñar bien el sistema de decisión: qué tareas van a modelos baratos y cuáles justifican el coste de un modelo caro.

La variedad de modelos es más importante que la calidad de uno solo. No uso el mismo modelo para revisar un documento, generar código, analizar una base de datos o mantener una conversación exploratoria. Cada tarea tiene un perfil de coste, latencia y capacidad diferente, y el setup gana cuando puedes elegir en cada momento.

Invertir en una herramienta, no en muchas. Conocer OpenCode en profundidad me ha dado más rendimiento que probar diez herramientas diferentes sin llegar a dominar ninguna. La configuración de skills, MCPs y flujos de trabajo es tiempo invertido que se amortiza con cada uso. Eso no significa que siga explorando y probando muchas otras, pero por el momento todo lo que es trabajo profesional va a OpenCode.

Cierre

No considero este setup definitivo. El mercado de la IA se mueve demasiado rápido como para aferrarse a una combinación concreta. Pero la estrategia sí creo que se mantendrá: variedad de modelos, una herramienta principal bien configurada, acceso a modelos frontier cuando sea necesario y modelos locales para lo que no debe salir de la máquina.

Siento que estamos rascando la superficie de lo que la IA puede hacer en el día a día del desarrollo de software. Experimentar, probar y compartir lo que funciona es, ahora mismo, la mejor inversión que podemos hacer. Aún así, para el trabajo profesional es bueno mantener cierta estabilidad y apostar por una herramienta de base. En el momento en que decida cambiarla será porque estoy convencido de haber encontrado una alternativa mejor, al menos para mi uso.

Creo también que es muy importante experimentar a tu propio ritmo, si te dejas llevar por todo lo que aparece en redes sociales, necesitarias dedicar varias horas al día a probar todo. Más que nunca es necesario sentar las bases de todas las novedades que supone la IA, pero sin querer abarcar todo, porque es imposible. Prefiero invertir en entender los conceptos e ir construyendo un sistema y dinámicas que me funcionen, que copiar las de otros, por mucho hype que estén despertando.

Pero antes de entrar en materia, hay que aclarar un concepto importante porque es fuente de confusión constante: cuando hablamos de modelos "open source" en IA, casi siempre nos referimos en realidad a modelos de pesos abiertos (open-weight). La diferencia es sutil pero clave:

• Open-weight: el fabricante publica los pesos del modelo (los parámetros entrenados) para que cualquiera pueda descargarlos y usarlos. Pero el código de entrenamiento, los datos y el proceso completo no se comparten. Licencias como Apache 2.0 o MIT permiten uso comercial sin restricciones.
• Open source real (según OSI): además de los pesos, se comparten el código de entrenamiento, los datos (o su composición) y los checkpoints intermedios. Esto es extremadamente raro en modelos grandes.

Cuando una empresa dice que su modelo es "open source", normalmente significa que puedes descargar los pesos y ejecutar el modelo, usarlo comercialmente (con restricciones variables según la licencia), y hacer fine-tuning y adaptación. Pero lo que no incluye casi nunca son los datos de entrenamiento (sabemos la composición general, pero no los ejemplos concretos), el código de entrenamiento completo, los checkpoints intermedios, ni la metodología exacta de limpieza y filtrado de datos.

Esto tiene implicaciones prácticas: no puedes verificar de forma independiente si el modelo fue entrenado con datos sesgados o con contenido con copyright. Tienes que confiar en lo que dice la empresa. Es mejor que un modelo cerrado, desde luego, pero no es el ideal del software libre tradicional.

Así que, con matices, podemos decir que hoy tenemos una gran variedad de modelos "abiertos" que podemos usar, descargar y en muchos casos afinar, pero cuyo proceso de entrenamiento sigue siendo un secreto industrial.

Familias de modelos por empresa

Voy a agrupar los modelos más relevantes por la empresa que está detrás.

Meta — Llama 4

Meta ha sido el gran impulsor del ecosistema open-weight con su familia Llama. En 2026, Llama 4 es su apuesta más ambiciosa, con tres variantes principales:

Arquitectónicamente, Llama 4 adopta Mixture of Experts (MoE), lo que significa que aunque el modelo tenga cientos de miles de millones de parámetros totales, solo activa una fracción por inferencia. Scout y Maverick activan solo 17B parámetros, lo que los hace sorprendentemente eficientes.

La licencia de Llama es propia de Meta: permite uso comercial, pero si tu producto supera los 700 millones de usuarios activos mensuales, necesitas permiso especial. Es una cláusula pensada para que gigantes como Google o Microsoft no puedan usarlo libremente compitiendo con Meta.

Alibaba — Qwen 3.5

La familia Qwen de Alibaba es probablemente la que más rápido ha evolucionado. En febrero de 2026 lanzaron Qwen 3.5, con versiones desde 27B hasta 397B parámetros, todas bajo Apache 2.0.

Qwen 3.5 destaca especialmente en razonamiento y tareas multimodales (texto + imagen). En GPQA Diamond, Qwen 3.5 lidera los modelos open-weight con un 88.4%, superando a modelos cerrados de generaciones anteriores.

Apache 2.0 es una de las licencias más permisivas que existen: puedes usar, modificar, distribuir y vender sin restricciones. Alibaba ha apostado fuerte por esta estrategia para ganar adopción global.

DeepSeek — V4 y V3.2

DeepSeek, el laboratorio chino, ha sido uno de los grandes disruptores. Su modelo DeepSeek V4-Pro alcanza un 80.6% en SWE-bench Verified, a solo 0.2 puntos de Claude Opus 4.6, y lo hace con licencia MIT.

DeepSeek llamó la atención mundial en 2025 por sus afirmaciones de entrenamiento eficiente (con un coste declarado muy inferior al de modelos equivalentes), lo que generó tanto admiración como controversia. Lo cierto es que sus modelos son, hoy por hoy, referencia en codificación y razonamiento matemático.

MIT es incluso más permisiva que Apache 2.0: básicamente puedes hacer lo que quieras con el modelo, siempre que incluyas el aviso de copyright.

Mistral AI — Mistral Large 3

Mistral, la startup francesa, representa a Europa en la élite de los LLMs. Su Mistral Large 3 (675B total / 41B activos) compite en la frontera, con licencia Apache 2.0 para los modelos abiertos. También tienen modelos más pequeños como Mistral 7B (el original que los hizo famosos) y Mixtral 8x22B.

Mistral tiene una estrategia dual: ofrece modelos abiertos potentes bajo Apache 2.0 y una versión comercial (Mistral Large) con capacidades adicionales bajo licencia paga. Es un enfoque pragmático que les ha dado una base de desarrolladores muy leal en Europa.

Google — Gemma 4

Google tiene dos líneas: Gemini (cerrado) y Gemma (abierto). Gemma 4, lanzado en 2026, es posiblemente el movimiento más importante de Google en el espacio open-weight.

Gemma 4 viene en tamaños de 2B, 9B y 31B (versión medium), y lo relevante es que todo Gemma 4 está bajo Apache 2.0. La versión de 31B alcanza un 80% en LiveCodeBench con solo una décima parte de los parámetros activos de los MoE frontera. Es ideal para ejecución local y edge deployment.

Moonshot AI — Kimi K2.5 / K2.6

Moonshot AI es una empresa china que ha destacado por su enfoque en contextos largos. Sus modelos Kimi fueron los primeros en soportar 2M tokens de contexto efectivo. Hoy, Kimi K2.5 y K2.6 son sus modelos estrella, con 1T parámetros totales (32B activos) y licencia open-weight.

Kimi K2.5 destaca especialmente en generación visual-a-código y agentes autónomos. K2.6 (lanzado a principios de 2026) mejora los benchmarks de razonamiento y codificación.

Zhipu AI — GLM-5

Zhipu AI es otro laboratorio chino que ha irrumpido con fuerza. Su GLM-5 (744B total / 40B activos) bajo licencia MIT es uno de los modelos más potentes en tareas de sistemas complejos y agentes de larga duración.

Microsoft — Phi-4

Microsoft ha apostado por modelos pequeños pero muy capaces. Phi-4 (14B) bajo licencia MIT demuestra que no todo es tamaño: supera a modelos de 70B+ en razonamiento matemático con una fracción de los recursos. Es perfecto para dispositivos con recursos limitados.

MiniMax — M2.5 / M2.7

MiniMax, otra empresa china, ha lanzado MiniMax-M2.5 (229B total / 10B activos) y su versión mejorada M2.7, enfocados en flujos de trabajo de ingeniería de software. Son modelos ligeros y rápidos, con buena relación calidad-recurso.

01.AI — Yi

Fundada por Kai-Fu Lee, 01.AI publicó la familia Yi bajo licencias Apache 2.0. Aunque no están en la frontera absoluta en 2026, siguen siendo modelos sólidos, especialmente en tareas en chino e inglés.

Tabla resumen de modelos y licencias

Routers de modelos: cómo acceder a todo esto

Todos estos modelos, al ser open-weight, se pueden descargar y ejecutar en local usando herramientas como Ollama, LM Studio o vLLM. De hecho, esa es una de las grandes ventajas del ecosistema abierto: no dependes de ningún proveedor y tus datos no salen de tu máquina. Sin embargo, ejecutar modelos grandes requiere hardware potente —una GPU con suficiente VRAM— y no todo el mundo tiene una RTX 4090 o un clúster en casa. Modelos como DeepSeek V4-Pro (1.6T parámetros) necesitan múltiples GPUs para funcionar a velocidad aceptable.

Aquí es donde entran los routers de modelos: servicios cloud que te permiten usar estos modelos sin necesidad de infraestructura propia. Unifican el acceso a decenas de modelos bajo una misma API, de modo que no tienes que gestionar 20 cuentas y 20 facturas diferentes.

OpenRouter

OpenRouter es el router más conocido. Funciona como una pasarela unificada: te registras una vez, cargas crédito y accedes a 400+ modelos de 60+ proveedores.

Fortalezas: - Catálogo enorme: desde los modelos frontier (Claude, GPT) hasta los más nicho - Auto-fallback: si un proveedor falla, OpenRouter redirige automáticamente - Sin logging por defecto (tu código no se usa para entrenar) - API compatible con OpenAI (cambias la URL y ya funciona) - Modelos gratuitos disponibles (limitados)

Debilidades: - Añade latencia (es una capa intermedia) - Comisión del 5.5% en compras de crédito - El tier gratuito es muy limitado (50 requests/día sin crédito)

OpenRouter usa precios passthrough: pagas lo mismo que pagarías yendo directamente al proveedor. Su negocio está en la comisión de crédito, no en marcar precio.

Groq

Groq es un caso diferente. No es un router, es un proveedor de inferencia con hardware propio: sus LPUs (Language Processing Units) son chips diseñados específicamente para ejecutar LLMs. El resultado es una velocidad de inferencia que puede alcanzar 500-1000 tokens/segundo, muy por encima de lo que ofrecen las GPUs tradicionales.

Fortalezas: - Velocidad bestial: tiempo hasta el primer token por debajo de 200ms - Tier gratuito generoso: 250K+ tokens/minuto - API compatible con OpenAI - Modelos populares: Llama 4 Scout, Qwen3-32B, DeepSeek

Debilidades: - Catálogo limitado (solo modelos open-source que ellos optimizan para su hardware) - No es un router (solo un proveedor) - Sin posibilidad de auto-hospedar (el hardware LPU es suyo)

Groq es ideal cuando necesitas velocidad y trabajas con modelos open-source populares. No te sirve si necesitas un modelo específico que ellos no tengan.

OpenCode Go

OpenCode Go es la apuesta del equipo de OpenCode. Por $10/mes obtienes acceso a 14+ modelos open-source de última generación a través de una API única.

Fortalezas: - Precio planísimo: $10/mes sin preocuparte por tokens - Modelos frontier open-source: DeepSeek V4 Pro, Qwen 3.6 Plus, Kimi K2.6, GLM-5.1, MiniMax M2.7 - API compatible con OpenAI (funciona con cualquier herramienta que hable OpenAI API) - Política zero-retention: tu código no se usa para entrenar - Infraestructura en US, EU y Singapur

Debilidades: - Límites de consumo por ventanas de tiempo: tu suscripción de $10 te da un pool de $60/mes en compute, con sub-límites de $12/5h y $30/semana para evitar abusos. Con modelos baratos (DeepSeek V4 Flash a $0.14/M tokens) llegas a miles de requests; con modelos caros (Kimi K2.6) el límite se alcanza antes. Nunca pagas más de los $10 al mes. - Solo modelos open-source (no hay Claude, GPT ni Gemini) - Dependes de la disponibilidad del servicio

OpenCode Go es perfecto si tu flujo de trabajo se basa en modelos open-source y quieres un coste predecible sin sorpresas en la factura.

Comparativa rápida

Conclusión

El ecosistema de modelos open source en 2026 es más rico que nunca. Hay modelos para cada necesidad, desde los gigantes multimodales como Qwen 3.5 o Llama 4 hasta pequeños pero matones como Phi-4 o Gemma 4 que funcionan en un portátil.

La principal recomendación que puedo dar es:

1. Para uso general con máxima calidad, Qwen 3.5 y DeepSeek V4 son las mejores opciones open-weight hoy por hoy.
2. Para ejecución local, Gemma 4 (31B) o Phi-4 (14B) son imbatibles en relación calidad/recursos.
3. Para desarrollo de software, Kimi K2.6 destaca en generación de código y agentes autónomos. Como alternativas, DeepSeek V4-Pro es el rey del SWE-bench Verified (80.6%) para tareas complejas, y Qwen 3.7 Max lidera en SWE-Bench Pro dentro del ecosistema OpenCode Go.
4. Para acceder a todo sin complicaciones, OpenRouter es la navaja suiza. Si buscas velocidad, Groq. Si prefieres coste fijo, OpenCode Go.

Y recuerda: aunque llamemos "open source" a estos modelos, lo que realmente tenemos son pesos abiertos con licencias variadas. Úsalos, aprovéchalos, pero sé consciente de lo que estás usando y de las limitaciones reales de cada "open" que ves en la etiqueta.

Durante la Revolución Industrial, la llegada del telar mecánico destruyó por completo el sector de los tejedores artesanales. Quienes habían pasado años aprendiendo la técnica manual de entrelazar hilos vieron cómo su oficio desaparecía ante una máquina que hacía lo mismo de forma masiva, rápida y barata. ¿Significó eso el fin de la industria textil? Al contrario. La manufactura de la tela se convirtió en una utilidad genérica, lo que redujo los costes drásticamente. El valor real de la industria se desplazó hacia arriba: hacia el diseño de moda, el patronaje a escala y la logística.

Pero hacer software no va solamente de tejer hilo, el proceso es mucho más complejo y la llegada de la IA no va transformar radicalmente la industria. Va a cambiar cosas y vamos a necesitar adaptarnos, eso sí.

Lo que cuesta entender, al parecer, es lo que la IA realmente hace: encontrar patrones matemáticos en datos existentes. Si limitamos nuestra profesión a lo que la IA puede replicar, corremos el riesgo de congelar la industria. La informática real sigue siendo un terreno estrictamente humano. Como decía Edsger Dijkstra:

"Computer science is no more about computers than astronomy is about telescopes"

La IA es un telescopio potentísimo, pero no es la astronomía. Confundir la capacidad de escribir código sintáctico con la capacidad de resolver problemas mediante la computación es el mayor error conceptual que estamos cometiendo.

Seguramente has experimentado con el vibe coding: te pones a construir una aplicación con IA, piensas en sacarle rendimiento, ponerla en un market y venderla. En unas pocas horas tienes una aplicación funcional y sientes que ya has hecho el 80% del trabajo. Piensas: «Mañana cierro los últimos flecos y la publico». Pero ese 20% que falta resulta no ser tan sencillo. Ya no es cuestión de horas, sino de días o semanas. O simplemente, nunca llegas a publicarla, porque la IA no es tan buena lidiando con la complejidad del mundo real. Esos últimos flecos son el producto, la usabilidad y la infraestructura: todo aquello que requiere el conocimiento y la experiencia de una persona.

Lo que la IA no sabe hacer: El mundo real más allá del código

Un modelo de lenguaje puede escribir una función limpia si la instrucción es lo suficientemente meticulosa. El problema es que el software no vive en el vacío; convive en un ecosistema complejo de usuarios, servidores, costes y decisiones estratégicas.

Existen tres dimensiones críticas donde la IA carece de la capacidad operativa para decidir:

1. El criterio de digitalización (Saber cuándo NO hacer software)

La IA siempre va a intentar resolver el problema generando texto o código, porque esa es su naturaleza estadística. Carece del criterio para analizar un proceso de negocio y concluir: "La solución óptima aquí no es construir una aplicación, sino cambiar este flujo organizativo en el mundo real". Saber cuándo no introducir tecnología porque sí, para evitar complejidad innecesaria, es una de las mayores muestras de madurez en ingeniería.

2. La experiencia de usuario (UX)

La IA no tiene un modelo mental de la realidad. Puede replicar interfaces basadas en patrones de diseño comunes (como colocar un botón de carrito arriba a la derecha), pero no entiende la fricción humana. No sabe el estrés que siente un operario de almacén usando una aplicación bajo la luz del sol directa, ni la confusión de un usuario ante un menú saturado. La UX requiere empatía y observación, algo que no se encuentra en una matriz de embeddings.

3. Las limitaciones y el diseño de la infraestructura

Escribir código es fácil; hacer que ese código escale de forma eficiente bajo restricciones de hardware reales es ingeniería pura. La IA no sufre cuando una base de datos PostgreSQL se satura por falta de memoria, ni entiende el impacto en costes que implica mover datos entre diferentes regiones de la nube. No contempla escenarios sin una buena conexión a Internet, con cortes de electricidad o sin cobertura móvil. La IA es como los experimentos de laboratorio, siempre asume condiciones ideales. Puede darte la sintaxis de una consulta, pero el diseño de una arquitectura tolerante a fallos que optimice los recursos físicos requiere comprender los trade-offs reales del sistema.

La trampa del estancamiento: La IA copia el pasado, el humano diseña el futuro

Hay una reflexión profunda que quizás estamos ignorando debido al hype: los modelos de lenguaje construyen software tal y como se ha hecho hasta hoy. Como los LLMs se entrenan con repositorios existentes (como el histórico de GitHub), son maestros de la probabilidad estadística respecto a lo que ya existe. Esto significa que la IA es, por definición, una fuerza conservadora y retrospectiva.

El bucle de la imitación: La IA encuentra y replica patrones. Si detecta que el 90% de los proyectos usan una estructura determinada para una API, te devolverá esa estructura. Está optimizada para darte la respuesta más probable, no la más innovadora.

Ante un desafío tecnológico inédito, un problema para el cual no existen tutoriales en internet ni código de entrenamiento, la red neuronal falla o alucina. No puede inventar un paradigma de programación nuevo; solo puede combinar los vectores numéricos de lo que alguien ya escribió antes.

Si las personas que nos dedicamos a la informática delegamos el pensamiento y la evolución de la disciplina en los asistentes de código, congelaremos el desarrollo de la tecnología. Nos estancaremos replicando las mismas arquitecturas y los mismos errores del pasado en un bucle infinito de software autogenerado.

Innovación frente a imitación

La evolución tecnológica nunca ha llegado por hacer de forma más rápida lo que ya sabíamos hacer. Llegó cuando Alan Turing imaginó una máquina que no existía, cuando se diseñaron los primeros sistemas operativos distribuidos para resolver la saturación de los mainframes, o cuando nacieron arquitecturas web descentralizadas para soportar millones de usuarios simultáneos.

Para que la informática siga avanzando, quienes nos dedicamos a la ingeniería debemos cambiar el enfoque de nuestro trabajo diario:

• Menos memorización de sintaxis, más pensamiento sistémico: Dejemos que la IA maneje los tokens mecánicos de la sintaxis y enfoquémonos en comprender los fundamentos lógicos y físicos de los sistemas. El hecho en sí de escribir código es fácil para la IA, conoce las estructuras, los patrones, la sintaxis, pero saber qué usar y cuándo es cosa nuestra.
• Enfrentar la incertidumbre: El verdadero valor de la ingeniería radica en los márgenes de los problemas nuevos, allí donde no hay documentación de StackOverflow ni datos de entrenamiento para el modelo. La innovación seguirá siendo humana, si dejamos a la IA diseñar las soluciones, serán siempre las que ya conocemos.
• Liderar la orquestación: Tratar a la IA como lo que es: un traductor universal de patrones existentes que acelera la imitación, permitiéndonos a nosotros liberar tiempo para la verdadera innovación y el diseño de soluciones estructuralmente nuevas. La IA es una herramienta que nos hace el trabajo más fácil, pero no hace nuestro trabajo.

Conclusión

Al final, la IA que conocemos hoy es solo eso: una herramienta. Una increíblemente potente, sí, pero una herramienta al fin y al cabo. Bien usada, nos facilita la vida, pero ni nos sustituye ni va a hacerlo en el corto plazo.

No es magia. No convierte a un principiante en un experto, ni a alguien sin criterio estético en un buen diseñador. La IA es un espejo que amplifica lo que ya somos.

El futuro no lo construirán quienes solo sepan hablar con la máquina, sino aquellos que, partiendo del criterio y la visión, dominen la IA como una palanca para ejecutar esa visión. Y entre dos profesionales con la misma visión, quien domine la herramienta para trabajar más rápido y mejor, será quien marque la diferencia.

• La Infraestructura Agéntica: El nuevo Stack
  • El Motor de Razonamiento (Capa de Cómputo)
  • El Protocolo MCP (Capa de Conectividad)
  • Las Skills
  • Arquitectura Multi-Agente (Capa de Gestión)
  • RAG Estructurado (Capa de Memoria)
  • El Bucle PEV: Planificar, Ejecutar, Verificar
• Las claves de la Ingeniería Agéntica
  • 1. El LLM como motor de razonamiento
    • El Razonamiento como Proceso de Decisión (Tool Use)
  • 2. La Taxonomía de Modelos: Especialización en 2026
    • Modelos de Razonamiento Profundo (Los Arquitectos)
    • Modelos de Código y "Flash" (Los Obreros Especializados)
    • Modelos de Gran Contexto (Los Bibliotecarios)
    • El coste del razonamiento
    • Cómo elegirlos
  • 3. Estrategia de Orquestación: El Patrón Planificador-Ejecutor
    • Integración de Skills y Evaluación de MCPs
    • Paralelización mediante Agentes y Subagentes
• La Conexión con la Ingeniería de Software Profesional
  • Spec-Driven Development (Desarrollo Guiado por Especificación)
    • El Fundamento Técnico: Reducción de entropía en la predicción de tokens
    • Anatomía de una Especificación Ejecutable por IA
    • El Ciclo de Desarrollo Guiado por Especificaciones
  • El Harness (El Arnés de Pruebas y Validación)
    • ¿Qué es un Harness de Ingeniería?
    • La arquitectura del bucle de autocorrección
    • Implementación real y seguridad
• Conclusiones: El verdadero papel del ingeniero

En 2026, el desarrollo de software, con IA, ha evolucionado más allá de la simple generación de fragmentos de código mediante prompts aislados. Estamos en plena evolución, del vibe coding —programar por sensaciones— a una Ingeniería Agéntica más rigurosa. La IA ya no es un asistente externo; es un componente central de la arquitectura que requiere diseño, validación y observabilidad.

El vibe coding consiste en utilizar la IA de forma intuitiva y no estructurada: lanzar un prompt vago, copiar el código resultante, ver si funciona y, si no, pedirle que "lo arregle". Aunque es bueno para prototipar, falla estrepitosamente al escalar por tres razones técnicas:

• Falta de Determinismo: Al no haber un "arnés" de pruebas, dependes de la suerte estadística del modelo en ese momento.
• Context Rot (Deterioro del contexto): En chats largos, el modelo pierde los requisitos iniciales o las restricciones arquitectónicas, introduciendo bugs sutiles que solo aparecen en runtime.
• Deuda Técnica Invisible: La IA suele priorizar la solución inmediata sobre la mantenibilidad. Sin una supervisión estructural, acabas con un "código espagueti" generado por una máquina.

La Infraestructura Agéntica: El nuevo Stack

Para crear aplicaciones robustas, hemos pasado de "chatear" a implementar una infraestructura de Ingeniería Agéntica, o al menos lo estamos intentado. Esta se basa en algunas capas fundamentales, de forma resumida:

El Motor de Razonamiento (Capa de Cómputo)

Ya no tratamos al LLM como una enciclopedia, sino como una CPU lógica.

• Modelos de Razonamiento Profundo: En 2026, usamos modelos que ejecutan una Cadena de Pensamiento (CoT) interna para validar su lógica antes de escribir código.
• Evaluaciones Automáticas: El sistema no acepta el código porque "parezca correcto"; lo pasa por un banco de pruebas (evaluaciones) que miden su precisión técnica.

El Protocolo MCP (Capa de Conectividad)

El Model Context Protocol (MCP) es el estándar que permite a la IA interactuar con herramientas reales de forma segura.

• En lugar de que el desarrollador copie y pegue logs de error, el agente tiene una Skill conectada vía MCP que le permite leer los logs del servidor, consultar la base de datos o revisar el historial de Git por sí mismo.

Las Skills

Las skills (o habilidades) son las funciones deterministas y herramientas específicas que ponemos a disposición del agente para que pueda interactuar con el entorno real. Un modelo de lenguaje por sí solo es puramente predictivo, por lo que una skill actúa como su "brazo ejecutor": un fragmento de código (generalmente funciones en Python o TypeScript) diseñado para realizar una tarea concreta, como ejecutar un test unitario, consultar el esquema de una base de datos o leer los logs de un servidor.

Para que el agente pueda utilizarlas, no basta con programar la función lógica, sino que es imprescindible acompañarla de una descripción semántica muy clara. El modelo lee este "contrato" o definición de la skill, comprende para qué sirve y qué parámetros necesita, y decide de manera autónoma cuándo y cómo invocarla en su bucle de razonamiento según los requerimientos del software que está desarrollando.

Arquitectura Multi-Agente (Capa de Gestión)

En lugar de un único "super-agente", dividimos el trabajo en agentes especializados.

• Arquitecto: Define el plan y las interfaces.
• Programador: Implementa la lógica siguiendo el plan.
• QA/Tester: Intenta romper el código del programador antes de que llegue a revisión humana.

RAG Estructurado (Capa de Memoria)

Para que la IA "entienda" un repositorio de miles de archivos, usamos Retrieval-Augmented Generation (RAG) avanzado.

• Embeddings de Código: El sistema fragmenta el código en vectores semánticos, permitiendo que el agente recupere exactamente el componente necesario para su tarea actual sin saturar su ventana de contexto.

Para saber más sobre esto, puedes consultar la versión original de La Guía de la IA , donde explicamos este y otros conceptos.

El Bucle PEV: Planificar, Ejecutar, Verificar

La diferencia real con el vibe coding es el rigor en el flujo de trabajo. En la ingeniería agéntica, el proceso es circular y auto-corregido:

1. Planificación: El agente genera un PLAN.md que detalla los cambios. El humano lo audita.
2. Ejecución: El agente aplica los cambios en un entorno aislado (sandbox).
3. Verificación: Se ejecutan tests automáticos, linters y análisis de seguridad. Si falla, el agente recibe el feedback y vuelve al paso 2 sin intervención humana.

En 2026, el desarrollo profesional ya no va sobre quien escribe mejor el código, sino sobre quien diseña los mejores prompts sistémicos, las herramientas MCP y los criterios de aceptación para que su infraestructura agéntica construya software de forma segura y escalable.

O al menos, esa es la teoría.

Las claves de la Ingeniería Agéntica

1. El LLM como motor de razonamiento

Para construir software con IA en 2026, el primer paso es dejar de ver al LLM como una base de datos de conocimiento y empezar a verlo como un motor de razonamiento probabilístico. En esta fase de la ingeniería agéntica, el modelo no solo genera texto; actúa como el "cerebro" que evalúa el estado de un sistema, decide qué herramientas invocar y valida sus propios resultados.

El Razonamiento como Proceso de Decisión (Tool Use)

La gran diferencia entre los modelos de "chat" de años anteriores y los actuales modelos de razonamiento profundo es la capacidad de gestionar el Tool Use (o Function Calling) con criterio técnico.

Anteriormente, los modelos a menudo sufrían de "precipitación": intentaban responder antes de analizar las pre-condiciones. Hoy, los modelos especializados en razonamiento utilizan un monólogo interno o Cadena de Pensamiento (CoT) para:

• Analizar la intención: ¿Qué está pidiendo realmente el desarrollador?.
• Seleccionar la herramienta: Evaluar si necesita consultar el esquema de la base de datos vía MCP o si puede resolverlo con la información en su ventana de contexto.
• Anticipar efectos: Razonar sobre cómo un cambio en un modelo de datos afectará a los controladores y a la UI antes de escribir la primera línea de código.

2. La Taxonomía de Modelos: Especialización en 2026

No existe un "modelo único" para todo. La ingeniería moderna se basa en la orquestación selectiva según las capacidades y costes de cada familia de modelos:

Modelos de Razonamiento Profundo (Los Arquitectos)

Estos modelos priorizan el acierto sobre la velocidad.

• Fortaleza: Excelente capacidad para resolver problemas de lógica pura, matemáticas y diseño de sistemas complejos.
• Uso ideal: Planificación de refactorizaciones masivas, resolución de bugs lógicos profundos y orquestación inicial de tareas agénticas.

Modelos de Código y "Flash" (Los Obreros Especializados)

Modelos optimizados para baja latencia y alta eficiencia en tareas sintácticas.

• Fortaleza: Generación de boilerplate, escritura de tests unitarios y documentación.
• Uso ideal: Autocompletado inteligente dentro del IDE y ejecución de sub-tareas definidas previamente por un modelo arquitecto.

Modelos de Gran Contexto (Los Bibliotecarios)

Modelos capaces de ingerir millones de tokens (repositorios enteros) en una sola sesión.

• Fortaleza: Capacidad para mantener la coherencia global en proyectos gigantescos sin depender exclusivamente de RAG externo.
• Uso ideal: Auditorías de seguridad de todo el código base o migración de versiones de frameworks en múltiples archivos simultáneamente.

Los modelos especializados en desarrollo de software son entrenados específicamente, pero no todos los entrenamientos son iguales. Fruto de ello, la manera en la que se enfrentan a una tarea es diferente. Algunos intentarán realizarla de forma global, pero si es demasiado grande se pueden perder entre el contexto, olvidar cosas durante la ejecución, etc. Hay modelos que son entrenados para realizar un plan previo, a modo de TODO, descomponiendo la tarea en pasos concretos, y luego ejecutarlos. Estos suelen conseguir mejores resultados porque manejan mejor todo el contexto, incluso pueden reevaluar el resultado de la subtarea anterior si ven algún problema.

El coste del razonamiento

Como ingenieros, debemos entender que el razonamiento no es gratuito. Los modelos que "piensan más" tienen:

1. Mayor Latencia: El tiempo de respuesta es más alto porque el modelo genera miles de tokens internos de razonamiento que tú no ves.
2. Mayor Coste de Inferencia: Estamos pagando por esos tokens de pensamiento interno.

Por tanto, usar un modelo de razonamiento profundo para añadir un comentario a una función es un anti-patrón de ingeniería. El criterio técnico consiste en equilibrar la complejidad del problema con la potencia del motor de razonamiento elegido.

Cómo elegirlos

Existen rankings técnicos de referencia que permiten orientar la elección del modelo según la tarea: LMSYS Arenadestaca en preferencias de programación general, LiveCodeBench evalúa lógica pura frente a problemas inéditos, y SWE-bench mide la capacidad de resolver issues reales de GitHub, lo cual es crítico para elegir un modelo "Arquitecto". Estas herramientas, junto con el leaderboard de Aider para edición de archivos, ofrecen una visión clara de qué modelos lideran en razonamiento y ejecución sintáctica en 2026.

No obstante, es fundamental tomar estos datos con prudencia; los benchmarks son entornos controlados que no siempre reflejan las fricciones de una infraestructura agéntica privada. Para una implementación profesional, los rankings deben servir solo como punto de partida, debiendo ser validados con métricas propias de observabilidad que analicen la latencia, el coste por millón de tokens y la precisión específica dentro de tu propio código base.

En el argot ciclista solemos decir que lo importante es el indio, no la flecha. Un buen ciclista con peor material (la bicicleta) siempre será mejor que uno mediocre aunque este lleve lo mejor de lo mejor. El cómo construyamos herramientas alrededor de un modelo, el cómo le demos contexto, instrucciones, etc. puede hacer que un modelo en teoría más modesto nos consiga mejores resultados.

3. Estrategia de Orquestación: El Patrón Planificador-Ejecutor

La efectividad de un modelo no depende solo de cuántos miles de millones de parámetros tiene, sino de cómo ha sido entrenado para enfrentarse a una tarea. Mientras que los modelos generalistas intentan resolver peticiones de forma global —lo que a menudo provoca que se "pierdan" en el contexto o ignoren restricciones críticas al final de una respuesta larga—, los modelos de razonamiento profundo actúan bajo una lógica de planificación previa. Este entrenamiento les permite generar un "monólogo interno" o un mapa de tareas (TODO) donde descomponen el problema en pasos atómicos antes de escribir la primera línea de código.

Esta capacidad de descomposición es lo que permite manejar proyectos complejos sin que la calidad del código se degrade. Al centrarse en subtareas específicas —como definir primero la interfaz, luego la lógica del repositorio y finalmente los tests—, el modelo mantiene una atención mucho más cerrada sobre las reglas de negocio de cada fragmento. Además, este enfoque permite la reevaluación dinámica: si el modelo detecta un error en el paso tres, tiene la capacidad de retroceder y ajustar el paso uno, algo que un modelo de generación directa simplemente no puede hacer porque su proceso es puramente predictivo y hacia adelante.

Por eso, en una infraestructura agéntica profesional, el éxito reside en saber qué "cerebro" asignar a cada fase del desarrollo. Utilizamos modelos de razonamiento profundo, como OpenAI o1 o DeepSeek-R1, para la fase de arquitectura y planificación, donde el acierto y la lógica son innegociables. Una vez que el plan es sólido y las subtareas están definidas, podemos delegar la ejecución mecánica en modelos más rápidos y económicos como Claude 3.5 Haiku o GPT-4o-mini, que destacan por su precisión sintáctica y velocidad. Esta orquestación no solo optimiza el coste y el tiempo de entrega, sino que garantiza que el resultado final sea fruto de una arquitectura pensada y no de una simple probabilidad estadística.

Integración de Skills y Evaluación de MCPs

Un modelo de lenguaje, por muy especializado que esté en código, vive aislado en un entorno puramente conceptual. Para que pueda operar de forma autónoma en el mundo real, necesita herramientas de interacción directa que actúen como sus manos y sus ojos. Estas herramientas se dividen en dos conceptos clave: las skills y los conectores de contexto.

Con el plan trazado, el sistema debe activar las herramientas necesarias para interactuar con el entorno. Aquí es donde integramos las skills: las funciones deterministas escritas en código (Python o TypeScript) que permiten al agente ejecutar acciones concretas como correr un linter o empaquetar un binario.

En paralelo, el ingeniero debe evaluar si la tarea requiere conectar con fuentes de información externas o bases de datos locales; de ser así, se despliegan servidores basados en el protocolo MCP (Model Context Protocol). El MCP actúa como el sistema nervioso del agente, permitiéndole consultar de forma estructurada el esquema de una base de datos PostgreSQL, leer archivos locales o comunicarse con APIs de terceros sin saturar la ventana de contexto con volcados masivos de texto.

Cuando te enfrentas a un problema que puede resolverse tanto con una skill como con un servidor MCP —el acceso a una base de datos es el ejemplo de manual—, la elección debe basarse en un criterio de eficiencia y seguridad. Los servidores MCP son excelentes como conectores universales y exploratorios, pero tienden a consumir mucha más ventana de contexto porque vuelcan metadatos estructurados y relaciones complejas para que el modelo decida de forma abierta. Una skill, en cambio, ofrece un control ultra-específico: tú defines la consulta exacta, ahorrando tokens y forzando al modelo a recibir una respuesta atómica. Sin embargo, hay un factor crítico: el riesgo de ejecución. Mientras que un servidor MCP suele estar limitado por diseño a la lectura del contexto, una skill basada en un script local suele ejecutarse con permisos completos de escritura por defecto. Si vas a usar una skill para interactuar con tus datos, es una buena práctica obligatoria crear usuarios del sistema o de la base de datos con permisos capados exclusivamente a nivel de lectura, impidiendo que una mala interpretación del agente altere accidentalmente los datos de tu entorno.

Paralelización mediante Agentes y Subagentes

Para evitar cuellos de botella en proyectos de gran envergadura, la arquitectura debe estructurarse mediante una jerarquía de agentes y subagentes. Un agente supervisor recibe el plan general y distribuye las subtareas de manera síncrona o asíncrona entre subagentes especializados que corren en paralelo. Mientras un subagente desarrolla el componente de autenticación, otro puede estar generando de forma simultánea la lógica de la API de pagos. Esta paralelización no solo acelera el ciclo de desarrollo, sino que compartimenta el contexto, asegurando que un error en un módulo no contamine el razonamiento del resto del sistema.

La Conexión con la Ingeniería de Software Profesional

Toda esta orquestación agéntica cobra sentido real cuando se conecta con dos metodologías críticas que garantizan que el código generado sea predecible, seguro y mantenible.

Spec-Driven Development (Desarrollo Guiado por Especificación)

El mayor error que cometen los desarrolladores al integrar agentes de IA en sus flujos de trabajo es asumir que el modelo "entiende" la arquitectura solo porque puede leer el código. Cuando delegamos tareas complejas a un sistema agéntico basándonos en instrucciones abiertas en lenguaje natural ("implementa el módulo de pasarela de pagos"), exponemos al sistema a la deriva semántica. El resultado suele ser un bucle infinito de correcciones, dependencias rotas y código que funciona de forma aislada pero destruye la consistencia del repositorio.

Para construir software profesional con modelos probabilísticos, necesitamos un marco determinista: el Spec-Driven Development (SDD) o Desarrollo Guiado por Especificación.

El Fundamento Técnico: Reducción de entropía en la predicción de tokens

Para entender por qué el SDD es imprescindible, debemos recordar cómo funciona un LLM por debajo. Un modelo de lenguaje no compila lógica; calcula la probabilidad estadística de la siguiente unidad de información o token.

Cuando lanzas una petición abierta en lenguaje natural, el espacio semántico de respuestas válidas tiende al infinito. El modelo se ve obligado a elegir entre miles de formas posibles de estructurar una función, nombrar variables o manejar errores. Cuanto mayor es la libertad del modelo, mayor es la entropía (el desorden del sistema) y, por tanto, mayor es la probabilidad de que ocurra una alucinación técnica o una inconsistencia arquitectónica.

El Spec-Driven Development mitiga este problema convirtiendo el lenguaje natural vago en un conjunto de restricciones rígidas e innegociables antes de que el agente escriba una sola línea de código de producción. Al alimentar al agente con una especificación técnica estricta (como un esquema JSON o un contrato OpenAPI), acotamos el espacio matemático de soluciones. El modelo ya no tiene que inventar la estructura; solo tiene que calcular los tokens que mejor se ajustan al contrato predefinido. La indeterminación de la IA se reduce al mínimo porque el margen de error probabilístico queda encajonado por la regla de negocio.

Anatomía de una Especificación Ejecutable por IA

Una especificación para consumo agéntico no es un documento de requerimientos tradicional lleno de prosa. Debe ser una fuente de verdad estructurada y procesable que sirva como contrato tanto para el programador humano como para la flota de subagentes.

Una spec efectiva debe contener tres capas de aislamiento:

• El Contrato de Interfaz (Sintaxis Estricta): Define las firmas exactas de las funciones, los endpoints de las APIs, los tipos de datos de entrada y salida, y los códigos de respuesta esperados. Utilizar formatos estandarizados como OpenAPI (Swagger) o esquemas de TypeScript TypeScript-first asegura que el modelo no improvise nombres de parámetros o tipos de variables.
• Las Reglas de Dominio (Semántica de Negocio): Describe el comportamiento lógico esperado bajo condiciones específicas. En lugar de explicarlo con ambigüedad, se define mediante lógica booleana o pseudocódigo declarativo (ej: si el estado del usuario es INACTIVO, la API debe retornar 403 inmediatamente).
• Restricciones de Infraestructura y Estilo: Establece qué librerías específicas están permitidas y cuáles están explícitamente prohibidas (ej: usar Leaflet para mapas, prohibido usar OpenLayers), el patrón arquitectónico obligatorio (ej: clean architecture, inyección de dependencias) y las directrices de manejo de excepciones.

El Ciclo de Desarrollo Guiado por Especificaciones

En un entorno de ingeniería real, el flujo de trabajo sigue una secuencia rígida dividida entre la toma de decisiones estratégicas (humano) y la ejecución sintáctica (IA).

• Diseño de la Spec: El desarrollador humano colabora con un modelo de razonamiento profundo para redactar la especificación técnica (SPEC.md u OpenAPI).
• Auditoría y Bloqueo: El humano audita la especificación, asegura que cubre las reglas de negocio y los casos límite, y bloquea el archivo. A partir de este momento, la spec es inmutable para los agentes
• Inyección y Ejecución: La spec se inyecta en el contexto de los subagentes ejecutores. Los subagentes programan las funciones ciñéndose estrictamente a las interfaces definidas.
• Validación en el Harness: El código generado se envía directamente al harness (el arnés de pruebas automatizadas). El arnés compila el código, corre linters, ejecuta tests unitarios y estresa la aplicación contra los criterios definidos en la especificación. Si un test falla, los logs se devuelven al agente que autocorrige su código hasta cumplir el contrato.

El Harness (El Arnés de Pruebas y Validación)

Una vez que los subagentes generan el código basándose en la especificación, el sistema no puede dar la tarea por buena sin una validación automática: aquí entra el harness (o arnés de ingeniería). El harness es el entorno aislado (sandbox o contenedor) provisto de un banco de pruebas automáticas (tests unitarios, de integración, linters y analizadores estáticos de seguridad) diseñados específicamente para validar el código producido. El agente no interactúa directamente con producción; entrega su código al arnés. Si el código pasa todas las pruebas del harness, se considera válido; si falla, los logs de error se inyectan automáticamente en la ventana de contexto del agente como retroalimentación para que inicie su bucle de autocorrección sin intervención humana. El harness es, en definitiva, la red de seguridad técnica que transforma la probabilidad del LLM en el determinismo que exige el software profesional.

¿Qué es un Harness de Ingeniería?

En el desarrollo de software AI-First, el harness (o arnés de validación) es un entorno aislado de ejecución —generalmente implementado mediante sandboxes o contenedores seguros— diseñado para interceptar, ejecutar y evaluar de forma determinista el código producido por un agente antes de que este pueda ser integrado en el repositorio principal.

El arnés actúa como un árbitro neutral. Su filosofía es simple: no importa lo seguro que el modelo afirme estar sobre su propuesta; el código no tiene valor hasta que demuestra su validez en runtime bajo pruebas controladas. El agente no interactúa de forma directa con las ramas productivas ni realiza commits automáticos; su único canal de entrega es el propio arnés.

La arquitectura del bucle de autocorrección

La principal virtud del harness no es solo detener el código defectuoso, sino cerrar el bucle de retroalimentación (feedback loop) para que el sistema se repare a sí mismo sin consumir tiempo del desarrollador humano. Esta infraestructura opera en cuatro etapas secuenciales:

• Intercepción y Aislamiento: El agente finaliza la edición de un componente y envía los archivos modificados al arnés. Esta ejecución ocurre dentro de un contenedor efímero (ej. Docker) totalmente aislado de la máquina local y de los servidores de producción para mitigar riesgos de seguridad.
• Análisis Estático y Estilo: El arnés somete los archivos a herramientas automáticas de formateo y estilo (linters como ESLint o Black) y a analizadores estáticos de seguridad. Si el modelo ha inventado una dependencia, ha dejado una credencial expuesta en el código o viola las reglas de tipado estricto, el arnés detiene el proceso.
• Ejecución de la Suite de Pruebas: El arnés lanza de forma automatizada las pruebas unitarias y de integración vinculadas al módulo modificado. Estas pruebas han sido predefinidas por el equipo de ingeniería o generadas a partir de una especificación técnica rígida (Spec-Driven Development).
• Enrutamiento del Output (Paso o Corrección): Si el código supera todas las pruebas del pipeline de forma determinista, el arnés valida la tarea y genera automáticamente una solicitud de extracción (Pull Request) para la revisión final del ingeniero humano. Si se detecta un fallo, el arnés intercepta la salida estándar de error (stderr), captura los logs detallados del compilador o del framework de pruebas, y los inyecta estructuradamente de vuelta en el contexto del agente.

Implementación real y seguridad

Desplegar un arnés profesional requiere tomar decisiones estrictas de infraestructura, poniendo especial atención en dos factores críticos:

• Sandboxing estricto: Permitir que un LLM ejecute código de forma dinámica significa darle la capacidad de correr comandos en el terminal. El arnés debe estar completamente capado a nivel de red (sin acceso a internet a menos que sea estrictamente necesario para descargar dependencias controladas) y con acceso restringido al sistema de archivos para evitar que un bucle defectuoso o una inyección de prompt comprometa la infraestructura de la empresa.

• Condición de parada y control de costes: Un agente atrapado en un error lógico complejo puede intentar corregirse a sí mismo infinitamente, consumiendo miles de tokens en el proceso. El arnés debe configurar límites estrictos de ejecución (ej: un máximo de 3 a 5 intentos de autocorrección). Si el agente no logra superar los tests tras el límite fijado, el arnés aborta la operación, congela el estado y alerta al desarrollador humano proporcionando la traza completa para su intervención.

Conclusiones: El verdadero papel del ingeniero

En esta era de la IA —y ya veremos lo que viene después—, la ingeniería del software seguirá siendo ingeniería del software. No estamos presenciando el fin de nuestra profesión, sino una evolución directa de nuestras responsabilidades. Los ingenieros seguiremos exactamente en nuestro papel de siempre, enfrentados ahora a un nuevo reto arquitectónico: intentar hacer que un modelo probabilístico se comporte de forma determinista.

El tablero se ha movido y el valor ya no está en el acto mecánico de escribir código, sino en crear los sistemas, las especificaciones y los arneses de validación necesarios para garantizar que lo que escriban las máquinas sea bueno, seguro y mantenible. Nuestra función es domar la estadística subyacente de los modelos y transformarla en software predecible de producción.

Seguiremos haciendo lo que sabemos hacer, ingeniería.

Esto no significa necesariamente que vayamos a cancelar nuestras suscripciones hoy mismo. La propuesta de valor de Gemma 4 es, sobre el papel, ayudarnos a ahorrar tokens de nuestras cuentas de pago y ganar privacidad en tareas mecánicas o procesamiento de datos locales. En este post, vamos a comprobar si realmente es capaz de actuar como un agente operativo configurándolo con LM Studio y OpenCode.

El Fundamento: ¿Qué significan los números?

Al buscar Gemma 4, verás nomenclaturas como "26B A4B". Descifrarlas es vital para no bloquear tu máquina:

• Los Parámetros (B): La "B" significa Billions (miles de millones). Son las variables que el modelo ajustó durante su entrenamiento. A más parámetros, mayor capacidad de razonamiento.

• Arquitectura MoE (Mixture of Experts): El modelo 26B A4B tiene 26 mil millones de parámetros totales, pero solo activa 4 mil millones (Active) por cada token generado. Obtienes la inteligencia de un modelo grande con la velocidad de uno pequeño, aunque necesitas RAM para alojar los 26B enteros.

El Formato: GGUF vs MLX

• GGUF: El estándar universal. Es el formato más común para Windows o Linux. Su gran ventaja es el GPU Offloading: si el modelo no cabe entero en tu tarjeta gráfica (VRAM), GGUF permite que la CPU ayude con el trabajo sobrante de forma transparente.

• MLX: El "traje a medida" para Apple Silicon. Si tienes un Mac (M1 a M4), el formato MLX es superior. Está diseñado por Apple para aprovechar la memoria unificada, permitiendo que la CPU y la GPU compartan datos instantáneamente sin cuellos de botella. Es más rápido y eficiente que cualquier otro formato en esta arquitectura.

Cuantización: ¿Por qué hablamos de "Bits"?

Los pesos originales de un modelo ocupan mucha memoria (16 bits). Cuantizar es reducir esos bits para que el modelo quepa en hardware doméstico:

• 8 bits: Casi sin pérdida de inteligencia, pero pesado.

• 4 bits (Q4_K_M): El estándar de oro. El modelo ocupa una cuarta parte del original con una pérdida mínima de razonamiento. Siempre que puedas, apunta a este nivel.

• 2 bits: El modelo se vuelve "torpe" y pierde coherencia lógica. Solo como último recurso.

Licencia Apache 2.0: Un cambio de paradigma

Uno de los aspectos más disruptivos de Gemma 4 no es técnico, sino legal. Históricamente, modelos como Llama o las versiones previas de Gemma utilizaban licencias personalizadas de "pesos abiertos" que imponían restricciones de uso comercial o límites de usuarios.

Gemma 4 rompe con esto al adoptar la licencia Apache 2.0. A diferencia de los modelos anteriores que eran "abiertos pero con condiciones", Apache 2.0 es una licencia permisiva de software libre real. Esto permite a cualquier desarrollador o empresa modificar, distribuir y usar el modelo con mayor libertad.

Más allá del chat: Gemma 4 en Modo Agente

Aquí es donde Gemma 4 brilla frente a sus predecesores. Ha sido diseñada con soporte nativo para function-calling y flujos de trabajo agénticos. Mientras que en LM Studio solo tienes un chat, herramientas como OpenCode permiten que Gemma 4 actúe como un agente de codificación.

¿Qué es OpenCode?

OpenCode es un agente de código abierto para tu terminal o IDE que puede leer tus archivos, ejecutar comandos de shell y aplicar correcciones automáticamente. No solo te da el código; crea el archivo, lo prueba y lo itera hasta que funciona.

Configuración del entorno (paso a paso)

Para tener este flujo de trabajo, necesitamos conectar ambas herramientas:

En LM Studio:

• Descarga Gemma 4 26B A4B (o la versión E4B si tienes poca RAM).

• Ve a la pestaña de Local Server y actívalo en el puerto 1234.

• Asegúrate de subir el GPU Offload al máximo y ajustar el contexto a un mínimo de 32K.

En OpenCode:

Configura el archivo opencode.json para que apunte a tu servidor local:

"lmstudio": {
  "name": "LM Studio",
  "npm": "@ai-sdk/openai-compatible",
  "options": {
    "baseURL": "http://localhost:1234/v1",
    "apiKey": "lm-studio"
  },
  "models": {
    "gemma-4-e2b": {
      "name": "Gemma 4 Local (LM Studio)"
    }
  }
}

Ahora, desde tu terminal, puedes lanzar comandos como: opencode "refactoriza este componente usando hooks de React" y el agente usará a Gemma 4 para realizar la tarea directamente en tu sistema de archivos.

Aunque sobre el papel todo parece sencillo, suele haber un problema con estas configuraciones. Le pides a opencode que haga algo usando gemma 4 y en lugar de esa acción te entrega un mensaje diciendo como se hace. Las herramientas no se terminan de entender entre sí. Raro en informática verdad?.

¿Qué es la parálisis del modelo?

Aunque Gemma 4 está entrenada para actuar como agente, su entrenamiento de refuerzo (RLHF) a menudo prioriza ser un "asistente servicial de chat". Ante una orden como "lista los archivos", el modelo puede caer en la parálisis de explicar en lugar de ejecutar. Te dirá "Para ver los archivos deberías usar ls" en lugar de emitir el comando técnico que OpenCode necesita procesar.

El System Prompt como Protocolo Operativo

Para romper esta inercia, debemos configurar un System Prompt en LM Studio que actúe como un "contrato de ejecución". No le estamos enseñando capacidades nuevas; le estamos indicando qué rol operativo debe asumir en este flujo de trabajo, por ejemplo:

"Eres un asistente de programación integrado en el terminal mediante OpenCode. Obligatorio: Para cualquier acción que requiera el sistema (leer archivos, listar directorios, ejecutar comandos), utiliza siempre el formato de herramientas de OpenCode. No te limites a escribir el comando, ejecútalo."

Este prompt garantiza que el modelo pase del modo "consultor" al modo "ejecutor", emitiendo las señales JSON correctas para que OpenCode actúe sobre tu sistema de archivos.

Conclusión

Gemma 4 es el primer modelo abierto que realmente permite un desarrollo local-first con capacidades agénticas algo serias. Pero seamos realistas, no se puede comparar con los servicios por API de los big players. Es una buena alternativa para no gastar tokens en tareas sencillas. Y Evidentemente, si tienes que trabajar con datos sensibles o necesitas privacidad y trabajar en local, aunque sea limitado, puede ser una gran ayuda.

Esto abre posibilidades interesantes, además, para explorar técnicas de trabajo con IA sin quemar el presupuesto de tokens. Eso sí, no esperes que te permita olvidarte de tus suscripciones actuales, porque las tareas que vas a poder delegar todavía están limitadas. Toca probarla a fondo y ver hasta dónde llega.

La alternativa más eficiente hoy en día es el uso de modelos de lenguaje locales. Gracias a la integración entre Ollama y el proyecto CLI OpenCode, es posible ejecutar un asistente potente directamente en tu máquina, sin costes de suscripción y con total privacidad.

1. Verificación de hardware: ¿Qué puedes ejecutar?

El primer paso para trabajar en local es conocer la capacidad real de tu equipo. No necesitas una estación de trabajo de última generación para tareas de código básicas, pero sí un mínimo de recursos para que la experiencia sea fluida.

Una herramienta muy recomendable para esto es canirun.ai. Este sitio analiza tus especificaciones técnicas (especialmente la memoria RAM y la VRAM de tu tarjeta gráfica) y te indica qué modelos podrás ejecutar.

2. El equilibrio entre potencia y ligereza

Para tareas de automatización y ayuda en el código, la regla general es que un modelo a partir de 7 mil millones de parámetros (7B) suele ser el punto de equilibrio ideal. Son lo suficientemente inteligentes para entender lógica de programación y lo bastante ligeros para correr rápido en hardware doméstico moderno.

En mi caso personal, estoy utilizando actualmente Qwen 2.5 Coder 7B. Para generar pequeños scripts de Python o comparar ficheros JSON de gran tamaño, su respuesta es casi instantánea y la precisión es sorprendente. No obstante, dependiendo de tu hardware (si tienes más de 32GB de RAM o una GPU potente), podrías escalar a modelos de 14B o 32B si buscas un razonamiento más profundo.

3. Configuración simplificada: El comando "mágico"

Aunque OpenCode permite una configuración manual detallada, la forma más rápida y limpia de conectar tus modelos locales con el asistente es utilizar el puente directo que ofrece Ollama.

Una vez tengas instalado Ollama y hayas descargado tu modelo preferido (por ejemplo, con ollama pull qwen2.5-coder), solo tienes que ejecutar:

ollama launch opencode

Este comando es clave porque automatiza toda la configuración: detecta tu instancia local, establece las variables de entorno necesarias y lanza la interfaz de OpenCode lista para trabajar. Evitas así tener que configurar manualmente proveedores externos o servicios en la nube, manteniendo todo el flujo 100% local.

4. Casos de uso ideales

¿Cuándo merece la pena usar este setup en lugar de una IA comercial? Principalmente en tareas de "baja complejidad pero alta fricción":

• Manipulación de archivos: "Crea un script que renombre todos los .txt de esta carpeta a .md y les añada la fecha actual".
• Comparación lógica: "Analiza estos dos directorios y dime qué funciones faltan por sincronizar".
• Limpieza de datos: "Tengo este CSV mal formateado, genera un script para normalizar las columnas".

Conclusión

La combinación de OpenCode y Ollama no solo es una cuestión de ahorro de costes (que también), sino de agilidad y privacidad. Al delegar las tareas más pesadas y repetitivas a un modelo local de 7B, liberas tu presupuesto de tokens para problemas realmente complejos y mantienes un flujo de trabajo en la terminal mucho más dinámico.

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.

Ni magia, ni robots: Solo computación y patrones

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.

¿Por qué ahora?

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:

• Datos masivos: Internet se ha convertido en el campo de entrenamiento más grande de la historia.
• Hardware (GPUs): Necesitábamos chips capaces de hacer billones de operaciones por segundo. La receta ya estaba escrita, pero hasta hace poco no teníamos el horno lo bastante potente para cocinarla.

¿Qué es un LLM en realidad?

Los modelos de lenguaje que usamos hoy son redes neuronales gigantescas entrenadas para una sola tarea: adivinar la siguiente palabra.

• Si escribes "El cielo está...", la red neuronal ha procesado tanta información que sabe que la palabra más probable es "azul".
• No es que "entienda" el concepto de cielo, es que es un maestro de la probabilidad estadística gracias a esa capacidad de computación masiva.

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.

Los tres pilares de lo que puede generar:

1. Texto (LLMs): Como ya vimos, son redes neuronales maestras en la probabilidad. No solo escriben poemas; pueden programar software, resumir libros o traducir idiomas captando los matices culturales, no solo palabra por palabra.
2. Imagen y Arte Visual: Modelos como Midjourney o DALL-E han aprendido la relación entre las palabras y los píxeles. Saben qué aspecto tiene la "luz de atardecer" o el "estilo cyberpunk" y pueden construir una imagen desde cero (píxel a píxel) a partir de una frase.
3. Multimodalidad (El presente): Esto es lo más nuevo y potente. Es la capacidad de la IA para saltar entre formatos. Por ejemplo, una IA que puede "ver" una foto de tu nevera y "escribir" una receta con lo que hay dentro, o una IA que "escucha" un audio y lo convierte en un vídeo.

¿Qué NO es la IA?

• No es un buscador como Google: Un buscador te lleva a una web; una IA genera una respuesta nueva combinando lo que sabe.
• No tiene sentimientos: Si te pide perdón por un error, no es porque esté arrepentida, es porque ha aprendido que "lo siento" es la respuesta socialmente correcta en esa situación.
• No es infalible: Puede equivocarse (y mucho). Es una herramienta de apoyo, no una verdad absoluta.

Cómo aprende una máquina?

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:

1. Entrenamiento: Le "alimentamos" con millones de ejemplos (textos, fotos, códigos).
2. Patrones: La máquina nota que los gatos suelen tener orejas puntiagudas y los perros hocicos más largos.
3. Predicción: Cuando le enseñas una foto nueva, no "sabe" qué es, pero dice: "Hay un 98% de probabilidades de que esto sea un gato".

El espejo humano: El sesgo que nos complica la vida

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).

• Si tú decías: "Me duele la cabeza".
• ELIZA buscaba las palabras clave y respondía: "¿Por qué dices que te duele la cabeza?".

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.

Capítulo 2. El Diccionario de Supervivencia

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.

1. El Token: La unidad de medida

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.

2. La Ventana de Contexto: No es un pozo sin fondo

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.

3. Embeddings: El carnet de identidad de tus datos

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?]

• "PostgreSQL" → [0.9, 0.9, 0.0] (Mucho software, mucha DB, nada animal).
• "MySQL" → [0.9, 0.8, 0.0] (Coordenadas casi idénticas; están "pegados" en el mapa).
• "Delfín" → [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:

1. Trocear el PDF en párrafos.
2. Generar el embedding (las coordenadas) de cada párrafo.
3. Cuando preguntas algo, busca qué trozos del PDF tienen las coordenadas más parecidas a tu duda y solo le pasa esos trozos a la Ventana de Contexto.

Es la base de lo que llamamos RAG: buscar por "sentido común" matemático para ahorrar tokens y ganar precisión.

4. Alucinaciones: Cuando la probabilidad falla

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.

5. Parámetros: El tamaño del "cerebro"

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.

6. Temperatura: ¿Robot o Artista?

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.

7. El RAG: ¿Cómo aprende la IA sobre tus datos?

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.

1. 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.

2. 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.

¿Cómo funciona el RAG por dentro?

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.

¿Por qué herramientas como NotebookLM parecen "acotarse" tanto?

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.

Capítulo 3. El Traductor Universal

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.

1. El código como arquitectura lógica

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.

2. ¿Por qué algunos modelos programan mejor que otros?

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.

3. Imágenes y Vídeo: Traduciendo palabras a píxeles

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.

4. La trampa del dibujo: ¿Por qué la IA no sabe cuántos dedos tiene una mano?

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á.

5. ¿Por qué unos modelos son más rápidos que otros?

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.

Capítulo 4. Instrucciones operativas (Prompting)

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.

1. Rompe el espejo: De la conversación a la instrucción

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".

2. La anatomía de un prompt profesional

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.

3. La técnica de la "Cadena de Pensamiento"

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.

4. El "Few-Shot": Enseñar con ejemplos

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.

• Ejemplo 1: Entrada -> Salida.
• Ejemplo 2: Entrada -> Salida.
• Ahora tú: Entrada -> ...

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.

5. Itera: El prompt perfecto no existe a la primera

En el desarrollo de software, raramente algo funciona a la primera versión. Con el prompting es igual.

• Si el resultado es demasiado largo, pide que lo recorte.
• Si es muy técnico, pide que baje el nivel.
• Si ha olvidado una parte, es posible que hayas superado la ventana de contexto o que la instrucción fuera ambigua.

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.

Capítulo 5. Las Herramientas de Desarrollo de Software

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.

El Agente: El "Cerebro" con iniciativa

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.

MCP: El protocolo que lo cambia todo

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.

• Utilidad real: Puedes decirle: "Busca en mi tabla de usuarios cuáles no han verificado el email y genera un script para enviarles un recordatorio". La IA consulta la estructura real, no se la inventa.

Los MCP son, en esencia, canales de comunicación entre los modelos de IA y herramientas externas.

Las Skills (Herramientas): Las "Manos" del agente

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:

1. Skills Nativas (Las que ya vienen "instaladas")

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.

• Cómo se usan: No tienes que hacer nada. La IA decide usarlas cuando tu petición lo requiere.

2. Skills de Ecosistema (Marketplace de conectores)

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.

3. Skills a medida (Las que tú programas)

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.

¿Cómo encaja todo esto? (Ejemplo práctico)

Imagina que estás trabajando en un mapa con Leaflet. Quieres añadir marcadores desde una base de datos:

1. El Agente es tu interlocutor.
2. El MCP es el puente que le permite leer tu base de datos PostgreSQL local.
3. La Skill es la capacidad que le has dado para "escribir en el archivo 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.

Instrucciones persistentes: Los archivos .md y ficheros de configuración

Si 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.

Capítulo 6. Estrategia de modelos: ¿A quién le pides cada tarea?

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.

1. Modelos de Razonamiento (O-series / "Deep Thinking")

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.

2. Modelos de Desarrollo (Coding Assistants)

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.

3. Modelos "Flash" o Ligeros (Velocidad y Eficiencia)

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.

4. Modelos de Gran Contexto (La memoria infinita)

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.

Capítulo 7. Conclusiones y el camino a seguir

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:

1. La comprensión es tu mejor herramienta

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.

2. Solo estamos rascando la superficie

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.

• Mi consejo: mantén la curiosidad activa.
• No te conformes con lo que aprendiste el mes pasado.
• Investiga, prueba modelos locales, experimenta con nuevos flujos de trabajo y, sobre todo, no te cases con una sola herramienta. La flexibilidad va a ser nuestra mayor ventaja competitiva.

3. Orquestación frente a monopolio

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.

Reflexión final

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.