28 de mayo de 2026
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:
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:
Ya no tratamos al LLM como una enciclopedia, sino como una CPU lógica.
El Model Context Protocol (MCP) es el estándar que permite a la IA interactuar con herramientas reales de forma segura.
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.
En lugar de un único "super-agente", dividimos el trabajo en agentes especializados.
Para que la IA "entienda" un repositorio de miles de archivos, usamos Retrieval-Augmented Generation (RAG) avanzado.
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.
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:
PLAN.md que detalla los cambios. El humano lo audita.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.
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.
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:
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:
Estos modelos priorizan el acierto sobre la velocidad.
Modelos optimizados para baja latencia y alta eficiencia en tareas sintácticas.
Modelos capaces de ingerir millones de tokens (repositorios enteros) en una sola sesión.
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.
Como ingenieros, debemos entender que el razonamiento no es gratuito. Los modelos que "piensan más" tienen:
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.
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.
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.
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.
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.
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.
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.
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.
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:
si el estado del usuario es INACTIVO, la API debe retornar 403 inmediatamente).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.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).
SPEC.md u OpenAPI).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.
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 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:
stderr), captura los logs detallados del compilador o del framework de pruebas, y los inyecta estructuradamente de vuelta en el contexto del agente.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.
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.
Si no te quieres perder ninguno de mis artículos, puedes agregar mi blog a tu lector de RSS preferido.
Suscribirse al RSS