🧩 Por qué dividir el flujo en tareas pequeñas
¿Eres nuevo aquí? Una task (tarea) es un fragmento aislado de trabajo dentro de una automatización; por ejemplo, "buscar el correo nuevo" es una task y "guardar en la base de datos" es otra. Piensa en una línea de montaje: si falla la etapa de pintura, no desmontas el auto entero y empiezas desde cero; reparas solo la pintura.
En tu laptop, cuando un script se rompe a mitad de ejecución, ves el error en la pantalla, presionas una tecla y vuelves a ejecutarlo. En la nube, nadie está mirando. Si toda la automatización es «un solo bloque» y falla cualquier parte, o todo vuelve a ejecutarse desde el inicio (lo que lleva tiempo y, a veces, repite una acción que ya había salido bien), o todo se bloquea y queda esperando a que te des cuenta. Ninguna opción es buena.
💡 Concepto principal
Una buena automatización se compone de tareas pequeñas e independientes. Si una falla, solo esa se repite — el resto del trabajo que ya salió bien sigue en pie.
- •Bloque único: si falla en cualquier punto, vuelve a hacer todo (o se bloquea todo).
- •Tareas pequeñas: si una falla, solo esa se repite; las demás ni se enteran.
🔁 Qué es un reintento, en la práctica
¿Eres nuevo aquí? Reintento (en inglés, retry) es la plataforma intentándolo de nuevo por su cuenta, una tarea que falló, sin que tengas que apretar ningún botón. Es como volver a llamar a alguien cuando se corta la llamada: no te rindes al primer intento, vuelves a probar en unos segundos.
La mayoría de los fallos de automatización no significa que «todo esté roto» — son pasajeros: el servicio externo estuvo sobrecargado durante dos segundos, internet tuvo un tropiezo, el servidor tardó un poco más de lo esperado. Un reintento automático resuelve la mayoría de estos casos sin que nadie se dé cuenta.
Leyenda: casi siempre, un fallo aislado se resuelve en el 2.º o 3.er intento, sin intervención humana. Solo cuando se agotan los intentos te llega una alerta.
🔍 Por dentro
- Intentos con espera creciente: la plataforma no insiste de inmediato — espera un poco más en cada intento para dar tiempo a que el problema pase.
- Límite de intentos: después de un número definido (normalmente 3), la plataforma se rinde y marca la tarea como fallida, avisándote.
📥📤 Buscar datos no es guardar datos
Esta es la verdadera razón para dividir el trabajo en tareas pequeñas: buscar un dato (leer un correo electrónico, consultar una hoja de cálculo) puede repetirse todas las veces que quieras sin problema — volver a leerlo no cambia nada. En cambio, grabar un dato (enviar un correo electrónico, crear un cobro, guardar un registro nuevo) es diferente: si el reintento repite esa parte, podrías terminar enviando el correo dos veces o duplicando el mismo registro en la base de datos.
Por eso, la regla práctica es separar "buscar" de "guardar" en tareas diferentes. Si la tarea de guardar falla después de que la de buscar ya funcionó, el reintento repite solo el guardado, sin buscar (y sin arriesgarse a duplicar) el dato de nuevo.
✓ Tareas separadas
- ✓Task 1 busca la nueva solicitud. Task 2 guarda la confirmación. Si la 2 falla, solo esa se repite.
- ✓Repetir la grabación es seguro porque ya sabe exactamente qué solicitud debe confirmar.
- ✓Ningún correo electrónico duplicado, ningún cobro duplicado.
✗ Todo en una sola tarea
- ✗Una sola task busca la solicitud y registra la confirmación en el mismo paso.
- ✗Si falla después de guardar (por ejemplo, al registrar que terminó), el reintento lo hace todo de nuevo, incluso el guardado que ya se había realizado.
- ✗Resultado: un correo electrónico duplicado o un cobro duplicado, sin que nadie lo note en el momento.
💡 Consejo práctico
Al pedirle una automatización a Claude Code, di explícitamente «separa el paso de buscar del paso de guardar, en tasks distintas». Es una frase sencilla que evita muchos problemas de duplicación.
🚦 La fila: quién espera su turno
¿Eres nuevo aquí? Una cola es una lista de tareas que esperan su turno para ejecutarse, como una fila en el banco: cada una se atiende en orden, una a la vez (o algunas en paralelo, según la configuración), sin que tengas que estar mirando. Si llegan 50 pedidos al mismo tiempo, entran en la fila y se procesan sin bloquear todo el sistema.
La cola trabaja junto con el reintento: cuando una tarea falla, en vez de desaparecer, puede volver al final de la cola para intentarlo de nuevo más tarde. Este mecanismo, en conjunto, es lo que le da a una automatización la resiliencia necesaria para funcionar 24 horas sin que alguien tenga que estar pendiente todo el tiempo.
Ocurre el evento
Llega una solicitud nueva, se cumple un horario programado — la tarea entra en la cola.
La plataforma quita uno a la vez
Sin sobrecargar el sistema — si llegan 50 de una vez, los procesa al ritmo que puede.
Funcionó, sale de la cola
Queda registrada como completada en el panel de ejecuciones (módulo 4.7).
Si falla, vuelve a la cola (con reintento)
Espera un poco, inténtalo de nuevo — hasta el límite de intentos del tema 2.
📋 Por qué el modo de planificación pesa más aquí
Allá en el módulo 0.5 aprendiste el modo plan: pedirle a Claude Code que muestre los pasos antes de actuar, para que puedas revisarlos antes de cualquier cambio real. En tareas locales, un bug se convierte en un archivo desordenado que puedes corregir en segundos. En producción, un bug en una automatización que se ejecuta sola puede causar datos duplicados o una acción real incorrecta: un correo que se envió dos veces al cliente, un cobro duplicado en la tarjeta de alguien.
Por eso, cuando le pidas al agente que escriba o modifique una automatización que se ejecutará en producción —sobre todo si guarda datos o envía cosas al exterior—, usa siempre el modo plan. Lee el plan prestando especial atención a esta pregunta: "¿Esto separa buscar de guardar? ¿Es seguro repetirlo si falla a mitad de camino?"
✓ Antes de publicar una automatización
- ✓Pidió el plan y lo leyó antes de aprobar el cambio
- ✓Confirmó que buscar y guardar están en tasks separadas
- ✓Probó en dev (módulo 4.3) antes de tocar producción
✗ Publicar por impulso
- ✗Aceptó el cambio sin revisar el plan
- ✗No preguntó qué pasa si la tarea falla a mitad de camino
- ✗Fue directo a producción sin pasar por desarrollo
⚠️ Atención
Reforzando el patrón «¿Nuevo aquí?»: idempotencia es el nombre técnico de una tarea que puede repetirse varias veces sin cambiar el resultado (repetir «buscar» es idempotente; repetir «guardar» puede no serlo). No necesitas memorizar el término: recuerda la regla práctica: separa buscar de guardar.
✅ Lista de verificación antes de publicar una automatización
Antes de escribir el código de verdad —eso viene en el módulo 4.6, el Build de esta ruta—, conviene tener una pregunta lista para hacerle a Claude Code, en texto simple y sin necesidad de entender programación.
Objetivo: pedirle al agente que revise el diseño de la automatización antes de escribir el código, aplicando lo que enseñó este módulo.
Antes de escrever o código desta automação, me mostre o plano dividido em
tarefas pequenas (tasks). Para cada task, diga: (1) ela só busca dado, ou
também grava/envia algo pra fora? (2) se ela falhar no meio e a plataforma
tentar de novo automaticamente, existe risco de duplicar um e-mail, uma
cobrança ou um registro? Se existir, ajuste o plano separando busca de
gravação antes de eu aprovar.Cómo verificar: la respuesta debe listar tasks separadas con nombres claros (p. ej., "buscar pedidos nuevos", "guardar confirmación") y explicar, para cada una que guarde algo, por qué es seguro repetirla sin duplicar. Si la respuesta solo dice "sí, todo está bien" sin explicar por qué, vuelve a pedir más detalles.
🎯 Concepto principal
- •Tareas pequeñas → falla aislada → daño pequeño.
- •El reintento se ocupa de «volver a intentarlo»; separar la búsqueda del registro se ocupa de «no duplicar».
- •La cola garantiza que no se pierda nada, incluso cuando llegan muchas cosas a la vez.
Verificación rápida (opcional): ¿por qué separar "buscar datos" de "guardar datos" en tareas diferentes?