Context-Engineering

Cuando comparamos herramientas de IA solemos empezar por el modelo. Que si este modelo razona mejor, que si aquel tiene más contexto, que si el nuevo benchmark lo coloca tres puntos por encima del anterior. Es lógico: el nombre del modelo es la parte visible, la que aparece en la documentación, en los selectores y, por supuesto, en el marketing.

Pero hay una pregunta que cada vez me parece más importante: cuando dos herramientas utilizan el mismo modelo y producen resultados muy diferentes, ¿qué estamos comparando realmente?

La respuesta corta es que no estamos usando solo un modelo. Estamos usando un sistema completo alrededor de él: instrucciones, contexto, memoria, herramientas, permisos, formatos de entrada y salida, bucles de validación, reintentos y condiciones de parada. A ese andamiaje se le suele llamar harness.

Y ese harness puede convertir un modelo competente en una herramienta muy útil o en un compañero que lleva veinte minutos leyendo archivos irrelevantes con una seguridad en sí mismo francamente admirable.

Este artículo cierra una serie de tres. Los anteriores cubren qué es Spec Driven Development y qué es Context Engineering. Si llegas aquí sin leerlos, la comparación que sigue va a ser menos útil.

Si ya los has leído, la pregunta que probablemente tienes es: ¿cuándo uso uno, cuándo uso el otro, y qué pasa cuando los combino? Aquí va la respuesta.

Si llevas un tiempo trabajando con IA, seguramente habrás visto en algún README, en algún hilo de Twitter o en alguna charla de meetup el consejo universal: “dale más contexto a la IA”. Lo dice todo el mundo con esa convicción de quien ha descubierto el agua caliente.

Y sí, dar contexto ayuda. El problema es que “dar contexto” como gesto vago no es lo mismo que hacerlo bien. Y hacerlo bien tiene nombre, tiene disciplina, y ese nombre no es el que circula por ahí.

Si llevas unos meses siguiendo el ruido de Twitter/X, LinkedIn y los blogs de las grandes plataformas, habrás visto que el término Spec Driven Development aparece cada vez más. GitHub lo usa para presentar Spec Kit. Microsoft lo menciona en su documentación de Azure Verified Modules. InfoQ le dedicó un artículo largo a principios de 2026.

Detrás del buzz hay algo concreto. SDD no es un invento reciente ni un eufemismo para “escribir documentación”. Tiene historia, tiene una mecánica clara y, con los agentes de código actuales, cobra un sentido que antes era difícil de aprovechar.