Contexto
Estoy construyendo un sistema que, cuando se gana un deal, setea todo el proyecto solo: cliente, repo, canal de Slack, proyecto de Harvest, wiki del repo, y notificación al dueño. Ocho pasos encadenados, cada uno hablando con una API externa distinta.
La primera versión del plan tenía dos supuestos silenciosos que hubieran sido carísimos:
- Que necesitaba un servidor dedicado para orquestar los pasos.
- Que podía empezar a escribir código sin definir primero los workflows en un lugar versionado y editable.
Los dos supuestos cayeron el mismo día.
Qué aprendí
1. Las colas de trabajo serias cuestan casi nada
El problema técnico concreto: mi stack corre en serverless (edge functions con timeout de 10 a 60 segundos). Un workflow que demora 2 o 3 minutos en completarse no cabe en una sola función serverless. Si respondo "OK, lo proceso en background" y la función muere antes de terminar, pierdo el trabajo silenciosamente.
Las soluciones clásicas que conocía:
- Levantar un servidor dedicado (VM always-on). Mínimo 5-10 USD/mes, más tiempo de mantenimiento, más superficie de ataque.
- Construir una cola propia con cron polling. Funciona pero eventualmente se rompe, sin observabilidad, sin retries automáticos.
- Comprar un servicio enterprise. 50-200 USD/mes.
La que descubrí: job queues con step functions nativas (el patrón donde cada paso del workflow es un checkpoint independiente con retry automático). Hay dos opciones maduras con free tier muy generoso. La que elegí me da 50,000 ejecuciones gratis al mes. Un workflow completo consume ~15 ejecuciones. Eso me da margen de ~3,000 deals ganados por mes sin pagar un peso.
Para el volumen real de una agencia: gratis efectivo para siempre.
La lección de fondo no es "usá esta herramienta". Es esta:
Cuando elegís infra para workflows asíncronos, los servicios SaaS con step functions y free tier ya igualaron o superaron a los servidores dedicados en costo, observabilidad y confiabilidad. El default viejo ("levantá un worker") es cada vez más caro que el default nuevo.
Boring technology con free tier está ganando. Hay que revisar los supuestos cada 12-18 meses.
2. Un wiki corto te obliga a planificar los agentes antes de codearlos
El segundo aprendizaje vino por accidente. Estaba por escribir 12 módulos nuevos cuando hice un inventario honesto de qué ya existía en el repo. Resultado: 7 de esos 12 ya estaban construidos. Iba a duplicar infraestructura sin darme cuenta.
¿Cómo se llega a ese error? Fácil: cuando el plan vive solo en la cabeza, no ves las duplicaciones. Cuando el plan vive en un wiki versionado con archivos específicos (architecture.md, reference.md, workflows.md), el ejercicio de escribirlo te fuerza a mirar la realidad.
La decisión que cambió todo: en vez de hardcodear los workflows del autopilot en código, los definí como playbooks en archivos YAML dentro del repo. Cada workflow es un archivo editable, cada paso es una llamada HTTP a un endpoint simple. Si mañana quiero agregar un paso o cambiar el orden, edito YAML. No toco código, no redeployo.
Tres beneficios inmediatos:
- No duplico lo que ya existe. Obligarte a escribir "paso 4: llamar al endpoint X" te obliga a verificar que X exista. Si existe, lo reusás. Si no, lo creás una vez y lo reusan todos los playbooks futuros.
- Cada agente IA consume el mismo endpoint. No tenés un agente con su lógica embebida y otro con otra. Todos llaman a los mismos HTTP endpoints idempotentes. Cambias el endpoint una vez y se actualiza para todos.
- El wiki es onboarding real para el próximo humano (o agente) que entre al proyecto. No hay "sabiduría oculta" en la cabeza de alguien. Si el workflow no está en el wiki, no existe.
El efecto secundario más valioso fue lo que pasó durante el planning: tuve que elegir entre 4 opciones de arquitectura para cada decisión crítica, con trade-offs explícitos. Terminé el día con 3 ADRs (architecture decision records) que cualquier persona puede leer y entender por qué el sistema es como es, no solo qué hace.
Resultado
- Un plan de 6 fases con ~16 archivos a tocar (antes eran ~30 por la duplicación).
- Revisión de arquitectura aprobada con cero gaps críticos.
- Decisión de infra que me ahorra ~100 USD/mes vs la opción que iba a tomar por default.
- 3 ADRs documentando las decisiones difíciles (cola de jobs, fuente de verdad del estado, migración de fuente de datos).
- La primera fase ya en ejecución (migración del registro de equipo a la base compartida, schema extendido, UI actualizada).
Aprendizaje clave
Construir con agentes no es "escribir código más rápido". Es forzar disciplina de planificación que antes te saltabas.
Cuando el código es gratis de escribir, el cuello de botella se mueve aguas arriba: ahora el costo está en tomar malas decisiones de arquitectura, duplicar infra, o elegir un servicio caro cuando hay uno gratis que alcanza. Un wiki corto con playbooks editables es la herramienta más barata para obligarte a resolver esas decisiones antes de que el agente las grabe en código.
La regla que me llevo para los próximos proyectos:
Ningún agente escribe código hasta que el workflow que va a automatizar está escrito como playbook en el wiki del repo, y hasta que confirmé que no estoy construyendo algo que ya existe.
El costo de esa disciplina es una hora. El costo de saltearla es semanas de refactor, o peor: facturas mensuales por servicios que nunca necesité.