Hay una conversación que se repite cada semana en Studio SmartWork. Un dueño de negocio nos escribe frustrado: "Probé a montar un bot con ChatGPT y los resultados son inconsistentes. A veces funciona, a veces se inventa cosas, a veces directamente ignora lo que le pido".
La reacción habitual es echarle la culpa al modelo. "La IA todavía no está lista". "Los LLMs alucinan demasiado". "Quizá dentro de un año".
Pero esa conclusión casi siempre es errónea. El problema rara vez es el modelo. El problema es cómo le estamos hablando.
Esta semana ha circulado por Hacker News un artículo titulado Specsmaxxing que ha generado cientos de comentarios entre desarrolladores. La tesis es sencilla pero importante: si quieres que la IA produzca resultados fiables, tienes que dejar de improvisar prompts y empezar a escribir especificaciones claras. Vamos a desgranar qué significa eso, por qué importa para tu negocio, y cómo aplicarlo aunque no seas técnico.
El problema real: "AI psychosis"
El autor del artículo le pone un nombre provocador a un fenómeno que cualquiera que haya intentado automatizar con IA reconoce: AI psychosis. Es esa sensación de estar discutiendo con un asistente que un día entiende perfectamente y al siguiente parece haber olvidado las reglas básicas. Le pides que clasifique emails y funciona. A la semana siguiente, los mismos emails los clasifica al revés.
¿Por qué pasa esto?
Porque los modelos de lenguaje son probabilísticos, no deterministas. No siguen reglas como un programa tradicional — interpretan instrucciones. Y si las instrucciones son ambiguas, cada interpretación puede ser ligeramente distinta. Multiplica eso por miles de ejecuciones al mes y tienes un sistema impredecible.
La solución no es rezar para que el modelo "entienda". Es eliminar la ambigüedad de raíz.
Qué es una spec (y por qué cambia todo)
Una spec (especificación) es un documento que describe con precisión qué tiene que hacer un sistema. No cómo lo hace — qué hace.
La diferencia entre un prompt y una spec es la diferencia entre:
"Oye, clasifica estos emails y respóndeme los importantes"
y
tarea: clasificación_email categorías: - urgente: requiere respuesta en menos de 2h - cliente_existente: viene de dominio en CRM - prospecto: primer contacto, sin historial - spam: detectado por filtros estándar - newsletter: contiene unsubscribe link reglas: - si urgente Y cliente_existente: notificar a Slack #ventas - si prospecto: enriquecer con LinkedIn antes de notificar - si spam: archivar sin notificar formato_respuesta: - asunto_original - categoría - acción_tomada - confianza (0-100)
El primero deja que el modelo decida qué significa "importante". El segundo no le deja margen para inventar.
Por qué YAML (y por qué te debería importar aunque no programes)
El autor del artículo defiende escribir specs en YAML, un formato que se lee casi como una lista con sangrías. La razón es práctica: YAML obliga a estructurar el pensamiento en jerarquías y relaciones explícitas. No puedes ser vago en YAML — o defines algo, o no existe.
No necesitas saber YAML para aprovechar esta idea. Lo importante es el principio:
| Prompt vago | Spec estructurada |
|---|---|
| "Responde profesionalmente" | Tono: formal-cercano. Saludo: "Hola [nombre]". Despedida: "Un saludo". Máximo 4 líneas. |
| "Si es urgente, avísame" | Urgente = contiene keywords ["hoy", "urgente", "reunión mañana"] O remitente en lista_VIP |
| "Resume la llamada" | Resumen: 3 bullets max. Incluir: decisión tomada, próximo paso, fecha límite. Excluir: small talk. |
Esta es la diferencia entre una automatización que funciona el 60% del tiempo y una que funciona el 98%.
Cómo aplicamos esto en Studio SmartWork
Cuando un cliente nos contrata para automatizar un proceso, lo primero que hacemos no es tocar código. Es escribir la spec.
Nuestro proceso típico es:
- Entrevista de descubrimiento. Hablamos con la persona que hace el trabajo manualmente hoy. Le pedimos que nos lo enseñe en directo, sin filtros.
- Mapeo de casos. Anotamos no solo el caso "normal", sino los raros. ¿Qué pasa cuando el email viene en otro idioma? ¿Cuando el cliente responde con una pregunta nueva? ¿Cuando el lead no tiene web?
- Spec en formato legible. Escribimos la lógica completa en un documento que el cliente puede leer y validar antes de que escribamos una línea de código. Si el cliente no lo entiende, está mal escrito.
- Validación con casos reales. Cogemos 20-30 ejemplos históricos y verificamos que la spec produciría el resultado correcto en cada uno.
- Construcción. Solo entonces empezamos a montar el bot en n8n con las APIs de IA correspondientes.
Este paso previo es la razón por la que entregamos automatizaciones funcionando en menos de 7 días sin que se rompan al mes siguiente. La spec es el contrato entre lo que el cliente espera y lo que la máquina hace.
Los tres errores más comunes al escribir specs
Después de cientos de procesos automatizados, estos son los fallos que vemos una y otra vez:
1. Confundir excepciones con casos normales. La gente describe el flujo feliz y olvida los bordes. "El bot recibe el email, lo clasifica y responde". Vale, ¿y si llegan 5 emails del mismo remitente en 3 minutos? ¿Y si el email es una respuesta a una conversación anterior? Las excepciones no son detalles — son donde fallan las automatizaciones.
2. Definir tareas en lugar de criterios. "Resume la reunión" es una tarea. "Un resumen es: 3 bullets máximo, cada uno empezando con verbo en pasado, máximo 15 palabras" es un criterio. Los criterios son evaluables. Las tareas son interpretables.
3. No definir qué NO hacer. Una buena spec dice tanto lo que el sistema debe hacer como lo que no debe hacer bajo ningún concepto. "Nunca prometer descuentos". "Nunca dar fechas concretas de entrega". "Nunca responder preguntas legales". Los límites son tan importantes como las capacidades.
El cambio mental que necesitas
Si estás pensando en automatizar algo en tu negocio — atención al cliente, gestión de emails, calificación de leads, lo que sea — el cambio mental más importante no es técnico. Es este:
La IA no es mágica. Es un ejecutor muy rápido de instrucciones precisas. Si las instrucciones son ambiguas, el resultado será ambiguo. Si son claras, el resultado será fiable.
Esto es buenas noticias, en realidad. Significa que no dependes de que los modelos mejoren para que tu automatización funcione. Depende de que tú (o quien te ayude) sepa traducir tu proceso a reglas claras.
Y aquí va una pista incómoda: si no eres capaz de explicarle tu proceso a un humano nuevo en menos de una hora con suficiente detalle para que lo haga bien, no hay IA en el mundo que lo automatice por ti. La automatización empieza por la claridad, no por la tecnología.
Por dónde empezar
Si quieres aplicar esto a tu negocio sin contratar a nadie, prueba este ejercicio esta semana:
- Elige una tarea repetitiva que hagas tú o tu equipo.
- Escríbela como si tuvieras que dejarle instrucciones a alguien que empieza mañana y al que no podrás llamar.
- Incluye: qué inputs recibe, qué outputs produce, qué decisiones toma, qué hace en cada caso raro que se te ocurra.
- Léela en voz alta. Cualquier frase que use "normalmente", "a veces" o "depende" es una señal de ambigüedad que hay que resolver.
Ese documento es el 80% del trabajo de automatizar la tarea. El otro 20% es montaje técnico — y ahí es donde un equipo como el nuestro entra. Pero la spec siempre la construimos juntos, porque nadie conoce el proceso mejor que quien lo vive.
La lección del artículo de Hacker News no es nueva, pero está volviendo con fuerza por una razón: a medida que la IA se mete en más procesos críticos, la diferencia entre un bot que funciona y uno que da vergüenza es exactamente esta. Specs claras. Reglas explícitas. Cero ambigüedad.
La buena noticia es que esto está al alcance de cualquier negocio. La mala es que no se puede saltar el paso.