Hubo un momento en mi trabajo con IA donde decidí que el problema era la falta de detalle. Que si los resultados no eran buenos era porque no había explicado suficiente. Así que empecé a construir prompts cada vez más largos. Llegué a escribir instrucciones de más de 800 palabras para una sola tarea.
El resultado fue desastroso. El modelo ignoraba partes enteras del prompt, mezclaba instrucciones de secciones distintas, y los outputs eran más inconsistentes que antes. Más contexto no significaba mejor resultado. Significaba más ruido.
Ese fracaso me llevó a entender algo que cambió completamente cómo trabajo: los modelos de lenguaje tienen un límite práctico de atención. Cuando un prompt supera cierta longitud, el modelo empieza a priorizar unas instrucciones sobre otras de forma impredecible. La solución no es escribir prompts mejores. Es escribir prompts más pequeños y encadenarlos.

Por qué los prompts cortos funcionan mejor
La idea es simple: en lugar de un prompt que pida analizar un texto, extraer conclusiones y traducirlas al inglés todo a la vez, creas tres prompts separados, cada uno haciendo una sola cosa.
Al reducir el alcance de cada instrucción, el modelo dedica toda su «atención» a una tarea concreta. El resultado es más preciso, más predecible y mucho más fácil de depurar cuando algo sale mal. Si el análisis es correcto pero la traducción falla, sabes exactamente dónde está el problema. En un prompt monolítico eso es imposible de identificar.
Lo llamo atomicidad, tomando prestado el término de programación: cada prompt hace una sola cosa y la hace bien. Nada más.
El router: quién decide qué prompt se activa
Cuando tienes varios prompts pequeños y especializados, necesitas algo que decida cuál usar según la situación. Esto es lo que se llama un router semántico, y es más sencillo de lo que parece.
Es simplemente otro prompt cuyo único trabajo es clasificar la intención del usuario y decidir a qué módulo enviársela. Si la petición es técnica, activa el prompt de código. Si es creativa, el de escritura. Si necesita datos, el de análisis.
Al principio me parecía añadir complejidad innecesaria. Pero en cuanto lo probé en un flujo real entendí el valor: el sistema usa solo los recursos que necesita para cada tarea. No activas el prompt de escritura creativa cuando alguien te pide que calcule algo. Es eficiente y el coste en tokens baja notablemente.
Autoconsistencia: cuando lanzas el mismo prompt tres veces a propósito
Esta es la técnica que más me sorprendió cuando la descubrí, porque parece contraintuitiva: en lugar de lanzar un prompt una vez y confiar en el resultado, lo lanzas tres veces en paralelo con temperatura alta para generar diversidad, y luego usas un cuarto prompt para comparar las tres respuestas y quedarte con la conclusión en la que coinciden al menos dos.
La lógica detrás es que los modelos son probabilísticos. A veces simplemente tienen un «mal día» y generan algo que no tiene sentido. Si lanzas el mismo prompt tres veces y dos de las respuestas coinciden en un dato, es mucho más probable que ese dato sea correcto que si solo tienes una respuesta.
Lo uso especialmente cuando el output va a usarse para tomar decisiones o cuando los errores tienen consecuencias reales. Para tareas creativas donde la variación es deseable no tiene tanto sentido, pero para extracción de datos, verificación de hechos o generación de código crítico marca una diferencia real en fiabilidad.

Cómo pasar contexto entre prompts sin perderlo
El problema más práctico de trabajar con prompts pequeños encadenados es que cada uno empieza sin saber lo que hicieron los anteriores. Si el prompt 1 analiza un documento y el prompt 3 necesita usar ese análisis, ¿cómo se lo pasas?
La solución que uso es un objeto JSON compartido que cada prompt lee al inicio y actualiza al final. Algo así como una pizarra donde cada módulo escribe sus resultados antes de pasar el turno al siguiente.
El prompt 1 lee la pizarra (vacía al principio), hace su análisis y escribe el resultado en el JSON. El prompt 2 lee ese JSON, añade su propia capa de análisis y actualiza el objeto. El prompt 3 recibe el JSON completo con todo el trabajo anterior y puede construir sobre él sin necesidad de re-procesar nada.
Es más trabajo de configuración inicial, pero una vez que tienes el sistema montado es sorprendentemente robusto. Y cuando algo falla, puedes inspeccionar el JSON en cualquier punto del flujo y ver exactamente qué tenía cada prompt cuando tomó sus decisiones.
Tokens de control: convertir lenguaje en lógica
Una cosa que me resultó muy útil es instruir a los prompts para que empiecen siempre su respuesta con una palabra clave concreta. Por ejemplo, SUCCESS si la tarea se completó correctamente o ERROR seguido del problema si algo falló.
Esto permite que el código que gestiona el flujo lea esa primera palabra y decida automáticamente si continuar al siguiente paso o pedir una corrección, sin necesidad de analizar todo el texto del output. Estás usando lenguaje natural como protocolo de comunicación entre módulos, que es una forma elegante de decir que la IA y tu código se entienden sin ambigüedad.
Una nota sobre el coste
El punto débil obvio de todo esto es que más prompts significa más tokens y más coste. Pero hay una forma de mitigarlo que funciona muy bien: usar modelos baratos para la creación y el router, y reservar el modelo más potente solo para los pasos donde el criterio realmente importa, como la evaluación o la síntesis final.
Como los prompts pequeños consumen pocos tokens por definición, el coste total acaba siendo similar o incluso menor que el de un solo prompt monolítico largo, con resultados notablemente más fiables.
Lo que cambió en mi forma de trabajar
Desde que empecé a pensar en prompts como módulos en lugar de instrucciones únicas, el tiempo que dedico a depurar errores bajó drásticamente. Cuando algo falla, sé exactamente en qué paso ocurrió. Puedo arreglarlo sin tocar el resto del sistema.
Y hay algo más difícil de cuantificar: la confianza. Cuando sabes que tu sistema tiene puntos de verificación incorporados y que cada paso hace una sola cosa bien definida, puedes delegar más trabajo a la IA sin estar pendiente de revisar cada output manualmente.
El prompt más largo que escribí fue el que peor funcionó. El sistema más fiable que tengo ahora está hecho de prompts que caben en tres líneas cada uno.
