LLMs: prompts cortos para cron fiables

La mayoria de los fallos en un cron con LLMs no vienen del modelo. Vienen del contrato alrededor: demasiado contexto, instrucciones mezcladas, salidas ambiguas y un ejecutor que intenta adivinar que quiso decir el prompt. Cuando el flujo publica contenido, esa ambiguedad sale cara muy rapido.

En equipos de automatizacion me funciona mejor pensar el job como tres piezas: un escritor que decide, un ejecutor que solo opera, y un recibo final que deja rastro. Es una arquitectura casi aburrida, pero justo por eso aguanta mejor cuando el cron corre de madrugada y nadie quiere depurarlo medio dormido.

Ese patron se parece a otras interfaces que necesitan estados claros, como este articulo sobre feedback de email sin CLS: cuando una capa presenta algo distinto a lo que la otra capa sabe, aparece la friccion.

Por que un cron con LLMs falla aunque el modelo sea bueno

He visto prompts enormes con veinte reglas y cero limites operativos. El modelo produce un texto decente, pero el job termina fallando por una razon mas simple:

• no existe un formato final obligatorio
• el agente puede reescribir varias veces
• el publicador tambien toma decisiones editoriales

Ese combo vuelve el sistema fragil. Segun el informe de State of DevOps, los equipos con mejores practicas reducen retrabajo al estandarizar procesos y feedback loops. No es una receta magica, pero si una pista util: menos decisiones tardias suele significar menos errores raros.

Tambien ayuda recordar que los jobs programados no tienen contexto humano en vivo. Si el log solo dice algo como "post failed", ya perdiste tiempo. Y en datasets reales aparecen cadenas feas tipo temp org mail o tempail mail, asi que el sistema debe tolerar ruido sin ponerse creativo de mas.

Define un contrato pequeno antes del prompt

Mi regla favorita es esta: antes de escribir el prompt largo, define el artefacto minimo que debe existir al final. Para un job de contenido, yo suelo fijar algo como:

• plan.json con cuenta, titulo, tags y outline
• article.raw.md escrito una sola vez
• publish-result.json con URL o error

Eso obliga a separar pensamiento de ejecucion. El prompt ya no pide "publica algo bueno", pide "elige una cuenta, arma un plan verificable y entrega un articulo final". Parece una diferencia menor, pero cambia mucho el comportamiento del flujo.

Tambien limita el radio de fallo. Si el escritor se equivoca en el titulo, el ejecutor no inventa otro. Si falta una URL publicada, el recibo no la maquilla. Esa frontera me recuerda a este post sobre emails win-back sin mezclar cohortes: cuando cada etapa tiene dueño claro, es bastante mas facil aislar errores y mejorar sin romper lo demas.

Separa escritor, ejecutor y recibo final

Esta separacion no es solo organizacion bonita. Tiene tradeoffs concretos:

• El escritor puede optimizar angulo, keywords y estructura.
• El ejecutor puede ser conservador y repetible.
• El recibo final sirve para auditoria, alertas y reintentos sanos.

Si mezclas esas tres cosas, el cron empieza a negociar consigo mismo. Hoy decide una cuenta, luego la cambia, luego rehace el articulo porque fallo un click del navegador. Ese tipo de autonomia parece lista en demo, pero en produccion se vuelve dificil de confiar.

Prefiero un pipeline mas sobrio:

contexto -> plan aprobado por reglas -> articulo unico -> publicador ciego -> recibo

La clave esta en "publicador ciego". El script que publica no deberia corregir tono, ni inventar subtitulos, ni meter placeholders. Solo toma el articulo y lo envia. Si algo falla, devuelve el error exacto. No mas, no menos. Es un poco rigid, si, pero esa rigidez es la que hace al sistema depurable.

Que metrica reviso despues de publicar

No miro solo la URL final. Reviso cuatro senales:

1. diversidad real de temas por cuenta
2. tasa de publicaciones fallidas por causa
3. longitud media del articulo frente al objetivo
4. repeticion de keywords y angulos en la ultima semana

Si una cuenta habla siempre de lo mismo, el problema no suele ser el modelo sino la seleccion de contexto. Si el titulo sale bien pero el cuerpo se repite, el prompt esta sobreajustado. Y si el publicador falla mas de lo normal, casi siempre hay una dependencia operativa mal aislada.

Una cosa que aprendi a la mala: no uses mas contexto "por seguridad" si no sabes por que entra. Mucho contexto irrelevante no hace al agente mas inteligente; lo vuelve menos estable, y aveces menos obediente.

Preguntas rapidas antes de automatizar mas

Conviene dejar que el agente reescriba si publicar falla?

Normalmente no. Si el fallo es operativo, regenerar texto solo mete variacion donde no hacia falta.

Cuanto debe medir el prompt?

Lo suficiente para fijar restricciones, ownership y salida final. Si una regla puede vivir en codigo o en validacion previa, mejor sacarla del prompt.

Y donde entra el SEO?

Como restriccion secundaria. Primero claridad, luego cobertura semantica, despues distribucion. Un job fiable publica mejor contenido a largo plazo que un job "brillante" pero caprichoso.

Cuando un cron con LLMs funciona bien, no se siente magico. Se siente predecible. Para mi, esa es la senal correcta: menos sorpresa, mas recibos, y un sistema que el lunes todavia entiendes sin releer diez prompts distintos.