Scheduler bukan editor yang bisa berpikir sendiri
“Ambil Markdown asli, perbaiki, lalu terbitkan.”
Kedengarannya gampang.
Sampai semuanya dicoba otomatis.
Sistem harus membaca Markdown, menentukan apakah siap, mengecek 12 bahasa, menghapus judul yang aneh, memeriksa tautan, menerbitkan, membuka halaman produksi, kembali saat gagal, mencari penyebab, memperbaiki, menjalankan ulang, lalu memastikan tidak ada bagian lain yang ikut rusak.
Tiba-tiba ban berjalan juga diminta menjadi pemimpin redaksi.
Masalahnya bukan Cloudflare Workers, tugas terjadwal, atau GitHub Actions jelek.
Mereka memang dibuat untuk pekerjaan yang berbeda.
Otomatisasi tradisional sangat bagus untuk mengulang prosedur yang sudah diketahui. Pabrik konten menerima teks yang selalu berbeda dan masalah yang juga berbeda. Banyak kasus membutuhkan membaca, memahami, memperbaiki, dan memeriksa hasil.
Itu lebih mirip pekerjaan agen AI daripada sekadar cron.
1. Pipeline yang sama belum tentu berarti pekerjaan yang sama
Pabrik artikel terlihat seperti produksi massal.
Masuk: Markdown. Keluar: artikel terbit.
Jadi terlihat seolah cukup menjalankan proses yang sama 100 kali.
Tapi teks bukan baut dengan ukuran standar.
Artikel A punya judul aneh. Artikel B kehilangan satu dari 12 bahasa. Artikel C sudah diterjemahkan, tetapi memakai istilah yang tidak pernah dicari orang lokal. Artikel D tanpa sengaja menampilkan catatan SEO internal. Artikel E punya tautan afiliasi yang valid tetapi ditempatkan di lokasi yang tidak masuk akal. Artikel F sudah terbit, tetapi status masih tertulis “sedang berjalan”.
Semuanya gagal di dalam pipeline yang sama.
Namun cara memperbaikinya berbeda.
Jika input selalu berubah, bentuk kegagalannya juga berubah.
2. Scheduler hebat untuk menjalankan pekerjaan yang sudah diketahui
GitHub Actions menjalankan workflow yang sudah didefinisikan ketika ada peristiwa, pemicu manual, atau jadwal tertentu.[1]
ChatGPT Scheduled Tasks juga menjalankan tugas pada waktu yang dipilih atau saat peristiwa yang didukung terjadi.[2]
Cloudflare Workers kuat untuk memproses permintaan, pekerjaan berkala, dan menghubungkan layanan.
Sistem seperti ini bagus menjawab:
“Kapan harus jalan?” “Script mana yang dijalankan?” “Perintah tadi berhasil?” “Kalau kondisi ini benar, langkah berikutnya apa?”
Tapi pertanyaan berikut berbeda:
“Judul ini terasa seperti terjemahan mesin?” “Bagian ini benar, tapi apakah berguna bagi pembaca?” “Tautannya valid, tapi kenapa diletakkan di sini?” “Kegagalan hari ini benar-benar sama dengan kemarin?”
Scheduler punya jam.
Ia tidak otomatis punya insting editor.
3. Bagian tersulit adalah menutup seluruh siklus perbaikan
Masalahnya bukan sekadar mengubah sesuatu.
Sistem harus:
menemukan kegagalan, mencari penyebab, memperbaiki, menjalankan ulang, memeriksa hasil nyata, mencari efek samping, dan mencoba dugaan lain bila perbaikan pertama salah.
Manusia melakukan ini hampir tanpa sadar.
Dalam otomatisasi, setiap perpindahan kondisi harus dirancang.
Kasus paling menyebalkan adalah “setengah berhasil”.
Halaman sudah terbit, tapi status belum berubah.
Penerjemahan selesai, tapi satu bahasa kosong.
Repositori berhasil diperbarui, tapi produksi gagal.
Kalau semuanya diulang begitu saja, publikasi atau pemrosesan bisa terjadi dua kali.
Karena itu tujuan otomatisasi yang tangguh bukan hanya “jangan gagal”.
Tujuannya:
aman saat dijalankan ulang.
Cloudflare Workflows mendukung langkah yang tahan gangguan, penyimpanan hasil, dan retry. Dokumentasinya juga menekankan desain operasi yang aman bila dipanggil lagi.[3][4]
4. Cloudflare bagus untuk pemulihan, tetapi pemulihan bukan penilaian editorial
Cloudflare Workflows dapat menyimpan status pekerjaan bertahap, mengulang langkah yang gagal, dan melanjutkan dari langkah yang sudah selesai.[3]
Cloudflare Queues dapat mencoba pengiriman ulang dan mengirim pesan yang berulang kali gagal ke Dead Letter Queue.[5]
Ini sangat cocok untuk:
gangguan jaringan sementara, API gagal, timeout, pesan yang terus gagal, pekerjaan yang harus dilanjutkan nanti.
Namun ada masalah lain:
“Bahasa Spanyolnya bisa dipahami, tapi orang lokal tidak akan mencari dengan frasa ini.”
“Isinya benar, tapi subjudul ini justru membuat artikel lebih buruk.”
Menambah retry dari tiga menjadi sepuluh tidak menciptakan kemampuan editorial.
Sistem hanya bisa mengulang kesalahan yang sama sepuluh kali dengan sangat disiplin.
Retry bukan pengganti penilaian.
5. GitHub Actions adalah meja kerja yang bagus, bukan editor otonom
GitHub Actions sangat berguna untuk pekerjaan deterministik.
Menjalankan tes. Memeriksa file. Build. Deploy jika syarat terpenuhi. Menjalankan script berkala.
Itulah kekuatannya.[1]
Namun Actions tidak membaca artikel lalu menyimpulkan:
“Masalah utama sebenarnya ada di pembukaan, bukan judul.”
AI memang bisa dipanggil dari workflow.
Tetapi saat itu masalah utama berubah menjadi:
konteks apa yang diberikan, apa yang boleh diubah, bagaimana hasil diverifikasi, dan bagaimana proses dilanjutkan setelah gagal.
Menyuruh bor listrik memimpin rapat redaksi lalu kecewa pada bornya juga agak tidak adil.
6. Lebih baik pisahkan jalur normal dan jalur pengecualian
Pabrik yang realistis membutuhkan dua jalur.
Jalur normal: otomatisasi hal yang bisa diuji
Mesin dapat memeriksa:
- file wajib ada
- 12 bahasa tersedia
- tidak ada kolom kosong
- format URL valid
- ID tidak duplikat
- perintah terbit berhasil
- halaman produksi dapat dibuka
Workers, script, dan Actions cocok untuk ini.
Jalur pengecualian: pisahkan masalah dan lanjutkan
Satu artikel gagal tidak boleh menghentikan seluruh antrean.
Catat alasannya. Pindahkan artikel itu ke jalur lain. Lanjutkan ke artikel berikutnya.
Kategori bisa berupa:
- bahasa hilang
- struktur salah
- tautan gagal
- publikasi gagal
- perlu penilaian isi
- penyebab belum diketahui
Kalau 90 dari 100 artikel lolos otomatis, terbitkan 90.
Tidak perlu membuat 90 artikel sehat ikut dihukum karena sepuluh artikel sedang bermasalah.
Lewati pengecualian dan terus berjalan.
7. Berikan pengecualian kepada agen yang bisa membaca repositori
Pengecualian biasanya membutuhkan membaca, menalar, mengedit, dan memverifikasi.
Di sinilah agen pemrograman cocok.
Dokumentasi Codex Cloud menjelaskan pekerjaan di lingkungan proyek yang sudah disiapkan untuk menyelidiki bug, mengubah kode, menjalankan tes, dan melanjutkan tugas cloud dari perangkat yang didukung.[6]
Dalam pabrik konten, agen bisa menjadi meja perbaikan:
ambil artikel yang gagal, baca Markdown asli, lihat hasil generasi, baca catatan kegagalan, periksa kode jika perlu, perbaiki, jalankan pengecekan, terbitkan ulang, dan cek halaman nyata.
Tidak perlu memakai penalaran mahal untuk semua artikel yang normal.
Yang rutin ditangani mesin.
Yang aneh ditangani agen.
8. Jika pengecualian sering muncul, naikkan menjadi aturan otomatis
Antrean pengecualian tidak boleh menjadi tempat sampah permanen.
Jika masalah yang sama terus muncul, itu bukan lagi pengecualian. Itu pola.
Jika satu bahasa sering hilang, tambahkan pemeriksaan otomatis.
Jika subjudul yang sama sering bocor, buat validator yang menolaknya.
Jika publikasi berhasil tetapi status sering gagal diperbarui, cek halaman produksi lebih dulu lalu perbaiki status secara otomatis.
Urutan yang sehat adalah:
jalankan pabrik, kumpulkan kegagalan nyata, gunakan agen untuk kasus langka, temukan pola, otomatisasi hanya pola yang sering muncul.
Mencoba menebak semua kegagalan sebelum mulai produksi adalah cara terbaik untuk membangun pabrik selamanya tanpa pernah menghasilkan apa pun.
Kesimpulan: scheduler adalah ban berjalan, agen AI adalah meja perbaikan
Cloudflare, tugas terjadwal, dan GitHub Actions terasa mengecewakan jika diharapkan menjadi editor otonom.
Namun perannya memang berbeda.
Sistem terjadwal harus:
memulai pekerjaan, menjalankan pemeriksaan objektif, meneruskan kasus normal, mengisolasi kegagalan, dan menjaga jalur tetap bergerak.
Agen harus menjawab:
“Kenapa artikel ini aneh?” “Apa yang harus diubah?” “Apakah perbaikannya benar-benar berhasil?”
Arsitekturnya sederhana:
Otomatiskan jalur mudah. Jangan biarkan satu pengecualian menghentikan satu batch. Kirim hanya pengecualian ke agen. Ubah pengecualian berulang menjadi aturan otomatis.
Pabrik konten tidak membutuhkan ban berjalan yang mampu memikirkan semuanya.
Yang dibutuhkan adalah ban berjalan yang tidak berhenti dan meja perbaikan cerdas untuk kotak yang keluar jalur.
- GitHub Docs, Workflows docs.github.com
- OpenAI Help Center, Scheduled tasks in ChatGPT help.openai.com
- Cloudflare Docs, Build your first Workflow developers.cloudflare.com
- Cloudflare Docs, Rules of Workflows developers.cloudflare.com
- Cloudflare Docs, Dead Letter Queues developers.cloudflare.com
- OpenAI Help Center, Using Codex Cloud help.openai.com
