~/VibeHandbook
PDF gratis

Capítulo 17 · 03

Caso de estudio 3: Una utilidad de automatización personal

La idea

Uno puramente egoísta: un script que cada mañana toma los eventos del calendario del día y el clima, arma un resumen de una línea y lo envía a un chat personal de Telegram. El objetivo era dejar de abrir tres aplicaciones antes del café.

La especificación

A scheduled job that runs at 7am my timezone. It reads today's
events from my calendar, fetches the forecast for my city, and
sends one Telegram message like: "3 events today, first at 9:30.
High 24C, rain after 4pm." If any source fails, still send what
you have and note what's missing.

Esa última frase —degradarse con elegancia en lugar de fallar por completo— es el tipo de comportamiento que hay que pedir de forma explícita. La IA no lo va a asumir. Si no se dice, el comportamiento por defecto al que un modelo recurre es "lanzar un error", lo que para un trabajo cron de las 7 a. m. significa una mañana silenciosa y ninguna pista de por qué.

La pila tecnológica

Una sola función programada sin servidor (un Worker activado por cron) para que no haya ninguna máquina que mantener en funcionamiento. Todo el proyecto es un archivo más un horario. Para una utilidad personal esto importa más de lo que parece: cualquier cosa con un servidor que cuidar es algo que eventualmente olvidarás pagar, y el proyecto muere de abandono en lugar de fallo.

Un disparador se ramifica hacia dos fuentes y converge en un solo mensaje. El try/catch alrededor de cada fuente es lo que permite que un solo fallo se degrade con elegancia en lugar de matar toda la ejecución:

                    ┌─────────────────┐
  7am cron ───────▶ │  WORKER         │
                    │                 │   try ┌──────────────┐
                    │  fetch sources ─┼──────▶│ WEATHER API  │
                    │  (each in       │       └──────────────┘
                    │   try/catch)    │   try ┌──────────────┐
                    │                 ┼──────▶│ CALENDAR API │
                    │  build summary  │       └──────────────┘
                    │       │         │
                    └───────┼─────────┘
                            ▼
                    ┌─────────────────┐
                    │  TELEGRAM BOT   │  "3 events today… High 24C"
                    └─────────────────┘
   one source fails → send what you have, note what's missing

Los prompts clave

Write a Cloudflare Worker triggered by cron at 7am Asia/Seoul.
It calls a weather API and a calendar API (I'll provide both
tokens as secrets), builds a one-line summary, and POSTs it to
the Telegram Bot API. Wrap each external call in try/catch so one
failure doesn't kill the message. Read every token from env.

Cuando quisimos iterar sobre la redacción sin esperar hasta las 7 a. m.:

Add a manual trigger: if the Worker is hit with a GET request and
a ?test=1 query param, run the same logic immediately and return
the message text in the response instead of sending it. Keep this
behind a secret token so only I can trigger it.

Ese disparador de prueba nos salvó de un ciclo de retroalimentación brutal: podíamos ver el resultado a demanda en vez de una vez al día. Es una jugada general que vale la pena robar: cada vez que tu código se ejecute según un horario, constrúyete una forma de ejecutarlo ahora mismo, a demanda, antes de comprometerte a esperar al reloj.

El obstáculo

El mensaje de Telegram llegaba, pero las horas estaban mal: los eventos aparecían en UTC, no en hora coreana. El clima estaba bien. Lo aislamos:

Calendar times are 9 hours off — showing UTC, not Asia/Seoul.
The weather time ("rain after 4pm") is correct. Here's how I
format both: [pasted]. Fix only the calendar formatting and tell
me why the weather path was already right.

La IA explicó que la del clima (Application Programming Interface — la puerta que un servicio expone para que otro programa obtenga sus datos) ya devolvía cadenas localizadas, mientras que la API del calendario devolvía marcas de tiempo en UTC que estábamos imprimiendo tal cual. Añadió una sola conversión de zona horaria en el paso de formateo del calendario. Acotar la corrección a "solo el camino del calendario" evitó que reescribiera el código del clima que ya funcionaba, una forma común en que las correcciones de la IA rompen cosas que estaban bien. La segunda mitad de ese —"tell me why the weather path was already right" (dime por qué el camino del clima ya estaba bien)— cumplió una doble función: nos dio la causa raíz real en lugar de una suposición, y obligó a la IA a articular la diferencia para que su corrección no "armonizara" accidentalmente ambos caminos en uno solo, roto.

El lanzamiento

"Lanzar" aquí solo significó desplegar el Worker, configurar el horario cron y añadir los tokens de API como secretos cifrados. Golpeamos el ?test=1 un par de veces para confirmar que el mensaje se leía bien, y luego lo dejamos correr. Ha funcionado cada mañana desde entonces, y la línea de degradación elegante demostró su valor un mes después, cuando la API del clima tuvo una interrupción y el mensaje igual llegó, solo que sin el pronóstico.

¿Lo quieres sin conexión?

Descarga el libro entero en PDF o EPUB — gratis.