Saltar a contenido

Estrategia de Context Window para LLMs

Proposito

Como gestionar el contexto que le das a un LLM para obtener los mejores resultados. El context window es limitado: lo que incluyes (y lo que excluyes) determina la calidad del output.

Cuando usarlo

  • Cuando trabajas en proyectos con muchos archivos y la IA no "entiende" tu codebase.
  • Cuando los resultados de la IA son genericos en vez de especificos a tu proyecto.

1. El Problema del Contexto

Los LLMs tienen un context window limitado (entre 100K y 200K tokens segun el modelo). Tu proyecto puede tener miles de archivos. No puedes meter todo.

La pregunta clave: Que incluir para que la IA genere codigo que se integre bien en tu proyecto?

2. La Jerarquia de Contexto

Ordena la informacion de mayor a menor importancia:

Nivel 1: Contexto Critico (siempre incluir)

  • La spec de la feature que estas implementando.
  • Las reglas de negocio relevantes.
  • La interfaz/contrato que el codigo debe cumplir (API contract, types).

Nivel 2: Contexto del Proyecto (incluir cuando sea relevante)

  • Convenciones del proyecto: CLAUDE.md, .eslintrc, patrones establecidos.
  • Archivos adyacentes: Servicios, modelos, o controllers que se relacionan con lo que estas generando.
  • Domain model: Entidades, value objects, y sus invariantes.

Nivel 3: Contexto de Referencia (incluir solo si es necesario)

  • Ejemplos existentes: "Este servicio sigue el mismo patron que BookingService" + codigo de BookingService.
  • Tests existentes: Para que la IA siga el patron de testing del proyecto.
  • Schema de BD: Solo las tablas relevantes.

Nivel 4: Contexto General (rara vez incluir)

  • Documentacion de librarias (la IA ya la conoce).
  • Archivos de configuracion genericos.
  • Historial de commits.

3. Estrategias Practicas

Estrategia 1: El Archivo de Contexto (CLAUDE.md)

Mantene un archivo en la raiz del proyecto con:

# Contexto del Proyecto

## Stack
- Backend: NestJS + TypeORM + PostgreSQL
- Frontend: React + TypeScript + Vite
- Testing: Jest + Supertest

## Convenciones
- Servicios de dominio en src/domain/services/
- Repositorios en src/infrastructure/repositories/
- Controllers en src/api/controllers/
- Tests al lado del archivo: archivo.spec.ts
- Naming: camelCase para variables, PascalCase para clases
- No usar `any` en TypeScript
- Errores con codigos: throw new AppError('BOOKING_NOT_FOUND', 404)

## Patrones
- Repository Pattern para acceso a datos
- Domain Services para logica de negocio
- DTOs para validacion de entrada (class-validator)

Estrategia 2: Prompt Modular

En vez de un prompt gigante, divide en pasos:

Paso 1: "Aqui esta la spec de la feature" -> IA entiende el QUE
Paso 2: "Aqui estan las convenciones del proyecto" -> IA entiende el COMO
Paso 3: "Genera el domain service" -> IA genera con contexto
Paso 4: "Aqui esta el controller existente como ejemplo, genera el nuevo" -> IA replica patron

Estrategia 3: El "Contexto Minimo Viable"

Para cada tarea, preguntate: cual es el minimo contexto que la IA necesita?

Tarea Contexto Minimo
Implementar un endpoint API contract + servicio existente como ejemplo
Escribir unit tests La clase a testear + un test existente como patron
Debugging El codigo con bug + el error + el comportamiento esperado
Refactoring El codigo actual + el patron objetivo
Generar migracion de BD El domain model + schema actual

Estrategia 4: IDE como Herramienta de Contexto

Si usas un IDE con IA integrada (Cursor, Claude Code, etc.):

  1. Abre los archivos relevantes antes de hacer el prompt. El IDE incluye los archivos abiertos como contexto.
  2. Usa @mentions para referenciar archivos especificos.
  3. Usa el proyecto completo cuando el IDE lo soporte (indexacion de codebase).

4. Errores Comunes

Error 1: Demasiado contexto

Meter 10 archivos "por si acaso" diluye la informacion relevante. La IA pierde foco.

Fix: Incluye solo lo directamente relevante a la tarea actual.

Error 2: Contexto obsoleto

Pegar una version vieja de un archivo que ya cambio.

Fix: Siempre lee el archivo fresco antes de incluirlo en el prompt.

Error 3: Sin contexto de convenciones

La IA genera codigo correcto pero con un estilo completamente diferente al del proyecto.

Fix: Incluye un ejemplo existente del patron que quieres que siga.

Error 4: Incluir secretos

Pegar archivos .env, credentials, o API keys en el prompt.

Fix: Sanitiza el contexto antes de enviarlo. Reemplaza valores reales con placeholders.

5. Ejemplo Completo: Contexto para Generar el CancellationService

[CONTEXTO DEL PROYECTO]
Stack: NestJS + TypeORM + PostgreSQL
Patron: Domain services con inyeccion de dependencias.
Los servicios de dominio estan en src/domain/services/.

[SPEC RELEVANTE]
Feature: Cancelacion de Turno
Reglas de negocio:
- RN-05: Cancelacion < 24h = penalizacion
- RN-06: 3 penalizaciones = bloqueo 30 dias

[API CONTRACT]
PATCH /api/v1/bookings/:id/cancel
Body: { reason?: string }
Responses: 200 (OK), 400 (BOOKING_NOT_CANCELLABLE), 403 (FORBIDDEN)

[EJEMPLO DE SERVICIO EXISTENTE - BookingCreationService]
@Injectable()
export class BookingCreationService {
  constructor(
    private readonly bookingRepo: BookingRepository,
    private readonly availabilityService: AvailabilityCalculator,
  ) {}

  async create(dto: CreateBookingDto, patientId: string): Promise<Booking> {
    // ... implementacion existente
  }
}

[MODELO DE DOMINIO]
Booking: id, patientId, doctorId, status (CONFIRMED|CANCELLED|COMPLETED|NO_SHOW)
BookingStatus transiciones: CONFIRMED -> CANCELLED

[LO QUE NECESITO]
Genera BookingCancellationService siguiendo el patron de BookingCreationService.
Incluye unit tests.

Checklist de Completitud

  • Jerarquia de contexto definida (4 niveles)
  • Estrategias practicas con ejemplos
  • Errores comunes documentados
  • Ejemplo completo de contexto
  • Revisada por otro ingeniero

Archivos relacionados