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

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

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

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

La Infraestructura Agéntica: El nuevo Stack

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

El Motor de Razonamiento (Capa de Cómputo)

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

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

El Protocolo MCP (Capa de Conectividad)

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

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

Las Skills

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

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

Arquitectura Multi-Agente (Capa de Gestión)

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

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

RAG Estructurado (Capa de Memoria)

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

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

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

El Bucle PEV: Planificar, Ejecutar, Verificar

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

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

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

O al menos, esa es la teoría.

Las claves de la Ingeniería Agéntica

1. El LLM como motor de razonamiento

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

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

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

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

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

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

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

Modelos de Razonamiento Profundo (Los Arquitectos)

Estos modelos priorizan el acierto sobre la velocidad.

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

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

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

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

Modelos de Gran Contexto (Los Bibliotecarios)

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

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

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

El coste del razonamiento

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

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

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

Cómo elegirlos

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

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

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

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

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

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

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

Integración de Skills y Evaluación de MCPs

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

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

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

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

Paralelización mediante Agentes y Subagentes

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

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

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

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

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

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

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

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

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

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

Anatomía de una Especificación Ejecutable por IA

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

Una spec efectiva debe contener tres capas de aislamiento:

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

El Ciclo de Desarrollo Guiado por Especificaciones

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

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

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

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

¿Qué es un Harness de Ingeniería?

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

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

La arquitectura del bucle de autocorrección

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

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

Implementación real y seguridad

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

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

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

Conclusiones: El verdadero papel del ingeniero

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

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

Seguiremos haciendo lo que sabemos hacer, ingeniería.

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

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

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

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

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

El Formato: GGUF vs MLX

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

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

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

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

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

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

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

Licencia Apache 2.0: Un cambio de paradigma

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

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

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

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

¿Qué es OpenCode?

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

Configuración del entorno (paso a paso)

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

En LM Studio:

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

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

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

En OpenCode:

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

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

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

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

¿Qué es la parálisis del modelo?

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

El System Prompt como Protocolo Operativo

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

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

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

Conclusión

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

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

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

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

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

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

2. El equilibrio entre potencia y ligereza

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

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

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

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

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

ollama launch opencode

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

4. Casos de uso ideales

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

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

Conclusión

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

Este post, más largo de lo habitual, nace de una necesidad personal: la de poner en orden mis propias notas, investigaciones y aprendizajes. Al final, escribir es la mejor forma que conozco de estructurar las ideas y separar el grano de la paja. Mi intención con esta serie no es venderte la última herramienta de moda, sino bajar a tierra lo que está pasando y cómo podemos entender esta tecnología sin que nos explote la cabeza.

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

A veces parece que hay una especie de "niebla" mental sobre la IA. Parece que estamos ante un oráculo o un cerebro consciente. Lo que veíamos en las películas se ha hecho realidad, y tenemos entre nosotros un Skynet o HAL de verdad. Pero si abrimos el capó y miramos los engranajes, la realidad es mucho más terrenal.

En esencia, la IA es software diseñado para imitar capacidades humanas, pero con una diferencia fundamental respecto al desarrollo tradicional. Si un programa clásico es una receta rígida donde yo, como programador, defino que "si pasa A, haz B", la IA es un aprendiz de patrones. No necesita que le dé todas las reglas por escrito; ella misma encuentra las regularidades en los datos. Pero ojo, no "piensa". Es pura estadística aplicada a una escala masiva.

¿Por qué ahora?

Algo que solemos ignorar es que las redes neuronales no son una novedad de hace dos años. La idea de imitar las conexiones sinápticas para procesar datos es una teoría que ya se manejaba en los años 50. Entonces, ¿por qué no tuvimos este "boom" hace décadas?

Para que estas redes neuronales "despertaran", han necesitado dos ingredientes que solo coinciden ahora:

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

¿Qué es un LLM en realidad?

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

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

Hasta hace nada, la IA se dedicaba a clasificar: te decía si un correo era spam o si en una foto aparecía un gato. Era IA discriminativa. Lo que ha cambiado las reglas del juego es la IA Generativa.

Como su nombre indica, su superpoder es crear contenido nuevo. Ha pasado de organizar carpetas a ser capaz de redactar un texto, generar una imagen desde cero o, lo que a muchos nos interesa, escribir una función de código que funciona a la primera. No es que "sepa" lo que hace, es que sabe qué palabra o píxel tiene más probabilidades de ir después del anterior.

Los tres pilares de lo que puede generar:

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

¿Qué NO es la IA?

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

Cómo aprende una máquina?

Imagina que quieres enseñarle a un niño a distinguir entre un perro y un gato. No le das un manual de 500 páginas sobre anatomía felina; simplemente ve un perro y le dices: "Esto es un perro", ve un gato y le dices "Esto es un gato". Aprende por repetición y asociación.

Con la IA pasa exactamente lo mismo:

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

El espejo humano: El sesgo que nos complica la vida

Aquí entra un tema que me parece clave para entender por qué a veces nos frustramos con estas herramientas. En los años 60, Joseph Weizenbaum creó ELIZA, un chatbot básico que imitaba a un terapeuta. Weizenbaum lo programó para imitar a un terapeuta rogeriano (una técnica de psicología que consiste en devolverle al paciente sus propias palabras).

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

Se quedó horrorizado al ver que la gente se abría emocionalmente con la máquina, creyendo que los entendía.

Tenemos una tendencia innata a humanizar la tecnología (antropomorfismo). Si algo nos responde con lenguaje fluido, nuestro cerebro asume que "hay alguien ahí". Nos enfadamos con el chat o le hablamos con rodeos. El problema es que, al tratarla como a un humano, perdemos la especificidad operativa. Olvidamos que estamos ante una herramienta de cálculo y no ante un oráculo.

Para sacarle partido de verdad a la IA, el primer paso es romper ese espejo: menos charla y más instrucciones precisas. No pienses que "entiende" tu problema, cuando en realidad sólo está haciendo estadística avanzada para darte la respuesta más probable. Entender esto es la clave para saber como sacarle partido, tratándola como lo que es: una herramienta.

Capítulo 2. El Diccionario de Supervivencia

En el post anterior hablábamos de que la IA no es magia, sino computación y patrones. Pero para movernos con soltura en este ecosistema y, sobre todo, para no frustrarnos cuando las cosas no salen como esperamos, necesitamos hablar el mismo idioma que la máquina.

Para manejar la IA con criterio, no basta con saber qué botones pulsar. Necesitas entender los mecanismos que definen su comportamiento. Si ignoras estos conceptos, estarás usando la herramienta a ciegas.

1. El Token: La unidad de medida

La IA no procesa palabras completas como nosotros; trocea el texto en tokens. Un token puede ser una palabra corta, una sílaba o incluso un signo de puntuación.

¿Por qué te importa? Porque todo en este mundo se mide en tokens: desde la capacidad de respuesta hasta lo que te cobran por las APIs. Si entiendes que la IA "trocea" la información, entenderás por qué a veces le cuesta tanto contar letras de una palabra o hacer rimas perfectas: ella no ve letras individuales, ve bloques de datos.

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

Este es, probablemente, el concepto más crítico. La Ventana de Contexto es la "memoria de trabajo" o la capacidad de atención de la IA en una sola sesión. Imagina que es una mesa de escritorio: cuando la mesa se llena, para poner un papel nuevo tienes que tirar uno de los que ya estaban.

• El peligro del truncamiento: Si le pasas un PDF de 200 páginas a una IA que solo tiene capacidad para 50, la IA no te avisará de que no llega. Simplemente cortará el texto sobrante. Tú creerás que ha analizado todo el archivo, pero la información del final (donde quizás estaba la conclusión o la cláusula clave) será invisible para ella.

• La pérdida en el medio: Incluso si el texto cabe, se ha demostrado que la IA recuerda mejor el principio y el final de lo que lee. Los detalles que quedan enterrados en el centro del documento suelen diluirse.

3. Embeddings: El carnet de identidad de tus datos

Si la Ventana de Contexto es nuestra "mesa de trabajo", los Embeddings son el sistema de archivado inteligente que nos permite no saturarla.

Para que una IA entienda la relación entre las ideas, utiliza estos "embeddings": una lista de números (vectores) que sitúa cada frase en un mapa gigante de miles de dimensiones. Para entenderlo como desarrolladores, bajémoslo a un ejemplo de solo 3 coordenadas: [¿Es software?, ¿Es una base de datos?, ¿Es un animal?]

• "PostgreSQL" → [0.9, 0.9, 0.0] (Mucho software, mucha DB, nada animal).
• "MySQL" → [0.9, 0.8, 0.0] (Coordenadas casi idénticas; están "pegados" en el mapa).
• "Delfín" → [0.0, 0.0, 0.9] (Vive en un barrio matemático totalmente distinto).

¿Por qué te importa esto en la práctica? Piensa en cuando subes un PDF a una IA. La IA no "lee" las 200 páginas cada vez que le preguntas algo. Lo que hace es:

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

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

4. Alucinaciones: Cuando la probabilidad falla

La IA Generativa es una máquina de predecir la siguiente palabra más probable. No tiene una base de datos de "verdades".

• El riesgo: Como está diseñada para ser coherente y elocuente, cuando no sabe algo, "rellena" el vacío con información que suena muy profesional pero que es falsa. No te miente por maldad; simplemente está cumpliendo su función de completar texto basándose en patrones.

• Mi consejo: Nunca la uses como fuente primaria para datos biográficos, leyes o fechas. Úsala para procesar datos que tú le entregues, no para que ella te los traiga de fuera.

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

Seguro que has oído que X modelo tiene "billones de parámetros". Un parámetro es, básicamente, una conexión ajustable en la red neuronal (como los cables en un cuadro de conexiones).

• Más parámetros suelen significar más matices, mejor comprensión de la ironía y más "sabiduría" generalista.

• Sin embargo, un modelo con menos parámetros pero mejor entrenado (con datos de mayor calidad) puede ser mucho más eficaz para tareas específicas, como programar, y además será mucho más rápido y barato.

6. Temperatura: ¿Robot o Artista?

Aunque a veces está oculto en la interfaz, la mayoría de los modelos tienen un ajuste de Temperatura.

• Temperatura baja (Cercana a 0): La IA es conservadora y previsible. Es el modo "ingeniero": ideal para código, resúmenes técnicos o datos.

• Temperatura alta (Cercana a 1): La IA se arriesga más, elige palabras menos probables. Es el modo "creativo": ideal para lluvia de ideas o escribir ficción.

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

Seguramente has probado herramientas como NotebookLM o le has subido un PDF a ChatGPT y te has sorprendido: de repente, la IA sabe todo sobre ese documento técnico de 50 páginas y sus respuestas se "acotan" estrictamente a lo que pone ahí. No se inventa cosas de internet, se centra en tus datos.

¿Cómo es posible? ¿Ha "estudiado" la IA tu documento y se lo ha aprendido para siempre? No. Lo que estás viendo en acción es una técnica llamada **RAG (Retrieval-Augmented Generation

Para entender el RAG, olvida la idea de que la IA "aprende". Imagina que la IA es un profesor superdotado que sabe de todo, pero al que le pides que haga un examen sobre un proyecto tuyo que él nunca ha visto.

1. Sin RAG (Entrenamiento): Sería como obligar al profesor a memorizar tu proyecto antes del examen. Es costoso, lento y, si mañana cambias una frase del proyecto, el profesor ya tiene información obsoleta en su cabeza.

2. Con RAG: Es como si el profesor fuera al examen con tus apuntes en la mano. No necesita memorizarlos; simplemente, cuando le haces una pregunta, él busca rápidamente en los apuntes, lee el párrafo relevante y te responde usando su inteligencia pero basándose solo en lo que pone el papel.

¿Cómo funciona el RAG por dentro?

Cuando subes ese PDF, el sistema hace tres cosas en milisegundos:

• Recuperación (Retrieval): Gracias a los Embeddings (los "carnets de identidad numéricos" que vimos antes), el sistema sabe qué párrafos de tu PDF están matemáticamente cerca de tu pregunta. Si preguntas por el "presupuesto", el sistema localiza instantáneamente la página donde están las cifras.

• Aumento (Augmentation): El sistema coge esos párrafos y los "pega" en un prompt invisible para ti que dice: "Aquí tienes estos fragmentos de texto. Úsalos como única fuente de verdad".

• Generación (Generation): La IA redacta la respuesta. Sigue usando su "cerebro" (su entrenamiento previo) para entender el lenguaje y redactar bien, pero los datos los saca exclusivamente de los fragmentos que le acabas de pasar.

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

Te habrás fijado en que si le preguntas a NotebookLM algo que no está en tus archivos, a veces te dice: "No puedo responder porque esa información no aparece en los documentos".

Esto no es porque la IA se haya vuelto "tonta" o haya olvidado lo que sabía. Es porque el sistema RAG tiene una instrucción de seguridad muy estricta: priorizar siempre el libro que tiene abierto. Esto es lo que nos da la seguridad de que la IA no va a "alucinar" o inventarse datos basándose en información genérica de internet.

Capítulo 3. El Traductor Universal

Si has seguido los posts anteriores, ya tienes claro que la IA no es un oráculo, sino un procesador de patrones. Pero aquí es donde la cosa se pone interesante: ¿Cómo es posible que un "Modelo de Lenguaje" (LLM) sea capaz de escribir una función en Python, diseñar un mapa web en Leaflet o generar una imagen de un astronauta a caballo?

La respuesta corta es que, para una IA, todo es lenguaje. Pero vamos a desglosarlo un poco mejor, porque entender esto es lo que te permite pasar de "jugar" con la IA a usarla como una herramienta de ingeniería real.

1. El código como arquitectura lógica

Para nosotros, programar es crear lógica. Para un LLM, aprender a programar no ha sido muy distinto a aprender inglés o gallego. El código tiene una sintaxis, una gramática y, sobre todo, una estructura previsible.

La IA ha sido entrenada con casi todo el código público que existe (pensemos en el volumen de datos de GitHub). Lo que hace no es "entender" informática, sino entender la secuencia lógica. Sabe que después de un if suele venir una condición y, tras ella, una indentación con una instrucción. Al ser un entorno tan rígido y con reglas tan claras, a la IA le resulta más fácil ser precisa programando que escribiendo poesía.

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

No es que unos sean "más listos" que otros, es una cuestión de dieta de datos.

• Los generalistas: Han leído de todo, incluyendo tutoriales obsoletos y código basura de foros olvidados. Por eso a veces te sugieren soluciones que "huelen" a 2010.

• Los especialistas (Fine-tuning): Son modelos que han pasado por un "posgrado". Se les ha entrenado específicamente con repositorios de alta calidad y se les ha refinado mediante humanos que les dicen: "Esta solución funciona, pero esta otra es más eficiente y segura". Es la diferencia entre un aprendiz y un senior.

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

Aquí es donde ocurre lo que llamamos multimodalidad. Al principio, esto era como un juego de teléfonos descompuestos: tenías un modelo que entendía el texto y le pasaba la orden a otro que generaba la imagen.

Hoy, los modelos más potentes son nativos multimodales. Desde el minuto uno de su entrenamiento, han visto imágenes y han leído sus descripciones simultáneamente. Han aprendido que el concepto lingüístico "atardecer" está vinculado a ciertos patrones de color y degradados de píxeles. Ya no "traducen" de un idioma a otro; entienden el mundo en ambos formatos de forma nativa.

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

Seguro que has visto esas imágenes con manos de seis dedos. Esto explica perfectamente por qué la IA no tiene un modelo mental de la realidad. Ella no sabe qué es una "mano" ni para qué sirve; solo sabe que en las fotos etiquetadas como "mano" suele haber formas alargadas de color carne. Si estadísticamente el patrón es confuso, el resultado visual también lo será.

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

A veces te encuentras con modelos que parecen un rayo y otros que escriben a paso de tortuga. Esto depende del número de parámetros (el tamaño del "cerebro") y del hardware que tengan detrás.

• Modelos Flash/Mini: Pocos parámetros, muy rápidos, ideales para tareas sencillas.

• Modelos de razonamiento: Son deliberadamente más lentos porque están programados para "pensar antes de hablar", verificando sus propios pasos lógicos internamente.

Entender que la IA es un motor de razonamiento estadístico cambia la forma en la que le pides las cosas. Si le pides código, dale la estructura. Si le pides una imagen, describe los patrones. No estás hablando con un artista ni con un colega senior; estás interactuando con un traductor universal de patrones que es tan bueno como la información con la que lo alimentas.

Capítulo 4. Instrucciones operativas (Prompting)

Si has llegado hasta aquí, ya sabes que la IA no te "entiende" en el sentido humano de la palabra; lo que hace es procesar una instrucción y calcular la respuesta más probable basándose en su entrenamiento. Por eso, el "arte" de dar instrucciones (que algunos llaman pomposamente Prompt Engineering) no consiste en ser educado, sino en ser meticuloso.

En mi día a día con el código o los mapas, si una consulta SQL no devuelve lo que quiero, no me enfado con la base de datos; reviso la sintaxis. Con la IA hay que aplicar la misma mentalidad.

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

El mayor error es tratar el chat como una charla de café. Escribir "Oye, ¿sería posible que quizás me ayudaras a resumir esto si no es mucha molestia?" solo añade ruido innecesario a la ventana de contexto.

La IA no necesita cortesía, necesita parámetros. Pasa de la "charla" a la instrucción operativa. Sé directo. Usa verbos de acción: "Resume", "Analiza", "Escribe", "Extrae".

2. La anatomía de un prompt profesional

Para que una instrucción sea robusta, yo suelo usar una estructura de tres capas:

• Rol (¿Quién eres?): Dile a la IA cómo debe comportarse. No es lo mismo pedirle algo a un "asistente genérico" que a un "ingeniero senior experto en PostgreSQL". Definir el rol acota el "espacio" de donde la IA sacará la información.

• Contexto y Tarea (¿Qué hacemos?): Sé específico. En lugar de "haz un resumen", usa "resume los 3 puntos clave de este texto técnico para un cliente que no sabe de tecnología".

• Formato de salida (¿Cómo lo quiero?): Define el output. ¿Quieres un JSON? ¿Una tabla Markdown? ¿Un párrafo de 50 palabras? Si no lo defines, la IA elegirá por ti, y probablemente no sea lo que necesitas.

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

Como vimos en el post anterior, algunos modelos programan mejor porque "piensan" antes de hablar. Tú puedes forzar ese comportamiento en cualquier modelo usando una técnica sencilla: pídele que razone paso a paso.

Si le lanzas un problema complejo de golpe, es más fácil que alucine. Si le dices: "Analiza el problema, desglósalo en pasos lógicos y, finalmente, dame la solución", la probabilidad de éxito aumenta drásticamente. Estás obligando a la red neuronal a seguir un camino lógico trazable.

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

A veces, una descripción no basta. Si quieres que la IA escriba con un estilo concreto o clasifique datos de una forma específica, dale ejemplos.

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

Es la forma más rápida de que la IA capte el patrón que buscas sin tener que escribir un manual de instrucciones infinito que sature los tokens de la sesión.

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

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

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

Dominar el prompting no es aprenderse "fórmulas mágicas", es aprender a comunicarte con una máquina de forma estructurada. Es, en esencia, volver a ser un poco artesano de la palabra para obtener resultados de ingeniería.

Capítulo 5. Las Herramientas de Desarrollo de Software

Si eres de los que, como yo, empezó usando la IA solo para preguntarle cómo centrar un div o para que te explicara una función compleja de PostgreSQL, tengo que decirte que te estás quedando en la superficie. En los últimos meses, el ecosistema ha dado un salto gigante: hemos pasado de "hablar con la IA" a "integrar la IA en nuestro entorno de desarrollo".

Como ingeniero, siempre busco soluciones que resuelvan problemas reales. Y aquí el problema real es la fricción: copiar código del chat, pegarlo en el editor, ver que falla porque la IA no conoce mi base de datos, y volver a empezar. Para resolver esto, han aparecido tres conceptos clave: Agentes, Skills y el protocolo MCP.

El Agente: El "Cerebro" con iniciativa

Un chat normal es pasivo: tú preguntas, él responde. Un Agente es un modelo de lenguaje al que le hemos dado un objetivo y autonomía para usar herramientas.

• Diferencia clave: Si le pides a un chat "arregla este bug", te dará el código. Si se lo pides a un Agente, él leerá el archivo, ejecutará el código para ver el error, buscará una solución y aplicará el parche.

• En resumen: Es un LLM que puede ejecutar un ciclo de: Pensar -> Actuar -> Observar el resultado.

MCP: El protocolo que lo cambia todo

Hace poco escribí en el blog sobre cómo conectar PostgreSQL a un agente de IA mediante MCP (Model Context Protocol). 

• ¿Qué es? Es un estándar abierto que permite que cualquier IA se conecte de forma segura a tus datos locales.

• ¿Para qué sirve? En lugar de copiar y pegar el esquema de tu base de datos en el chat (con el riesgo de seguridad y el gasto de tokens que eso supone), el agente "habla" directamente con tu base de datos a través de MCP.

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

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

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

Una de las dudas más comunes es cómo "aprende" la IA a hacer cosas nuevas. Las Skills (o herramientas) no son algo que la IA traiga de serie (aunque algunas sí) por "saber mucho", sino funciones que tú, como desarrollador, tienes que habilitar o programar.

Podemos dividirlas en tres niveles según su origen:

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

Muchas herramientas de IA (como ChatGPT, Claude o Gemini) ya traen herramientas de serie. Por ejemplo, el acceso a internet, la ejecución de código Python en un entorno seguro (Code Interpreter) o la generación de imágenes.

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

2. Skills de Ecosistema (Marketplace de conectores)

Aquí es donde entra lo que comentábamos del MCP. Existe ya un ecosistema de servidores MCP creados por la comunidad.

• Cómo se instalan: Es muy parecido a instalar una dependencia en un proyecto. Te descargas un servidor MCP ya hecho (por ejemplo, uno para Google Drive, otro para Slack o el de PostgreSQL que mencioné en mi post ).

• Configuración: Simplemente editas un archivo de configuración en tu entorno (como el claude_desktop_config.json) y le dices dónde está ese servidor. A partir de ese momento, la IA "ve" esa nueva habilidad.

Los MCP dotan a los modelos de IA de nuevas Skills.

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

Si necesitas que la IA haga algo muy específico de tu flujo de trabajo (por ejemplo, "publicar este borrador en mi blog de Hugo"), tienes que crear la Skill tú mismo.

• Cómo se hacen: No es más que una función en Python o TypeScript.

• El "Contrato": Lo más importante no es solo el código, sino la descripción. Tienes que escribir un pequeño texto explicando a la IA para qué sirve esa función y qué parámetros necesita. La IA lee esa descripción y, cuando ve que tu petición encaja, "llama" a tu función.

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

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

1. El Agente es tu interlocutor.
2. El MCP es el puente que le permite leer tu base de datos PostgreSQL local.
3. La Skill es la capacidad que le has dado para "escribir en el archivo mapa.js".

Tú solo dices: "Añade al mapa los puntos de la tabla 'eventos' de mi base de datos". El Agente usa el MCP para consultar la tabla, procesa los datos y usa su Skill de escritura para actualizar tu código.

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

Si estamos tratando de ser meticulosos y evitar la "charla" innecesaria, no tiene sentido repetirle nuestras preferencias a la IA en cada nuevo chat. Aquí es donde entran los archivos de configuración de contexto, como los ai.md, agents.md o los .cursorrules.

• ¿Qué son? Son archivos de texto plano que colocas en la raíz de tu proyecto. En ellos defines las reglas del juego: qué librerías prefieres (por ejemplo, Leaflet sobre OpenLayers ), cómo quieres que se estructure el código o qué estándares de seguridad debe seguir.

• Instrucciones del modelo (System Prompts): Muchos modelos permiten ahora adjuntar un archivo de "instrucciones personalizadas". En lugar de un prompt efímero, es un contrato permanente. Si en mi blog hablo de usar PostgreSQL con MCP, en mi archivo de agente definiré que siempre que consulte la base de datos, use ese protocolo específico.

• La ventaja técnica: Al tener estas instrucciones en un fichero .md, puedes versionarlas con Git. Si cambias tu forma de trabajar o añades una nueva Skill a tu flujo, el Agente se actualiza automáticamente al leer el archivo.

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

A estas alturas de la guía, ya tienes el entorno configurado y sabes cómo dar instrucciones. Pero te falta lo más importante para el día a día: saber qué modelo elegir. Hoy en día no hay una sola "IA"; hay un catálogo creciente de modelos con especialidades muy distintas.

Si intentas resolver un problema de lógica compleja con un modelo rápido, te dará una respuesta errónea con mucha seguridad. Si usas un modelo pesado para corregir una falta de ortografía, estás matando moscas a cañonazos. Vamos a poner orden en este ecosistema.

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

Estos son los modelos "lentos" por diseño (como la serie o1 o los nuevos modelos de pensamiento profundo). Su característica principal es que utilizan una cadena de pensamiento interna antes de escribir la primera palabra.

• Cuándo usarlos: Problemas de lógica pura, matemáticas, arquitectura de software compleja o cuando necesitas que la IA verifique su propia respuesta varias veces.

• La clave: Úsalos cuando el "qué" es difícil de resolver y requiere un plan previo. No esperes velocidad; espera acierto.

2. Modelos de Desarrollo (Coding Assistants)

Aunque los generalistas programan bien, existen versiones optimizadas para el código (como los que alimentan a Cursor o versiones específicas "Coder"). Estos modelos han tenido una dieta de entrenamiento basada en repositorios de alta calidad y entienden mejor la jerarquía de un proyecto.

• Cuándo usarlos: Para refactorizar código, crear tests unitarios o entender cómo una función en db.py afecta a tu mapa en index.html.

• El consejo: Úsalos dentro de tu IDE. Son modelos que brillan cuando tienen acceso a tu sistema de archivos.

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

Son los modelos pequeños (como GPT-4o-mini, Claude Haiku o Gemini Flash). Tienen menos parámetros, lo que los hace increíblemente rápidos y económicos en términos de tokens.

• Cuándo usarlos: Tareas mecánicas o de bajo razonamiento. Traducir un texto, resumir un hilo de emails, formatear un JSON o cambiar el tono de un párrafo.

• La ventaja: Su latencia es mínima. En el tiempo que un modelo de razonamiento empieza a "pensar", este ya ha terminado la tarea.

4. Modelos de Gran Contexto (La memoria infinita)

Hay modelos específicos que destacan por tener una Ventana de Contexto gigantesca (capaces de leer libros enteros o repositorios completos de una vez).

• Cuándo usarlos: Cuando tienes que analizar una documentación técnica de 500 páginas, buscar un bug en un proyecto antiguo con cientos de archivos o cruzar datos de múltiples fuentes.

• Ojo con: "Lost in the middle". Aunque puedan leer mucho, recuerda lo que vimos en el Capítulo 2: si el dato importante está en la mitad del texto, es mejor usar un modelo de razonamiento para asegurar que no se le pase por alto.

Capítulo 7. Conclusiones y el camino a seguir

Después de haber desgranado desde qué es un token hasta cómo orquestar agentes con MCP, toca hacer una pausa y mirar el mapa completo. Escribir esta serie me ha servido para poner orden a mis investigaciones, pero sobre todo para reafirmar algunas convicciones sobre cómo debemos afrontar este cambio quienes nos dedicamos a la tecnología.

Estas son mis conclusiones tras meses de "cacharrreo", pruebas y algún que otro error de concepto:

1. La comprensión es tu mejor herramienta

No basta con saber qué botones pulsar. Entender cómo funciona la IA por dentro, su naturaleza estadística, sus límites de contexto y por qué alucina, es lo que marca la diferencia entre quien se frustra y quien sabe trabajar con ella. Como en cualquier otra rama de la ingeniería, conocer los cimientos te permite construir estructuras mucho más sólidas. Si sabes por qué la IA se equivoca, sabrás cómo corregir la instrucción para que no vuelva a suceder.

2. Solo estamos rascando la superficie

Lo que hoy nos parece revolucionario, como el Model Context Protocol (MCP) que os comentaba hace unos días, probablemente sea solo el estándar básico de mañana. Estamos en una fase muy temprana de esta tecnología.

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

3. Orquestación frente a monopolio

Si algo me preocupa de este "boom" es la tendencia a quedarnos atrapados en un solo ecosistema. Ahora más que nunca, es vital huir del vendor lock-in.

• Usa modelos diferentes según la tarea: razonamiento para la lógica, modelos flash para la velocidad y modelos de código para el desarrollo.

• Prioriza opciones que te permitan saltar entre proveedores. Herramientas como OpenRouter u OpenCode Zen, o incluso el uso de modelos Open Source en local no son solo una cuestión de preferencia técnica; son una cuestión de soberanía tecnológica. En un mundo donde los modelos cambian de la noche a la mañana, tener el control de tus fuentes de inteligencia es fundamental.

Reflexión final

La IA no ha venido a sustituir nuestra capacidad de pensar, sino a amplificar nuestra capacidad de hacer. Seguimos siendo artesanos e ingenieros de la tecnología , y nuestra labor sigue siendo la misma: resolver problemas reales con las mejores herramientas a nuestro alcance. La IA es solo un nuevo martillo, muy potente, pero que requiere una mano experta que sepa dónde golpear.

Espero que esta guía te haya servido para despejar un poco la niebla y empezar a usar estas herramientas con más criterio y menos miedo. Nos vemos en los próximos posts, seguramente probando alguna nueva "skill" o integrando mapas en algún flujo de trabajo que hoy ni siquiera imaginamos.

Me encontraba en una situación que probablemente te suene familiar. Tenía un proyecto antiguo, una aplicación web funcional que lleva años funcionando, alimentada por una base de datos PostgreSQL que... bueno, digamos que ha vivido su propia vida.

Cada cierto tiempo, el cliente pedía información que no se podía ver en la aplicación web, por lo que era necesario consultar directamente la base de datos. Y cada vez, me enfrentaba al mismo ritual:

1. Abrir el cliente de base de datos
2. Recordar qué tabla almacena qué información (la documentación estaba, sabes, "actualizada")
3. Escribir consultas SQL que parecían novelas de misterio con múltiples JOINs
4. Esperar varios minutos mientras la base de datos trabajaba
5. Formatear los resultados para que fueran comprensibles

No era técnicamente difícil, pero sí increíblemente lento y repetitivo. Y no nos engañemos, hacer consultas SQL no es divertido.

Primer Intento de solución: "IA, Ayúdame a Escribir SQL"

Como buen desarrollador del siglo XXI, mi primer pensamiento fue: "¿Puede la IA ayudarme con esto?". Empecé a usar chats con modelos de IA para generar las consultas SQL.

El proceso era algo así:

Yo: Necesito una consulta que me muestre estos datos.

IA: Aquí tienes la consulta SQL:

Funcionaba... hasta que no funcionaba. El problema fundamental: la IA no conocía mi base de datos. Tenía que explicarle constantemente:

"La tabla usuarios se llama realmente clientes" "Los campos de fecha están en formato timestamp" "La relación entre clientes y pedidos es a través de cliente_id, no usuario_id" "Ten cuidado que hay clientes inactivos en la tabla clientes_baja"

Cada consulta me llevaba más tiempo explicando el contexto que escribiendo SQL yo mismo. Era como tener que entrenar a alguien cada vez que quería hacer una pregunta, bueno, de hecho era literalmente así.

El Momento MCP: Cuando Todo Cambió

Investigando sobre cómo las IAs podrían conectarse directamente a bases de datos, apareció MCP (Model Context Protocol). Y fue como si se encendiera una bombilla.

MCP no es un modelo ni una IA nueva, es un protocolo que permite a los modelos interactuar con herramientas externas (bases de datos, APIs, sistemas locales) de forma estructurada.

¿Y si en lugar de explicarle a la IA cómo es mi base de datos, pudiera simplemente dejarla hablar con ella directamente?

Dejé de pensar en "cómo genero mejores consultas SQL" y empecé a pensar en "cómo conecto la IA directamente a mis datos".

La diferencia es sutil pero fundamental:

• Antes: yo → IA → texto SQL → yo → base de datos → yo → IA
• Ahora: yo → IA → base de datos → IA

Eliminaba el intermediario (yo) y con ello, toda la fricción.

Experimento #1: Gemini-cli y la Vía Fácil

Empecé con Gemini-cli porque descubrí que tenía un sistema de extensiones ya maduro. Entre ellas, una extensión oficial para PostgreSQL.

La instalación fue ridiculamente sencilla:

gemini extensions install https://github.com/gemini-cli-extensions/postgres

Configuré las variables de entorno, y en minutos, tenía una IA que podía consultar mi base de datos real. El momento mágico fue cuando pregunté (ejemplo figurado):

Yo: "Muéstrame todos los clientes de Madrid"

Gemini: "Tengo 3 clientes en Madrid: Ana García, Carlos López y María Pérez. Ana se registró hace 2 semanas y ya ha hecho un pedido."

No me devolvió una consulta SQL, me devolvió una respuesta basada en los datos. La IA había ejecutado la consulta, interpretado los resultados, y me los presentó de forma natural.

Ventajas de este enfoque:

• Super rápido de configurar
• Extensión oficial y bien mantenida
• Integración perfecta con PostgreSQL
• Resultados conversacionales inmediatos

🚀 Experimento #2: Opencode y el Camino Manual

Como últimamente estoy experimentando bastante con Opencode (una herramienta que me está encantando), quise ver cómo podía lograr lo mismo con ellos. Aquí la historia fue diferente.

Opencode no tiene un sistema de extensiones predefinido como Gemini-cli. En su lugar, utiliza MCP de forma más nativa, pero requiere que configuremos los servicios MCP manualmente.

El proceso fue:

1. Instalar postgres-mcp como paquete npm
2. Configurar opencode.json para que usara este MCP local
3. Ajustar las variables de entorno para que coincidieran

Aunque fue más manual que el enfoque de Gemini-cli, una vez funcionó, la experiencia fue igual de impresionante. La diferencia principal está en la filosofía:

• Gemini-cli: Tiene extensiones prefabricadas para todo
• Opencode: Te da las herramientas para construir tus propias conexiones

Este Repositorio No Es el Proyecto, Es Mi Guía

He creado un pequeño repositorio en mi cuenta de GitHub con la configuración y una base de datos de ejemplo para probarlo. Es principalmente una documentación para mi yo del futuro. Pero como compartir es vivir, ahí queda, por si a alguien le es útil o quiere hacer pruebas.

• Tiene una configuración para arrancar un PostgreSQL con Docker
• Tiene una base de datos de ejemplo (una tienda online con datos realistas)
• Está todo documentado paso a paso (para no perder horas configurándolo de nuevo)
• Incluye la configuración para ambas soluciones (Gemini-cli y Opencode)
• Funciona out-of-the-box (para que mi yo del futuro no sufra)

Conclusiones

Si no te gustan, tengo otras. Pero:

• La IA es el mayor avance en interfaces de usuario desde que se inventó el ratón. Los modelos pueden ser mejores o peores, acertar más o menos según su entrenamiento y sus capaciades, pero lo que es innegable es que la IA está cambiando la forma de relacionarnos con la tecnología. Ahora podemos hablarle a todo, incluído a una base de datos.

• "Me fío de todo el mundo pero desconfío del diablo que llevan dentro". Esta frase es de la película The Italian Job. Viene que ni al pelo. Los modelos de IA son lo que son, se basan en probabilidad, no hacen magia, recuérdalo siempre. En este ejemplo concreto, si conoces el dominio que estás consultando y algo te huele raro, revisa, es muy probable que la IA haya hecho mal. Coteja la información, revisa la SQL que ha usado, etc. sobre todo si la información es importante.

Definiendo nuestros datos GeoJSON

Para este ejemplo, definiremos los datos directamente en una variable de JavaScript. En una aplicación real, estos datos vendrían normalmente de una API o un fichero .geojson.

Añadiendo capas WMS

Además de las capas de teselas habituales (llamadas capas TMS o XYZ), Leaflet puede consumir servicios WMS (Web Map Service). Estos servicios son un estándar muy común en el mundo de los SIG. Para este ejemplo, usaremos el servicio de ortofotos del Plan Nacional de Ortofotografía Aérea (PNOA) de España. Se hace a través de L.tileLayer.wms:

var pnoa = L.tileLayer.wms('http://www.ign.es/wms-inspire/pnoa-ma', {
    layers: 'OI.OrthoimageCoverage',
    format: 'image/jpeg',
    transparent: true,
    attribution: 'PNOA cedido por © <a href="http://www.ign.es/ign/main/index.do">Instituto Geográfico Nacional</a>'
});

Marcadores personalizados con HTML, CSS y Font Awesome

Una de las formas más potentes de personalizar los marcadores es usando L.divIcon. A diferencia de L.icon que usa una imagen, divIcon nos permite usar código HTML y CSS, lo que abre la puerta a usar librerías de iconos como Font Awesome.

El proceso combina la lógica de JavaScript con los estilos de CSS.

En la parte de JavaScript, dentro de la función pointToLayer, decidimos qué icono y qué estilo aplicar a cada punto. Usamos un switch para elegir una clase de Font Awesome (ej: fa-tree) y una clase CSS propia (ej: parque) basándonos en las propiedades de los datos. Luego, pasamos estas clases al divIcon:

var customIcon = L.divIcon({
    className: 'custom-marker ' + markerColorClass, // Clases para el CSS
    html: `<i class="fas ${iconClass}"></i>`,      // HTML con el icono de Font Awesome
    iconSize: [30, 30]
});

A continuación, en el CSS, definimos los estilos. Tenemos una clase base, .custom-marker, que crea el círculo contenedor del icono. Luego, las clases específicas (.playa, .parque, .faro) establecen el color tanto del borde del círculo como del propio icono de Font Awesome que contiene.

.custom-marker { 
    background-color: rgba(255, 255, 255, 0.9); 
    border: 2px solid #333; 
    border-radius: 50%;
    /* ... más estilos ... */
}
.custom-marker.playa { border-color: #00aaff; color: #00aaff; }
.custom-marker.parque { border-color: #28a745; color: #28a745; }

De esta forma, el HTML y el CSS trabajan juntos para crear un marcador totalmente personalizado.

Creando un selector de capas

Para permitir al usuario cambiar entre diferentes mapas base y activar o desactivar capas de datos, usamos L.control.layers.

var baseMaps = {
    "Mapa": carto,
    "Ortofoto": pnoa
};
var overlayMaps = {
    "Puntos de interés": markers
};
L.control.layers(baseMaps, overlayMaps).addTo(map);

Ejemplo completo

El siguiente código HTML es un ejemplo completo y autocontenido.

<!DOCTYPE html>
<html>
<head>
    <title>Leaflet Avanzado: WMS y Control de Capas</title>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <link rel="stylesheet" href="https://unpkg.com/leaflet/dist/leaflet.css" />
    <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.15.4/css/all.min.css">
    <style>
        html, body { height: 100%; margin: 0; padding: 0; display: flex; flex-direction: column; }
        h1 { text-align: center; padding: 10px 0; margin: 0; }
        #map { flex-grow: 1; }
        .custom-marker { 
            background-color: rgba(255, 255, 255, 0.9); 
            border: 2px solid #333; 
            border-radius: 50%; 
            width: 30px; 
            height: 30px; 
            display: flex; 
            justify-content: center; 
            align-items: center; 
            box-shadow: 0 2px 5px rgba(0,0,0,0.3); 
            font-size: 16px; 
        }
        .custom-marker.playa { border-color: #00aaff; color: #00aaff; }
        .custom-marker.parque { border-color: #28a745; color: #28a745; }
        .custom-marker.faro { border-color: #ffc107; color: #ffc107; }
    </style>
</head>
<body>

<h1>Leaflet Avanzado: WMS y Control de Capas</h1>
<div id="map"></div>

<script src="https://unpkg.com/leaflet/dist/leaflet.js"></script>
<script>
    // 1. Definir capas base
    var carto = L.tileLayer(
        'https://{s}.basemaps.cartocdn.com/light_all/{z}/{x}/{y}{r}.png', 
        {
            attribution: '&copy; <a href="https://www.openstreetmap.org/copyright">OpenStreetMap</a> contributors &copy; <a href="https://carto.com/attributions">CARTO</a>'
        }
    );

    var pnoa = L.tileLayer.wms('http://www.ign.es/wms-inspire/pnoa-ma', {
        layers: 'OI.OrthoimageCoverage',
        format: 'image/jpeg',
        transparent: true,
        attribution: 'PNOA cedido por © <a href="http://www.ign.es/ign/main/index.do">IGN</a>'
    });

    // 2. Inicializar el mapa
    var map = L.map('map', {
        center: [43.35, -8.36],
        zoom: 13,
        layers: [carto]
    });

    // 3. Datos GeoJSON
    var geojsonData = {
      "type": "FeatureCollection",
      "name": "oleiros_puntos",
      "features": [
        {
          "type": "Feature",
          "properties": { "name": "Playa de Santa Cristina", "tipo": "Playa" },
          "geometry": { "type": "Point", "coordinates": [-8.378631, 43.339596] }
        },
        {
          "type": "Feature",
          "properties": { "name": "Parque de José Martí", "tipo": "Parque" },
          "geometry": { "type": "Point", "coordinates": [-8.378567, 43.336728] }
        },
        {
          "type": "Feature",
          "properties": { "name": "Faro de Mera", "tipo": "Faro" },
          "geometry": { "type": "Point", "coordinates": [-8.354416, 43.383347] }
        },
        {
          "type": "Feature",
          "properties": { "name": "Playa de Bastiagueiro", "tipo": "Playa" },
          "geometry": { "type": "Point", "coordinates": [-8.362489, 43.340981] }
        }
      ]
    };

    // 4. Capa de marcadores personalizados
    var markers = L.geoJSON(geojsonData, {
        pointToLayer: function (feature, latlng) {
            var iconClass, markerColorClass = '';
            switch (feature.properties.tipo) {
                case 'Playa': 
                    iconClass = 'fa-umbrella-beach'; 
                    markerColorClass = 'playa'; 
                    break;
                case 'Parque': 
                    iconClass = 'fa-tree'; 
                    markerColorClass = 'parque'; 
                    break;
                case 'Faro': 
                    iconClass = 'fa-lightbulb'; 
                    markerColorClass = 'faro'; 
                    break;
                default: 
                    iconClass = 'fa-map-marker-alt'; 
                    break;
            }
            var customIcon = L.divIcon({
                className: 'custom-marker ' + markerColorClass,
                html: `<i class="fas ${iconClass}"></i>`,
                iconSize: [30, 30]
            });
            var popupText = '<strong>' + feature.properties.name + '</strong>' + 
                            '<br>Tipo: ' + feature.properties.tipo;

            return L.marker(latlng, { icon: customIcon }).bindPopup(popupText);
        }
    }).addTo(map);

    // 5. Configurar el control de capas
    var baseMaps = {
        "Mapa": carto,
        "Ortofoto": pnoa
    };

    var overlayMaps = {
        "Puntos de interés": markers
    };

    L.control.layers(baseMaps, overlayMaps).addTo(map);

    // 6. Ajustar el zoom a los marcadores
    map.fitBounds(markers.getBounds());

</script>

</body>
</html>

Bonus final: Latitud y Longitud, el eterno debate

Un detalle importante a tener en cuenta es el orden de las coordenadas. Si te has dado cuenta el orden de las coordenadas es diferente cuando definimos el centro del mapa en leaflet, respecto de como se definen en el geojson. No existe un estándar único en el mundo de la información geográfica, lo que a menudo causa errores inesperados.

• Leaflet, en sus funciones principales como L.mapsetView() o L.marker(), generalmente espera el formato [latitud, longitud].
• El estándar GeoJSON, sin embargo, especifica el orden inverso: [longitud, latitud].

Esta inconsistencia es habitual entre diferentes herramientas, formatos y estándares del mundo SIG. Afortunadamente, en este caso, la función L.geoJSON() de Leaflet es lo suficientemente inteligente como para leer correctamente las coordenadas en el formato estándar de GeoJSON sin que tengamos que hacer ninguna conversión manual. Para quien quiera profundizar más en este curioso problema, el artículo Lon, lat is the right way de Tom MacWright lo explica de maravilla.

Esta filosofía tiene una ventaja importante: puedes empezar de forma simple y rápida, sin tener que aprender una API enorme o cargar funcionalidades que no necesitas. Y si tu proyecto crece, puedes ir ampliándolo con una extensa colección de plugins oficiales y de la comunidad que añaden todo tipo de capacidades: desde dibujar polígonos y medir distancias, hasta mostrar datos en 3D o integrar servicios de geocodificación.

En resumen: Leaflet es pequeño y fácil al principio, pero no se queda corto. Es como una navaja suiza a la que le puedes ir añadiendo herramientas a medida que las necesitas.

¿Por qué usar Leaflet?

• Ligera: el núcleo pesa menos de 50 KB.
• Compatible: funciona en la mayoría de navegadores y dispositivos móviles.
• Extensible: cuenta con multitud de plugins para añadir funcionalidades avanzadas.
• Fácil de aprender: ideal para principiantes y proyectos rápidos.

Ejemplo básico de mapa con Leaflet

El siguiente ejemplo muestra cómo crear un mapa centrado en unas coordenadas concretas, añadir un marcador y mostrar un popup. Solo necesitas incluir la librería Leaflet y un contenedor para el mapa.

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <title>Mapa con Leaflet</title>
    <meta name="viewport" content="width=device-width, initial-scale=1.0">

    <!-- CSS de Leaflet -->
    <link rel="stylesheet" href="https://unpkg.com/leaflet/dist/leaflet.css" />

    <style>
        #map {
            height: 500px;
        }
    </style>
</head>
<body>

<h1>Mi primer mapa con Leaflet</h1>
<div id="map"></div>

<!-- JS de Leaflet -->
<script src="https://unpkg.com/leaflet/dist/leaflet.js"></script>
<script>
    // Inicializar el mapa
    var map = L.map('map').setView([43.3336, -8.3174], 14);

    // Añadir capa base de OpenStreetMap
    L.tileLayer('https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png', {
        attribution: '&copy; <a href="https://www.openstreetmap.org/">OpenStreetMap</a> contributors'
    }).addTo(map);

    // Añadir un marcador
    var marker = L.marker([43.3336, -8.3174]).addTo(map);

    // Popup en el marcador
    marker.bindPopup("<b>Hola!</b><br>Este es un mapa de Leaflet centrado en Oleiros.").openPopup();
</script>

</body>
</html>

Cómo funciona el código

• Importamos Leaflet: a través de sus archivos CSS y JS desde un CDN.
• Creamos un contenedor #map: donde se dibujará el mapa.
• Inicializamos el mapa: con L.map() y lo centramos en un punto.
• Añadimos una capa base: usando L.tileLayer() con teselas de OpenStreetMap.
• Colocamos un marcador: y le añadimos un popup.

Entender qué significan estos conceptos te ahorrará muchos quebraderos de cabeza. Porque antes de representar datos geográficos en la web, hay que entender una idea clave: el planeta en el que vivimos no es fácil de convertir en un plano.

La Tierra no es una esfera perfecta. De hecho, se parece más a una patata: está achatada por los polos, algo abultada por el ecuador y llena de irregularidades causadas por la gravedad, las montañas y los océanos. Esa forma tan real pero complicada se llama geoide, y aunque describe bien cómo es el planeta, resulta imposible de usar directamente en los cálculos de un mapa.

Para simplificar las cosas, se utiliza una superficie más regular llamada elipsoide de referencia. Es una figura matemática que se ajusta al geoide, pero lo bastante sencilla para trabajar con ella. Existen varios elipsoides, pero hoy el más usado es el WGS84, el mismo que emplea el GPS y la mayoría de servicios de mapas en línea.

Con el elipsoide definido, necesitamos una forma de localizar puntos sobre él. Para eso se usan las coordenadas geográficas, que indican la latitud (posición norte-sur) y la longitud (posición este-oeste). Por ejemplo, 43.333°N, -8.317°O nos lleva a Oleiros, en Galicia. Es un sistema perfecto para referirse a lugares sobre el globo, pero poco práctico para dibujarlos en una pantalla, porque los ordenadores trabajan con coordenadas planas (x, y).

Y aquí llega el paso más importante: convertir una superficie curva en un plano. Este proceso se llama proyección cartográfica.Imagina intentar aplanar la piel de una naranja sobre una hoja de papel: tendrás que estirar, cortar o deformar algo. Con la Tierra pasa lo mismo. Cada proyección elige qué quiere conservar (las distancias, las áreas, los ángulos…) y qué está dispuesta a deformar. No hay una proyección perfecta, solo la más adecuada según el uso.

La proyección Web Mercator

En el mundo del webmapping, la proyección más común es la Web Mercator, una adaptación moderna de la proyección creada por Gerardus Mercator en el siglo XVI. Es la que utilizan Google Maps, OpenStreetMap, Bing Maps, y casi todos los visores actuales.

Su gran ventaja es que permite mostrar todo el planeta como una cuadrícula continua y realizar zoom progresivo sin interrupciones, lo que resulta ideal para aplicaciones interactivas. Internamente, Web Mercator transforma las coordenadas de latitud y longitud en metros usando el elipsoide WGS84, y “recorta” la Tierra a una latitud máxima de ±85°. Esto evita que las zonas cercanas a los polos se estiren infinitamente.

El inconveniente, claro, es la distorsión: los objetos cercanos a los polos se ven mucho más grandes de lo que son. Groenlandia parece casi tan grande como África, cuando en realidad África es unas 14 veces mayor. Por eso, aunque Web Mercator es práctica, no es la proyección adecuada para hacer cálculos de superficie o distancia.

Aun así, su sencillez y compatibilidad la han convertido en el estándar de facto en los mapas web. Cuando ves un mapa en línea, lo más probable es que esté en EPSG:3857, el código oficial de esta proyección.

Sistemas de referencia: el idioma de los mapas

Cada combinación de elipsoide, proyección y unidad de medida forma lo que se conoce como un sistema de referencia espacial. Podemos imaginarlo como el “idioma” que usan los datos geográficos para decirle al mapa dónde se encuentra cada punto.

Un sistema de referencia se compone, generalmente, de tres partes:

1. Datum o marco de referencia: define la forma y posición del elipsoide respecto a la Tierra real. Por ejemplo, el WGS84 es un datum global.
2. Proyección cartográfica: establece cómo se transforma la superficie curva del elipsoide en un plano (por ejemplo, Mercator, UTM, Lambert, etc.).
3. Unidades de medida: indican en qué se expresan las coordenadas (grados, metros, pies…).

Estas tres piezas juntas determinan cómo deben interpretarse las coordenadas de un archivo o servicio geográfico. Por ejemplo:

• EPSG:4326 → usa el datum WGS84, sin proyección (coordenadas en grados de latitud y longitud).
• EPSG:3857 → usa el mismo datum WGS84, pero proyectado con Web Mercator, y las coordenadas se expresan en metros.
• EPSG:25831 → corresponde al sistema UTM huso 31N sobre el datum ETRS89, habitual en España peninsular.

Saber en qué sistema están tus datos, y cuál usa tu mapa, es esencial para que todo encaje. Si no coinciden, los puntos aparecerán desplazados, a veces cientos de kilómetros fuera de lugar. Por suerte, la mayoría de librerías modernas permiten gestionar estos sistemas de forma automática.

¿Qué hacen las librerías web con todo esto?

Una buena noticia: no necesitas preocuparte demasiado por las transformaciones.
Librerías como Leaflet, OpenLayers o MapLibre están pensadas para que los datos “simplemente funcionen”.

La mayoría de los mapas en la web utilizan Web Mercator (EPSG:3857), pero muchos conjuntos de datos, APIs o servicios de datos abiertos vienen en EPSG:4326, es decir, con latitudes y longitudes en grados. ¿Cómo es posible que ambos se entiendan?

La clave está en que los dos sistemas comparten el mismo elipsoide, WGS84.
Eso significa que la relación entre coordenadas geográficas (grados) y proyectadas (metros) es directa y fácil de calcular matemáticamente. Cuando una librería como OpenLayers recibe datos en 4326, no necesita hacer una transformación geodésica compleja, sino una simple conversión de grados a metros en la proyección Web Mercator.

En la práctica, es como si el mapa y tus datos hablaran el mismo idioma con distinto acento: basta una pequeña traducción. Por eso puedes pasar coordenadas en 4326 y ver cómo se dibujan correctamente sobre un mapa base en 3857, sin que aparezcan desplazadas ni deformadas.

Ahora bien, cada librería gestiona esto de forma un poco diferente:

• Leaflet trabaja de forma nativa en Web Mercator y no incluye soporte interno para transformar entre sistemas distintos. Si tus datos están en otra proyección, tendrás que convertirlos antes o usar un plugin como Proj4Leaflet.

• OpenLayers integra el motor Proj4js y puede transformar coordenadas directamente entre sistemas definidos por su código EPSG. Esto la hace más flexible para trabajar con datos en diferentes proyecciones sin necesidad de preprocesarlos.

• MapLibre GL JS trabaja también en Web Mercator, pero con una particularidad: está pensada principalmente para mapas vectoriales. Su motor de renderizado asume que las coordenadas de los datos están en EPSG:4326 (grados) y las proyecta internamente a 3857 en tiempo real, aprovechando la GPU del navegador. Es decir, hace la conversión sobre la marcha de forma eficiente y transparente para ti. No incluye herramientas de reproyección entre otros sistemas, pero en la mayoría de los casos no las necesita.

En resumen, las tres librerías coinciden en que Web Mercator es su lenguaje común, y todas pueden mostrar datos en 4326 sin problemas. La diferencia está en cuánta ayuda ofrecen si trabajas fuera de ese “idioma estándar”.

En resumen

Cuando trabajas con mapas web, tus datos siguen un camino que va desde la forma real del planeta hasta el plano del navegador:

Tierra → Geoide → Elipsoide → Coordenadas → Proyección → Mapa

Comprender esta secuencia te ayudará a evitar errores y, sobre todo, a entender qué está ocurriendo “debajo del mapa”.

En siguientes artículos veremos cómo llevar estos conceptos a la práctica: cómo cargar datos, elegir proyecciones y crear tus propios mapas interactivos.

¿Qué son Leaflet, OpenLayers y MapLibre?

Para empezar, un poco de contexto. Leaflet es una librería nacida en 2011 que se ha ganado la fama por ser ligera, fácil de aprender y con una curva de aprendizaje muy amigable para principiantes. Su foco principal es facilitar la creación de mapas web sencillos, con funcionalidades básicas pero muy bien diseñadas, y una amplia variedad de plugins para ampliar sus capacidades.

Por otro lado, OpenLayers es un proyecto más antiguo (desde 2006) y mucho más completo y robusto. Está pensado para quienes necesitan hacer proyectos GIS avanzados con análisis espacial, soporte para múltiples formatos, proyecciones y operaciones complejas sobre datos geográficos. Su curva de aprendizaje es más pronunciada, pero a cambio ofrece una potencia y flexibilidad que pocas librerías pueden igualar.

Finalmente, MapLibre es relativamente más nuevo y nace como un fork abierto de Mapbox GL JS. Su especialidad son los mapas vectoriales renderizados con WebGL, lo que permite crear visualizaciones muy modernas, estilizadas y con gran rendimiento para datos complejos y dinámicos. MapLibre está ganando mucha popularidad especialmente para aplicaciones que buscan estética y rendimiento en mapas web.

Comunidad y desarrollo: ¿qué librería está más activa?

Al elegir una librería para tus proyectos, es fundamental conocer qué tan activa y saludable es su comunidad de desarrolladores, así como la frecuencia con la que se actualiza el proyecto. Esto afecta la calidad del software, la rapidez en corregir errores y la disponibilidad de nuevas funcionalidades.

Una métrica comúnmente citada son las estrellas en GitHub, que indican popularidad, pero no siempre reflejan la actividad real de desarrollo. Por eso, también es útil mirar otros datos como el número de contribuidores activos, la frecuencia de lanzamientos y el nivel de interacción en los issues y pull requests.

Leaflet tiene aproximadamente 43,000 estrellas en GitHub, lo que indica una comunidad muy amplia y extendida. El número de contribuidores totales es de más de 800 en total, aunque a lo largo del tiempo no se ha mantenido constante. La frecuencia de actualizaciones es moderada, con la última versión estable importante lanzada hace más de dos años. Aunque la comunidad es grande, el ritmo de desarrollo es algo pausado en la actualidad. Hay que tener en cuenta que el modelo de Leaflet es tener un núcleo pequeño, que es el repositorio del que se muestra la gráfica, y un ecosistema grande de plugins, a través de los cuales se dota de más funcionalidad.

OpenLayers cuenta con unas 13,000 estrellas en GitHub y alrededor de 400 contribuidores en total. A diferencia de Leaflet, el equipo de desarrollo lanza actualizaciones regularmente, con versiones nuevas casi cada mes. Además, la comunidad es muy técnica, lo que favorece un desarrollo continuado y la incorporación de funcionalidades complejas, muy valoradas en proyectos GIS profesionales.

MapLibre, con cerca de 8,500 estrellas, es la más joven de las tres pero destaca por su crecimiento rápido. Cuenta ya con más de 500 contribuidores en total y una actividad intensa en issues y pull requests, lo que refleja una comunidad vibrante y muy involucrada en mantener la librería actualizada con las últimas tecnologías, especialmente para mapas vectoriales con WebGL.

En resumen, si bien Leaflet sigue siendo la librería más popular, OpenLayers y MapLibre tienen comunidades muy activas y desarrollo frecuente, cada una con su enfoque particular.

Licencias: la tranquilidad de trabajar con software libre

Otro punto que siempre preocupa a quienes empiezan y también a quienes trabajan en proyectos profesionales es la licencia del software. Las tres librerías usan licencias permisivas BSD de 2 cláusulas, lo que significa que puedes usarlas, modificarlas y distribuirlas sin muchas restricciones, incluso en proyectos comerciales. Esto ofrece una gran tranquilidad y flexibilidad para tu trabajo.

¿Cuál librería elegir?

Si estás buscando algo sencillo, que te permita crear mapas rápidamente sin tener que lidiar con complejidades técnicas, Leaflet es sin duda la mejor opción para empezar. Su comunidad enorme y su ecosistema de plugins te facilitarán mucho el aprendizaje y la implementación.

Si tu objetivo es ir más allá y trabajar en proyectos GIS con análisis espaciales, múltiples capas y datos complejos, OpenLayers es la herramienta ideal. Su potencia y flexibilidad se reflejan en el nivel de detalle que puedes manejar en tus mapas.

Por último, si quieres crear mapas modernos, vectoriales y estilizados, que aprovechen WebGL para un rendimiento y estética superior, MapLibre es una opción muy interesante y actualizada, ideal para aplicaciones que buscan impactar visualmente sin perder rendimiento.

Conclusión

En resumen, las tres librerías tienen sus puntos fuertes y la elección depende mucho del tipo de proyecto que quieras hacer y tu nivel de experiencia. Leaflet es ideal para empezar rápido y sencillo, OpenLayers para proyectos GIS más avanzados y MapLibre para quienes buscan mapas vectoriales modernos y estilizados.

Este artículo ofrece una visión general basada en el estado actual de las herramientas y sus comunidades, pero no debe tomarse al pie de la letra. La mejor manera de aprender y decidir es explorando y probando por ti mismo cada una de ellas, ya que cada proyecto tiene necesidades y matices únicos.

Cuando comenzó a desarrollarse el mundo de la informática, los ordenadores eran aparatos muy caros que casi no cabían en una habitación. Un par de fabricantes se repartían el mercado de ese hardware, porque en aquel momento el software no valía nada por sí mismo. En ese momento el software era libre.

La cosa siguió avanzando, los ordenadores empezaron a cambiar de tamaño, cada vez eran más pequeños y su capacidad de procesamiento más grande. Llegamos a la década de los 70, aparece el PC, el personal computer, la posibilidad de llevar los ordenadores a los hogares. Al mercado del hardware empiezan a llegar más fabricantes, el software poco a poco empieza a ser compatible entre equipos y entonces se vuelve importante.

De repente alguien piensa que el negocio ya no está tanto en el hardware sino en el software, así que decide cogerlo y meterlo en cajas para venderlo. Junto con unos textos amplios y de tamaño de letra muy pequeña que establecen las condiciones bajo las que, una vez comprado, puedes hacer uso del mismo. Porque lo compraste, pero no es tuyo. Solo tienes una licencia de uso.

Desde ese momento llega una época oscura, en la que el software ya no es libre. Pero igual que en los cómics de Astérix, hay una aldea de irreductibles galos que no están dispuestos a dejarse conquistar por el imperio. Son el movimiento del Software Libre.

Gracias a ellos el software resistió y no todo se volvió privativo. Pero fueron tiempos difíciles, porque el imperio intentó acabar con estos valientes galos de muchas formas.

Finalmente, y como bien sabemos por la historia, todos los grandes imperios acaban cayendo, o cambiando. Hoy en día, esas grandes corporaciones que querían acabar con el software libre, son las que más contribuyen a su desarrollo. Cosas veredes.

Vivimos ahora en un tiempo donde el hardware está en la nube y el software se utiliza para crear servicios, que es donde está el negocio. El software dejó de ser un fin para ser un medio y, por tanto, ya puede ser libre de nuevo. No hay mal que por bien no venga.

Pero si otra cosa nos enseñó la historia es que, de una forma u otra, todo se repite. Cuando un imperio cae, otro ya está empezando a crecer. Por eso ahora que el software vuelve a ser libre, no podemos bajar la guardia. En nuestras manos está lograr que esta situación perdure. No venció la filosofía, sino la conveniencia, y por lo tanto este statu quo es aún frágil.

En nuestras manos está hacer ver que este modelo funciona, que se puede hacer negocio liberando el software, que puede ser igual o incluso más seguro a pesar de que el código fuente sea público, que facilita y potencia mucho más la innovación. En definitiva, que es el modelo que nunca se debió abandonar.

Porque el software siempre fue libre.

--
Editorial publicada en el portal Mancomún.