AI bisa ngasih jawaban cepat. Masalahnya: siapa yang cukup paham buat tahu jawaban itu benar?
Artikel ini ngebahas kenapa skill developer tidak jadi murah hanya karena coding agent makin pintar. Justru saat automation makin gampang dipakai, skill verifikasi, debugging, dan memahami sistem jadi makin mahal. Buat developer yang mulai pakai AI harian, poin utamanya bukan “jangan pakai AI”, tapi jangan sampai lu mengotomasi pekerjaan yang belum lu pahami sama sekali.
Apa itu Automation Without Understanding?
Automation without understanding adalah kondisi ketika proses kerja bisa dijalankan otomatis, tapi manusia yang memakai hasilnya tidak lagi punya kapasitas cukup buat memahami, mengecek, dan menantang output tersebut.
Istilah ini gua ambil dari esai arXiv “Automation Without Understanding” karya Jun-Yong Park. Konteks tulisannya adalah matematika: AI mulai bisa menghasilkan pekerjaan level riset, sementara pipeline manusia yang bisa memahami pekerjaan itu justru melemah. Ini bukan cuma isu akademik. Di software development, pola yang sama mulai terasa: coding agent bisa menulis kode, tapi tim tetap butuh orang yang ngerti sistem, constraint, test, dan failure mode.
Kalau tidak, automation berubah dari leverage jadi risk multiplier. Output makin banyak, tapi kapasitas review tidak ikut naik.
Kenapa ini relevan buat developer?
Developer sekarang hidup di fase yang aneh. Lu bisa buka coding agent, minta bikin fitur, refactor file, generate test, bahkan baca error log panjang. Banyak pekerjaan yang dulu makan waktu bisa dipercepat.
Tapi ada tradeoff yang sering tidak dibahas: AI membuat biaya menghasilkan solusi turun, sementara biaya membuktikan solusi itu benar tetap tinggi.
Contoh sederhana: agent bisa bikin middleware auth dalam beberapa menit. Secara visual kodenya rapi. Nama variabelnya bagus. Test happy path lewat. Tapi kalau lu tidak paham session, cookie, CSRF, token expiry, permission boundary, dan threat model, lu bisa saja merge kode yang “kelihatan benar” tapi bolong di bagian paling mahal.
Masalahnya bukan AI-nya bodoh. Masalahnya, sistem software jarang gagal di bagian yang terlihat dari prompt pertama. Dia gagal di edge case, state lama, data buruk, race condition, migration aneh, permission yang bocor, atau asumsi yang tidak pernah ditulis.
Skill developer bergeser, bukan hilang
Gua tidak percaya narasi “developer tidak perlu paham coding lagi”. Yang lebih masuk akal: sebagian skill bergeser.
Dulu banyak energi developer habis buat ngetik implementasi manual. Sekarang sebagian implementasi bisa dibantu AI. Tapi skill yang naik nilainya adalah skill yang membuat output AI aman dipakai:
- Membaca kode dengan skeptis, bukan cuma lihat apakah build lulus.
- Menulis test yang benar-benar menjaga behavior, bukan test kosmetik yang cuma mengejar coverage.
- Memahami domain, karena AI tidak selalu tahu aturan bisnis yang tidak tertulis.
- Menentukan risk boundary: mana yang boleh di-vibe-code, mana yang wajib review ketat.
- Melihat failure mode: apa yang terjadi kalau API timeout, data kosong, user tidak punya izin, atau job jalan dua kali.
Ini juga nyambung dengan tulisan Doug Turnbull tentang “Why write code in 2026”. Ia memosisikan engineer bukan cuma sebagai penulis kode, tapi pembangun software factory: tests, linting, type system, eval, dokumentasi repo, knowledge base, dan guardrail yang bikin agent bisa bekerja lebih aman.
Dengan kata lain, prompt bukan pengganti engineering discipline. Prompt hanya interface. Factory-nya tetap harus dibangun.
Jangan outsource pemahaman ke autocomplete
AI paling berbahaya saat jawabannya terdengar masuk akal di area yang belum lu pahami.
Kalau lu minta AI menjelaskan topik yang sudah lu kuasai, lu bisa cepat melihat bagian yang salah. Kalau lu minta AI membuat sesuatu di area yang benar-benar gelap buat lu, output yang salah bisa tetap terasa meyakinkan. Di sinilah automation without understanding mulai bahaya.
Rich Sutton pernah menulis tentang “One-Step Trap” di riset AI: model satu-langkah yang tidak sempurna bisa menghasilkan prediksi jangka panjang yang makin melenceng saat di-roll out terus. Analogi buat developer: keputusan kecil yang tidak diverifikasi bisa menumpuk jadi desain yang salah, terutama kalau agent dibiarkan lanjut mengerjakan layer berikutnya di atas asumsi awal yang rapuh.
Lu mungkin tidak melihat bug di file pertama. Tapi bug itu bisa jadi fondasi buat lima file berikutnya.
Checklist praktis sebelum merge kode AI
Kalau lu pakai coding agent, coba pakai checklist ini sebelum merge:
- Jelaskan ulang perubahan dengan bahasa sendiri. Kalau lu tidak bisa menjelaskan, jangan merge dulu.
- Cek file yang disentuh agent. Apakah scope-nya wajar, atau dia muter terlalu jauh?
- Cari asumsi yang tidak tertulis. Misalnya permission, format data, timezone, retry, dan concurrency.
- Tambah test untuk failure path. Jangan cuma test kasus ideal.
- Run command verifikasi manual. Build, lint, test, migration dry run, atau request lokal jika relevan.
- Bandingkan dengan desain awal. Apakah agent menyelesaikan problem, atau malah bikin abstraction baru yang tidak perlu?
- Tentukan rollback plan. Kalau ini menyentuh auth, payment, database, atau data user, lu butuh jalur mundur.
Checklist ini tidak bikin workflow jadi anti-AI. Justru ini bikin AI lebih kepakai karena output-nya masuk ke jalur engineering yang bisa dipercaya.
Apa yang sebaiknya dipelajari developer pemula?
Kalau lu developer pemula, jangan cuma belajar “prompt yang bagus”. Prompt memang berguna, tapi fondasinya tetap hal-hal boring yang membuat lu bisa mengecek output AI.
Prioritas yang menurut gua lebih tahan lama:
- Debugging: baca stack trace, isolasi bug, bikin reproduksi kecil.
- Testing: bedakan unit test, integration test, dan test yang benar-benar menjaga behavior.
- HTTP dan database: karena banyak aplikasi tetap rusak di request, state, dan query.
- Security dasar: auth, authorization, secrets, input validation, dan dependency risk.
- Git workflow: review diff, revert, bisect, dan pisah eksperimen dari branch utama.
- System design kecil: retry, idempotency, queue, cache, timeout, dan observability.
AI bisa bantu lu belajar semua itu lebih cepat. Tapi jangan biarkan AI mengambil alih bagian memahami. Kalau yang lu latih cuma cara meminta jawaban, lu akan lemah saat jawabannya salah.
Takeaway
Automation bagus kalau manusia masih punya kapasitas buat memahami dan memverifikasi hasilnya. Kalau tidak, output cepat hanya memindahkan masalah dari “lama membuat” menjadi “susah dipercaya”.
AI agent akan makin bagus. Tooling akan makin murah. Tapi developer yang bisa membaca sistem, menemukan asumsi, menulis guardrail, dan bilang “ini belum aman buat merge” justru makin penting.
Jadi, pakai AI. Eksperimen. Bikin workflow lebih cepat. Tapi jangan outsource pemahaman lu. Di era output murah, skill yang mahal adalah tahu mana output yang layak dipercaya.
FAQ mini
Apakah ini berarti developer pemula jangan pakai AI?
Bukan. Developer pemula boleh pakai AI, tapi gunakan AI buat belajar dan mempercepat feedback, bukan buat melewati pemahaman dasar. Minta AI jelaskan tradeoff, bikin contoh kecil, dan bantu debugging, lalu tetap verifikasi sendiri.
Apa bedanya AI sebagai leverage dan AI sebagai risiko?
AI jadi leverage saat lu punya tujuan jelas, test, constraint, dan review. AI jadi risiko saat lu menerima output karena terlihat rapi, padahal lu tidak paham asumsi dan failure mode-nya.
Skill apa yang paling penting di era coding agent?
Menurut gua: verifikasi. Ini gabungan dari debugging, testing, domain knowledge, security sense, dan kemampuan membaca diff dengan skeptis.
