English

Termina cada prompt con una sección de "NO hagas"

La parte más poderosa de tu prompt es la parte que dice que no. Pediste un endpoint; el agente, "para ayudar", refactorizó otros tres, cambió una dependencia y tocó el esquema. Nada de lo que escribiste estaba mal — simplemente nunca trazaste el límite. Una sección Do-Not de tres líneas al final del prompt es el arreglo más barato del prompt engineering.

Por qué la IA construye de más

Los agentes de código optimizan para un resultado que parezca completo, no mínimo. Ante "agrega un rate limiter", el modelo tiene que adivinar el radio de impacto: ¿debería también actualizar la cadena de middleware? ¿Agregar un flag de configuración? ¿Instalar una librería? Cuando el prompt calla, el modelo llena el silencio — la guía de prompt engineering de GitHub pide declarar los requisitos de forma explícita y evitar la ambigüedad justamente porque el modelo la resuelve por su cuenta. La guía de Claude Code de Anthropic dice lo mismo desde el otro lado: cuanto más precisas tus instrucciones, menos correcciones necesitas, y una buena spec "declara qué queda fuera de alcance".

Construir de más no es un bug del modelo que vaya a desaparecer. Es subespecificación, y arreglarla te toma unas 15 palabras.

La sección Do-Not

Termina el prompt con restricciones negativas explícitas, una por línea:

Add a rate limiter to POST /api/orders.
Return 429 with a Retry-After header when the limit is hit.

Do NOT:
- modify any existing endpoint
- change the database schema
- add new dependencies (use what's already in package.json)
- touch files outside src/middleware/

Que vaya al final importa menos que hacerla explícita y verificable: cada línea es algo que puedes comprobar en el diff. "No cambió nada fuera del alcance de la tarea" pasa de ser una esperanza a ser un criterio de revisión.

Qué límites poner

De tres a cinco líneas es el punto justo. Un muro de 20 líneas de "No hagas" se lee por encima — el mismo modo de falla que un CLAUDE.md inflado, donde las reglas importantes se pierden en el ruido.

Trucos avanzados

• Acompaña el "no" con un "sí". La guía de prompting de Anthropic señala que los modelos siguen mejor las instrucciones positivas que las negaciones puras para el estilo ("write flowing prose" funciona mejor que "don't use markdown"). Para el alcance, los negativos duros funcionan — pero agregar la alternativa ayuda: "Do not add new dependencies; use the stdlib http client."
• Promueve los límites recurrentes. Un Do-Not que escribes todos los días pertenece a CLAUDE.md (o al archivo de reglas de proyecto de tu agente), para que aplique en cada sesión. Los realmente innegociables van en guardrails deterministas — p. ej. un hook de Claude Code que bloquea escrituras en tu carpeta de migraciones. Los prompts son consejos; los hooks se cumplen.
• Cierra el ciclo en la revisión. Pide al agente (o a una sesión revisora limpia) verificar el diff contra la lista Do-Not: "Confirm nothing outside src/middleware/ changed." Los límites que puedes buscar con grep son límites que se sostienen.
• Acota también las investigaciones. "Investigate the auth flow — do not make any changes" convierte a un agente ansioso en uno de solo lectura.

Recursos

• Prompting best practices — Anthropic — restricciones explícitas; instrucciones positivas vs. negativas
• Prompt engineering for GitHub Copilot Chat — GitHub Docs — evitar ambigüedad, declarar requisitos específicos
• Claude Code best practices — Anthropic — acotar prompts, specs con fuera-de-alcance, hooks como límites forzados
• System prompts — guía de prompt engineering de Anthropic — dónde viven las reglas y límites permanentes