AI bisa bikin kerja kelihatan lebih cepat, tapi kalau loop review lu dipotong, yang naik bukan produktivitas. Yang naik adalah risiko.
Artikel ini membahas pelajaran dari laporan Bloomberg soal Ford yang merekrut kembali quality inspectors setelah eksperimen AI quality-control tidak selalu cukup. Intinya bukan “AI gagal” atau “AI jelek”. Intinya: AI automation tetap butuh orang yang paham domain, terutama saat output-nya berdampak ke kualitas produk, keamanan, reputasi, atau uang.
Buat developer, pelajarannya dekat banget: kode AI yang compile belum tentu benar, PR yang terlihat rapi belum tentu aman, dan automation yang jalan lancar belum tentu punya judgement. Kalau lu pakai AI coding tool, agent, atau workflow otomatis, pertanyaan pentingnya bukan cuma “bisa jalan nggak?”, tapi “siapa yang ngecek saat hasilnya salah dengan cara yang halus?”
Kenapa cerita Ford relevan buat developer?
Bloomberg melaporkan Ford sempat mengalami masalah dalam quality-control berbasis AI dan akhirnya merekrut kembali inspector serta engineer berpengalaman. Detail lengkapnya memang ada di balik paywall, jadi gua nggak mau overclaim soal penyebab tunggalnya. Tapi sinyal besarnya jelas: di area yang butuh judgment lapangan, automation belum tentu bisa menggantikan pengalaman manusia begitu saja.
Ini mirip banget dengan software engineering. Banyak developer sekarang memakai AI untuk generate code, refactor, bikin test, menulis migration, bahkan memperbaiki bug. Output-nya sering terlihat meyakinkan. Masalahnya, software jarang rusak dengan cara yang dramatis di awal. Kadang bug-nya baru muncul saat data production beda, user flow lebih aneh, load lebih tinggi, atau security boundary disentuh dari sisi yang tidak kepikiran.
AI bagus untuk mempercepat pekerjaan yang pattern-nya jelas. Tapi domain judgment tetap mahal karena dia datang dari pengalaman melihat sistem gagal berkali-kali. Senior engineer bukan cuma orang yang mengetik lebih cepat. Mereka sering dibayar karena tahu kapan sesuatu yang “kelihatan benar” sebenarnya berbahaya.
Apa itu review loop dalam AI automation?
Review loop adalah rangkaian pengecekan sebelum output AI dianggap aman dipakai. Dalam software, bentuknya bisa berupa code review, test otomatis, staging deployment, observability, security scan, rollback plan, dan approval manusia untuk perubahan berisiko tinggi.
Review loop yang sehat biasanya punya empat lapis:
- Validasi teknis: apakah kode compile, test lulus, dan tidak merusak kontrak API?
- Validasi produk: apakah perubahan ini benar-benar menyelesaikan problem user?
- Validasi risiko: apakah ada dampak ke security, data privacy, billing, atau reliability?
- Validasi operasional: kalau salah, apakah lu bisa mendeteksi dan rollback cepat?
AI bisa membantu di tiap lapis itu, tapi jangan jadikan AI sebagai satu-satunya penjaga. Kalau tool yang membuat perubahan juga menjadi tool yang menyatakan perubahan itu aman, lu sedang bikin konflik kepentingan versi engineering.
Kesalahan umum: mengira output cepat sama dengan output siap pakai
AI membuat biaya produksi output turun drastis. Draft artikel bisa jadi lebih cepat. Kode boilerplate bisa muncul dalam hitungan detik. Test skeleton bisa dibuat otomatis. Tapi saat biaya membuat output turun, biaya memilih output yang benar justru makin penting.
Di sinilah banyak tim salah baca. Mereka melihat AI bisa menghasilkan 10 opsi, lalu menganggap produktivitas naik 10x. Padahal kalau 10 opsi itu tetap harus dibaca, diuji, dibersihkan, dan diselaraskan dengan konteks sistem, bottleneck pindah ke review.
GitHub sendiri pernah membahas evaluasi agentic harness Copilot dari sisi performance dan efficiency. Pelajarannya penting: model pintar saja tidak cukup. Cara agent diberi konteks, dievaluasi, dan diarahkan punya pengaruh besar terhadap hasil. Dengan kata lain, AI coding bukan cuma soal model. Ini soal sistem kerja di sekeliling model.
Contoh nyata di codebase: bug yang lolos karena terlihat benar
Bayangin lu minta AI memperbaiki bug login. Dia menemukan fungsi validasi token, mengubah kondisi expiry, menambahkan test, lalu semua test hijau. Dari luar, kelihatan rapi.
Tapi ada beberapa pertanyaan yang belum tentu dijawab oleh AI:
- Apakah perubahan ini memengaruhi session lama yang masih aktif?
- Apakah refresh token punya aturan berbeda dari access token?
- Apakah mobile app versi lama masih kompatibel?
- Apakah perubahan ini membuka celah replay atau privilege escalation?
- Apakah monitoring lu bisa menangkap spike login failure setelah deploy?
Di sinilah judgment manusia masuk. Bukan untuk menolak AI, tapi untuk memberi konteks yang tidak selalu tertulis di file. Banyak risiko produk hidup di history tim, incident lama, kebiasaan user, dan kompromi teknis yang tidak masuk README.
Kapan output AI wajib direview manusia?
Menurut gua, semakin besar blast radius sebuah perubahan, semakin wajib ada review manusia. Ini checklist sederhana yang bisa lu pakai hari ini:
- Menyentuh auth, permission, session, atau payment? Wajib review manusia.
- Mengubah query data production atau migration database? Wajib review manusia.
- Menambah dependency, plugin, GitHub Action, atau script install? Wajib review manusia.
- Memakai secret, token, credential, atau akses cloud? Wajib review manusia.
- Mengubah logic bisnis yang berdampak ke uang, stok, invoice, atau entitlement? Wajib review manusia.
- Agent menjalankan command di environment nyata? Wajib ada sandbox, log, dan batas permission.
Kalau perubahan cuma rename variable lokal atau generate UI statis yang mudah dicek, AI bisa lebih bebas. Tapi kalau perubahan punya efek sistemik, perlakukan AI seperti junior developer super cepat: sangat membantu, tapi tetap perlu arahan, review, dan guardrail.
Human-in-the-loop bukan berarti anti-automation
Banyak orang memakai istilah human-in-the-loop seolah artinya proses jadi lambat. Padahal yang bikin lambat biasanya bukan review-nya, tapi review yang tidak jelas kriterianya.
Review manusia yang bagus harus fokus ke keputusan yang memang butuh judgment. Jangan minta manusia mengecek hal yang bisa dicek mesin. Format, lint, unit test, typecheck, dan policy sederhana sebaiknya otomatis. Waktu manusia dipakai untuk hal yang lebih mahal: tradeoff, risiko, edge case, dan konteks produk.
AI automation yang sehat biasanya terlihat seperti ini:
- AI membuat draft perubahan di branch atau worktree terpisah.
- Test, lint, typecheck, dan scan otomatis jalan dulu.
- AI merangkum diff, alasan perubahan, dan area risiko.
- Manusia review bagian yang punya blast radius tinggi.
- Deploy bertahap dengan monitoring dan rollback yang jelas.
Dengan pola ini, AI tetap mempercepat kerja, tapi tidak mengambil alih keputusan paling berisiko.
Kenapa ini penting buat personal workflow rafli.dev?
Gua sendiri makin sering memakai automation buat workflow konten dan development: Obsidian untuk backlog, Ghost CMS untuk draft, Hermes Agent untuk riset dan automation, plus berbagai tool AI untuk mempercepat nulis dan debugging. Tapi makin banyak automation yang gua pasang, makin jelas juga satu hal: semua workflow otomatis butuh batas.
Draft artikel tetap harus dibaca. Kode tetap harus dites. Sumber tetap harus dicek. Credential tidak boleh dilempar sembarangan ke agent. Dan kalau ada automation yang bisa membuat perubahan nyata, harus ada log dan cara membatalkannya.
Itu alasan gua suka framing “AI sebagai multiplier”, bukan “AI sebagai pengganti judgment”. Multiplier itu memperbesar kapasitas kerja lu. Tapi kalau arahnya salah, dia juga memperbesar kesalahan lu.
Takeaway praktis buat developer
- AI automation paling aman saat tugasnya jelas, output-nya bisa diuji, dan blast radius-nya kecil.
- Semakin dekat ke production, security, uang, dan data user, semakin wajib ada review manusia.
- Jangan ukur produktivitas AI dari jumlah output. Ukur dari useful work yang benar-benar sampai production tanpa menambah risiko liar.
- Senior judgment makin penting karena AI membuat output murah, bukan membuat risiko hilang.
- Automation yang bagus bukan yang menghapus manusia, tapi yang membuat manusia fokus ke keputusan yang paling bernilai.
FAQ singkat
Apakah ini berarti AI coding tidak layak dipakai?
Nggak. AI coding sangat layak dipakai untuk eksplorasi, boilerplate, test awal, refactor kecil, dokumentasi, dan debugging terarah. Yang bahaya adalah memakai output AI sebagai kebenaran final tanpa review.
Apakah semua PR dari AI harus direview manual?
Kalau PR itu masuk codebase tim atau production, iya, minimal ada review manusia. Untuk eksperimen lokal, lu bisa lebih santai, tapi tetap pisahkan workspace supaya tidak merusak kerja utama.
Apa metrik yang lebih sehat dari “AI bikin berapa baris kode”?
Pakai metrik seperti task success rate, bug yang lolos, waktu review, rollback rate, incident, dan seberapa banyak perubahan AI yang benar-benar dipakai tanpa rewrite besar.
Penutup
Pelajaran paling penting dari cerita Ford bukan “jangan pakai AI”. Pelajarannya: jangan buang mekanisme review cuma karena tool baru terlihat pintar.
AI bisa mempercepat kerja developer, creator, dan tim produk. Tapi begitu automation menyentuh sistem nyata, lu tetap butuh domain knowledge, test, observability, dan manusia yang berani bilang: “ini kelihatan jalan, tapi belum tentu aman.”
Kalau lu sedang membangun workflow AI, simpan prinsip ini: output AI boleh murah, tapi judgment tetap aset mahal.
