Posts

Kode Lu Makin Cepat, Otak Lu Makin Meleset: Fakta dari Data AI Coding 2026

September 26, 2026
"AI bikin lu produksi 10 kali lebih banyak. Yang gak dia kasih tau: otak lu yang tadi jalan, lagi dimatikan pelan-pelan."
Dulu, belajar ngoding itu ritual: baca dokumentasi, ketik sendiri, error, pusing, benerin sendiri, akhirnya ngerti. Sekarang? Lu ketik prompt, kode muncul dalam 8 detik, lu bilang "mantap", commit. Enak? Enak. Produktif? Iya. Tapi ada yang bayar: skill lu. Gue baru baca beberapa riset 2026 soal ini, dan jujur, ini bikin gue mikir keras. Gue yakin banyak pemula belum baca datanya.
Januari 2026, Anthropic nge-publish randomized controlled trial — bukan survey, bukan opini influencer, tapi eksperimen beneran. Subjeknya developer yang lagi belajar library Python baru. Dua kelompok. Satu boleh pakai AI assistance. Satu nulis kode sendiri. | Kelompok | Skor kuis pemahaman | |----------|---------------------| | Coding manual (tanpa AI) | Baseline | | Pakai AI assistance | 17% lebih rendah | 17% itu kalo diterjemahin ke rapor, hampir dua nilai huruf. Dan kuisnya nanyain konsep yang baru mereka pakai beberapa menit sebelumnya — bukan teori semester lalu yang wajar kalo lupa. Yang lebih nyesek: waktunya hampir sama. Kelompok AI keluar sedikit lebih cepat, tapi selisihnya gak signifikan secara statistik. Jadi lu bayar pakai pemahaman. Balasannya? Beberapa menit doang.
Insight: AI sering ngasih lu ilusi efisiensi, bukan efisiensi beneran. Lu ngerasa cepat karena hasilnya instan — tapi yang lu tebus itu otak lu sendiri.
Anthropic juga ngelihat gimana orangnya interaksi sama AI. Kelompok yang nilainya jelek punya pola:
  1. Minta kode dulu, pahami belakangan (atau gak paham sama sekali)
  2. Minta AI yang debug, bukan nyelidik sendiri
  3. Accept, accept, accept — autopilot penuh dari awal sampai akhir
  4. Gak pernah nanya "kenapa solusi ini bisa jalan?"
Kelompok yang nilainya bagus pakai pola beda: nyoba sendiri dulu → stuck → baru minta AI → verifikasi hasilnya → jelasin ulang dengan kalimat sendiri.
Pola kedua bukan berarti "AI itu salah". Pola kedua berarti AI dipakai di posisi yang bener: sebagai tutor dan second opinion, bukan sebagai pengganti otak lu.

Riset kedua datang dari kerjaan yang dipublikasikan lewat NBER, dengan data lebih dari 100.000 developer GitHub — pemakaiannya dilacak dari telemetry asli, bukan ngandelin jawaban survey. Angkanya: | Generasi tool | Kenaikan commit | Kenaikan release | |---------------|-----------------|------------------| | Autocomplete | +40% | — | | Agent interaktif | +140% | — | | Agent otonom | +180% | +30% | Liat polanya. Commit naik 6 kali lebih besar daripada release. Artinya: jauh lebih banyak kerjaan yang dimulai daripada yang beneran nyampe ke user.
Insight: Commit itu output. Release itu hasil. AI optimisasi output, bukan hasil. Kalo lu cuma ngukur jumlah commit, lu ngukur aktivitas, bukan kontribusi.
Karena agent itu objektifnya jelas dan dangkal: hasilkan banyak perubahan, cepat, selesai. Agent gak punya:
  • Tanggung jawab kalo ada bug di production jam 2 pagi
  • Taste buat mutusin mana fitur yang layak rilis
  • Context soal user yang beneran nunggu
  • Rasa malu waktu kodenya hancur
Perusahaan yang cuma ngukur velocity commit bakal senyum di dashboard. User-nya? Beda cerita.
MIT Media Lab nge-publish hasil yang lebih nyeremin lagi: makin sering lu mindahin kerjaan mikir ke AI, makin lemah kemampuan mikir lu sendiri saat lu butuh. Bagian paling bengis: efeknya gak kelihatan waktu terjadi. Lu ngerasa produktif. Yang turun ada di belakang, dan baru kerasa pas lu butuh skill itu sendiri — di interview, di depan error production, pas internet mati dan AI-nya gak ada. Dan justru di titik itulah kemampuan lu diuji. Karena:
  • Interview tes lu ngerjain sendiri
  • Production — AI salah, lu yang di-hold accountable
  • Skill yang gak pernah dibangun gak bisa dipinjam mendadak

Solusinya bukan "buang AI" — itu reaksi emosional, bukan strategi. Solusinya: ubah posisinya. AI tetap lu pakai buat hal yang bikin cepat tapi gak nentuin skill: boilerplate, scaffolding, draft dokumentasi, konfigurasi CI/CD, nyari kemungkinan lokasi bug. AI lu stop atau tahan buat hal yang bikin skill lu: konsep baru, debugging yang bikin pusing, arsitektur, dan semua kode yang bakal lu jelasin di depan orang. Gue bagi semua kerjaan jadi tiga zona: Zona MERAH — AI dilarang total
  • Konsep baru yang belum pernah lu pakai sama sekali
  • Debugging bug yang belum lu pahami akarnya
  • Semua kode yang bakal lu pakai saat interview
  • Latihan dasar: loop, array, function, struktur data
Zona KUNING — AI boleh, wajib diverifikasi
  • Boilerplate, CRUD, setup config
  • Bikin test untuk kode yang sudah lu pahami
  • Refactor yang sifatnya mekanis
  • "Tulis test buat fungsi ini" — lalu baca test-nya dan pastikan dia ngetes hal yang benar
Zona HIJAU — AI wajib, lepas kendali
  • Scaffold project, bikin puluhan file awal
  • Config CI/CD dari template
  • Cari kandidat masalah: "di mana ada potensi null reference di file ini?"
  • Dokumentasi, release notes, commit message
Tes cepatnya: kalo lu mau bisa jawab pertanyaan "kenapa" tanpa buka AI → zona kuning atau hijau. Kalo jawabannya "ntah deh, AI yang tau" → zona merah.
Gue punya aturan pribadi yang simpel dan gak enak:
Waktunya lu harus bisa jelasin 100% kode lu tanpa buka AI. Kalo belum bisa, itu bukan kode lu — itu utang.
Konkret di terminal, tiap selesai satu fitur sebelum commit:
git diff HEAD~1 --stat
Terus baca diff-nya baris per baris. Bagian yang lu gak bisa jelasin, tandai:
// TODO: kenapa ini pakai optional chaining? gue belum ngerti
Terus beresin minggu ini juga. Gak ribet, tapi efeknya gede — karena pas lu dipaksa jelasin, otak lu beneran nyerap, bukan cuma nge-scroll. Bonus yang gue suka: tiap minggu, tulis ulang manual satu bagian kecil. Lu udah pakai AI bikin satu route Next.js? Bangun ulang bagian yang sama pake tangan sendiri, 30 menit. Gak ada yang ngeliat, gak ada yang dinilai — tapi otaknya ngolah beda.
Data di atas bukan ajakan berhenti AI. Ini ajakan ngerti: skill yang paling mahal bukan ngetik kode cepat. Yang mahal:
  1. Menerjemahkan requirement yang ambigu — client bilang "bikin yang bagus", lu yang ubah jadi keputusan teknis
  2. Ngeh kapan AI salah — ngecek, bukan nge-paste
  3. Debugging sistem di production — bukan syntax error, tapi "kenapa latency naik 3x setelah deploy"
  4. Judgment soal trade-off — Zod atau Yup? REST atau tRPC? monolith atau microservice? AI ngasih opsi, lu yang milih
Empat hal itu gak bisa di-otomatisasi pake autocomplete. Dan justru itu yang diuji di interview dan di kerjaan beneran.
Fakta pahit: portofolio lu bisa aja di-generate AI dalam semalam. Tapi jawaban lu waktu ditanya "jelasin kode ini" — itu yang gak bisa di-generate. Dan di pasar kerja yang sesak, itu bedanya.

  • [ ] Kerjaan lu hari ini masuk zona merah, kuning, atau hijau?
  • [ ] Kode yang lu commit minggu ini — bisa lu jelasin semuanya tanpa AI?
  • [ ] Ada konsep yang lu ngerasa "udah ngerti" tapi sebenarnya cuma lu accept dari AI?
  • [ ] Beresin TODO yang lu tulis minggu lalu
  • [ ] Minggu depan, jadwalin satu task yang wajib dikerjakan manual

Jawabannya: tergantung cara lu megang AI-nya, bukan AI-nya. AI itu alat. Kalo lu yang pegang, lu produksi jauh lebih banyak dari yang bisa lu sendiri. Kalo lu yang disandera, lu dapat output 10x dan skill 0,7x. Gue percaya 2027 yang dicari bukan programmer paling cepat ngetik kode. Yang dicari programmer yang paling jelas mikirnya — dan itu dibangun, sama kayak dulu, cuma sekarang harganya lebih mahal karena godaannya jauh lebih besar. Jadi: minggu depan, satu task manual, satu TODO ditulis, satu diff dibaca pelan-pelan. Sisanya? Pakai AI sepuasnya.
Pernah ngerasa "kode gue jalan tapi gue gak ngerti kenapa"? Drop cerita di komentar — gue penasaran berapa banyak yang ngerasa sama. Gak ada yang dihakimi di sini. 😊
Mau workflow belajar yang seimbang antara AI dan fundamental? Cek tentang saya — gue share stack, setup, dan resource yang gue pakai sehari-hari.
Referensi: