Por qué Claude 4.6 no basta sin contexto: el gran punto ciego del desarrollo con LLM

Un LLM potente no compensa una entrada deficiente: si el agente solo ve un fragmento de código, y no la arquitectura, las dependencias y las reglas del entorno, los errores resultan casi inevitables. Un desarrollador que se ha pasado casi por completo a la programación con IA mediante Cursor y Claude 4.6 explica por qué el contexto resultó más importante que elegir entre modelos.

No es el modelo, es el contexto

En el desarrollo con LLM es fácil obsesionarse con comparar GPT, Claude y Gemini y con pulir prompts. Pero en la práctica la mejora suele venir no de cambiar de modelo, sino de cuánta información útil recibe el agente antes de su primera acción. Si el contexto incluye la estructura de los servicios, las restricciones de la infraestructura, las bibliotecas compartidas, las convenciones del equipo y las decisiones pasadas, el modelo actúa como un ingeniero que ya ha trabajado en el proyecto. Si no, hasta un agente potente empieza a adivinar, y en producción las conjeturas salen caras.

El autor lo plantea sin rodeos: la diferencia entre un «agente con contexto» y un «agente sin contexto» no se mide en porcentajes de calidad, sino en consecuencias. Uno cierra la tarea en unos minutos; el otro pierde una hora, rompe servicios vecinos y acaba en una reversión. Para un desarrollador en solitario con decenas de microservicios y hosts, no es un riesgo teórico, sino un problema operativo diario. Aquí la IA no trabaja en un entorno aislado, sino en un sistema vivo, donde cualquier error alcanza al instante a otros componentes.

«La diferencia es el camino de una solución en cinco minutos a una

hora de errores y reversiones».

Cómo se rompen los agentes

Cuando la IA escribe código casi de forma autónoma, no le basta con ver el archivo actual. En los sistemas reales la lógica está repartida entre repositorios, configuraciones, infraestructura y reglas informales. Un agente puede reescribir correctamente una función y aun así romper una integración, porque desconoce una dependencia antigua, un ajuste inusual del host o una convención que no está documentada explícitamente en ningún sitio. Cuanto más se parece el sistema a un ecosistema vivo, más cara resulta la falta de ese conocimiento.

• relaciones entre microservicios y orden de despliegue
• particularidades de las bibliotecas compartidas y contratos internos de API
• límites del hardware, las máquinas virtuales y el entorno local
• reglas de pruebas, verificación manual y reversión de cambios

Por eso el autor organiza su trabajo en torno a una base de conocimiento y no a un único prompt afortunado. La idea es que el agente vea no solo el código, sino un mapa del sistema: qué se conecta con qué, dónde están los puntos débiles, qué decisiones ya se tomaron y qué restricciones no se pueden vulnerar. Un buen prompt ayuda a plantear la tarea, pero no sustituye la memoria del proyecto. Sin ella, el LLM sigue siendo un ejecutor rápido pero miope, capaz de ir con seguridad en la dirección equivocada.

Una capa de conocimiento del sistema

El enfoque se probó con Claude 4.6 Opus, con una ventana de contexto de hasta un millón de tokens. Es una salvedad importante: el método depende no solo de la calidad de las descripciones, sino también de la capacidad del modelo para retener físicamente un gran volumen de datos y extraer lo esencial. Una ventana pequeña recortará la mitad de la información útil, y un análisis débil se ahogará en el ruido incluso con un buen conjunto de documentos. En este esquema, el tamaño del contexto pasa a ser parte de la herramienta y no un dato vistoso en la nota de lanzamiento.

La conclusión práctica es simple: el contexto hay que construirlo como una capa independiente del sistema. Incluye notas de arquitectura, descripción de servicios, lista de dependencias, estructura de los entornos, escenarios típicos de pruebas y reglas para cambios seguros. Cuanto mejor esté organizada esta capa, más se acerca el agente de IA a un socio técnico completo: no se limita a generar código, sino que entiende dónde encaja exactamente y qué puede afectar. Dicho de otro modo, la documentación empieza a funcionar como interfaz para el modelo.

Se nota sobre todo en el modo en que el desarrollador formula primero la tarea, luego discute con el agente el plan de arquitectura, y después el modelo escribe el código y las pruebas, ejecuta él mismo las comprobaciones y corrige los errores que encuentra. Esta orquestación solo funciona cuando el agente tiene el panorama general del proyecto. De lo contrario, la automatización acelera no el desarrollo, sino la propagación de decisiones erróneas. Cuantas más acciones se delegan en el modelo, más cara resulta cada laguna de conocimiento.

Qué significa

El mercado de la programación con IA se desplaza poco a poco de la carrera de modelos a la carrera por un contexto de calidad. Para desarrolladores y equipos, esto significa que el próximo gran aumento de productividad no vendrá de un prompt nuevo, sino de una base de conocimiento del proyecto bien construida. No ganarán quienes simplemente tengan un LLM más potente, sino quienes le enseñen a ver el sistema completo. Ahí es donde hoy surge la ventaja competitiva real.