LLMs: contratos de salida para cron fiables

Cuando un job con LLM corre cada pocas horas, el problema serio no suele ser "escribe peor". El problema real es mas seco: entrega un resultado dificil de publicar, dificil de revisar o imposible de retomar sin adivinar cosas. En varias automatizaciones internas he visto que el coste no estaba en generar el texto, sino en no tener un contrato de salida claro entre el agente que piensa y el script que ejecuta. Ese detalle parece menor, pero cambia todo.

Mi regla es simple: el cron agente escribe plan, draft y metadatos congelados; el publicador solo ejecuta. Si ambos lados mezclan criterio, aparecen bugs aburridos y bastante caros de rastrear despues.

Donde se rompen de verdad los cron con LLMs

Piensalo como un diagrama en palabras:

1. El scheduler despierta al agente.
2. El agente elige cuenta, angulo y artefactos.
3. Un script publica lo que encuentra en el run directory.
4. Horas despues alguien revisa el resultado o un fallo.

La mayoria de roturas llegan en la frontera entre 2 y 3. Si el agente deja un titulo pero no una descripcion consistente, el publicador tiene que inventar. Si cambia el articulo despues de escribir el plan, ya no existe una fuente unica de verdad. Si reintenta y vuelve a generar, la auditoria queda medio rota, y eso luego confunde a todo el mundo.

Esto se parece bastante a diseñar feedback estable al enviar emails: no basta con que el sistema "funcione". Tiene que devolver el dato correcto, en el momento correcto y con una forma facil de consumir. Con LLMs pasa lo mismo, solo que el output ya no es una pantalla sino un paquete de publicacion.

El contrato de salida que yo pediria

Para un cron writer yo pediria cuatro piezas obligatorias:

1. plan.json con cuenta, keywords, links y outline.
2. article.raw.md escrito una sola vez.
3. un run_id visible en carpeta y logs.
4. un resultado final del publicador, sin reinterpretar el contenido.

Ese contrato hace que el sistema sea menos "creativo" justo donde no debe serlo. Y eso es bueno. Los LLMs sirven para explorar angulos, redactar y comprimir contexto; no sirven tan bien para ser una capa invisible de negocio cuando nadie puede verificar lo que decidieron.

Un ejemplo minimo seria algo asi:

{
  "run_id": "20260814T082220Z-lucasg88",
  "username": "lucasg88",
  "title": "LLMs: contratos de salida para cron fiables",
  "files": ["plan.json", "article.raw.md"],
  "publish_cmd": "publish_devto.sh <run_dir>"
}

No hace falta hacerlo barroco. De hecho, cuanto mas corto y mas estable, mejor. La gente escanea antes de confiar. Nielsen Norman Group lleva anos insistiendo en que la informacion clara y bien fragmentada reduce carga cognitiva en tareas de revision (NN/g). En un pipeline programado, esa claridad se convierte en menos errores humanos y menos retrabajo raro.

Como separar plan, draft y publicacion

La separacion que mejor me ha funcionado es esta:

1. El agente decide el tema usando historial y perfil.
2. Escribe plan.json primero.
3. Redacta article.raw.md exactamente una vez contra ese plan.
4. El publicador solo lee archivos y llama a la API.

La clave no es tecnica, es de limites. Si el publicador empieza a corregir tags, traducir keywords o completar enlaces faltantes, ya dejaste de tener un ejecutor. Ahora tienes una segunda capa de decision. Y cuando dos capas deciden, tarde o temprano una contradice a la otra, aun si al inicio parecia comodo.

Por eso prefiero un run directory auditable. Si alguien pregunta por que se publico cierto post, deberias poder abrir la carpeta y entenderlo en cinco minutos. Sin rebuscar prompts, sin adivinar estados en memoria, sin perseguir un temp org mail perdido en logs que ni hacian falta guardar.

Algo parecido pasa cuando quieres validar email sin frenar el formulario: la UX mejora cuando cada capa sabe su trabajo. El input valida. La UI explica. El submit decide. En cron con LLMs, el plan orienta, el draft comunica y el publisher publica. Ya esta, no deberia ser mas lioso que eso.

Que validar antes de llamar al publicador

Yo pondria un checklist corto antes del paso final:

1. El title existe y sigue debajo del limite.
2. La description cabe en el snippet.
3. Los enlaces internos usan el idioma correcto.
4. backlink_count coincide con el plan.
5. El markdown no tiene placeholders ni campos vacios.
6. El draft fue escrito una sola vez para ese run_id.

Tambien revisaria pequeñas cosas humanas: tono consistente, anchors naturales y que las keywords raras no dominen el texto. Si necesitas meter frases como tempail o generador de emails falsos, mejor hacerlo con calma y contexto. Si el lector nota que el articulo fue diseñado alrededor de la keyword y no alrededor del problema, la confianza baja rapidito.

El tradeoff es honesto: un contrato mas estricto reduce flexibilidad en ejecucion, pero sube mucho la confiabilidad operacional. Para mi compensa de sobra. Los cron jobs buenos no son los mas listos; son los que fallan de forma entendible.

Preguntas frecuentes

Debo regenerar el articulo si la publicacion falla?

No. Si el contrato dice una sola generacion, se respeta. Reintentas la ejecucion con los mismos artefactos o reportas el error. Regenerar mezcla evidencia y te deja un historial feo de revisar.

Donde conviene guardar las decisiones editoriales?

En plan.json, no en el script de publicacion. Cuenta elegida, title, tags, internal links y reglas del run deben vivir ahi, para que el ejecutor siga siendo tonto y predecible.

Esto aplica solo a DEV.to?

Para nada. Sirve en cualquier workflow donde un agente redacta y otro paso publica, envia o despliega. Mientras exista frontera entre pensar y ejecutar, vale la pena formalizar la salida.

Mi conclusión es bastante poco glamorosa, pero util: si quieres cron jobs con LLMs que duren meses sin drama, dales un contrato de salida pequeño, visible y facil de auditar. No hace magia, pero evita muchisimo caos futuro.