Automasi Gagal Bukan Soal Model yang Bodoh
Gue pernah ngerasain ini. Loe pasang automasi buat ngerapihin kerjaan rutin, beberapa minggu kemudian kerjaan loe malah nambah. Hasilnya ngawur di beberapa tempat, dan tiap error harus dicek manual satu-satu buat tau bagian mana yang rusak. Penyebabnya bukan yang gue duga.
Awalnya gue ngira modelnya kurang pintar. Jadi gue ganti pendekatannya, nambah instruksi, nambah aturan di prompt. Yang kejadian malah kebalikannya. Makin banyak instruksi, makin banyak tempat gagal, dan makin susah nyari biang keroknya.
Kerjaan baru yang muncul dari automasi gagal itu nggak kelihatan di awal. Dia muncul pelan-pelan. Loe mulai ngecek hasilnya tiap pagi, lalu ngecek dua kali sehari, lalu nggak berani nggak ngecek. Di titik itu loe bukan lagi punya automasi, tapi punya hewan peliharaan baru yang harus diawasi.
Yang akhirnya gue sadar: di VPS gue ada 9 job otomatis yang jalan tiap hari. Tujuh di antaranya script murni, nol token, nggak pernah nyentuh model sama sekali. Cuma 2 job yang benar-benar butuh model. Sisanya kerjaan yang keluarannya bisa ditentukan.
Yang bikin repot justru bukan tujuh script itu. Dua job yang pakai model itu yang paling sering bikin gue jengkel, dan bukan karena dia bodoh. Satu di antaranya pernah mati diem-diem: balasannya cuma 403, nggak ada notifikasi apa pun, dan nggak ada yang sadar sampai berhari-hari kemudian.
Perhatiin pola di situ. Yang gagal bukan kemampuan modelnya, tapi nggak ada yang ngabarin waktu dia berhenti kerja. Kalau loe punya sepuluh job dan nol alarm, loe nggak punya automasi. Loe punya pekerjaan tersembunyi.
Jadi biang keroknya bukan kepintaran modelnya. Biang keroknya penempatan: model dipakai di tempat yang harusnya script biasa, plus nggak ada satu pun cara buat tau dia mati.
Urutannya: Deterministik Dulu, Model Belakangan
Pertanyaan yang gue pakai buat mutusin sekarang cuma satu. Kalau keluarannya bisa gue tulis sendiri sebagai aturan, kenapa gue minta model nebak? Selama jawabannya bisa ditentukan, itu kerjaan script.
Contoh yang gampang: narik data, ngecek tanggal, ngerapiin nama file, ngurutkan baris, ngebuang yang kosong, ngirim ke tempat yang sudah pasti. Semua itu nggak butuh kreativitas. Butuh urutan yang sama tiap kali.
Model baru masuk kalau kerjaannya soal bahasa. Nulis, meringkas, ngerapiin nada, atau milih jawaban dari beberapa opsi yang emang kabur. Di situ model menang, dan di situ gue rela bayar.
Kebiasaan yang bikin automasi berantakan itu satu: semua kerjaan dilempar ke satu agent, dari ngecek file sampai nulis balasan. Begitu satu bagian ngaco, loe nggak tau bagian mana yang ngaco. Kalau kerjaannya dipisah, script buat urusan urutan, model buat urusan bahasa, tiap bagian bisa gagal sendiri tanpa ngerusak yang lain.
Gue nggak pernah masang model buat kerjaan yang bisa gue tulis sendiri sebagai aturan. Prinsipnya sama kayak biaya: bayar kalau selesai, per task, bukan langganan bulanan. Tujuh job di VPS gue jalan tanpa keluar biaya token sama sekali, dan itu bukan prestasi. Itu cuma penempatan yang bener. Yang mahal itu bukan modelnya, tapi kerjaan yang dipaksa masuk ke model.
Kalau loe masih di tahap milih kerjaan mana yang perlu diganti duluan, urutannya gue tulis di berhenti nyari tools AI, ganti dulu kerjaan yang paling ngeselin. Tulisan ini lanjutannya: setelah kerjaannya ketemu, putuskan pakai script atau model.
Kerjaan Ini Pakai Script atau Model?
Tabel ini yang gue pakai tiap nambah job baru. Kalau job loe nggak ada di daftar, tes pakai satu pertanyaan: kalau loe bisa nulis aturannya, itu kerjaan script.
| Kerjaan | Pakai | Kenapa |
|---|---|---|
| Narik data, terus nyimpen ke file | Script | Keluarannya pasti, nggak ada yang perlu ditimbang |
| Ngecek tanggal, jadwal, dan batas waktu | Script | Aturannya jelas, salah sedikit pun langsung ketahuan |
| Ngerapiin nama file dan folder | Script | Polanya sama tiap kali dijalankan |
| Ngitung dan ngurutkan angka | Script | Hasilnya bisa dicek ulang manual |
| Nulis ringkasan dari catatan panjang | Model | Butuh bahasa, bukan urutan |
| Ngerapiin nada balasan yang kasar | Model | Keputusannya soal rasa, bukan aturan |
| Milih jawaban pas pertanyaannya kabur | Model | Nggak ada aturan tetap yang bisa ditulis |
| Ngecek hasil kerjaan model | Script | Gatenya harus deterministik, bukan dinilai model |
Perhatiin baris terakhir. Gate buat ngecek hasil model itu sendiri harus script, bukan model lagi. Kalau loe ngecek hasil model pakai model, loe cuma mindahin tempat nebak, dan nggak ada yang bisa dipercaya waktu dua-duanya salah.
Cara cepat nebak loe salah tempat atau nggak: hitung berapa kali loe bolak-balik ngecek hasil satu job. Kalau loe ngeceknya lebih sering daripada job-nya jalan, berarti itu kerjaan yang mestinya bisa ditentukan aturannya. Pindahin ke script, dan loe balik punya waktu.
Satu Job Satu Tugas, Satu Log Sendiri
Ini bagian yang paling sering dilupain, termasuk sama gue. Job otomatis nggak boleh punya dua tugas. Sekali dia ngerjain dua hal, waktu satu bagian gagal, loe nggak bisa bilang bagian mana yang gagal.
Kalau langkahnya lebih dari satu, pecah jadi job terpisah. Job yang pendek bisa dites ulang sendiri tanpa nyeret job lain ikut jalan.
Tiap job nulis hasil dan error-nya ke catatan sendiri. Waktu ada yang mati, loe buka satu catatan, bukan ngecek semua job satu-satu.
Sebelum keluarannya dipakai orang lain, ada satu pemeriksaan yang ngukur. Panjangnya, isinya, jumlahnya. Kalau nggak lolos, job itu berhenti di situ.
Kirim ke publik, hapus data, atau apa pun yang susah ditarik balik, harus lewat satu titik di mana manusia bilang lanjut.
Log juga nggak perlu mewah. Yang penting tiga hal: kapan job jalan, apa hasilnya, dan kalau gagal, alasannya apa. Log yang cuma nulis selesai itu sama kayak nggak punya log.
Satu contoh nyata yang bikin gue ngerasa bodoh. Artikel versi tipis 468 kata pernah tayang di halaman publik. Versi finalnya, 1.084 kata, nyangkut dan nggak pernah naik. Yang publish mikir semuanya beres, karena nggak ada satu pun gate yang ngukur panjang tulisan.
Ada lagi satu artikel yang tayang di halaman publik tanpa lampu hijau dari gue. Bukan karena sengaja, tapi karena jalur publish-nya emang nggak punya titik approval. Dua-duanya kelas masalah yang sama: nggak ada satu pun yang ngukur.
Jalur Manual Itu Wajib, Bukan Cadangan
Aturan terakhir yang paling sering disepelein: harus ada cara manusia ngerjain kerjaan itu tanpa nunggu scriptnya dibenerin. Bukan buat selamanya, cukup buat lewat hari ini.
Job yang mati diem-diem itu contohnya. Tanpa jalur manual, loe nggak punya pilihan selain nunggu sadar sendiri bahwa ada yang rusak. Itu yang bikin satu job bisa mati berhari-hari tanpa ada yang ngeh.
Kalau loe baru sadar ada job yang gagal waktu loe buka log manual, berarti job itu gagal senyap. Automasi yang aman itu yang ngabarin loe, bukan yang nunggu loe nanya.
Bikin jalur manualnya murah, jangan sempurna. Satu halaman catatan berisi langkah yang bisa dikerjain orang lain sudah cukup. Yang penting waktu automasinya mati, loe nggak berhenti total.
Contoh lain di mana automasi baru dipasang setelah aturannya jelas ada di studi kasus otomasi CS WhatsApp.
Urutan lengkapnya sederhana. Deterministik dulu, model cuma buat bagian bahasa, tiap job satu tugas dengan log sendiri, dan selalu ada pintu manual. Empat hal itu nggak bikin automasi loe sempurna. Tapi cukup buat bikin loe tau kapan dia rusak tanpa harus nemu sendiri.
Mulai dari yang paling gampang: buka daftar job loe hari ini, tandai mana yang sebenernya nggak butuh model. Yang kelihatan paling sepele biasanya justru di situ biang keroknya.
