El agente no se volvió más inteligente — el proyecto sí

Hace seis meses, una tarea de programación requería una sesión entera de explicación. La semana pasada, el mismo tipo de tarea tomó una oración. El modelo no cambió entre esas dos sesiones. Claude Opus 4.6 sirvió a ambas. Los mismos pesos, la misma arquitectura, la misma ventana de contexto, las mismas capacidades.

El agente de IA no se volvió más inteligente entre la sesión 1 y la sesión 500; lo que cambió fue la infraestructura del proyecto. Esta es la afirmación central del territorio de la ingeniería de IA: el modelo es una constante, y la variable es todo lo que construyes a su alrededor. En proyectos de larga duración, el modelo aporta aproximadamente el 30% de la calidad de la sesión, mientras que el contexto acumulado proporciona el otro 70%: documentos de convenciones, memorias de decisiones, artefactos de transferencia, hooks, skills y cobertura de pruebas. Un modelo peor en un proyecto rico a menudo supera a un modelo mejor en uno vacío.

El proyecto cambió.

La conversación equivocada

La conversación sobre productividad con IA gira casi por completo en torno a las capacidades del modelo. Qué modelo es más rápido. Qué modelo escribe el mejor código. Qué modelo maneja el contexto más largo. El supuesto implícito es que el modelo es la variable: actualiza el modelo, mejora el resultado.

Este supuesto es erróneo para proyectos de larga duración. En un proyecto en el que llevo trabajando seis meses con más de 500 sesiones de agente, el modelo aporta quizá el 30% de la calidad de la sesión. El otro 70% proviene de la infraestructura acumulada del proyecto: documentos de convenciones, memorias de decisiones, artefactos de transferencia, hooks de comportamiento, skills codificadas y cobertura de pruebas.

Un mejor modelo en un proyecto vacío produce mejor salida que un peor modelo en un proyecto vacío. Un peor modelo en un proyecto con 500 sesiones de contexto acumulado a menudo produce mejor salida que un mejor modelo en un proyecto vacío. La infraestructura domina al modelo. Por eso el contexto es arquitectura – el conocimiento acumulado del proyecto no es información complementaria, sino estructura portante.

Evidencia

La corrección de rendimiento de la página de mercado ilustra el punto. Una oración: “arregla el rendimiento de la página de mercado”. El agente:

1. Leyó un documento de transferencia de una sesión anterior que diagnosticaba el cuello de botella
2. Identificó la ruta de código correcta (market_hub(), no _fetch_market_data())
3. Implementó una consulta de base de datos paginada con un RPC agregado
4. Escribió pruebas
5. Desplegó

Austin pasó de 14 segundos a 108 milisegundos. Una mejora de 132x a partir de una sola indicación.¹

Esto no sucedió porque el modelo sea inteligente. Sucedió porque existía el documento de transferencia. La transferencia capturó un diagnóstico que sobrevivió a tres correcciones de revisión de código y dos reordenamientos de prioridades a lo largo de cuatro días. Sin la transferencia, el agente habría empezado desde cero. Habría investigado la ruta de código equivocada (como hizo el primer borrador de la transferencia). Habría propuesto parciales HTMX innecesarios (como hizo el plan original). La transferencia contenía los errores ya cometidos y corregidos. El agente heredó la comprensión corregida.

La contribución del modelo fue leer la transferencia e implementar la corrección. La contribución de la infraestructura fue tener la transferencia correcta para leer.

Qué cambia y qué no

Entre la sesión 1 y la sesión 500 en el mismo proyecto, exactamente una cosa permanece constante: el modelo. Todo lo demás cambia.

Qué cambia:

• El CLAUDE.md pasa de vacío a completo. Las preguntas sobre convenciones desaparecen. El artículo sobre patrones de AGENTS.md describe los patrones específicos que hacen que estos archivos sean efectivos.
• Los archivos de memoria se acumulan. Las decisiones quedan en caché. Los trade-offs quedan registrados. El proyecto deja de relitigar preguntas ya resueltas.
• Los hooks se acumulan. Cada uno previene una clase de fallo que ocurrió en una sesión anterior. 84 hooks interceptando 15 de los 26 tipos de eventos del ciclo de vida que Claude Code expone, cada uno una cicatriz de un incidente pasado.
• Las skills se acumulan. Los flujos de trabajo repetitivos se convierten en operaciones de un solo comando. El nightcheck que tomó una sesión entera para diseñar ahora se ejecuta en 2 minutos.
• Las pruebas se acumulan. El agente hace cambios más audaces porque puede verificarlos de inmediato.
• Los documentos de transferencia se acumulan. Las investigaciones complejas persisten a través de los límites de sesión.

Qué permanece igual:

• El modelo. Los mismos pesos. Las mismas capacidades. La misma tendencia a desviarse de la tarea, a verificar de forma fantasma los resultados de las pruebas (véase la puerta de evidencia) y a proponer abstracciones innecesarias.

Los modos de fallo del modelo son constantes. La capacidad de la infraestructura para detectar esos modos de fallo crece con cada sesión. La sesión 500 es mejor que la sesión 1 no porque el modelo haya mejorado, sino porque la infraestructura aprendió a compensar las debilidades constantes del modelo.

El marco de inversión

Si el modelo no es la variable, entonces la selección del modelo no es la decisión de inversión principal. La inversión principal está en la infraestructura de contexto.

Un equipo que gasta $200/mes en Claude Max (que ejecuta Opus 4.7 por defecto) e invierte fuertemente en archivos CLAUDE.md, sistemas de memoria, hooks, skills y cobertura de pruebas superará a un equipo que gasta $200/mes en el mismo plan sin inversión en infraestructura. El costo del modelo es idéntico. La calidad de la salida diverge porque la infraestructura diverge.

Esto replantea la pregunta sobre productividad. La pregunta no es “¿qué modelo deberíamos usar?” La pregunta es “¿qué hemos construido alrededor del modelo que hace que cada sesión sea mejor que la anterior?”

Las organizaciones que veo luchando con la productividad de IA no están usando el modelo equivocado. Están comenzando cada sesión desde cero. Sin documento de convenciones. Sin sistema de memoria. Sin hooks. Sin skills. Sin contexto acumulado. Cada sesión es la sesión 1, sin importar cuántas sesiones la precedieron.

El modelo mejorará

Los modelos seguirán mejorando. Claude Opus 4.7 fue mejor que Claude Opus 4.6, Opus 5 será aún mejor. La mejora es real y valiosa. Pero la mejora es aditiva, no multiplicativa.

Un modelo que es 20% mejor en la generación de código produce una salida 20% mejor en un proyecto vacío. El mismo modelo con 500 sesiones de contexto acumulado produce una salida que es cualitativamente diferente, no solo cuantitativamente mejor. La infraestructura de contexto no suma un 20% a la capacidad del modelo. Proporciona el diagnóstico, las restricciones, los criterios de verificación y el historial operativo que el modelo no puede producir por sí solo, sin importar cuán capaz sea.

Ningún modelo, por capaz que sea, puede saber que market_hub() carga todas las filas de company_markets y las pagina en Python a menos que algo se lo diga. El documento de transferencia se lo dice. El modelo lee y actúa. La inteligencia está distribuida entre el modelo (leer, razonar, implementar) y la infraestructura (conocer, restringir, verificar).

Sesión 500

La sesión 500 se ve así: expreso lo que quiero en una oración. La arquitectura de agente Ralph es el sistema que hace esto posible. El agente lee el CLAUDE.md y conoce las convenciones. Lee los archivos de memoria y conoce las decisiones. Lee la transferencia y conoce el diagnóstico. Se topa con un hook que previene el mismo error que otro agente cometió hace tres meses. Verifica su trabajo contra la suite de pruebas. Reporta la finalización con evidencia para cada afirmación.

La sesión 1 se ve así: explico el esquema de la base de datos, las convenciones de enrutamiento, la herencia de plantillas, la capa de caché, la canalización de despliegue y los patrones de pruebas. El agente hace preguntas aclaratorias. Propone un enfoque que viola tres convenciones. Lo corrijo. Implementa la corrección. Reporta “las pruebas pasan” sin ejecutar pytest.

El modelo es el mismo en ambas sesiones. El proyecto no.

Preguntas frecuentes

¿No importa todavía la calidad del modelo?

Sí. Un modelo más fuerte lee el contexto de manera más efectiva, razona sobre los trade-offs con mayor precisión e implementa soluciones de forma más limpia. La calidad del modelo establece el piso. La infraestructura eleva el techo. En un proyecto maduro, el techo importa más que el piso.

¿Esto es específico de los agentes de codificación?

No. Cualquier flujo de trabajo de IA donde el mismo dominio de tarea se repite a través de sesiones se beneficia del contexto acumulado. Escritura, investigación, análisis, soporte al cliente. La infraestructura específica difiere (guías de estilo en lugar de CLAUDE.md, bases de conocimiento en lugar de hooks), pero la dinámica es la misma: el proyecto mejora porque el contexto alrededor del modelo se acumula.

¿Qué pasa con los modelos multimodales o los modelos de razonamiento?

El mismo principio. Un modelo de razonamiento que puede pensar durante 10 minutos sobre un problema todavía necesita saber sobre qué problema pensar. El documento de transferencia, el archivo de convenciones y el sistema de memoria proporcionan la definición del problema. El modelo proporciona el razonamiento. Un mejor razonamiento sobre un problema bien definido produce mejores resultados que un razonamiento inferior, pero un mejor razonamiento sobre un problema indefinido produce una confusión que suena mejor.

¿Cómo empiezo si tengo cero infraestructura de contexto?

Escribe un archivo CLAUDE.md que describa las convenciones de tu proyecto. Ese único archivo es la inversión de mayor impacto. Todo lo demás se acumula a partir de ahí.²

Fuentes