Menulis Skrip Bash dengan AI Tanpa Merusak Server

Kamu minta AI membuatkan skrip untuk menghapus file backup yang lebih tua dari 14 hari. Dalam beberapa detik skripnya jadi, rapi, lengkap dengan komentar. Skrip itu benar untuk server yang dibayangkan AI. Masalahnya, server yang dibayangkan AI belum tentu sama dengan servermu: path berbeda, variabel yang ternyata kosong, atau perintah yang berperilaku lain di distribusi yang kamu pakai.

AI memang mempercepat penulisan skrip Bash, terutama untuk tugas rutin seperti backup, rotasi file, atau pengecekan layanan. Tapi skrip shell punya sifat yang tidak memaafkan: ia menjalankan apa yang tertulis, tanpa bertanya. Artikel ini membahas cara bekerja dengan AI supaya kecepatan itu tidak dibayar dengan server yang rusak.

Kesalahan skrip AI yang paling sering berbahaya

Kesalahan yang paling merusak biasanya bukan sintaks, melainkan asumsi. Contoh klasiknya adalah variabel kosong di dalam perintah hapus. Baris seperti rm -rf "$BACKUP_DIR/"* terlihat wajar, tetapi bila BACKUP_DIR tidak terisi karena salah ketik atau file konfigurasi tidak terbaca, perintah itu berubah menjadi menghapus isi direktori root.

Asumsi lain yang sering muncul: path yang tidak ada di servermu, nama layanan yang berbeda (misalnya versi PHP-FPM), perintah yang hanya ada di distribusi tertentu, atau skrip yang mengira dijalankan sebagai root. Ada juga skrip yang tidak berhenti saat satu langkah gagal, sehingga langkah berikutnya bekerja dengan data yang setengah jadi. Misalnya proses kompresi backup gagal, tapi skrip tetap menghapus file aslinya.

AI tidak melihat servermu. Semua yang tidak kamu sebutkan akan ia isi dengan tebakan yang masuk akal secara umum.

Cara meminta skrip yang aman

Mulailah dari prompt yang lengkap. Sebutkan distribusi dan versinya, user yang menjalankan skrip, path yang terlibat, apa yang harus terjadi bila sebuah langkah gagal, dan bagaimana skrip akan dijadwalkan. Lalu minta pengaman secara eksplisit, karena AI tidak selalu menambahkannya sendiri.

Pengaman yang layak diminta di hampir setiap skrip: baris set -euo pipefail di awal supaya skrip berhenti saat perintah gagal, saat memakai variabel yang belum diisi, atau saat salah satu bagian pipeline gagal. Semua variabel dikutip ganda ("$VAR") agar nama file berspasi tidak pecah. Untuk perintah berisiko, pakai bentuk ${VAR:?}, yang membuat Bash menghentikan skrip dengan pesan error bila variabelnya kosong atau tidak terisi. Minta juga mode uji coba (dry-run), misalnya opsi --dry-run yang hanya mencetak apa yang akan dihapus atau diubah tanpa benar-benar melakukannya.

Perlu diingat, set -e tidak menangkap semua kegagalan. Manual Bash menjelaskan sejumlah pengecualian, misalnya perintah di dalam kondisi if atau rangkaian && dan ||. Jadi tetap minta AI menulis pengecekan eksplisit di langkah penting, seperti memastikan file backup benar-benar ada dan tidak kosong sebelum file lama dihapus.

Satu kebiasaan kecil yang sangat membantu: minta AI menuliskan daftar asumsi di bagian atas skrip sebagai komentar. Misalnya "skrip ini mengira backup tersimpan di folder tertentu, dijalankan oleh user tertentu, dan butuh perintah tertentu terpasang". Daftar ini membuat tebakan AI terlihat jelas, sehingga kamu bisa mencoretnya satu per satu sebelum skrip dipakai. Kalau ada asumsi yang salah, perbaiki di prompt lalu minta skripnya ditulis ulang, jangan menambal baris secara manual tanpa memahami alurnya.

Memeriksa skrip sebelum dijalankan

ShellCheck adalah alat analisis statis untuk skrip shell yang tersedia di repositori paket banyak distribusi dan juga bisa dicoba di situs resminya. Ia mengenali pola berbahaya seperti variabel tanpa kutip di perintah rm. Jadikan ShellCheck pemeriksaan wajib, bukan opsional. Peringatannya juga bisa ditempel kembali ke AI untuk diperbaiki, lalu diperiksa ulang.

Langkah yang paling sering dilewati adalah uji kegagalan. Skrip yang berjalan mulus saat semuanya normal belum tentu aman saat disk penuh atau server backup tidak bisa dihubungi. Padahal justru kondisi seperti itulah yang terjadi jam dua pagi ketika tidak ada yang mengawasi.

Sebelum dijadwalkan

Skrip yang lolos uji masih perlu beberapa hal sebelum dipasang permanen. Pastikan ia menulis log ke file atau ke journal, sehingga bila gagal kamu bisa menelusurinya. Tentukan siapa yang mendapat notifikasi bila skrip berhenti dengan error. Jalankan dengan user yang hak aksesnya secukupnya, bukan root bila tidak perlu. Simpan skrip di repositori atau setidaknya folder yang ter-backup, beserta catatan kapan dan kenapa diubah.

Untuk penjadwalan, systemd timer memberi log dan status yang lebih mudah dipantau daripada cron biasa. Caranya dibahas di memakai systemd timer sebagai pengganti cron. Kalau skripnya untuk backup database, bandingkan dengan pendekatan di backup database MySQL dan PostgreSQL otomatis agar tidak ada langkah penting yang terlewat, misalnya uji restore.

Bagaimana kalau AI-nya langsung menjalankan skrip?

Asisten AI di terminal bisa menulis sekaligus menjalankan skrip. Ini praktis untuk server uji, tetapi berisiko di produksi. Biarkan mode persetujuan aktif, baca setiap perintah sebelum disetujui, dan jangan jalankan agen sebagai root. Pengaturan izin dan sandbox untuk alat seperti ini dibahas di asisten AI di terminal untuk admin server.

Pola kerja yang aman sebenarnya sederhana: AI menulis, kamu membaca, ShellCheck memeriksa, server uji membuktikan, baru produksi menjalankan. Setiap tahap menangkap jenis kesalahan yang berbeda.

Ringkasnya, AI adalah juru tulis skrip yang cepat tetapi tidak mengenal servermu. Beri konteks lengkap, minta pengaman seperti set -euo pipefail, ${VAR:?}, dan mode dry-run, periksa dengan ShellCheck, lalu uji di server terpisah termasuk skenario gagal. Dengan kebiasaan itu, skrip buatan AI bisa sama andalnya dengan skrip yang ditulis tangan.