Context Engineering for Software Development

Qué problema resuelve y cuál es su alcance

Context Engineering for Software Development es la selección, organización, delimitación, actualización y transferencia deliberada de información disponible para un sistema AI mientras realiza trabajo de ingeniería de software. Es una definición de trabajo del Atlas, no un estándar formal. La pregunta central es qué necesita saber el sistema para la próxima decisión y cómo mantener esa información pertinente durante la tarea.

Este canonical trata específicamente la aplicación al desarrollo: repositorios, contratos, pruebas, instrucciones y evidencia del cambio. Context Management conserva el tratamiento general en Application Patterns, con Context Engineering como práctica de diseño deliberado dentro de esa área; aquí no se pretende definirlos para todos los productos AI. La aplicación puede abarcar asistencia conducida por una persona o trabajo delegado a un coding-agent, sin exigir agencia autónoma ni múltiples participantes.

El problema no se resuelve adjuntando todo el repositorio. Información ausente puede ocultar una restricción, pero información sobrante puede incorporar ruido, decisiones obsoletas o instrucciones incompatibles. La discusión de contexto de Anthropic fundamenta examinar selección y continuidad, más allá de redactar una solicitud. El Atlas aplica esa preocupación al trabajo de software sin importar una receta universal ni prometer mejoras cuantitativas.

Contexto, prompt y Prompt Engineering

El prompt comunica una solicitud o instrucción en una interacción; puede incluir objetivo, restricciones y ejemplos. El contexto es más amplio: información disponible durante inferencia y ejecución, como archivos seleccionados, instrucciones aplicables, mensajes anteriores, resultados de herramientas y condiciones del entorno. El prompt participa en ese conjunto, pero no lo agota. Un archivo disponible en disco tampoco está necesariamente presente en la entrada del modelo.

Prompt Engineering se concentra en cómo expresar instrucciones y preguntas. Context Engineering pregunta además qué información entra, desde dónde, cuándo, con qué alcance y cómo se renueva o transfiere. Ambas actividades pueden coexistir. Una solicitud bien formulada no compensa una interfaz obsoleta, y seleccionar archivos pertinentes no vuelve irrelevante explicar el resultado buscado. No se afirma que una disciplina haya reemplazado a la otra.

La guía de trabajo con Codex relaciona encargo, contexto, restricciones y condiciones de finalización. Es un ejemplo de preparación de tareas, no un formulario obligatorio. En una corrección pequeña puede bastar una selección breve; en una investigación distribuida pueden hacer falta observaciones sucesivas. El volumen inicial no ofrece una medida universal de calidad.

Memoria, estado y Context Window

Memoria nombra mecanismos o información conservada para recuperarla a través del tiempo. El contexto activo reúne lo que está disponible para la decisión actual. Una memoria puede aportar contenido a ese contexto; no significa que todo lo guardado deba cargarse ni que una conversación extensa constituya memoria fiable. La persistencia de una nota y su recuperación efectiva son condiciones diferentes.

El estado de ejecución describe lo ocurrido o lo pendiente: un comando activo, una autorización sin resolver, archivos modificados o resultados recibidos. Parte de ese estado puede transformarse en contexto mediante un resumen o una observación. No todo estado interno necesita exponerse al modelo, y un texto que diga «test pendiente» no demuestra que exista un proceso en ejecución. El agent-harness conserva responsabilidades de runtime distintas de la estrategia informativa.

Context Window, desarrollado dentro de llm-fundamentals, es capacidad o límite de la representación que el modelo puede considerar. Una ventana mayor puede admitir más información, pero no elimina selección, actualidad, autoridad ni costo. La documentación de la ventana de Claude Code ilustra que el contexto contiene distintas clases de material. Aquí no se fija un tamaño ni un umbral de compaction, porque dependen del modelo y del runtime.

Repository Context y Task Context

Repository Context describe el código y su organización: estructura relevante, símbolos, interfaces, tests, configuración, dependencias, comandos de build, documentación y decisiones arquitectónicas. No es un inventario que deba cargarse completo. Para entender un endpoint pueden importar su contrato y una prueba de integración más que todos los archivos del proyecto o una descripción histórica de su arquitectura.

Task Context explica el encargo particular: objetivo, problema, criterios de aceptación, restricciones, subsistema afectado, errores observados y decisiones previas. Una discusión de issue puede contener evidencia útil y opiniones descartadas; no todas deben convertirse en requisitos. Diferenciar tarea y repositorio permite detectar cuándo una convención estable no responde la pregunta concreta o cuándo una solicitud necesita aclaración comercial.

Las preferencias del usuario y las políticas de organización pueden aportar guía, sin desplazar la relevancia de repositorio y tarea. El contexto del entorno describe plataforma, herramientas, branch, worktree, comandos y permisos conocidos. Esa representación no es el agent-execution-environment mismo: informar que existe un runtime no lo instala, y mencionar permisos no los concede. persistent-instructions desarrolla la guía reutilizable que puede ingresar en esta selección.

Selección y adquisición progresiva

Context Selection pregunta qué evidencia ayuda a la decisión actual. Puede apoyarse en archivos explícitos, búsqueda de símbolos o código, retrieval, exploración mediante herramientas o información humana. Son mecanismos diferentes para encontrar material; ninguno determina automáticamente su relevancia, autoridad o vigencia. El nombre de un archivo parecido al problema no prueba que participe de la ejecución observada.

Una adquisición progresiva puede comenzar con el encargo, localizar el área, leer un contrato y expandir contexto según los resultados. Evita asumir que toda información necesaria se conoce de antemano. Tampoco es siempre superior: una restricción global conocida puede necesitar estar presente desde el inicio, y búsquedas reiteradas pueden consumir más tiempo que una explicación breve del responsable.

En Commerce, agregar un endpoint de consulta de pedidos puede requerir ruta, autorización, DTO y tests representativos. Inspeccionar primero el controlador correspondiente permite encontrar convenciones reales. Si aparece una dependencia de Payments, el agente puede consultar su interfaz sin cargar todo el servicio ni asumir autorización para cambiarlo. La selección sigue preguntas y evidencia; no una obligación de leer el árbol completo antes de cada edición.

Refresh, actualidad y cambios de situación

El contexto puede quedar obsoleto durante la tarea. Otro cambio puede alterar un archivo, el usuario puede corregir el requisito o una ejecución puede devolver nueva evidencia. Una referencia que era adecuada al comenzar no debe conservarse como hecho incuestionable. Refresh consiste en volver a observar lo relevante cuando una decisión depende de que siga siendo cierto, sin releer indiscriminadamente todo el material.

Conviene distinguir qué cambió y qué conclusión dependía de ello. Si cambió la firma del servicio, puede hacer falta revisar llamadas y tests; si solo cambió el mensaje del usuario, puede cambiar el alcance autorizado aunque los archivos sean idénticos. La fecha o revisión de una observación ayuda a interpretarla, pero no garantiza actualidad. Mantener un resumen actualizado exige contrastarlo con las fuentes que pretende representar.

Compression y Compaction

Una ejecución larga puede resumir, comprimir o descartar contexto anterior para continuar dentro de límites prácticos. Compaction busca conservar lo útil reduciendo el material activo; las realizaciones concretas varían. No equivale a una memoria duradera perfecta. Una representación más corta puede omitir restricciones, rationale, casos límite, incertidumbre o procedencia que luego vuelven a importar.

En la tarea de Commerce, «endpoint terminado» es un resumen insuficiente si omite que falló la prueba de autorización y que el usuario prohibió modificar Payments. Conservar solo conclusiones puede transformar hipótesis en hechos. Una compaction útil necesita preservar qué se verificó, qué sigue pendiente y cómo recuperar evidencia, sin exigir conservar cada línea de una salida repetitiva.

Las instrucciones importantes tampoco deberían desaparecer inadvertidamente, pero no se presupone que todos los harnesses las preserven igual. Puede ser necesario recargarlas desde su fuente y comprobar su aplicabilidad actual. El documento Persistent Instructions aborda esa continuidad. Una compaction que facilita seguir trabajando no demuestra que el sistema retuvo todos los detalles ni que repetir el relato del resumen sea una verificación independiente.

Context Isolation y límites distintos

Context Isolation separa información expuesta a tareas, sesiones o agentes para limitar contaminación, historia irrelevante, instrucciones conflictivas o exposición innecesaria. Una investigación de autenticación puede necesitar evidencia distinta de otra sobre estilo visual. Separar sus contextos no garantiza independencia de criterio: ambos sistemas pueden compartir modelo, supuestos, fuentes o errores de una descripción inicial.

La frontera informativa no es agent-sandboxing. Dos agentes pueden tener contextos separados y compartir máquina, red o credenciales. Un proceso aislado técnicamente puede recibir un contexto contaminado. Workspace Isolation separa archivos y estado de trabajo; no determina qué historia o resumen recibe el modelo. Las tres separaciones pueden alinearse, pero ninguna implica automáticamente las otras.

Context Handoffs

Context Handoff transfiere información relevante cuando otra persona, agente o sesión continúa una parte del trabajo. Puede incluir objetivo, estado, decisiones, archivos cambiados, trabajo restante, comprobaciones e incertidumbres. No se exige un schema ni un archivo universal. El criterio es que el receptor pueda entender qué debe hacer y qué afirmaciones necesitan volver a contrastarse.

Transferir información no equivale a transferir responsabilidad o control. Un Agent Handoff puede requerir contexto, mientras un resumen para revisión humana puede compartirlo sin delegar la decisión de release. Tampoco una nota «autorizado» sustituye la evidencia y el alcance de una aprobación. El receptor necesita distinguir guía vigente, observación previa y sugerencia del autor del handoff.

Un buen handoff permite recuperar fuentes sin copiar todo su contenido. Referencias a archivos, revisión y resultados ayudan, pero pueden quedar obsoletas si el workspace cambia. La documentación de proyectos y chats de Codex distingue conversación y archivos del working tree; ese ejemplo recuerda que continuidad de transcript no congela el repositorio. El receptor debe revalidar lo que su próxima acción presupone.

Procedencia, autoridad y confianza

La procedencia permite preguntar de dónde vino un dato: usuario, repositorio, herramienta, documentación externa o resumen generado. Relevancia pregunta si ayuda a la tarea; autoridad, si puede dirigir una decisión; confianza, con qué fundamento se utiliza. Son ejes distintos. Un README puede explicar correctamente una API sin tener autoridad para anular una restricción del usuario o una política de runtime.

Resultados de búsqueda, compilación, tests o diffs pueden convertirse en contexto. Tool output no es automáticamente una instrucción confiable. Un archivo recuperado puede contener texto que intenta cambiar el encargo; repetirlo dentro de un resumen no le concede autoridad. Esta relación con prompt injection se menciona para conservar la frontera, sin desarrollar aquí un canonical de AI Security.

Tampoco todas las salidas tienen igual valor probatorio. Un error de preparación informa sobre el entorno, no necesariamente sobre el código. Una hipótesis generada por otro agente sigue siendo hipótesis aunque llegue con una explicación detallada. Mantener procedencia y grado de certeza ayuda a evitar que el contexto acumulado convierta suposiciones en requisitos aparentes.

Presupuesto, calidad y trade-offs

La selección enfrenta capacidad de ventana, latencia, costo de inferencia y overhead de herramientas o retrieval. Reducir texto puede perder detalles; incorporar más puede introducir ruido o instrucciones incompatibles. No se establece un presupuesto universal de tokens ni una fórmula que maximice utilidad. El compromiso depende de la tarea, los datos y las garantías que se necesiten conservar.

Relevancia, actualidad, autoridad, completitud suficiente, especificidad y procedencia son dimensiones útiles para revisar contexto, no un scoring model normativo. Información secreta o innecesaria puede aumentar riesgo sin aportar una decisión útil. Más contexto no garantiza un mejor resultado y mejor selección no determina por sí sola la calidad del agente: modelo, tools, permisos y verificación también influyen.

Ejemplo integrado en un repositorio .NET

La tarea es agregar en Commerce.Api una consulta del estado de un pedido sin alterar cobros. Repository Instructions indica la versión objetivo declarada en el repositorio, comandos de build/test, convenciones y áreas generadas que no deben editarse. El prompt aporta el endpoint deseado y criterios de aceptación. El contexto seleccionado incorpora contrato HTTP, autorización, implementación relevante y pruebas existentes.

Una búsqueda identifica la ruta y un test revela una condición de acceso no mencionada en el encargo. Esa observación actualiza la comprensión; no autoriza suprimir el control para conseguir un test verde. Si otra sesión retoma, necesita saber qué archivos cambiaron, qué comprobación falló y qué decisión sigue abierta. No necesita recibir todos los logs ni acceso adicional a producción para interpretar el estado.

El ejemplo combina tarea, instrucciones persistentes, contexto del repositorio, observaciones y una representación pertinente del estado en contexto activo. El modelo y el sistema agente lo utilizan para proponer el próximo paso. Es síntesis conceptual del Atlas, no una API de ensamblado ni una metodología obligatoria de desarrollo; cada componente conserva sus responsabilidades.

Fallos frecuentes y relaciones en el Atlas

task-prompts, agent-skills y agent-profiles pueden aportar fuentes al contexto activo, junto con instrucciones y observaciones; su disponibilidad no demuestra que se hayan cargado ni aplicado. development-context-and-execution-records conserva evidencia que puede recuperarse para un handoff, sin sustituir la selección y actualización de información pertinente.

Contexto faltante puede ocultar una restricción; contexto obsoleto puede sostener una decisión inválida; exceso irrelevante puede dificultar encontrar lo importante. También pueden fallar un resumen, una selección de fuentes o una transferencia. Repetir una afirmación incierta no aumenta su evidencia. La recuperación exige localizar qué observación falta o dejó de ser válida, en lugar de añadir información sin una pregunta concreta.

repository-exploration-and-task-framing desarrolla la actividad que descubre evidencia del repositorio y establece el significado de una tarea. Produce contexto candidato; Context Engineering abarca además selección, mantenimiento y transferencia de información durante el trabajo. RAG puede recuperar evidencia para generación, mientras Tool Use permite adquirirla sin decidir por sí mismo qué conservar activo. Sus tratamientos generales viven en sus propios canonicals de Application Patterns.

agent-harness puede implementar carga, selección, refresh, compaction o transferencia; no es la estrategia informativa misma. persistent-instructions aporta una fuente de guía; coding-agent utiliza contexto para trabajar bajo un objetivo. ai-assisted-software-engineering conecta esta lectura con el resto de la rama. El canonical conserva alcance de desarrollo sin duplicar el tratamiento general de Context Management.

Fuentes

Fuentes primarias consultadas el 2026-10-26. Definición de trabajo, distinciones, dimensiones de revisión y Commerce son síntesis editorial del Atlas, no estándares universales ni claims cuantitativos de rendimiento.

• Anthropic: Effective context engineering for AI agents, selección y continuidad de contexto; artículo de 2025, sin convertir su implementación en regla universal.
• OpenAI: Best practices, preparación de tareas y contexto pertinente en Codex.
• Claude Code: Explore the context window, clases de información y gestión de una ventana finita.
• OpenAI: Projects and chats, continuidad de conversación y relación con archivos actuales.