Context Engineering: la disciplina que satisface equipos con IA y sin IA

La mayoría de equipos de desarrollo usan IA de la misma forma que usaban Stack Overflow hace diez años: cada persona busca por su cuenta, encuentra lo que funciona, y no comparte lo aprendido. Solo que ahora, en lugar de copiar snippets, escriben prompts. Y el resultado es el mismo: conocimiento fragmentado, resultados inconsistentes y una curva de aprendizaje que se repite con cada nuevo miembro del equipo.

Esto tiene un nombre. Y una solución.

Se llama context engineering: la práctica de diseñar, estructurar y gestionar el contexto que reciben los agentes de IA para producir resultados consistentes, predecibles y alineados con los estándares del equipo.

No es un concepto teórico. Es lo que separa a los equipos que "usan IA" de los equipos que dominan IA.

La evolución que la mayoría de equipos no ve

La adopción de IA en desarrollo de software ha seguido un patrón predecible. Cada fase resuelve un problema pero crea otro:

La mayoría de equipos están en la fase 1 o, como mucho, en la fase 2. Las organizaciones que están en la fase 3 o 4 no necesariamente usan mejores modelos. Usan mejor contexto.

El dato relevante: Según datos de adopción, el 80% de equipos usa IA de forma individual. Solo el 20% ha sistematizado cómo la usa. Y menos del 5% trata el contexto de IA como un activo de ingeniería gestionado.

Qué es context engineering (y qué no es)

Context engineering no es prompt engineering con otro nombre.

Prompt engineering se centra en formular una buena pregunta. Context engineering se centra en construir el sistema que hace que cualquier pregunta produzca un buen resultado.

Incluye:

• Diseño de contexto. Qué información necesita la IA para tu proyecto: arquitectura, convenciones, patrones, restricciones.
• Estructura y niveles. No toda la información se carga siempre. Progressive disclosure: lo mínimo para decidir, lo completo para ejecutar, lo detallado bajo demanda.
• Composabilidad. Contextos modulares que se combinan sin conflicto. Una skill para testing, otra para code review, otra para documentación, coexistiendo.
• Versionado y testing. El contexto se trata como código: se versiona en git, se testea que active correctamente, se itera basándose en resultados.
• Distribución organizacional. Lo que un developer descubre, todo el equipo lo hereda. Automáticamente.

En resumen: context engineering es a la IA lo que DevOps fue a la infraestructura. La sistematización de lo que antes se hacía de forma artesanal.

Skills: la formalización del context engineering

Anthropic ha publicado recientemente un estándar abierto llamado Agent Skills que formaliza estos principios. Una skill es una carpeta que contiene:

• SKILL.md (obligatorio): Instrucciones en Markdown con metadatos YAML.
• scripts/ (opcional): Código ejecutable para validaciones o transformaciones.
• references/ (opcional): Documentación adicional cargada bajo demanda.
• assets/ (opcional): Templates, recursos, ejemplos de referencia.

Lo interesante no es la estructura de carpetas. Es el modelo mental que implica.

Progressive disclosure: la IA no carga todo, carga lo justo

El sistema usa tres niveles de información:

1. Nivel 1 (metadatos YAML): Siempre cargado. Le dice a la IA cuándo activar la skill. Mínimo consumo de tokens.
2. Nivel 2 (cuerpo SKILL.md): Se carga cuando la IA determina que la skill es relevante. Instrucciones completas.
3. Nivel 3 (archivos enlazados): La IA los consulta solo cuando necesita detalle adicional. Documentación, guías API, ejemplos.

Este patrón es relevante porque resuelve un problema real: la ventana de contexto no es infinita. Más contexto no es mejor contexto. Mejor contexto es el contexto correcto en el momento correcto.

La analogía que lo explica todo

Anthropic usa una analogía de cocina que es muy clara:

MCP (Model Context Protocol) es la cocina profesional: acceso a herramientas, ingredientes, equipamiento. Conecta la IA con tus servicios (Linear, Notion, GitHub, Slack...).

Skills son las recetas: instrucciones paso a paso sobre cómo crear algo valioso con esas herramientas.

Sin recetas, tienes una cocina que nadie sabe usar. Sin cocina, las recetas son teoría. Juntos, permiten que cualquier persona del equipo ejecute flujos complejos sin tener que inventarlos cada vez.

Tres categorías de skills según el problema que resuelven

Anthropic ha identificado tres patrones recurrentes en cómo los equipos usan skills. Cada uno resuelve un problema distinto:

De skill individual a capacidad organizacional

Lo que hace que context engineering sea una disciplina y no solo una técnica es el cambio de escala: de lo individual a lo organizacional.

Las skills se pueden distribuir a nivel de organización. Esto significa:

• Un admin despliega una skill y todo el equipo la tiene automáticamente.
• Las actualizaciones son centralizadas. Cuando alguien mejora una skill, todos se benefician instantáneamente.
• La IA se comporta consistentemente para todos los miembros del equipo en el mismo proyecto.
• El onboarding se acelera porque los nuevos miembros heredan meses de conocimiento colectivo.

Esto es el salto que la mayoría de equipos no ha dado. No es que las herramientas no lo permitan. Es que no han reconocido la gestión del contexto como una responsabilidad de ingeniería.

El problema real: Cuando cada developer tiene sus propios prompts, el equipo tiene N formas distintas de usar la misma herramienta. Los resultados son inconsistentes. El código generado no respeta las convenciones. Y cada nuevo miembro tarda semanas en ser productivo con IA. No es un problema de herramientas, es un problema de contexto.

Testing de contexto: tratar instrucciones como código

Una de las prácticas más interesantes del estándar de Skills es la propuesta de testing. Si tu contexto es un activo de ingeniería, debería testearse como tal:

• Tests de activación: ¿La skill se carga cuando debería? ¿No se carga cuando no debería?
• Tests funcionales: ¿El output es correcto? ¿Las llamadas a APIs funcionan? ¿Los edge cases están cubiertos?
• Tests de rendimiento: ¿Es mejor con la skill que sin ella? ¿Cuántos mensajes de ida y vuelta se ahorran? ¿Cuántos tokens se consumen?

Datos de comparación que propone Anthropic para medir el impacto:

El concepto es simple: las instrucciones que le das a la IA son un sistema, y los sistemas se miden.

La conexión con Spec-Driven Development

Si esto suena familiar, es porque lo es.

En onext llevamos implementando los principios de context engineering en equipos de desarrollo desde antes de que existiera el término. Lo llamamos Spec-Driven Development (SDD): especificaciones estructuradas que guían a los agentes de IA con control, predictibilidad y trazabilidad.

La convergencia es directa:

• La "constitución" del proyecto en SDD es el equivalente a un SKILL.md organizacional: reglas inmutables que la IA debe respetar.
• Los templates de especificación son skills de categoría 1: documentos y assets consistentes.
• Los playbooks de prompts son skills de categoría 2: flujos de trabajo automatizados.
• El flujo de code review para IA es una skill de categoría 3: inteligencia de dominio aplicada sobre herramientas.

Lo que SDD ha demostrado: Los equipos que trabajan con especificaciones estructuradas en lugar de prompts ad hoc reducen un 75% el tiempo por feature, mejoran un 40% la consistencia del código generado y logran que cada línea de código sea trazable a un requisito. El context engineering es la formalización de estos principios a escala de industria.

Por dónde empezar

No necesitas implementar todo a la vez. La evolución natural es:

1. Semana 1-2: Crea un AGENTS.md o CLAUDE.md en tu repositorio principal. Documenta las convenciones que tu equipo ya sigue. Nuestra guía de instrucciones compartidas explica cómo hacerlo paso a paso.
2. Semana 3-4: Identifica 2-3 flujos repetitivos (code review, generación de tests, documentación) y crea instrucciones específicas para cada uno.
3. Mes 2: Empaqueta las instrucciones más efectivas como skills portables. Añade scripts de validación donde tenga sentido.
4. Mes 3+: Establece un ciclo de mejora continua: contribución, revisión, validación, distribución, feedback. Trata el contexto como un producto interno.

La clave es empezar pequeño, con lo que ya funciona, y escalar desde ahí.

El contexto es la ventaja competitiva

Todos los equipos tienen acceso a los mismos modelos. GPT-4, Claude, Gemini. Las herramientas se comoditizan. Los modelos mejoran para todos por igual.

Lo que no se comoditiza es el contexto. Cómo configuras la IA, qué sabe de tu proyecto, qué convenciones respeta, qué patrones sigue, qué errores evita. Eso es propio de tu equipo. Eso no se copia. Eso se construye.

Los equipos que dominan context engineering:

• Obtienen resultados consistentes sin depender del developer que escriba el prompt.
• Escalan el conocimiento colectivo con cada mejora que cualquier miembro aporta.
• Reducen el onboarding de semanas a días.
• Generan código que respeta la arquitectura desde el primer intento.
• Tratan la IA como un miembro más del equipo, no como un autocompletado sofisticado.

La pregunta no es si tu equipo va a usar IA. La pregunta es si el contexto que le proporcionas será artesanal o ingenieril. Esa decisión define los resultados.