Y es que el problema no es que se liberen cosas. El problema es que se vacía el significado de una palabra que nos costó décadas construir.

Cuatro libertades, otra vez

En el software libre la brújula siempre fueron las cuatro libertades: usar el programa para cualquier propósito, estudiarlo, modificarlo y compartirlo, con o sin cambios. La Open Source Initiative tradujo esa idea a una definición práctica de licencias. No es un eslogan. Es un contrato social: si no puedes estudiar y cambiar lo esencial, no es libre aunque diga open en la caja.

Con la IA pasó lo previsible. Empezaron a circular modelos con licencias permisivas sobre los ficheros de pesos, y de ahí al titular de “modelo open source” había un paso muy corto y muy tentador. La OSI, después de un proceso largo y ruidoso, publicó la Open Source AI Definition 1.0. No inventa una filosofía nueva: aplica las mismas libertades a un sistema de IA.

Para que un sistema de IA se considere Open Source AI, tiene que permitirte usarlo, estudiarlo, modificarlo y compartirlo sin pedir permiso. Y aquí viene la parte que a mucha gente le molesta: una precondición de esas libertades es tener acceso a la forma preferida de hacer modificaciones. En software clásico eso es, básicamente, el código fuente. En aprendizaje automático no basta con un binario bonito.

De qué está hecho un modelo (y qué habría que liberar)

Un LLM no es un programa al uso. Es más bien el resultado de un proceso industrial: datos, código, cómputo y parámetros. Si uno se pregunta qué habría que liberar para que las cuatro libertades sean reales, la OSI lo deja bastante claro en tres bloques.

Información sobre los datos. No siempre se puede redistribuir el dataset entero —hay derechos de terceros, datos personales, contratos— y la definición no es ingenua al respecto. Pero sí exige información suficientemente detallada como para que una persona competente pueda construir un sistema sustancialmente equivalente: procedencia, alcance, cómo se obtuvieron y seleccionaron los datos, etiquetado, filtrado, qué partes son públicas y dónde están, qué partes se compran a terceros y a quién. Sin eso, “estudiar el sistema” se queda en mirar el escaparate.

Código. El código completo para entrenar y ejecutar el sistema. Procesado y filtrado de datos, entrenamiento con sus argumentos y ajustes, validación, librerías de apoyo, tokenizadores, código de inferencia, arquitectura. Es decir: no solo el script de demo que carga el modelo y te contesta en el terminal.

Parámetros. Los pesos y demás configuración aprendida. Idealmente también checkpoints intermedios y estado del optimizador cuando aplique. Esto es lo que la gente descarga cuando dice “me he bajado el modelo”.

Si te fijas, liberar solo el último de los tres es como publicar el ejecutable compilado y decir que el software es libre porque cualquiera puede copiar el binario. Puedes usarlo, a veces incluso adaptarlo un poco, pero no puedes reconstruir el camino. Y sin el camino, la libertad de estudiar y modificar de verdad se queda a medias.

Hay otra forma de verlo, más de oficio: el valor de un modelo grande no está solo en el fichero final. Está en la receta, en las decisiones de filtrado, en lo que se dejó fuera, en lo que se reforzó en el alineado, en los fallos que se corrigieron a mitad de entrenamiento. Esa es la parte que casi nunca se abre del todo. Y es justo la parte que permitiría auditar sesgos, reproducir resultados o mejorar el sistema desde fuera sin empezar de cero cada vez.

Entonces, ¿qué son los open weights?

Pues eso: pesos abiertos. Modelos en los que se publican los parámetros finales —a veces bajo Apache 2.0, MIT u otra licencia razonable; a veces bajo licencias propias con condiciones extra— para que cualquiera pueda descargarlos, ejecutarlos, hacer fine-tuning o montar un servicio encima.

No es poca cosa. Respecto a un modelo solo accesible por API, la diferencia es enorme. Puedes correrlo en tu máquina, no mandar tu código a un tercero, elegir el hardware, afinarlo para un dominio, o montar infraestructura propia. En un país, en una empresa o en una administración, eso cambia el tablero de la dependencia. Yo, que estos meses he estado usando modelos en local para escribir, programar y trastear con mapas, lo noto cada día: no es lo mismo alquilar inteligencia por token que tener el artefacto en casa.

Pero open weight no es open source en el sentido de la definición de la OSI. La propia OSI lo explica sin rodeos: los pesos abiertos no incluyen, por lo general, el código de entrenamiento completo ni la transparencia fuerte sobre los datos. Te dan el resultado del entrenamiento, no el proceso. Sirven para desplegar y adaptar; sirven mucho menos para reproducir, auditar de verdad o colaborar en la raíz del sistema.

Es un término útil, siempre que no se use como disfraz. El problema empieza cuando el marketing convierte “pesos abiertos” en “open source” y nos vamos acostumbrando a la trampa. Verdades a medias, otra vez: sí, es más abierto que un modelo cerrado; no, no es software libre con otro nombre.

Licencias que parecen libres (y no siempre lo son)

Aquí el software libre también tiene memoria. Hay licencias que parecen permisivas y luego meten una cláusula que rompe la libertad de uso para cualquier propósito, o la de compartir sin pedir permiso. En modelos pasa igual. Hay familias muy populares cuya licencia permite mucho… hasta que superas un umbral de usuarios o compites en cierto terreno. Otras son genuinamente permisivas sobre los pesos, y aún así el entrenamiento sigue siendo secreto industrial.

Desde el punto de vista ético del software libre, la pregunta no es solo “¿puedo descargarlo?”. Es “¿puedo usarlo para lo que me dé la gana, entender cómo se hizo, cambiarlo de verdad y pasar ese cambio a otra persona sin negociar con el dueño original?”. Si alguna de esas puertas está cerrada o solo entreabierta, llamarlo open source es, como mínimo, un abuso del diccionario.

Y conste que el modelo de negocio de no abrir el entrenamiento es lícito. Faltaría más. Igual que es lícito vender software privativo. Lo que no me parece de recibo es apropiarse del prestigio moral y técnico que el movimiento libre construyó, para vender como libertad lo que en realidad es una distribución controlada de un artefacto.

Por qué importa, más allá del purismo

Se puede pensar que esto es discusión de puristas. Yo creo que no. Cuando una administración pública o una empresa estratégica apuesta por un modelo “abierto”, la letra pequeña decide si estás reduciendo dependencias o solo cambiando de dueño. Si solo tienes pesos, puedes ejecutar y adaptar; si mañana necesitas reentrenar desde una base auditable, entender un fallo sistemático o demostrar cómo se construyó el sistema, te encuentras otra vez pidiendo permiso o reinventando la rueda.

En software libre aprendimos que la conveniencia mueve más que la filosofía. Por eso el statu quo siempre es frágil. Ahora mismo conviene a bastantes actores soltar pesos y quedarse el resto: ganan adopción, narrativa de apertura y una comunidad que mejora el producto en la capa de arriba, sin tocar la fábrica. Es un avance respecto al secretismo total. También es un techo de cristal si nos dormimos en la etiqueta.

A mí los pesos abiertos me parecen una buena noticia, y los uso. Me parece mejor un Llama, un Qwen, un Gemma o un DeepSeek descargable que un muro de API con términos que cambian cada trimestre. Pero no confundo el alivio con la llegada a destino. Open weight es un paso. Open source AI, de verdad, es otra cosa.

Mientras tanto, en los despachos

Y mientras debatimos esto en blogs y foros, gobiernos y agencias de supervisión de la IA hablan sin parar de ética, de confianza, de IA centrada en las personas. La pregunta es en qué se están fijando de verdad.

La respuesta, simplificando, es casi siempre la misma: en el uso. El Reglamento europeo de IA es el ejemplo más claro. Clasifica sistemas por riesgo, prohíbe prácticas inaceptables, exige supervisión humana, documentación, trazabilidad, etiquetado de contenido generado y, para los modelos de propósito general, transparencia y ciertas obligaciones sobre derechos de autor y seguridad. La Oficina Europea de IA y, aquí en España, la AESIA, nacen sobre todo para vigilar eso: que no se despliegue cualquier cosa en sanidad, empleo, fronteras o justicia; que la ciudadanía sepa cuándo habla con una máquina; que haya alguien a quien reclamar cuando el sistema falla.

Todo eso es necesario. Faltaría más. Un modelo libre mal usado también puede hacer daño, y el derecho a no ser discriminado por un algoritmo no se resuelve solo con una licencia OSI. Pero si miras el tablero con gafas de software libre, se ve el hueco enseguida: se regula el comportamiento del sistema en producción mucho más que la libertad de estudiarlo y reconstruirlo.

Cuando el reglamento pide un resumen público del contenido de entrenamiento de los modelos de propósito general, no está pidiendo el dataset ni la receta completa. Pide un mapa a grandes rasgos: fuentes, dominios, algo de procesado. Útil para ejercer derechos y para periodistas o investigadores con paciencia. Insuficiente para lo que la OSI llama la forma preferida de hacer modificaciones. Transparencia de cumplimiento no es lo mismo que apertura radical. Se parece más a la ficha técnica de un electrodoméstico que al código fuente de un compilador.

Lo mismo pasa con buena parte de las estrategias nacionales y de las “agencias de IA ética”. El centro de gravedad está en el riesgo del despliegue, en la gobernanza del proveedor, en la evaluación de impacto, en no comprar sistemas prohibidos. Casi nunca en exigir —ni siquiera en priorizar de verdad en la compra pública— modelos que uno pueda auditar de extremo a extremo, reentrenar con datos propios o mantener sin volver a pasar por caja del fabricante. Se habla de soberanía tecnológica, y a veces se financia un modelo europeo “abierto”; luego, al mirar la letra pequeña, vuelves a encontrarte pesos, licencias a medias y poca fábrica a la vista.

No es que no se mueva nada. Hay iniciativas de modelos abiertos con dinero público, hay excepciones o tratos más suaves para ciertos sistemas de código abierto en el propio reglamento, hay gente dentro de la administración que entiende la diferencia. Pero la corriente principal sigue siendo otra: ética del uso, no ética de la libertad del artefacto. Como si bastara con poner guardarraíles al coche sin preguntar si podemos abrir el capó, fabricar recambios o enseñar a otra persona a arreglarlo.

Desde el mundo del software libre, esa frontera es vieja. Llevamos años diciendo que no basta con que el programa “haga las cosas bien” si no puedes mirar cómo las hace y cambiarlas cuando dejen de hacerlas bien. Con la IA el argumento se vuelve más urgente, no menos: si el Estado y las agencias se conforman con fichas de transparencia y evaluaciones de riesgo sobre cajas negras —aunque sean cajas negras con pesos descargables—, estaremos domesticando el relato ético sin acercarnos de verdad a modelos que se parezcan al software libre.

En nuestras manos está, también como ciudadanía y como sector técnico, empujar la conversación un poco más lejos. No solo ¿se usa bien esta IA?, sino ¿podemos estudiar, modificar y compartir de verdad el sistema con el que nos gobiernan o nos atienden?. Porque si la respuesta es no, la ética se queda en el manual de instrucciones. Y el manual, ya se sabe, lo escribe quien tiene la llave de la fábrica.

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.