Cómo escribir system prompts más cortos y efectivos

Escribir un buen system prompt en 2026 ya no consiste en decir "eres un experto". El prompt más efectivo suele ser más corto que el que tienes hoy, y aquí verás por qué esa idea contraintuitiva funciona. Esto te sirve si trabajas con modelos de IA y quieres respuestas más precisas sin pelear contra tus propias instrucciones.

La clave está en entender que un rol suelto ya no alcanza. Antes bastaba con "eres un analista de datos" y ese era todo el contexto. Hoy ese rol compite con la memoria del proyecto, las descripciones de las herramientas y los documentos que subiste. Un rol impecable puede perder contra una memoria que dice lo contrario [00:34].

Cuáles son los tres bloques de un system prompt

Un system prompt bien estructurado se divide en tres partes, y cada una tiene su propia trampa [00:22].

• Rol: quién es y qué decisiones puede tomar. La trampa es escribir adjetivos como experto o profesional en vez de límites reales.
• Constraints: las restricciones. La trampa es acumularlas hasta que empiezan a contradecirse entre sí.
• Output: formato, longitud y estructura. La trampa es no describirlo porque parece obvio, y nunca es obvio.

De los tres, el que más problemas causa es el segundo. Ahí es donde casi todos nos equivocamos.

Qué es la zona Ricitos de Oro en un prompt

Anthropic describe dos formas de fallar con las restricciones, y hay que evitar ambas [01:00]. Es como la sopa del cuento: ni tan fría ni tan caliente.

• Sobreespecificar: una lógica compleja y demasiado detallada que busca provocar un comportamiento exacto. Se rompe con el primer caso que no estaba previsto.
• Subespecificar: una guía sin señales concretas. El modelo termina adivinando.

¿Cuál es el punto ideal de un system prompt? Es el conjunto mínimo de información que describe completamente el comportamiento esperado. Mínimo y completo al mismo tiempo, ese es el sweet spot.

Darle espacio al modelo para explorar los patrones a su alrededor le permite ser más inteligente al resolver tu solicitud, en vez de gastar esfuerzo resolviendo conflictos internos.

Cómo saber si una restricción sobra

Aquí viene la regla más importante de toda la clase [02:22]: solo escribes una restricción si puedes nombrar el caso concreto en el que el modelo se equivocó sin ella.

¿Cuándo debo agregar una restricción a mi prompt? Solo cuando puedes nombrar el caso real donde el modelo falló sin ella. Si no puedes nombrarlo, no es una restricción: es una corazonada.

Cada regla rígida que pones equivale a apostar que conoces todos los casos límite. Y la verdad es que casi nunca los conocemos. Los modelos actuales tienen juicio para decisiones que antes había que dictarles.

Cómo se ve una instrucción antes y después

Un ejemplo real muestra el poder de esta regla [01:37]. La versión vieja decía: nunca escribas comentarios, no escribas docstrings de múltiples párrafos, una línea corta máximo. El problema es que chocaba con otra instrucción activa que pedía dejar documentación según sea necesario.

Dos instrucciones peleando en el mismo contexto, y el modelo gastando energía en resolver el conflicto en lugar de trabajar.

La versión nueva es una sola línea: escribe código que se lea como el código de alrededor, igual a su densidad de comentarios, nombres e idioma. Cubre más casos porque no pelea con nada.

Cómo reescribir un prompt inflado paso a paso

Veamos un prompt real de atención al cliente para una tienda de electrónica llamada Volta Electrónica, que opera en México, Colombia y Chile [04:12]. El original acumulaba restricciones que se contradecían entre sí.

Al pasar el filtro caso por caso, esto es lo que sucede:

• Sé breve y al grano: es una preferencia, no una falla documentada. Va fusionada con el output.
• Explica cada paso con detalle: contradice a la anterior. Se borra.
• Nunca más de dos oraciones: vuelve a contradecir. Se borra.
• No uses lenguaje técnico: se conserva, porque hubo un caso real donde se le dijo RMA a un cliente y no entendió.
• No prometas nada que no puedas cumplir: se conserva, porque prometió reponer un producto descontinuado.
• Nunca inventes información: se conserva, ligada al SLA de 30 días.
• Siempre verifica antes de responder: ¿verificar contra qué? No es accionable. Se borra.
• No des fechas de entrega: se conserva, porque decía llega el martes y luego llega el viernes.
• Sé claro: demasiado subjetivo. Se elimina.

Después del filtro, el prompt queda limpio: un rol concreto ("eres el asistente de soporte de Volta Electrónica"), los constraints que sí tienen un caso documentado, y un output sencillo de máximo tres párrafos que siempre cierra con el siguiente paso concreto para el cliente [06:18].

¿Por qué un system prompt corto funciona mejor? Porque cada restricción innecesaria genera conflictos internos que el modelo debe resolver. Menos reglas contradictorias significan más capacidad para responder bien tu solicitud.

Cómo aplicar esto en tu propio prompt

El reto de la clase es directo y lo puedes hacer hoy [06:38]. Toma cualquier instrucción larga que le hayas escrito a una IA esta semana y transfórmala.

1. Sepárala en tres bloques: rol, constraints y output. Vas a descubrir que tenías mucho de uno y casi nada de otro.
2. Pasa el filtro por cada restricción. Si no puedes nombrar el caso donde falló sin ella, bórrala.
3. Cuenta las líneas antes y después. Si no bajaste, no fuiste suficientemente estricto.
4. Corre ambas versiones en sesiones distintas con la misma tarea y compara.

Verás que la versión corta casi siempre gana. ¿Te animas a compartir un pantallazo del antes y después de tu prompt en los comentarios?