El Contexto en IA:
Lo que un Tester Necesita Antes de Construir con IA

1. El Contexto: la Capa que Nadie Menciona

Hay una variable que decide, más que ninguna otra, si una solución construida con IA sirve o no: el contexto que esa IA tuvo disponible antes de escribir la primera línea. No el modelo, no el Prompt, no el Skill instalado — el contexto. Y es, casi sin excepción, la variable de la que menos se habla.

La conversación pública sobre IA aplicada a Testing gira en otras tres cosas: qué Skill instalar, qué Agente orquestar, qué Prompt escribir para que la IA construya bien. Es contenido útil, pero todo asume que el contexto ya está resuelto, y casi nunca lo está. El tester de hoy cada vez construye más con ayuda de un asistente de IA — Claude Code, Gemini CLI, Cursor, el que corresponda en cada equipo — scripts de automatización, frameworks de testing, dashboards, pipelines. Construir bien con esas herramientas es el escenario donde el problema del contexto se vuelve imposible de ignorar.

Un Prompt impecable, ejecutado por el mejor modelo disponible, con el Skill más pulido, produce una solución técnicamente funcional que puede no tener nada que ver con el proyecto real — si el contexto que recibió no incluye cómo está armado ese proyecto, para qué producto es, o qué ya se probó y se descartó. Ese es el punto central de este artículo: no cómo construir con IA, sino qué contexto necesita existir antes de que valga la pena intentarlo.

2. Sin Contexto, la IA Construye Desconectado del Proyecto Real

Esto se siente apenas empezás a pedirle a un asistente de IA que te construya algo. Le pedís un framework de testing E2E, un script de smoke test post-deploy o un dashboard para tus resultados de performance, y sin contexto adicional obtenés una solución genérica:

El resultado no es "mal código". Es código que funciona en aislamiento y genera fricción real al integrarlo: reescritura, conflictos con lo que ya existe, doble mantenimiento de dos formas distintas de hacer lo mismo.

Esto no se resuelve mejorando la redacción del Prompt. Se resuelve dándole al asistente la información que un tester senior ya tiene en la cabeza antes de tocar el teclado: qué stack se usa, qué ya existe, y qué ya se descartó.

3. Framework: Los 5 Tipos de Contexto Antes de Construir

Cuando un tester senior arma una solución a mano, no parte de un Prompt en blanco. Cruza, casi sin pensarlo, cinco fuentes de información distintas antes de escribir una línea. Hacer ese cruce explícito es lo que hay que replicar para que un asistente de IA construya algo usable.

Ninguna de las cinco capas reemplaza a las otras. El contexto de tarea sin contexto de proyecto genera una solución que cumple el objetivo pero no encaja con el stack real. El contexto de proyecto sin contexto de enfoque genera código técnicamente prolijo que se construyó como framework reutilizable cuando lo que hacía falta era un script descartable de una tarde. Las cinco juntas son las que producen algo que un equipo puede integrar sin reescribirlo desde cero.

4. El Contexto que Cambia el Resultado

El pedido: "Necesito que armes un framework de testing E2E para el checkout." Mismo Prompt en ambos casos, al mismo asistente de IA. Lo único que cambia es el contexto disponible antes de escribirlo.

> Necesito que armes un framework de testing E2E para el checkout.

Instalando dependencias por default...
- selenium-webdriver
- pytest + Page Object Model genérico

tests/
├── test_checkout.py
├── pages/
│   └── checkout_page.py
└── conftest.py

Funciona en aislamiento, pero el repo real usa Playwright + TypeScript desde hace un año, ya tiene helpers/auth.ts para login y fixtures/test-data.ts para datos de prueba, y el equipo descartó un flujo único de checkout el sprint pasado porque no cubría el caso de usuario invitado. Nada de eso llegó al asistente — así que nada de eso está en el resultado. Lo que se construyó no se puede mergear tal cual: hay que reescribirlo en el stack correcto y volver a resolver un problema que el equipo ya había resuelto.

[contexto de proyecto] El repo ya usa Playwright + TypeScript.
Los E2E viven en e2e/ y comparten helpers/auth.ts (login) y
fixtures/test-data.ts (datos de prueba).
[contexto de producto] El checkout tiene dos flujos distintos:
invitado y usuario logueado — se descartó un flujo único en el
sprint pasado porque no cubría el caso invitado.
[contexto de enfoque] Esto es un framework reutilizable para
todo el equipo, no un script puntual — tiene que integrarse al
pipeline de CI que ya corre en cada PR.

> Necesito que armes un framework de testing E2E para el checkout.

Usando Playwright + TypeScript (ya establecido en el repo)
Reutilizando helpers/auth.ts y fixtures/test-data.ts

e2e/
├── checkout/
│   ├── checkout-guest.spec.ts
│   ├── checkout-logged-in.spec.ts
│   └── checkout.page.ts
└── (agregado a .github/workflows/e2e.yml existente)

La segunda solución no es "mejor código" en abstracto — es código que un compañero de equipo puede revisar y aprobar sin preguntar "¿por qué esto no usa lo que ya tenemos?". El Prompt fue idéntico en ambos casos. Lo que cambió el resultado fue que la IA supo, antes de escribir una línea, con qué proyecto real estaba trabajando.

5. Cómo Construir el Contexto Antes de Construir con IA

Inyectar contexto "a mano" cada vez que le pedís algo a la IA no escala — y si depende de que copies y pegues el ticket, la estructura del repo y las decisiones previas cada sesión, en la práctica no va a pasar. El contexto tiene que quedar armado como infraestructura del proyecto, no como esfuerzo manual repetido. Esto no depende de qué asistente uses: Claude Code, Gemini CLI o cualquier otro leen el mismo tipo de contexto si se lo das en el formato que cada uno espera.

El propio equipo de ingeniería de Anthropic llega a la misma conclusión desde el lado del modelo: en "Effective context engineering for AI agents" describen el contexto como "un recurso finito con retornos marginales decrecientes" y recomiendan cargar contexto de proyecto persistente por adelantado, complementado con recuperación "just in time" del resto. Es la misma arquitectura de las cuatro piezas de abajo, descrita desde adentro de Claude Code en vez de desde el flujo de trabajo del tester.

Ninguna de estas piezas es exótica. Lo que cambia es el orden de prioridades: antes de invertir tiempo en afinar el Prompt perfecto o en elegir el Agente ideal, hay que asegurar que exista la infraestructura de contexto que ambos van a necesitar para construir algo que encaje, no algo que haya que reescribir.

6. Conclusión: Contexto Primero, Construcción Después

El tester que empieza a construir con IA suele invertir el orden natural: primero prueba Prompts, después Skills, después Agentes, y recién cuando algo no encaja con el proyecto se pregunta por qué. Conviene invertir ese orden. Antes de pedirle a la IA que construya cualquier cosa — un framework, un script, un dashboard — vale la pena asegurarse de que tiene contexto de tarea, de producto, de proyecto, de enfoque y documental disponible.

Skills, Agentes y Prompts siguen siendo necesarios — son la capa de ejecución. Pero ejecutan sobre lo que reciben. Si lo que reciben es un pedido aislado sin saber con qué stack conviven, qué ya se probó y para qué producto es, el resultado va a compilar y va a estar desconectado. Eso es exactamente lo que separa una demo impresionante de una solución que un equipo puede integrar en producción.

Gartner lo resumió así en julio de 2025: "context engineering is in, and prompt engineering is out."

Antes de pedirle a la IA que te construya la próxima solución, la pregunta no es qué Prompt escribir — es qué contexto real le vas a dar para que construya algo que tu equipo pueda usar tal cual.