Ingeniería de contexto: que la IA no adivine nada
Una IA que programa no sabe lo que tu equipo decidió. Todo lo que no esté escrito en lo que le das, lo adivina — y lo hace con total seguridad. La buena noticia: tu equipo ya produjo, sprint tras sprint, justo la información que ella necesita (el backlog, los casos de uso, el diagrama de clases, el diagrama de estados). Esta guía enseña a convertir esos artefactos en contexto, para que la IA ejecute y vos conserves el control de las decisiones.
👁 — vistas · Ing. Roy Carrasco, Facultad de Ingeniería de Sistemas · UAB
Volvés al equipo de EventoUAB, ya en el Sprint 3. Valentina va a rehacer una historia con un asistente de código y Camila (la PO) es quien decide qué reglas de negocio valen. En cada decisión podés probar primero un camino equivocado, ver su consecuencia sin ninguna penalidad, y recién después se desbloquea el correcto.
Dos líneas y un módulo que no es nuestro
La historia #14, «Cancelar una reserva», vuelve al tablero del Sprint 3: la primera versión no distinguía estados y Camila pidió rehacerla bien. Valentina abre su asistente de código y escribe lo primero que se le ocurre: «Hacé el módulo para cancelar reservas de EventoUAB en JavaScript». En diez segundos tiene esto:
// cancelarReserva.js
import { db } from "./db.js";
import { enviarCorreo } from "./correo.js";
export async function cancelarReserva(reservaId, usuario) {
const reserva = await db.reservas.findById(reservaId);
if (reserva.userId !== usuario.id && usuario.rol !== "admin") {
throw new Error("No autorizado");
}
reserva.status = "CANCELLED";
reserva.motivo = usuario.motivo;
reserva.penalidad = reserva.precio * 0.2;
await db.reservas.save(reserva);
await enviarCorreo(usuario.email, "Reserva cancelada");
return reserva;
}
Compila, se lee prolijo y hasta suena razonable. Pero Valentina lo mira con calma y se da cuenta de que casi nada de eso existe en EventoUAB:
| Lo que escribió la IA | La realidad del proyecto |
|---|---|
db.reservas.findById, ./db.js | No hay ese módulo ni esa API de base de datos. |
reserva.userId, usuario.rol === "admin" | Una reserva pertenece a un club, y no existe el rol «admin». |
reserva.status = "CANCELLED" | El atributo se llama estado y sus valores van en español. |
reserva.motivo, reserva.penalidad, reserva.precio | Nadie pidió motivos ni cobros; las reservas no tienen precio. |
enviarCorreo(...) | Notificar a Bienestar es otra historia, no esta. |
| (no hay nada sobre las 2 horas) | La regla central de la historia ni aparece. |
Un prompt de dos líneas deja decenas de decisiones abiertas. La IA no puede preguntar «¿cómo se llama el dueño de la reserva?», así que elige una respuesta verosímil. Lo verosímil casi nunca coincide con lo que tu equipo acordó.
¿Cómo sigue Valentina?
Parchar lo que se ve es apagar un incendio cada vez: Valentina corrige lo que reconoce como raro, pero lo inventado que suena plausible se queda. Y la próxima vez que pida otra función, la IA volverá a inventar. El problema está en la entrada, no solo en la salida. Probá con otra opción.
«Mejor y más profesional» no agrega ni un dato nuevo: la IA volverá a rellenar los mismos huecos, solo que con otro estilo. Puede salir un código más elegante y igual de ajeno al proyecto. Repetir la consigna no reemplaza darle información. Probá con otra opción.
Exacto. El defecto es de información, no de modelo. Lo que importa es qué recibe la IA, no cuántas veces se lo pidas. Seguí leyendo ↓
Qué es la ingeniería de contexto
El prompt es la instrucción («hacé esto»). El contexto es todo lo demás que el modelo tiene delante cuando responde: los documentos, los nombres, las reglas, los ejemplos. La ingeniería de contexto es decidir qué información recibe, con qué forma y en qué orden, para que haga la tarea sin suponer.
| Escribir un prompt | Ingeniería de contexto | |
|---|---|---|
| Pregunta | ¿Cómo se lo pido? | ¿Qué necesita saber para no tener que adivinar? |
| Material | Una frase o un párrafo. | Historia, casos de uso, modelo, estados, límites y convenciones. |
| Quién decide | La IA, en lo que no dijiste. | El equipo, y queda por escrito. |
| Resultado | Código que se ve bien. | Código que se puede comprobar contra un artefacto. |
Tu equipo ya tiene el material
No hay que inventar documentos nuevos. Cada artefacto que el curso te hizo producir cubre un tipo distinto de hueco:
| Artefacto | Qué decide | Qué inventaría la IA si falta |
|---|---|---|
| Backlog: historia, criterios y DoD | Qué hacer y cuándo está terminado. | Reglas de negocio, bordes y alcance. |
| Casos de uso | Quién lo usa y qué pasa en cada rama. | Actores, pasos y flujos alternativos. |
| Diagrama de clases | Cómo se llaman las cosas y cómo se relacionan. | Clases, atributos y relaciones. |
| Diagrama de estados | Qué se puede hacer en cada momento. | Transiciones y estados que no existen. |
Relevante: solo lo que la tarea necesita; el ruido compite con lo importante. Exacto: los mismos nombres que el código final, copiados y no parafraseados. Verificable: cada línea del resultado tiene que poder rastrearse hasta un artefacto.
El artefacto es la fuente de verdad y el código es su consecuencia. Si el código y el artefacto discrepan, alguno de los dos está mal, y quien lo decide es una persona del equipo, no el modelo. Eso es lo que significa que el programador mantenga el control.
¿Cuánto del backlog le paso?
Valentina ya entendió que debe dar contexto. Lo primero que piensa es el backlog: ahí está la historia #14 y todo lo que Camila pidió. El tablero del producto tiene 38 historias entre «Ver disponibilidad», «Lista de espera», «Notificar a Bienestar» y varias más. ¿Qué pega en el chat?
¿Qué parte del backlog le da a la IA?
Más no es mejor. Con las 38 historias, la IA ve «Lista de espera» y «Notificar a Bienestar» y puede decidir adelantar esa parte «ya que está». El contexto irrelevante compite con el importante y arrastra la función hacia otras historias. Probá con otra opción.
«Sentido común» es justo el nombre elegante de adivinar. Cuántas horas de anticipación, quién puede cancelar y qué pasa en el borde no se deducen del título: están solo en los criterios de aceptación que Valentina dejó afuera. Probá con otra opción.
Exacto. La historia, sus criterios y la DoD son lo que esta tarea necesita, y nada más. Seguí leyendo ↓
El backlog como contexto: el qué y el cuándo está listo
Una historia bien escrita ya es medio prompt. Los criterios de aceptación son las reglas que el código debe cumplir y que la prueba va a comprobar; la Definition of Done dice qué más hace falta para llamarla terminada. Y hay una sección que casi nadie escribe y que más protege: lo que NO entra en esta historia.
Historia #14 — Cancelar una reserva
Como estudiante responsable de un club, quiero cancelar una reserva
que ya no voy a usar, para liberar el espacio.
Criterios de aceptación
- Solo el club que hizo la reserva puede cancelarla.
- No se puede cancelar con menos de 2 horas de anticipación.
Justo 2 horas antes sí se puede.
- Solo se puede cancelar una reserva confirmada.
Fuera de esta historia
- Notificar a Bienestar Estudiantil (historia #22).
- Cobros, penalidades o motivos de cancelación.
Definition of Done
- Una prueba automática por cada criterio, incluido el borde.
- PR revisado por otra persona del equipo.
Una IA que escribe código tiende a ser servicial de más: agrega notificaciones, validaciones, campos «por si acaso». Decirle explícitamente qué queda afuera es la forma más barata de evitarlo, y le sirve al revisor para detectar cuando se pasó.
«Y encima me agregó un administrador»
Con la historia en el chat, la nueva versión ya valida las 2 horas. Pero Valentina nota otra cosa: la IA le dejó un parámetro esAdmin «para que Bienestar pueda cancelar cualquier reserva». Nadie pidió eso. La historia dice quién cancela, pero no dice quién más existe en el sistema, y la IA tuvo que imaginarse a los actores.
¿Cómo evita Valentina que la IA invente actores y pasos?
Una prohibición sin referencia no funciona: «no inventes roles» no le dice cuáles roles sí existen, y para la IA un administrador es perfectamente razonable. Decirle lo que no haga sirve; decirle lo que sí hay sirve mucho más. Probá con otra opción.
Eso traslada una decisión del equipo a un modelo que no conoce a Bienestar ni a los clubes de la UAB. Su lista será larga, genérica y verosímil, y «los que parezcan razonables» termina siendo un juicio sin criterio. Los roles los define el producto, no la IA. Probá con otra opción.
Exacto. Un caso de uso nombra a los actores que existen y fija el camino de cada rama; ya no hay lugar para el administrador inventado. Seguí leyendo ↓
Casos de uso como contexto: quién y qué rama
El diagrama de casos de uso fija el alcance (qué hace el sistema y quién lo usa). Su descripción textual fija el comportamiento: el flujo principal y los alternativos son, casi uno a uno, las ramas del código y las pruebas.
Actores del sistema: Estudiante (responsable de un club) y Bienestar.
Actor de este caso: Estudiante. Bienestar no participa.
Precondición: el estudiante inició sesión.
Flujo principal
1. El estudiante elige una reserva de su club.
2. El sistema verifica que sea del club y que falten 2 horas o más.
3. El estudiante confirma.
4. El sistema marca la reserva como cancelada y libera el espacio.
Flujos alternativos
2a. La reserva es de otro club: se rechaza.
2b. Faltan menos de 2 horas: se rechaza.
2c. La reserva no está confirmada: se rechaza.
Postcondición: el espacio queda libre en ese horario.
| Parte del caso de uso | Dónde termina en el código |
|---|---|
| Actores | Quién llama a la función y qué datos recibe; no hay ningún rol extra. |
| Flujo principal | El camino feliz de la función. |
| Flujos alternativos | Cada if que lanza un error, y una prueba por rama. |
| Postcondición | Lo que la prueba comprueba al final. |
Los nombres que la IA se inventa
Ahora el flujo es correcto, pero los nombres siguen sueltos: la IA escribe reserva.status, reserva.userId y usuario.club porque nadie le dijo cómo se llaman las cosas. En el proyecto, el diagrama de clases (el modelo de dominio) ya lo resolvió: Estudiante, Club, Reserva y Espacio, con sus atributos. Valentina tiene ese diagrama dibujado en el repositorio.
¿Cómo le pasa el diagrama de clases a la IA?
Algunos modelos leen imágenes, pero una letra mal interpretada (horaInicio por hora_inicio) pasa sin que nadie se entere. Y una captura no se versiona ni se compara con el código. Si el contexto debe ser exacto, el texto gana. Probá con otra opción.
Parafrasear reintroduce el problema: «fecha, horas y un estado» no dice que son fecha, horaInicio, horaFin y estado, ni cuál es la relación con Club. La IA volverá a elegir sus propios nombres. Probá con otra opción.
Exacto. El texto conserva cada nombre tal cual, vive en el repositorio junto al código y se puede revisar en un PR. Seguí leyendo ↓
Diagrama de clases como contexto: nombres y estructura
El diagrama de clases le da a la IA el vocabulario del dominio. El modelo de EventoUAB se puede escribir como texto con Mermaid, un lenguaje de diagramas que GitHub y GitLab dibujan solos, y que cualquier IA lee sin ambigüedad.
classDiagram
class Estudiante {
nombre
carnet
correo
}
class Club {
nombre
facultad
}
class Reserva {
fecha
horaInicio
horaFin
estado
}
class Espacio {
nombre
capacidad
tieneProyector
}
Estudiante "1" --> "0..*" Club : lidera
Club "1" --> "0..*" Reserva : solicita
Reserva "0..*" --> "1" Espacio : ocupa
| Qué lee la IA | Qué evita |
|---|---|
| Los nombres de los atributos, tal cual | status, start_time, hora_inicio y otras variantes. |
| Que la reserva la solicita un Club | userId y un «usuario» que no existe en el dominio. |
| Qué atributos NO existen | precio, motivo, penalidad, canceladaPor. |
La multiplicidad (1, 0..*) | Guardar una lista de reservas dentro de Club, o un solo espacio con varias reservas simultáneas. |
El diagrama solo ayuda si la instrucción lo vuelve una frontera: «usá únicamente las clases y atributos de este diagrama; si necesitás otro, preguntá». Sin esa frase, la IA lo trata como una sugerencia.
Cancelar lo que ya está cancelado
Con historia, caso de uso y modelo, la función ya se parece a EventoUAB. Valentina la prueba con una reserva ya cancelada: la IA responde «cancelada con éxito». Con una reserva que ya terminó ayer, también. El atributo estado existe, pero nadie le dijo qué valores puede tomar ni cuáles cambios están permitidos.
¿Cómo cierra Valentina ese hueco?
Es el juego del topo: solo aparecen los casos que Valentina imagina, y el resto queda a merced de la IA. Y los if sueltos no dejan constancia de cuál es la regla completa. Un diagrama escribe todas las reglas de una vez. Probá con otra opción.
«Cómo funcionan las reservas en general» no es «cómo funcionan las de EventoUAB». La IA puede inventar «pendiente de pago» o «reprogramada», estados que el producto no tiene, y el código quedaría coherente consigo mismo pero ajeno al diseño. Probá con otra opción.
Exacto. El diagrama fija los estados válidos, y la regla «lo que no está permitido, se rechaza» convierte cualquier omisión en un error visible. Seguí leyendo ↓
Diagrama de estados como contexto: qué se puede hacer cuándo
Un objeto como la reserva vive una secuencia de estados, y no todos los saltos son válidos. El diagrama de estados es la lista cerrada de esos saltos. Para la IA es contexto que dice «estos son los únicos valores de estado» y «estas son las únicas transiciones».
stateDiagram-v2
[*] --> confirmada : reservar
confirmada --> cancelada : cancelar (2 h o más antes)
confirmada --> finalizada : pasa la horaFin
cancelada --> [*]
finalizada --> [*]
| Desde | Evento | Hacia | ¿Se permite? |
|---|---|---|---|
confirmada | cancelar | cancelada | Sí, con 2 h o más de anticipación. |
confirmada | pasa la horaFin | finalizada | Sí (otra historia). |
cancelada | cancelar | — | No: error. |
finalizada | cancelar | — | No: error. |
Es una lista de permitidos, no de prohibidos: no hace falta enumerar todas las cosas que no se pueden hacer. Cualquier transición ausente del diagrama es un error. Cada fila de la tabla se vuelve una prueba, y la prueba atrapa a la IA si se inventa una transición.
«Asumí que cualquier miembro del club puede cancelar»
Valentina armó el paquete completo y, al final de su pedido, agregó una regla: «si te falta información, no la completes: listá tus supuestos». La IA entrega la función y, al pie, escribe: «Supuesto: asumí que cualquier miembro del club puede cancelar, no solo quien lidera el club». El modelo dice que un Estudiante «lidera» un Club, pero no dice nada de los demás miembros. Es un hueco real, y la IA lo señaló en vez de taparlo.
¿Qué hace Valentina con ese supuesto?
Una regla de negocio no es un detalle de implementación: quién puede cancelar lo decide el producto. «Suena razonable» es exactamente el criterio con el que la IA inventó el administrador. Si el supuesto está mal, el error aparece en producción, no en el chat. Probá con otra opción.
El código queda con una regla que ningún documento respalda. Cuando alguien más (o la misma IA, en otra sesión) retome la historia, va a volver a adivinar, y quizá distinto. La decisión tiene que quedar escrita donde el próximo la va a leer. Probá con otra opción.
Exacto. La decisión la toma quien tiene la autoridad, queda en el artefacto, y recién después se toca el código. El contexto es un documento vivo, no un prompt descartable. Seguí leyendo ↓
Los huecos y el control: lo que la IA no puede decidir por vos
Con el paquete completo, la función que sale ya no inventa nada: cada línea tiene un origen que se puede señalar. Mirá el resultado y fijate de dónde sale cada decisión.
// reservas.js
const HORAS_MINIMAS = 2; // criterio 2 (historia #14)
export function cancelarReserva(reserva, club, ahora) {
if (reserva.club !== club) { // criterio 1; flujo alternativo 2a
throw new Error("Solo el club dueño puede cancelar la reserva");
}
if (reserva.estado !== "confirmada") { // diagrama de estados; flujo 2c
throw new Error("Solo se puede cancelar una reserva confirmada");
}
const inicio = new Date(`${reserva.fecha}T${reserva.horaInicio}`); // atributos del modelo
const horasAntes = (inicio - ahora) / 3600000;
if (horasAntes < HORAS_MINIMAS) { // criterio 2; borde: justo 2 h sí; flujo 2b
throw new Error("Solo se puede cancelar con 2 horas de anticipación");
}
return { ...reserva, estado: "cancelada" }; // transición confirmada → cancelada
}
Y las pruebas salen de las mismas fuentes, una por criterio, por rama y por transición. Se ejecutaron en Node con node --test:
import test from "node:test";
import assert from "node:assert/strict";
import { cancelarReserva } from "./reservas.js";
const reserva = {
club: "Robótica", fecha: "2026-11-10",
horaInicio: "10:00", horaFin: "12:00", estado: "confirmada",
};
const a = (hhmm) => new Date(`2026-11-10T${hhmm}`);
test("el club dueño cancela con 3 horas de anticipación", () => {
assert.equal(cancelarReserva(reserva, "Robótica", a("07:00")).estado, "cancelada");
});
test("otro club no puede cancelar", () => {
assert.throws(() => cancelarReserva(reserva, "Teatro", a("07:00")), /club dueño/);
});
test("no se cancela una reserva ya cancelada", () => {
assert.throws(() => cancelarReserva({ ...reserva, estado: "cancelada" }, "Robótica", a("07:00")), /confirmada/);
});
test("no se cancela una reserva finalizada", () => {
assert.throws(() => cancelarReserva({ ...reserva, estado: "finalizada" }, "Robótica", a("07:00")), /confirmada/);
});
test("borde: justo 2 horas antes sí se puede", () => {
assert.equal(cancelarReserva(reserva, "Robótica", a("08:00")).estado, "cancelada");
});
test("borde: 1 h 59 min antes no se puede", () => {
assert.throws(() => cancelarReserva(reserva, "Robótica", a("08:01")), /2 horas/);
});
Si se cambia < por <= en la comparación de las horas, falla exactamente una prueba: la del borde de 2 horas. Esa prueba existe porque el criterio lo pedía, no porque la IA se acordó de él.
Las reglas para el asistente
El paquete de contexto cierra con unas pocas reglas que convierten los documentos en una frontera. Son las que evitaron que la IA «completara» el hueco de la decisión 6:
| Regla | Por qué |
|---|---|
| Usá solo los nombres de clases, atributos y estados del contexto. | Evita el vocabulario paralelo (status, userId). |
| Si falta información, no la completes: preguntá o listá el supuesto al final. | Convierte un error silencioso en una pregunta visible. |
| No agregues nada de la sección «Fuera de alcance». | Frena a la IA servicial de más. |
| Entregá una prueba por criterio y por transición, incluidos los bordes. | Cada regla del contexto queda comprobable. |
Una plantilla reutilizable: CONTEXTO.md
Todo lo anterior cabe en un solo archivo de texto que vive en el repositorio. Muchos asistentes de código leen automáticamente un archivo de instrucciones de la raíz (como AGENTS.md o CLAUDE.md), y también podés pegar el tuyo al empezar una conversación:
# CONTEXTO — [Producto] · Historia #[N] "[Título]"
## 1. Tarea
Una frase: qué se implementa y en qué archivo.
## 2. Historia y criterios (del backlog)
Copiá la historia, sus criterios de aceptación con los bordes y la DoD.
## 3. Caso de uso
Actores, precondición, flujo principal, flujos alternativos y postcondición.
## 4. Modelo (diagrama de clases, en Mermaid)
Clases, atributos con sus nombres exactos y relaciones con multiplicidad.
## 5. Estados (diagrama de estados, en Mermaid)
Estados válidos y transiciones permitidas.
## 6. Fuera de alcance
Lo que NO se hace en esta historia.
## 7. Convenciones
Lenguaje, librería de pruebas, idioma de los mensajes de error.
## 8. Reglas para el asistente
1. Usá solo los nombres de este documento.
2. Si falta información, preguntá o listá el supuesto al final.
3. No agregues nada de la sección 6.
4. Entregá una prueba por criterio y por transición, con los bordes.
Si cambia una regla y no se actualiza el artefacto, la IA seguirá aplicando la versión vieja con total convicción. Por eso la decisión 6 terminó con un cambio en la historia y no solo en el código: el artefacto se corrige primero, y el código lo sigue.
Armador de paquete de contexto
Tarea: «implementar cancelar reserva». Marcá qué artefactos le das a la IA y mirá cuántas decisiones le dejás adivinar. Abajo se arma el texto que pegarías en el chat. Probá con ninguno, con uno solo, con todos, y buscá cuál combinación es la mínima que cubre todo.
Detectar lo que inventó la IA
Otro intento de la IA, esta vez con la historia #14, el modelo y el diagrama de estados, pero sin la sección «Fuera de alcance». Leelo línea por línea contra los artefactos de esta guía.
export function cancelarReserva(reserva, club, ahora) {
if (reserva.club !== club) throw new Error("Solo el club dueño puede cancelar");
if (reserva.estado === "finalizada") throw new Error("La reserva ya terminó");
const horas = (new Date(`${reserva.fecha}T${reserva.horaInicio}`) - ahora) / 3600000;
if (horas < 2) throw new Error("Faltan menos de 2 horas");
reserva.estado = "cancelada";
reserva.canceladaPor = club;
reserva.penalidad = horas < 24 ? 50 : 0;
notificarBienestar(reserva);
return reserva;
}
¿Esta línea sale del contexto, o la inventó la IA?
if (reserva.club !== club) throw …
reserva.canceladaPor = club
if (horas < 2) throw …
notificarBienestar(reserva)
if (reserva.estado === "finalizada") throw …
reserva.penalidad = horas < 24 ? 50 : 0
reserva.estado = "cancelada"
Las tres invenciones se detectan porque están ahí. Pero este intento también omitió algo: solo rechaza finalizada, así que una reserva ya cancelada se cancela otra vez sin error. Ninguna línea está «mal»; falta una. Por eso la lista de transiciones del diagrama se convierte en pruebas: una omisión solo aparece cuando algo la comprueba.
Actividades de repaso
Un repaso integrador de lo que acabás de recorrer. Cada actividad se corrige al instante; tu progreso se guarda automáticamente en este navegador.
Une cada artefacto con lo que evita que la IA adivine.
¿Qué distingue a la ingeniería de contexto de simplemente escribir un buen prompt?
Mientras más documentos del proyecto le pases a la IA, mejor va a ser su resultado.
La IA devuelve código que usa un atributo reserva.motivo, que no aparece en el diagrama de clases. ¿Qué corresponde hacer?
🎯 Reto Final: el CONTEXTO.md de tu próxima historia
Ahora con tu propio proyecto. Elegí la próxima historia que vayas a programar con ayuda de una IA y escribí su CONTEXTO.md usando la plantilla: la historia con sus criterios, el caso de uso, el modelo y los estados que la tocan, qué queda fuera de alcance y las reglas para el asistente. Si algún artefacto todavía no existe en tu equipo, anotá qué decisiones quedarían sin dueño.
CONTEXTO.md de una historia real de tu proyecto.
- La historia incluye criterios de aceptación con al menos un caso de borde, no solo el camino feliz.
- Los nombres de clases, atributos y estados están copiados del modelo, no parafraseados.
- Los estados listan las transiciones permitidas, y dice que cualquier otra se rechaza con un error.
- Hay una sección «Fuera de alcance» que nombra al menos una cosa que la IA podría querer agregar.
- Las reglas para el asistente piden preguntar o listar supuestos en vez de completar huecos.
- Para cada decisión que hoy no está en ningún artefacto, anotaste quién la toma (la PO, el equipo).
Cheat Sheet
| Término | Idea clave |
|---|---|
| Ingeniería de contexto | Decidir qué información recibe la IA, con qué forma y en qué orden, para que no tenga que suponer. |
| Prompt vs. contexto | El prompt es la instrucción; el contexto es la información que la rodea. |
| Backlog | La historia, sus criterios con bordes y la DoD. Solo la de la tarea, no todo el tablero. |
| Fuera de alcance | Lo que NO se hace. Frena a la IA servicial de más. |
| Caso de uso | Actores y flujos: cada rama es un if y una prueba. |
| Diagrama de clases | Nombres y relaciones exactos, en texto (Mermaid), y la frontera «solo esto». |
| Diagrama de estados | Lista cerrada de transiciones: lo que no figura se rechaza. |
| Hueco | Decisión que ningún artefacto cubre. La IA pregunta o lista el supuesto; lo resuelve quien tiene autoridad. |
| Fuente de verdad | El artefacto manda y el código lo sigue. Se actualiza primero el documento. |
| Trazabilidad | Cada línea del código se puede rastrear hasta un artefacto. Si no se puede, sobra o falta algo. |
| CONTEXTO.md | Un archivo en el repositorio que reúne todo lo anterior para cada historia. |
¿Sabías que...?
🧠 Un nombre nuevo para algo viejo
En 2025, varias personas de la comunidad de desarrollo con IA empezaron a preferir «ingeniería de contexto» a «ingeniería de prompts», porque lo que decide la calidad del resultado no es la frase sino toda la información que rodea la tarea. La idea de fondo es la de siempre: especificar bien antes de programar.
📄 AGENTS.md y CLAUDE.md
Muchos asistentes de código buscan, en la raíz del repositorio, un archivo de instrucciones (los nombres más comunes son AGENTS.md y CLAUDE.md) y lo leen al empezar cada sesión. Es el mismo principio del CONTEXTO.md: el contexto versionado junto al código, revisable en un PR.
🔎 Más contexto no siempre es mejor
Los modelos tienen una ventana de contexto finita, y aun dentro de ese límite, la información irrelevante compite por la atención del modelo. Por eso la regla de oro es «relevante, exacto y verificable», no «todo lo que tengas».