Conservo varios prompts desde hace más tiempo del que me gustaría admitir. Al principio funcionaban bien y, cada vez que algo fallaba, les añadía otra frase. Si una respuesta se desviaba, aparecía un «piensa paso a paso». Si el formato variaba, incorporaba un ejemplo más largo. Cada párrafo parecía una pequeña póliza de seguro.
Con el tiempo, aquel seguro empezó a estorbar. Las respuestas no eran necesariamente peores, pero sí más largas y ceremoniosas. Un cambio menor comenzaba con un plan innecesario. El modelo repetía información que sus herramientas podían consultar por sí mismas. La decisión que yo necesitaba quedaba enterrada bajo instrucciones escritas para otra generación de modelos.
Mi primera reacción fue culpar al modelo. Abrí una conversación nueva, describí el mismo encargo en cuatro frases y obtuve algo más fácil de revisar. Ahí entendí el problema: el prompt no fallaba por viejo, sino porque seguía asumiendo trabajos que ya se hacían en otro lugar.
Pensé que el modelo había empeorado
El caso era bastante corriente: leer el registro de una incidencia, ordenar las causas probables y dejar preparado el siguiente comando de diagnóstico. El prompt que utilizaba superaba las cuarenta líneas. Asignaba un rol, obligaba a seguir una secuencia de razonamiento, fijaba el formato e incluía ejemplos de herramientas que el agente ya podía utilizar.
La respuesta parecía minuciosa, pero costaba comprobarla. Hechos observados y conjeturas convivían en el mismo bloque; además, el modelo proponía acciones que no había ejecutado. Mantuve el mismo registro y dejé solo el objetivo, qué podía afirmarse con los datos disponibles y el criterio de finalización. El segundo resultado incluyó menos hipótesis y mejores comandos. Lo importante no era que sonara más limpio: el operador podía decidir antes qué hacer.
Una comparación aislada no basta. Repetí la prueba con revisión documental, diagnóstico de errores y comprobación de hojas de cálculo. Solo retiré las reglas que añadían tiempo de revisión de forma constante sin mejorar el trabajo entregado.
Un prompt «viejo» suele ser un prompt con funciones solapadas
Ahora reviso los prompts por responsabilidad, no frase por frase.
El Prompt define el propósito y los límites. El Contexto aporta el material de ese encargo. El Harness ejecuta y verifica lo repetible. Cuando un solo documento intenta asumir las tres funciones, también resulta más difícil averiguar por qué ha fallado.
El Prompt contiene el objetivo, las restricciones, qué pruebas son válidas y el criterio de finalización. El Contexto reúne el material vivo: archivos, normas del proyecto y pruebas disponibles. El harness —el entorno de ejecución del agente— se ocupa de la planificación, las llamadas a herramientas, las pruebas, los reintentos y los puntos en los que debe intervenir una persona.
Muchos prompts escritos para los primeros asistentes mezclan las tres capas. Cuando algo sale mal, todo parece un problema de redacción. A veces el error está en un documento desactualizado o en una prueba que nunca llegó a ejecutarse. Separar las capas permite buscar la avería en un sitio concreto.
Las primeras frases que eliminé
Empecé por los roles que no cambiaban ninguna conducta. «Actúa como un experto sénior» dice poco si no concreta qué riesgo hay que proteger, qué evidencia vale y cuándo debe detenerse el trabajo. Prefiero explicar qué no puede ponerse en peligro y en qué momento la decisión vuelve a una persona.
También quité las peticiones de narrar todo el razonamiento interno. No necesito una retransmisión del proceso mental. Necesito afirmaciones vinculadas a un log, un documento fuente o una prueba, y que la incertidumbre aparezca señalada.
Después eliminé los tutoriales de herramientas repetidos cuando el propio sistema ya aportaba su definición y su esquema. Mantengo un ejemplo solo si limita una conducta que de otro modo cambia demasiado.
Las fechas escritas a mano fueron otra retirada sencilla. «Hoy es agosto de 2025» se convierte en deuda en cuanto alguien copia el prompt. Para una investigación sensible al tiempo, inyecto la fecha actual y registro las fechas de publicación y revisión de las fuentes.
Por último recorté procedimientos y esquemas que estaban ahí para transmitir una falsa sensación de control. Conservo un formato fijo si otra aplicación debe procesarlo. Mantengo una ruta obligatoria si existe una exigencia normativa. En los demás casos dejo que el agente elija el camino y evalúo el resultado entregado.
Hay instrucciones que no se deben borrar
Ni siquiera un modelo mejor conoce las condiciones internas de cada operación:
- cuánto cuesta enviar una respuesta incorrecta a un cliente
- qué acciones se pueden ejecutar automáticamente y cuáles necesitan aprobación
- qué métrica define el éxito y qué condición detiene el proceso
- qué reglas contractuales o internas no deben inferirse
- qué formato necesita el siguiente sistema que recibirá el resultado
No son trucos de prompting, sino conocimiento operativo. Revisar un prompt antiguo debería hacer ese conocimiento más visible, no eliminarlo por perseguir brevedad.
Parte del trabajo del prompt ha pasado a las herramientas
El artículo de OpenAI sobre Harness Engineering cuestiona que AGENTS.md termine convertido en un manual de mil páginas. Propone un mapa breve hacia el material pertinente y que las pruebas y herramientas hagan cumplir las reglas que un párrafo no puede garantizar.
Fuente: OpenAI, Harness engineering: leveraging Codex in an agent-first world, 11 de febrero de 2026. El texto trata las guías concisas, la divulgación progresiva y las restricciones aplicadas por el entorno.
No es solo una cuestión de ordenar la documentación. «Ejecuta las pruebas», «corrige los fallos» o «no importes esta dependencia» son ruegos débiles si viven únicamente en prosa. Un harness puede ejecutar la comprobación y detener el trabajo. El prompt solicita; el harness hace cumplir.
Mi regla es sencilla: si una persona repite la misma comprobación en varias ejecuciones, compruebo si debería convertirse en un test, un script, un límite de permisos o una lista de control. Cuando la respuesta es sí, retiro esa petición repetida del prompt.
También dejé de asumir que más contexto siempre es mejor
Cargar todas las políticas, actas y conversaciones anteriores parece prudente. También puede diluir el encargo actual. Anthropic presenta el contexto como un recurso finito y utiliza la expresión context rot: al crecer el contexto, puede disminuir el valor que el modelo obtiene de cada token adicional.
Fuente: Anthropic, Effective context engineering for AI agents, 29 de septiembre de 2025. El artículo plantea las instrucciones del sistema, las herramientas, los datos externos y el historial como un problema de gestión del contexto.
Separé el contexto permanente del material recuperable. El archivo permanente conserva el objetivo del proyecto, las reglas innegociables y los enlaces a las pruebas. Las políticas detalladas, las retrospectivas y las notas de herramientas viven en archivos separados y se cargan solo para los trabajos que las necesitan. No se pierde información; se vuelve localizable.
Un prompt, antes y después
La versión antigua decía:
Eres un experto sénior con diez años de experiencia. Piensa paso a paso y explica cada etapa de tu razonamiento. Redacta primero un plan, espera la aprobación y después comienza el trabajo.
Suena responsable, pero no menciona el trabajo. No identifica la entrada, la regla de evidencia ni el punto de llegada. La sustituí por esta:
Revisa el registro de la incidencia adjunto y ordena las causas más probables, aportando una evidencia para cada una. No afirmes una causa que los logs no permitan sostener. El encargo termina cuando el operador dispone del siguiente comando de diagnóstico listo para ejecutar.
La segunda versión no prescribe una manera de pensar. Nombra el material, el límite de lo que puede afirmarse y el estado que cuenta como terminado. Si hace falta planificar, el agente planificará. Si la aprobación es obligatoria, el harness se detendrá en ese punto.
Cómo reviso un prompt cuando cambia el modelo
No reescribo toda la biblioteca cada vez que aparece un modelo. Elijo tres trabajos representativos y comparo el prompt actual con una versión más corta bajo las mismas condiciones. Después compruebo:
- ¿Mejoró el resultado que recibe el usuario?
- ¿Disminuyeron las afirmaciones sin respaldo?
- ¿Se redujo el tiempo de revisión humana?
- ¿Hubo menos peticiones de corrección?
- ¿Puedo localizar el fallo en Prompt, Contexto o Harness?
Combino entradas sencillas y problemáticas. En revisión documental utilizo documentos de distinta longitud. En una comprobación de datos incluyo valores ausentes y formatos rotos. Si retirar una regla perjudica una clase de trabajo, la recupero con una condición más estrecha. Las eliminaciones también necesitan control de versiones.
Qué significa retirar un prompt antiguo
No todas las instrucciones escritas hace un año están mal. Una promesa hecha al cliente o una condición estricta de parada puede seguir siendo la línea más valiosa del archivo. Lo que ya no tiene sentido es obligar al prompt a cargar con capacidades que el modelo aporta, controles que una herramienta aplica mejor y documentación que se puede consultar cuando sea necesaria.
Dejo visibles cuatro cosas: el resultado esperado, los límites que no se pueden cruzar, qué pruebas son válidas y el criterio de finalización. El material se carga para cada encargo. El harness ejecuta aquello que puede repetirse.
La mejora más importante no fue un tono más agradable. Fue poder distinguir, después de un fallo, si debía corregir el encargo, cambiar el material o añadir una comprobación al entorno. Esa claridad me ha resultado más útil que cualquier fórmula nueva de prompting.
