Guía práctica para convertir una tarea en una automatización construida, probada y desplegada con un agente de programación.
Abres la IA, escribes, esperas, obtienes un resultado. Ahorras tiempo, pero tú sigues siendo el disparador.
Algo ocurre, el sistema trabaja y aparece el resultado, sin que tengas que acordarte de pedirlo.
Al terminar esta guía tendrás un procedimiento para llevar una tarea repetitiva desde una frase hasta una automatización que corre por sí sola, con pruebas y con forma de vigilarla.
¿Qué hace que empiece?
¿Qué necesita recibir o conocer?
¿Qué tiene que hacer?
¿Qué debe existir cuando termina?
DISPARADOR: ______________________________ INFORMACIÓN: _____________________________ TRABAJO: _________________________________ RESULTADO: _______________________________
Sé qué debe ocurrir y sé cuándo. Ejemplo: un resumen cada viernes.
No sé cuándo pasará, pero sé qué hacer cuando pase. Ejemplo: llega un reporte.
Conozco el objetivo, pero no todos los pasos.
¿Necesito que la IA decida esto cada vez, o ya conozco los pasos?
Pégala en Claude Code o Codex y después escribe la tarea. El agente debe hacer preguntas, no crear archivos.
Quiero convertir una tarea real en una automatización. No construyas nada todavía. Primero ayúdame a aclarar el problema. Identifiquemos: 1. DISPARADOR: qué hace que el trabajo empiece. 2. INFORMACIÓN: qué necesita recibir o conocer. 3. TRABAJO: qué pasos debe realizar. 4. RESULTADO: qué debe existir cuando termine. Hazme las preguntas mínimas necesarias para eliminar ambigüedades. Clasifica el caso como programado, disparado por un evento o potencialmente agéntico. Dime si los pasos pueden ser deterministas o qué decisión debe tomarse durante la ejecución. No escribas código hasta que yo apruebe el diseño.
Con lo que ya aclaramos, propón la arquitectura mínima para automatizar esta tarea. Prioridades: solución sencilla, no agregar servicios innecesarios, no usar autonomía agéntica si los pasos ya están definidos, separar claramente lo local de lo remoto, identificar credenciales sin pedirme valores, explicar pruebas antes y después del despliegue y explicar qué podría salir mal. Todavía no implementes. Muéstrame flujo completo, componentes, disparador, entrada, procesamiento, salida, secretos necesarios, pruebas, coste o recursos y riesgos. Termina pidiéndome aprobación.
Diseño aprobado. Implementa la versión mínima acordada. No cambies partes del proyecto que no sean necesarias; no introduzcas credenciales en el código; no subas archivos de entorno; no inventes datos cuando falte información; agrega validaciones y pruebas; prueba primero localmente; diagnostica y corrige defectos; no despliegues todavía. Al terminar, explica qué construiste, qué archivos cambiaste, qué pruebas ejecutaste, qué falló, qué corregiste y qué sigue sin estar comprobado. Después detente y espera mi autorización.
| Caso | Qué compruebas |
|---|---|
| Caso normal | Con datos completos y correctos, el resultado es el esperado. |
| Dato faltante o defectuoso | El sistema avisa qué falta en lugar de inventarlo. Ejemplo: marca REVISAR. |
| Ausencia de datos | No rompe ni produce un resultado falso. |
| Entradas adversariales | Responde con error claro, no se corta de golpe. |
| Errores externos | Quedan registrados y se entienden. |
| Efectos externos | No envía, borra, cobra ni registra nada indebido. |
Guarda la historia de cambios en tu computadora.
Aloja el código; puede ser privado.
Guardan secretos locales. Nunca se comparten ni se suben.
Aloja el código. No ejecuta el sistema.
Ejecuta las tareas desplegadas, fuera de tu computadora.
En la arquitectura demostrada, el despliegue se lanza con un comando desde tu computadora. Subir código a GitHub no actualiza la tarea por sí solo. En Trigger.dev: crea o verifica cuenta y proyecto, despliega una versión probada, revisa el historial de ejecuciones, ejecuta el caso alojado y confirma cómo detenerlo antes de activar un horario real.
Trabaja sobre una copia de desarrollo del workflow. Conecta tus propias credenciales dentro de n8n, prueba los nodos y mantén el workflow inactivo hasta verificar rutas normales y de error. Para usar Claude con n8n mediante MCP, configura localmente la URL de tu instancia y tu API key, comienza en solo lectura y nunca pegues esa key en un chat o repositorio.
La clase trabajó un workflow de Gmail hacia Siigo. Esta descarga conserva la estructura y conexiones de 24 nodos, pero no contiene parámetros, credenciales, IDs, endpoint ni datos operativos. Se importa para configurar y adaptar en una copia de desarrollo.
| Conserva | No incluye |
|---|---|
| Nombres, tipos, posiciones y conexiones de los 24 nodos. El workflow sigue inactivo. | Configuración de nodos, reglas, código operativo, credenciales, IDs de Gmail/Telegram, endpoint o datos de Siigo. |
Rellena los campos y copia el resultado para pegarlo en tu agente. Lo escrito se guarda solo en este navegador.
0 de 13 marcados
Elige una tarea repetitiva real, de las que todavía inicias tú, y pásala por las cuatro cajas. Si ya conoces los pasos, empieza determinista. Luego usa la Instrucción 1 y deja que el agente te haga las preguntas.
¿Por qué sigo siendo yo el que tiene que iniciar esto?