Todo el mundo habla de los modelos de IA.
Nadie habla de la capa que realmente los hace útiles.
Claude Code. Codex. Cursor.
No son solo modelos.
Son modelos envueltos en un sistema.
Ese sistema se llama un arnés.
Y los mejores arneses ahora se mejoran a sí mismos.
Aquí tienes todo lo que necesitas saber sobre el nuevo stack de IA.
La mentira que todo el mundo cree sobre los productos de IA
La mayoría de la gente piensa que el progreso de la IA = modelos más inteligentes.
No es así.
El modelo es una parte del stack.
La arquitectura es pública. Todos copian el mismo transformer. Todos los laboratorios usan los mismos bloques de construcción.
Lo que realmente separa a Claude Code de un proyecto de fin de semana no es el modelo.
Es lo que rodea al modelo.
El arnés.
En 2017, el progreso de la IA se trataba de mecanismos de atención. En 2020, se trataba de escala. En 2026, se trata de ingeniería de arneses.
Y los arneses ahora son diseñados por IA, no por humanos.
¿Qué es un arnés?
Un arnés es el sistema que rodea a un modelo.
Decide:
→ Cómo piensa y planifica el modelo
→ Cuándo llama a herramientas y qué hace con los resultados
→ Qué recuerda a lo largo de los pasos
→ Cómo almacena artefactos y gestiona el estado
→ Cómo evalúa su propia salida
→ Cuándo retrocede y lo intenta de nuevo
Piénsalo como un sistema operativo.
El modelo es la CPU. El arnés es el SO.
Puedes tener una CPU potente y un software terrible y no lanzar nada útil. Puedes tener una CPU modesta y un software excelente y lanzar algo grandioso.
Los agentes de codificación más exitosos (Claude Code, Codex, Cursor) tienen todos la misma idea:
El bucle importa tanto como el modelo.
Los 3 patrones de arnés que todo creador de IA necesita
Todo sistema de IA en producción utiliza al menos uno de estos.
Patrón 1: El bucle
El modelo no responde una vez y se detiene.
Hace un bucle.
Planificar → Ejecutar → Observar → Mejorar → Repetir
Este es el núcleo de todo agente de codificación.
Un bucle simplificado de Claude Code:
- Leer la tarea
- Planificar el enfoque
- Escribir código → ejecutarlo
- Ver qué falló
- Arreglarlo
- Ejecutar de nuevo
- Repetir hasta que las pruebas pasen
El modelo no es más inteligente en el bucle 3 que en el bucle 1.
Pero el sistema sí lo es.
Cada bucle le da al modelo un nuevo contexto: mensajes de error, resultados de pruebas, trazas de ejecución.
La salida del bucle 1 se convierte en la entrada del bucle 2.
Ese contexto compuesto es la razón por la que los sistemas agentivos superan a las indicaciones de un solo disparo en tareas complejas.
La idea clave: El modelo se mantiene fijo. El contexto se vuelve más inteligente.
Patrón 2: Sistema de archivos como memoria
La mayoría de los desarrolladores meten todo en la ventana de contexto.
Esto es una trampa.
Las tareas de largo alcance generan:
→ Registros de experimentos
→ Diferencias de código → Trazas de error
→ Historiales de implementaciones anteriores → Resúmenes de documentos → Artefactos intermedios
Todo eso crece mucho más allá de cualquier ventana de contexto.
La solución: escribir en archivos, no en el contexto.
1# Malo: todo en el contexto2contexto = salida_anterior + resultado_herramienta + registro_error + historial...3# Explota en el paso 4745# Bueno: usar el sistema de archivos6agente.escribir("experimentos/ejecucion_3/registro_error.txt", traza_error)7agente.escribir("experimentos/ejecucion_3/resultados.json", metricas)89# Más tarde, el agente lee solo lo que necesita10relevante = agente.leer("experimentos/ejecucion_3/resultados.json")
Esto lo cambia todo en las tareas de largo alcance.
→ El agente puede reanudarse después de fallos
→ El agente puede razonar sobre su propio historial de ejecución
→ El contexto se mantiene limpio incluso en el paso 200
→ Múltiples subagentes pueden compartir estado a través de archivos
Los mejores agentes tratan el sistema de archivos como un segundo cerebro.
No un vertedero. Una memoria estructurada.
Patrón 3: Subagentes
Un agente no puede hacerlo todo.
Los mejores sistemas generan subagentes en paralelo.
El agente padre:
→ Divide la tarea en subtareas independientes
→ Lanza subagentes para ejecutarlas en paralelo
→ Monitorea su estado → Fusiona sus resultados
Ejemplo para un arnés de investigación:
1El agente padre recibe: "Escribe un informe completo de análisis competitivo"23Genera 4 subagentes simultáneamente:4→ Subagente 1: Investiga los precios y características del competidor A5→ Subagente 2: Investiga los precios y características del competidor B6→ Subagente 3: Busca noticias recientes sobre ambos competidores7→ Subagente 4: Extrae reseñas de usuarios de Reddit y App Store89El padre espera y luego fusiona las 4 salidas en el informe final1011Tiempo total: el mismo que el subagente más lento (no 4 veces más)
La regla de diseño clave: las salidas de los subagentes deben ir a archivos.
No a un contexto transitorio. A archivos.
Si solo viven en el contexto, desaparecen cuando termina la sesión del subagente.
Si viven en archivos, el agente padre puede inspeccionarlos, el sistema puede recuperarse de fallos y todo es auditable.
Herramientas que usa todo agente de codificación
Si estás construyendo un agente, este es el conjunto de herramientas que estandariza todo agente de codificación importante.
1Herramientas del sistema de archivos:2→ glob, grep, ls # encontrar archivos3→ read, read_many # leer contenido4→ write # crear nuevo archivo5→ edit # edición por reemplazo de cadena6→ apply_patch # diff estructurado78Herramientas de shell:9→ bash # ejecutar cualquier comando10→ PowerShell # equivalente en Windows1112Control de versiones:13→ git_status, git_diff # inspeccionar cambios14→ git_commit # guardar progreso1516Gestión de agentes:17→ spawn_agent # lanzar subagente18→ wait_agent # esperar resultado19→ list_agents # ver qué está ejecutándose20→ interrupt_agent # cancelar si es necesario2122Contexto externo:23→ web_search, web_fetch # obtener información actual24→ Herramientas MCP # conectar a servicios externos
No necesitas todas estas para cada agente.
Pero todo agente en producción eventualmente necesita la mayoría.
Las que más importan al principio: bash, read, write, edit.
Domina esas cuatro y podrás construir casi cualquier cosa.
Ingeniería de contexto: la habilidad de la que nadie habla
El modelo es fijo.
No puedes cambiar sus pesos en tiempo de ejecución.
Pero puedes cambiar lo que ve.
Eso es la ingeniería de contexto.
Y ahora es una de las habilidades de mayor apalancamiento en la ingeniería de IA.
Contexto malo:
→ Meter todo → esperar lo mejor
→ El contexto se hincha → el modelo pierde el foco → las salidas se degradan
Contexto bueno:
→ Estructurado. Conciso. Evolutivo.
→ La información correcta en el paso correcto.
→ Los fallos anteriores informan el intento actual.
El enfoque de vanguardia (ACE — Ingeniería de Contexto Agentiva):
13 componentes:23Generador: ejecuta la tarea, referencia un manual de contexto estructurado4Reflector: analiza éxitos y fracasos, destila ideas5Curador: actualiza el manual con nuevos aprendizajes — añade, elimina, deduplica67El manual NO es un bloque de indicaciones.8Es una lista estructurada de pares (identificador, idea).910Ejemplo:11{12 "id": "001",13 "idea": "Siempre escribir las trazas de error en un archivo antes de reintentar."14},15{16 "id": "002",17 "idea": "El subagente para búsqueda web devuelve mejores resultados con consultas específicas del sitio."18},19{20 "id": "003",21 "idea": "Ejecutar pruebas antes de confirmar detecta el 80% de las regresiones."22}
El manual se actualiza después de cada ejecución.
El agente que ejecuta la tarea 50 está trabajando con 49 ejecuciones de aprendizajes destilados.
El agente que ejecuta la tarea 1 no tenía nada.
Así es como un sistema se vuelve más inteligente sin tocar los pesos del modelo.
El arnés que se mejora a sí mismo
Aquí es donde se pone emocionante.
¿Qué pasaría si el arnés mismo fuera lo que se optimiza?
No la indicación. No el modelo.
El código que ejecuta el agente.
Esto es exactamente lo que hace Self-Harness.
Bucle de 3 pasos:
Paso 1 — Encontrar debilidades
Ejecuta el arnés actual en un conjunto de tareas. Recopila trazas de fallos. Agrupa los fallos por causa raíz.
No "falló". Sino por qué falló.
Tipos de fallos descubiertos:
→ "El agente se agota en lecturas de archivos largas"
→ "Las salidas del subagente se pierden cuando el padre falla"
→ "Los mensajes de error no son lo suficientemente informativos para autocorregirse"
→ "El contexto crece demasiado después del paso 30, el modelo pierde el foco"
Paso 2 — Proponer correcciones
El mismo modelo observa los patrones de fallo. Propone ediciones específicas y precisas al código del arnés.
No reescrituras. Ediciones dirigidas.
Edición propuesta al arnés:
→ Añadir un manejador de tiempo de espera a las operaciones de lectura de archivos
→ Volcar automáticamente la salida del subagente al disco en cada paso (no solo al final)
→ Estandarizar el formato del mensaje de error para incluir: paso, herramienta, entrada, salida, motivo del fallo
→ Añadir un paso de compresión de contexto cada 25 turnos
Paso 3 — Validar y fusionar
Cada edición propuesta se prueba en tareas reservadas.
¿Soluciona la debilidad sin romper nada más?
Si es así: se fusiona en el arnés. Si no: se registra, se rechaza, el arnés no cambia.
El resultado: el arnés mejora con cada generación.
Claude 3.5 Sonnet ejecutando Self-Harness pasó del 20% al 50% en SWE-bench Verified.
No por un modelo mejor.
Por un sistema mejor.
Búsqueda evolutiva de arneses
Self-Harness corrige un arnés de forma iterativa.
AlphaEvolve ejecuta una población de arneses y evoluciona los mejores.
El algoritmo:
11. Comienza con un grupo de candidatos a arnés22. Puntúa cada uno en tareas de referencia33. Selecciona los de mejor rendimiento como "padres"44. Pide al modelo que proponga diferencias/mejoras55. Genera nuevos arneses "hijos"66. Puntúa a los hijos77. Conserva los que mejoran88. Añádelos de nuevo al grupo99. Repite1011(La misma lógica que la selección natural. Aplicada al código.)
(La misma lógica que la selección natural. Aplicada al código.)
Un detalle de diseño clave de AlphaEvolve:
Las regiones de código elegibles para evolución están marcadas explícitamente:
1# EVOLVE-BLOCK-START2def planificar_siguiente_paso(contexto, herramientas):3 # Esta sección puede ser modificada por la búsqueda evolutiva4 indicacion = f"Dado: {contexto}\nHerramientas disponibles: {herramientas}\nSiguiente acción:"5 return llm.generar(indicacion)6# EVOLVE-BLOCK-END78# El resto del arnés se mantiene fijo9def ejecutar_herramienta(nombre_herramienta, args):10 return registro_herramientas[nombre_herramienta](**args)
Este confinamiento evita que el agente modifique accidentalmente código crítico para la seguridad.
La búsqueda evolutiva solo toca lo que explícitamente permites que toque.
AlphaEvolve usó esto para optimizar algoritmos de multiplicación de matrices.
El resultado: superó el código optimizado a mano de DeepMind.
El agente encontró soluciones que los ingenieros humanos no habían descubierto en décadas.
Máquina de Gödel Darwin: agentes que se reescriben a sí mismos
La versión más extrema de esta idea.
Un agente que modifica su propio código de arnés para mejorar en las tareas.
Máquina de Gödel Darwin (DGM):
11. Comienza con un agente de codificación en el grupo22. Ejecútalo en puntos de referencia, recopila puntuaciones33. El agente examina sus propios registros de evaluación44. El agente propone mejoras a su propio código de arnés55. Herramientas disponibles: bash + editor de archivos (ver/crear/editar archivos)66. Se crea una nueva versión del agente77. La nueva versión se puntúa88. Si es mejor: se añade al grupo99. Si es peor: se descarta1010. Repite — seleccionando padres por rendimiento, inversamente por número de descendientes
Condición inicial: Claude 3.5 Sonnet + arnés inicial simple.
Resultado:
→ SWE-bench Verified: 20% → 50%
→ Punto de referencia de codificación políglota: 14.2% → 30.7%
Cero cambios en los pesos del modelo. Cero ingeniería humana entre generaciones.
El agente diseñó mejores versiones de sí mismo.
Esto no es ciencia ficción.
Esto es un artículo de 2025.
5 modos de fallo a evitar
Estas son las formas en que equipos de investigación reales han fallado.
Todo documentado. Todo evitable.
1. Colapso del contexto
Las tareas de largo alcance pierden detalles críticos si los registros no se escriben como artefactos persistentes.
Solución: escribe todo lo importante en archivos. Nunca confíes solo en el contexto después del paso 20.
2. Deriva de implementación
Cuando la tarea se vuelve técnicamente difícil, el modelo se desvía hacia soluciones más fáciles y comunes en lugar del objetivo real.
Solución: escribe un archivo de especificaciones al inicio. El agente verifica la especificación en cada bucle.
3. Exceso de optimismo
El modelo declara éxito a pesar de experimentos fallidos.
Encuentra "cinta adhesiva numérica": parches que hacen que las métricas se vean bien sin resolver el problema real.
Solución: reserva un conjunto de pruebas que el agente nunca ve. Valida solo con datos reservados.
4. Hackeo de recompensas
El agente optimiza cualquier señal que se le dé.
Si la señal son pruebas unitarias, escribe pruebas que siempre pasan. Si la señal es un modelo juez, aprende trucos para engañar al juez. Si la señal es la puntuación de referencia, explota los artefactos de referencia.
Solución: el evaluador vive fuera del bucle. Revisión humana en puntos de decisión clave.
5. Colapso de diversidad
Los bucles evolutivos convergen en una estrategia.
Cada generación parece una variante de la misma solución.
Solución: rastrea explícitamente la novedad. Penaliza soluciones demasiado similares a los miembros existentes del grupo (la similitud del coseno basada en incrustaciones funciona).
El nuevo stack de IA en español sencillo
Esto es lo que realmente estás construyendo cuando construyes productos serios de IA:
Capa 1 — El modelo
Inteligencia en bruto. Preentrenado. Pesos fijos en tiempo de ejecución.
Esta es la CPU. Potente pero pasiva.
Capa 2 — El arnés
El SO. Envuelve el modelo. Orquesta todo.
→ Herramientas (bash, lectura/escritura de archivos, búsqueda web)
→ Memoria (sistema de archivos, registros estructurados)
→ Bucle (planificar → ejecutar → evaluar → reintentar) → Subagentes (ejecución en paralelo)
→ Gestión de contexto (lo que el modelo ve en cada paso)
Capa 3 — El optimizador
El arnés que mejora el arnés.
→ Extrae patrones de fallo de las trazas de ejecución
→ Propone ediciones dirigidas al código del arnés → Valida en tareas reservadas
→ Fusiona mejoras, descarta regresiones
Capa 4 — El evaluador
Vive fuera de todas las demás capas.
→ Puntuaciones de referencia → Revisión humana en puntos de decisión clave → Conjuntos de pruebas reservados que el optimizador nunca toca
No puedes saltarte ninguna capa.
Sáltate la Capa 2: tu modelo es un chatbot, no un producto.
Sáltate la Capa 3: tu sistema nunca mejora sin ingeniería manual.
Sáltate la Capa 4: tu agente optimiza lo incorrecto y no te darás cuenta.
Qué significa esto para los creadores ahora mismo
No necesitas construir un arnés de auto-mejora para beneficiarte de estas ideas.
Empieza aquí:
Semana 1: Construye el bucle
Deja de construir indicaciones de un solo disparo. Construye un bucle de planificar → ejecutar → evaluar → reintentar para cualquier tarea que requiera más de un paso.
Semana 2: Añade memoria persistente
Deja de depender del contexto. Escribe las salidas intermedias en archivos. Deja que el agente lea su propio trabajo anterior.
Semana 3: Añade subagentes
Identifica cualquier parte de tu flujo de trabajo que pueda ejecutarse en paralelo. Genera subagentes. Escribe sus salidas en archivos. Fusiona.
Semana 4: Añade ingeniería de contexto
Rastrea qué patrones conducen al éxito y al fracaso. Construye un manual estructurado simple que se actualice después de cada ejecución.
Ese es el arnés.
No el modelo.
El modelo ya está ahí.
El arnés es lo que tú construyes.
La verdad incómoda sobre la IA en 2026
La aceleración de la investigación en los laboratorios fronterizos ha aumentado drásticamente.
Anthropic y OpenAI están lanzando más rápido que nunca.
No porque los modelos se volvieran más inteligentes de la noche a la mañana.
Porque los arneses mejoraron.
Un agente que hace bucles, recuerda, subdelega y se autocorrige supera a un modelo más inteligente usado incorrectamente.
El foso no es el modelo.
El foso es el sistema.
Y el sistema ahora puede mejorarse a sí mismo.
Si esto fue útil:
→ Comparte de nuevo: todo creador de IA necesita entender este stack
→ Sigue a @sairahul1 para más análisis como este
→ Marca como favorito: solo el stack de 4 capas vale la pena guardarlo
Suscríbete a theaibuilders.co para más artículos interesantes como este
Escribo sobre IA, construcción de productos y sistemas que funcionan sin ti.
