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:

• Elige un stack por default (por ejemplo Selenium + Python) aunque tu equipo ya estandarizó Playwright + TypeScript
• Arma una estructura de carpetas de tutorial, que no respeta la organización real del repo
• Reimplementa utilidades — helpers de login, fixtures de datos, clientes de API — que ya existen en el proyecto, porque no sabía que existían
• No se integra con el pipeline de CI/CD real, porque nunca vio cómo corre hoy
• Ignora que ese mismo tipo de solución ya se intentó antes y se descartó por una razón concreta

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.

• Contexto de proyecto persistente: un archivo de contexto en la raíz del repo (CLAUDE.md, GEMINI.md, .cursorrules o el equivalente de tu asistente) con stack, estructura de carpetas y utilidades ya existentes, para que la IA no reinvente lo que tu equipo ya armó.
• Contexto operacional en vivo: servidores MCP conectados a Jira, Confluence o GitHub permiten que el agente lea el ticket y la documentación real, en vez de que se los resumas vos mismo. Ver MCPs para QA para la guía de conexión.
• Contexto histórico indexado: un vault de conocimiento (decisiones de arquitectura de testing, soluciones ya probadas y descartadas, postmortems) consultable por el agente, no solo archivado. Es exactamente el sistema descrito en Segundo Cerebro para QE — ese artículo es el "cómo" de la capa de contexto de producto y contexto documental de este framework.
• Contexto de enfoque explícito: esto no se automatiza — es criterio humano. Decirle a la IA si lo que va a construir es un script descartable de una tarde o una pieza que va a vivir en el repo a largo plazo es una línea que cuesta segundos y cambia por completo qué tan sólido se construye.

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.

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.