Studi Kasus 3: Utilitas Otomasi Pribadi

Idenya

Satu ide yang murni untuk diri sendiri: sebuah skrip yang setiap pagi mengambil acara kalender hari itu dan cuaca, memformatnya menjadi satu baris ringkasan, dan mengirimkannya ke sebuah chat Telegram pribadi. Intinya adalah berhenti membuka tiga aplikasi sebelum minum kopi.

Spesifikasinya

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.

Kalimat terakhir itu — menurun secara anggun (degrade gracefully) alih-alih mogok total — adalah jenis perilaku yang harus kamu minta secara eksplisit. AI tidak akan mengasumsikannya sendiri. Kalau tidak diucapkan, pengaturan bawaan yang akan diraih model adalah "lempar error", yang untuk sebuah pekerjaan cron jam 7 pagi berarti pagi yang senyap tanpa petunjuk sama sekali.

Stack-nya

Satu fungsi serverless terjadwal (sebuah Worker yang dipicu Cron) sehingga tidak ada mesin yang perlu terus dijaga hidup. Semuanya hanya satu berkas ditambah satu jadwal. Untuk utilitas pribadi ini lebih penting dari yang terlihat: apa pun yang punya server yang perlu dijaga adalah hal yang suatu saat akan lupa kamu bayar, dan proyek itu mati karena terabaikan, bukan karena gagal.

Satu pemicu bercabang ke dua sumber dan mengerucut kembali menjadi satu pesan. try/catch di sekitar setiap sumber itulah yang memungkinkan satu kegagalan menurun secara anggun alih-alih membunuh seluruh proses:

                    ┌─────────────────┐
  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

Prompt-prompt kuncinya

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.

Saat kami ingin mengulik kata-kata dalam pesannya tanpa menunggu sampai jam 7 pagi:

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.

Pemicu uji itu menyelamatkan kami dari lingkaran umpan balik yang menyiksa — kami bisa melihat hasilnya kapan pun, bukan sekali sehari. Ini gerakan umum yang layak ditiru: kapan pun kodemu berjalan sesuai jadwal, buatlah cara untuk menjalankannya sekarang juga, sesuai permintaan, sebelum kamu berkomitmen untuk menunggu jam berdetak.

Hambatannya

Pesan Telegram-nya sampai, tapi waktunya salah: acara-acara muncul dalam UTC, bukan waktu Korea. Cuacanya sudah benar. Kami mengisolasi masalahnya:

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.

AI menjelaskan bahwa API cuaca (Application Programming Interface — pintu yang dibuka satu layanan agar program lain bisa mengambil datanya) sudah mengembalikan string yang terlokalisasi, sementara API kalender mengembalikan timestamp UTC yang kami cetak apa adanya. AI menambahkan satu konversi zona waktu pada langkah pemformatan kalender. Membatasi cakupan perbaikan hanya "jalur kalender saja" mencegah AI menulis ulang kode cuaca yang sudah bekerja dengan benar — cara umum bagaimana perbaikan AI justru merusak hal yang tadinya baik-baik saja. Bagian kedua dari prompt itu — "tell me why the weather path was already right" — punya fungsi ganda: memberi kami penyebab sesungguhnya alih-alih sekadar tebakan, dan memaksa AI untuk mengartikulasikan perbedaannya sehingga perbaikannya tidak tidak sengaja "menyelaraskan" kedua jalur itu menjadi satu jalur yang sama-sama rusak.

Peluncurannya

"Peluncuran" di sini hanya berarti men-deploy Worker-nya, mengatur jadwal cron-nya, dan menambahkan token API sebagai secret terenkripsi. Kami mengakses endpoint ?test=1 beberapa kali untuk memastikan pesannya terbaca dengan baik, lalu membiarkannya berjalan. Ia berjalan setiap pagi sejak saat itu — dan baris penurunan-anggun (graceful-degradation) itu membuktikan nilainya sebulan kemudian, ketika API cuaca mengalami gangguan (outage) dan pesannya tetap sampai, hanya tanpa perkiraan cuaca.