Empecemos por el principio.

Era jueves cualquiera. Tenía un DataFrame de pandas con datos de ventas que necesitaba analizar para el lunes. Abrí Claude, pegué las primeras filas del DataFrame, y escribí lo que pensé que era el prompt adecuado:

"Eres un experto analista de datos con 10 años de experiencia. Analiza estos datos de ventas y dame insights accionables. Usa visualizaciones cuando sea apropiado."

¿El resultado? Un análisis genérico. "Podrías agrupar por categoría", "Considera hacer un gráfico de líneas", "Revisa valores nulos". Nada malo, pero nada útil.

Una hora y 8 iteraciones del prompt después, seguía en el mismo sitio.

Entonces hice algo diferente. Dejé de intentar escribir el prompt perfecto y empecé una conversación de verdad:

"Mira, tengo datos de ventas de una tienda online. Las ventas cayeron un 20% el último mes y no sé por qué. Ya revisé las métricas básicas y todo parece normal. El equipo de marketing lanzó una campaña hace 6 semanas. Aquí está el CSV con los últimos 3 meses. Las columnas son: fecha, producto_id, categoria, precio, cantidad, cliente_id. ¿Qué debería mirar?"

Primera respuesta: útil.

Tercera iteración: problema encontrado.

No cambié el prompt. Cambié el contexto.

La diferencia fundamental: Tokens vs Significado

Aquí está lo que tardé tiempo en entender.

Los Large Language Models (LLMs) como GPT o Claude procesan información en ventanas de contexto. Para Claude, esa ventana es de ~200K tokens. Para GPT-4, son 128K tokens. Esos tokens son tu espacio de trabajo.

Durante años, el enfoque del Prompt Engineering fue: "¿Cómo optimizo las instrucciones para usar menos tokens y obtener mejores resultados?"

Es la pregunta equivocada.

La pregunta correcta es: "¿Cómo uso esa ventana de contexto para dar información RELEVANTE que permita al modelo entender realmente mi problema?"

Prompt Engineering trata la interacción como una función: output = f(prompt). Das instrucciones optimizadas, obtienes un resultado.

Context Engineering trata la interacción como una sesión colaborativa: output = f(contexto_acumulado, historial, restricciones, ejemplos). Construyes un estado compartido.

La diferencia técnica es brutal:

# Enfoque Prompt Engineering
prompt = "Optimiza este código Python de pandas"
resultado = llm.complete(prompt)

# Enfoque Context Engineering
contexto = {
    "código": script_completo,
    "entorno": {"python": "3.9", "pandas": "1.5.3", "ram": "8GB"},
    "problema": "tarda 45s con 500k filas",
    "intentos_previos": ["usar itertuples", "cache con lru_cache"],
    "restricciones": ["no puedo instalar dask"]
}
resultado = llm.complete(contexto)

Uno da instrucciones. El otro da estado.

Por qué esto importa: Modelos de lenguaje son modelos de estado

Aquí está el concepto clave que cambia todo: los LLMs modernos con ventanas de contexto largas son fundamentalmente diferentes a los primeros modelos.

GPT-3 tenía 4K tokens de contexto. La estrategia óptima era prompt engineering: comprimir la máxima información en el mínimo espacio posible.

Claude 3 tiene 200K tokens. GPT-4 Turbo tiene 128K. Gemini 1.5 Pro tiene 1M de tokens.

No estás limitado por espacio. Estás limitado por claridad.

Los modelos actuales pueden mantener "en mente" el equivalente a ~150 páginas de texto. El problema ya no es "¿cómo comprimo mis instrucciones?" sino "¿cómo estructuro la información para que el modelo entienda el problema como yo lo entiendo?"

Esto tiene implicaciones técnicas directas:

  1. Retrieval vs Context Window: Con ventanas pequeñas, necesitabas RAG (Retrieval Augmented Generation) para todo. Con ventanas grandes, puedes meter contexto directamente. RAG sigue siendo útil para datasets masivos, pero para desarrollo día a día, el contexto directo funciona mejor.

  2. Few-shot Learning: Los prompts con 3-5 ejemplos funcionaban porque era lo máximo que cabía. Ahora puedes dar 20-30 ejemplos si es necesario. La pregunta ya no es "¿cuántos ejemplos caben?" sino "¿cuántos ejemplos necesito para comunicar el patrón?"

  3. Stateful vs Stateless: El prompt engineering clásico era stateless por necesidad. Cada query era independiente. Con context engineering, puedes mantener estado entre interacciones, construyendo iterativamente sobre conversaciones anteriores.

Los tres pilares técnicos del Context Engineering

Después de trabajar así durante meses, identifiqué tres elementos técnicos que lo hacen funcionar:

1. Contexto estructurado sobre instrucciones planas

La diferencia entre dar instrucciones y dar estado.

Ejemplo real:

Tenía un script de pandas que tardaba demasiado. El enfoque tradicional de prompt engineering:

"Optimiza este código de pandas. Debe ser más rápido."

El enfoque de context engineering:

# ESTADO DEL SISTEMA
Versión: Python 3.9, pandas 1.5.3
Datos: 500K filas, 20 columnas, CSV de 1.2GB

# CÓDIGO ACTUAL
df = pd.read_csv('datos.csv')
df = df.drop_duplicates()
df['nueva_col'] = df.apply(lambda row: row['col_a'] * row['col_b'], axis=1)
resultado = df.groupby('categoria')['nueva_col'].sum()

# PROBLEMA
Tarda 45 segundos. El cuello de botella parece estar en el .apply()

# YA INTENTÉ
- usar itertuples(): sin mejora
- chunking al leer CSV: sin cambio significativo

# RESTRICCIÓN
Solo puedo usar pandas/numpy standard. No dask, no modin.

Con esta estructura, la primera respuesta fue: "El .apply() es el problema. Usa vectorización: df['nueva_col'] = df['col_a'] * df['col_b']. Bajó a 3 segundos."

El contexto estructurado permitió al modelo:

  • Descartar soluciones que ya intenté

  • Respetar mis restricciones técnicas

  • Identificar el problema real (apply vs vectorización)

  • Dar una solución directamente aplicable

2. Iteración con memoria: la conversación como estado acumulado

Los LLMs no tienen memoria real entre sesiones. Pero dentro de una sesión, cada mensaje añade al contexto disponible.

La clave técnica es que cada interacción en una conversación tiene acceso a TODO el historial previo (hasta el límite de tokens). Esto significa que el modelo "recuerda" no solo lo que dijiste, sino también:

  • Sus respuestas previas

  • Lo que funcionó o no funcionó

  • Las aclaraciones que diste

  • Los ejemplos que compartiste

Esto permite un patrón de trabajo fundamentalmente diferente:

Conversación 1: "Tengo datos de ventas. ¿Cómo los analizo?" [Respuesta genérica sobre EDA]

Conversación 2 (con contexto acumulado): "Las ventas de electrónica cayeron. ¿Por qué?" [Respuesta específica usando conocimiento de conversación 1]

Conversación 3: "Crea una visualización de esto" [Visualización que usa los insights de conversaciones 1 y 2]

Conversación 4: "Convierte esto en un script que corra automáticamente" [Script completo con todo el contexto previo]

Cada paso es incremental. El contexto se acumula. Para la interacción 4, el modelo tiene el equivalente a 4 páginas de contexto específico a tu problema.

3. Artifacts y código como contexto persistente

Aquí es donde la teoría se vuelve práctica de verdad.

En Claude (y algunos otros LLMs), existen "artifacts": código, análisis, o documentos que persisten en la conversación y pueden ser modificados iterativamente.

Técnicamente, esto significa:

  • El código no es solo output, es parte del contexto

  • Puedes hacer cambios incrementales sin reescribir todo

  • El modelo mantiene la estructura completa del código en su contexto

Flujo de trabajo real:

# Iteración 1 - Script básico
import pandas as pd
df = pd.read_csv('datos.csv')
print(df.describe())

"Añade limpieza de duplicados y nulos"

# Iteración 2 - Con limpieza
import pandas as pd
df = pd.read_csv('datos.csv')
df = df.drop_duplicates()
df = df.fillna(method='ffill')
print(df.describe())

"Añade visualización de ventas por mes"

# Iteración 3 - Con visualización
import pandas as pd
import matplotlib.pyplot as plt

df = pd.read_csv('datos.csv')
df = df.drop_duplicates()
df = df.fillna(method='ffill')
df['fecha'] = pd.to_datetime(df['fecha'])

ventas_mes = df.groupby(df['fecha'].dt.to_period('M'))['ventas'].sum()
ventas_mes.plot(kind='bar')
plt.savefig('ventas_mensuales.png')

Cada iteración PRESERVA el contexto anterior. No estás empezando de cero. Estás refinando.

Esto es exponencialmente más eficiente que prompt engineering, donde cada cambio requiere re-explicar todo el contexto.

Los errores técnicos que matan el contexto

Error #1: Contexto sin estructura

Pegar 500 líneas de código sin explicación es tan malo como no dar contexto.

Los LLMs procesan información secuencialmente. Si todo tu contexto es un blob sin estructura, el modelo tiene que "adivinar" qué es importante.

Mal:

[Pegar todo el código]
[Pegar todo el traceback]
Arréglalo

Bien:

PROBLEMA: KeyError en línea 45
CÓDIGO RELEVANTE: [Solo la función que falla]
ERROR: [Traceback específico]
CONTEXTO: Esta función procesa datos de usuario. Falla cuando...

Error #2: Omitir restricciones técnicas

El mes pasado pedí ayuda para optimizar un script. La respuesta sugería usar dask, joblib, y crear índices en PostgreSQL.

Problema: estaba trabajando en un Jupyter notebook corporativo. No podía instalar nada. No tenía PostgreSQL.

Las restricciones técnicas NO son limitaciones a disculparse por. Son parte esencial del contexto.

Si no las compartes, el modelo te dará la mejor solución en un mundo ideal. Tú vives en el mundo real.

Error #3: Contexto genérico sobre especificidad

"Tengo un problema con pandas" vs "El método .apply() con lambda tarda 45s en 500k filas"

La especificidad permite al modelo acceder a conocimiento técnico preciso. Los LLMs están entrenados con millones de ejemplos de código. Cuando eres específico, pueden matchear tu problema con patrones conocidos.

Genérico = respuesta genérica. Específico = respuesta específica.

La implementación práctica

Aquí está cómo implementar esto en tu flujo de trabajo diario:

Ejemplo para análisis de datos:

CONTEXTO BASE (preparar una vez):
- Dataset: [descripción de columnas y tipos]
- Objetivo de negocio: [qué decisión se necesita tomar]
- Restricciones: [pandas, matplotlib, Jupyter]
- Output esperado: [notebook + PNGs para presentación]

CADA ANÁLISIS NUEVO:
- Datos actuales: [CSV o primeras filas]
- Pregunta específica: [qué necesitas saber]
- Build iterativamente desde ahí

Ejemplo para desarrollo:

CONTEXTO BASE:
- Stack: Python 3.x, librerías disponibles
- Arquitectura: [cómo encaja este código]
- Restricciones: [lo que no puedes cambiar]

CADA PROBLEMA:
- Código relevante: [no todo, solo lo necesario]
- Error específico: [no "no funciona", sino qué pasa]
- Lo que intentaste: [para no repetir]

La primera vez toma 15-20 minutos. Las siguientes veces, 2-3 minutos.

De instrucciones a colaboración

Después de unos cuantos meses trabajando así, mi forma de usar IA cambió por completo.

Ya no pienso en "¿cómo escribo el prompt perfecto?" Pienso en "¿qué información necesita mi “colaborador” para resolver esto?"

No es semántica. Es un cambio fundamental en cómo aprovechas la capacidad de los LLMs modernos.

Los modelos actuales tienen la capacidad técnica de mantener conversaciones largas, procesar contexto complejo, y construir soluciones iterativamente. El prompt engineering los trata como calculadoras sofisticadas. El context engineering los trata como colaboradores técnicos.

La diferencia práctica:

Prompt Engineering: 10 intentos de 5 minutos = 50 minutos, resultado aceptable

Context Engineering: 10 minutos de setup + 3 iteraciones de 5 minutos = 25 minutos, resultado preciso

Y la próxima vez que hagas algo similar: 2 minutos.

Tu próximo paso

Esta semana, toma UN problema recurrente. Puede ser análisis de datos, debugging, o cualquier código que tengas entre manos.

No escribas un prompt. Prepara contexto:

  • ¿Cuál es el problema REAL?

  • ¿Qué restricciones técnicas tienes?

  • ¿Qué has intentado?

  • ¿Qué output necesitas?

Comparte TODO eso. Después, construye iterativamente.

La primera respuesta será 10x mejor que con tu mejor prompt.

Y cuando funcione, guarda ese contexto. Porque la próxima vez vas a empezar desde ahí.

Recursos de interés

Fundamentos de LLMs y contexto:

Para desarrollo y datos:

Herramientas y frameworks:

PD: ¿Cómo trabajas tú con IA? ¿Sigues optimizando prompts o ya diste el salto al context engineering? Me interesa saber qué está funcionando en el mundo real del desarrollo y análisis de datos.

PPS: Si esto cambió cómo piensas sobre trabajar con IA, compártelo. Todos seguimos aprendiendo cómo usar estas herramientas de forma más efectiva.

Keep Reading

View more
caret-right
© 2026 Cerebro y Código.
beehiivPowered by beehiiv