AI Pair Programming dan Skill Gap Junior Developer

Pull request itu cuma tiga baris dan semua tests hijau. Sebuah TypeError di formatter invoice diperbaiki dengan memberi nilai default nol pada field discount, dan seluruh baris di bawahnya kembali ter-render. Saya bertanya kepada junior yang membukanya, kenapa nilai itu bisa undefined sejak awal. Jawabannya datang tanpa rasa canggung, karena baginya itu bukan pengakuan apa-apa: agent yang menyarankannya.

Fix itu kemungkinan besar benar untuk order yang dites, dan justru itu yang membuat topik ini sulit dibicarakan. Tulisan ini soal satu skill yang benar-benar terancam oleh AI pair programming — debugging dari first principles — lima sub-skill penyusunnya, drill yang sekarang saya pakai sebagai ganti menjelaskan fix, dan pertanyaan yang harus diajukan seorang reviewer untuk membedakan fix yang dipelajari dari fix yang dipinjam. Angka adopsi dan trust diambil dari 2025 Stack Overflow Developer Survey; angka self-assessment dari uji acak METR.

Syntax tidak pernah jadi bagian yang sulit

Skill yang terkikis oleh agent bukan syntax. Junior yang lupa urutan argumen di callback reduce tidak pernah benar-benar terhambat karena itu: dokumentasinya hanya sejauh satu tab browser pada 2015, dan kini sejauh satu prompt. Yang dulu dilatih para junior puluhan kali seminggu, tanpa pernah menyebutnya latihan, adalah hal lain sama sekali — loop antara gejala dan penyebab.

Loop itu terlatih secara tidak sengaja, karena dulu memang tidak ada jalan lain melewatinya. Stack trace muncul, dan satu-satunya cara lewat adalah membacanya, menduga, menguji dugaan itu, dan salah beberapa kali sebelum akhirnya benar. Agent menghapus monopoli itu dengan menawarkan jalan kedua, dan jalan kedua lebih cepat untuk hampir setiap bug yang dihadapi satu per satu. Tidak ada yang memilih jalur lambat empat puluh kali seminggu kalau jalur cepat ada di depan mata, dan itulah kenapa ini masalah struktural, bukan masalah disiplin.

Loop debugging punya lima langkah dan agent mengambil tiga

Kalau ditulis lengkap, loop-nya cukup pendek untuk diaudit. Setiap langkah adalah skill terpisah, dan masing-masing meluruh sendiri-sendiri begitu ada yang mengerjakannya untuk kita.

1. Baca stack trace dan cari frame pertama yang merupakan kode kita sendiri, bukan frame tempat nilainya akhirnya membuat sesuatu pecah. Dua hal itu biasanya baris yang berbeda, di repository yang berbeda pula.
2. Sebutkan satu penyebab, dirumuskan supaya run berikutnya bisa membuktikannya salah. Ada yang aneh dengan discount tidak bisa dibantah; query melewatkan join discount untuk order yang dibuat sebelum migrasi pricing bisa.
3. Rancang eksperimen termurah yang memisahkan penyebab itu dari kandidat berikutnya yang paling mungkin — sengaja bukan eksperimen yang membenarkan penyebab favorit kita.
4. Kalau tidak ada hipotesis yang bertahan menghadapi bukti, berhenti menebak dan lakukan bisect: cari satu pengecekan yang gagal saat bug muncul, lalu biarkan tooling memangkas ruang pencarian sampai tersisa satu commit.
5. Sadari momen ketika prediksi Anda dan output berselisih. Inilah langkah yang mengubah apa yang Anda yakini, dan satu-satunya yang tidak bisa dikerjakan orang lain untuk Anda.

Agent dengan senang hati mengerjakan dua langkah pertama, memekanisasi langkah keempat kalau diberi perintah test, dan hampir selalu melewati langkah ketiga — ia menawarkan fix, bukan eksperimen, karena fix itulah yang diminta. Langkah kelima sama sekali tidak bisa ia lakukan, sebab langkah kelima terjadi di dalam kepala yang sudah membuat komitmen. Junior yang langsung lompat ke fix tidak punya komitmen yang tercatat, jadi tidak ada apa pun yang bisa dibantah oleh output.

Membaca stack trace itu keputusan, bukan sekadar memindai

Minta seorang junior yang sudah enam bulan pairing dengan agent untuk membaca stack trace dengan suara keras, dan Anda akan cepat tahu apakah ia pernah benar-benar membacanya. Kegagalan yang umum bukan kebingungan. Kegagalannya adalah membaca baris teratas, mengenali kata-katanya, lalu berhenti di situ.

TypeError: Cannot read properties of undefined (reading 'toFixed')
    at formatCurrency (/srv/app/node_modules/@acme/invoice-kit/dist/format.js:41:28)
    at Array.map (<anonymous>)
    at buildRows (/srv/app/node_modules/@acme/invoice-kit/dist/rows.js:88:19)
    at renderInvoice (/srv/app/src/invoice/render.ts:48:29)   <-- first frame we own
    at handler (/srv/app/src/routes/invoice.ts:22:11)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)

// The stack proceeds from the most recent call to earlier ones (MDN), so:
//   frame 1 = where it threw. Read it to learn what toFixed wanted: a number.
//   frame 4 = the first frame we own. That is where the undefined was handed
//             over, and the only line in this list we are allowed to change.
//
// The three-line fix defaults the field to zero at frame 1's doorstep.
// It turns a loud crash into a silent, wrong invoice: discount 0.00 on every
// order the query forgot to join. Green tests, incorrect PDFs.

Dari ujung mana Anda mulai adalah pilihan yang ada aturannya. Mulai dari atas kalau tipe error-nya sendiri asing, karena frame teratas satu-satunya yang memberi tahu apa yang sebenarnya diminta oleh pemanggilan yang gagal itu. Mulai dari bawah kalau frame-frame teratas semuanya ada di dalam dependency, karena keputusan terakhir program kita sendirilah satu-satunya hal di daftar itu yang boleh kita ubah. Dua kebiasaan ini tidak sulit dipelajari. Dua-duanya juga tidak terlihat kalau fix yang berfungsi sudah datang sebelum stack trace sempat dibaca.

Hipotesis yang tidak bisa dibuktikan salah cuma perasaan

Sepuluh detik paling berharga dalam debugging adalah waktu yang dipakai mengubah kecurigaan menjadi kalimat yang bisa salah. Dua hipotesis yang sama-sama menjelaskan satu gejala menuntut eksperimen yang berbeda, dan eksperimen yang layak dijalankan adalah yang mematikan salah satu hipotesis, bukan yang menyanjungnya.

// H1: discount is undefined because the query omits the join for orders
//     created before the pricing migration.
// H2: discount is undefined because the DTO strips zero-valued fields
//     on serialisation.
//
// Both explain the crash. Neither is worth arguing about, because one line
// at the boundary between them settles it:
console.log(JSON.stringify(rows[0]));
// discount present here  -> H1 is dead, the loss is downstream in the DTO
// discount absent here   -> H2 is dead, the loss is upstream in the query

// When nothing survives contact with the evidence, stop guessing and bisect.
// Any check that exits non-zero on the bug will do:
git bisect start HEAD v3.11.0
git bisect run npm test -- invoice.spec.ts
// About nine checkouts across four hundred commits, and no intuition required.

Bisect adalah disiplin yang sama, tinggal dimekanisasi. Begitu tidak ada hipotesis yang bertahan menghadapi bukti, satu pengecekan yang exit non-zero saat bug muncul membuat git memangkas ruang pencarian berulang kali — sekitar sembilan checkout untuk empat ratus commit, bukan empat ratus kali membaca diff. Junior jarang memakainya, dan bukan karena perintahnya sulit: bisect baru terasa layak disiapkan setelah Anda menerima bahwa intuisi Anda sudah habis, dan menerima hal itu pun sebuah kebiasaan yang harus dilatih.

Drill-nya: prediksi dulu, baru jalankan

Menjelaskan sebuah fix kepada junior mengajarkan jauh lebih sedikit dari yang terasa, karena penjelasan yang jernih enak didengar dan gratis untuk diterima. Pembalikan yang berhasil adalah memaksa mereka berkomitmen pada satu hasil lebih dulu: prediksi, lalu pengamatan, lalu penjelasan atas jarak di antara keduanya. Ini urutan predict-observe-explain yang dipakai dalam pengajaran sains untuk memunculkan miskonsepsi, dan mekanismenya sama persis di dalam terminal — prediksi keliru yang sudah ditulis adalah miskonsepsi yang punya alamat, sehingga output punya sesuatu untuk dikoreksi.

# 1. WRITE THE PREDICTION DOWN. Before running anything, before asking anything.
#    Three lines in a scratch file nobody reviews:
#
#      cause:    renderInvoice passes undefined for orders with no discount row
#      evidence: the first frame we own is render.ts:48, not the library frame
#      test:     log rows[0] at render.ts:47 and expect no discount key

# 2. RUN THE EXPERIMENT YOU JUST WROTE. The experiment, not the fix.
node --enable-source-maps dist/invoice.js 8842 2>&1 | head -20

# 3. NOW bring in the agent. Paste the trace AND the three lines, and ask which
#    of the three is wrong. A prediction gives a model something to correct;
#    a bare stack trace gives it something to guess at.

# 4. Score it out of three: cause, evidence, test.
#    A wrong prediction you wrote down is worth more than a right fix you
#    watched appear. Only the mismatch changes what you believe.

Agent tidak dikeluarkan dari drill ini. Ia dipindahkan. Perannya bergeser dari memproduksi fix menjadi memeriksa prediksi, dan itu pemakaian yang lebih baik dari segala sisi: tempel stack trace berikut tiga baris prediksi Anda, tanyakan baris mana yang salah, dan penjelasan yang datang tertuju pada apa yang benar-benar Anda yakini, bukan pada nilai undefined secara umum. Junior tetap mendapat jawabannya di bawah satu menit. Mereka hanya membayar satu menit komitmen lebih dulu.

Yang benar-benar membaik, dan itu bagian terbesarnya

Tidak satu pun dari ini adalah cerita kemunduran, dan tulisan yang memperlakukannya begitu salah membaca dua tahun terakhir. Junior yang masuk sekarang lebih diuntungkan hampir di semua sisi yang bisa saya amati langsung.

• Mereka merilis sesuatu yang nyata di minggu pertama, bukan bulan pertama, karena scaffolding, config dan boilerplate tidak lagi menghabiskan seluruh masa onboarding.
• Mereka membaca jauh lebih banyak kode asing, karena biaya untuk bertanya apa isi sebuah file empat ratus baris sudah turun mendekati nol.
• Mereka punya penjelas library internals yang selalu tersedia jam dua pagi, tanpa beban sosial harus bertanya hal mendasar ke senior.
• Mereka berani mengambil pekerjaan di atas level mereka dan sering menyelesaikannya, dan memang begitulah sebuah level bergerak naik.

Jadi tujuannya bukan menahan alatnya, yang lagi pula mustahil ditegakkan dan tidak manusiawi. Tujuannya menjaga satu aktivitas sempit tetap manual dengan sengaja: dua atau tiga bug seminggu di mana agent boleh menjelaskan apa saja dan tidak boleh memperbaiki apa pun.

Pemakaian naik, trust turun, dan itu lingkungan yang Anda latih

2025 Stack Overflow Developer Survey mencatat 84% responden sudah memakai atau berencana memakai AI tools dalam proses development mereka, dan 51% developer profesional memakainya setiap hari. Sentimennya bergerak ke arah sebaliknya pada periode yang sama: lebih banyak developer yang justru tidak percaya pada akurasi AI tools, 46%, dibanding yang percaya, 33%, dan sentimen positif turun dari di atas 70% pada 2023 dan 2024 menjadi 60%. Frustrasi yang paling banyak disebut, 66%, adalah solusi yang nyaris benar tapi tidak benar-benar benar. Yang kedua, 45%, adalah debugging kode hasil AI memakan lebih banyak waktu.

Baca angka-angka itu bersamaan dan prioritas pelatihannya berhenti jadi soal selera. Dua pertiga gangguan harian industri ini adalah kelas output yang terlihat benar padahal tidak — persis output yang hanya tertangkap oleh loop verifikasi yang terlatih, dan persis output yang akan di-merge oleh junior yang tidak punya loop itu. Pemakaian naik bersamaan dengan trust turun bukan kontradiksi. Itu deskripsi tempat kerja di mana verifikasi adalah skill yang langka.

Yang harus ditanyakan saat review sekarang

Me-review pull request junior yang dibantu AI berarti menanyakan kenapa, bukan apakah tests-nya lolos. Tests lolos kini properti termurah yang bisa dimiliki sebuah diff — agent akan mengulang sampai lolos, dan nilai default yang ditanam di titik lempar error mencapai hijau lebih cepat daripada fix di penyebabnya. Pada kasus invoice tadi, ia mencapai hijau sambil diam-diam mencetak discount nol pada setiap order yang join-nya terlewat di query, dan itu hasil yang lebih buruk daripada crash yang digantikannya.

Tiga pertanyaan menyelesaikan sebagian besar pekerjaannya, dan tidak satu pun bernada menyerang. Apa dugaan pertama Anda, dan apa yang mematikannya? Frame mana di stack trace itu yang milik kita? Apa yang akan gagal seandainya Anda keliru? Penulis yang benar-benar men-debug masalahnya menjawab ketiganya masing-masing satu kalimat. Penulis yang menerima saran akan tertahan di pertanyaan pertama, dan jeda itulah seluruh sinyalnya — bukan aba-aba untuk menceramahi. Agent yang menyarankannya adalah hal yang sepenuhnya wajar untuk dilakukan; itu baru jadi masalah ketika tidak ada yang menanyakan pertanyaan berikutnya.

Aturan yang saya pegang sekarang cukup sempit untuk benar-benar dijalankan: agent boleh menjelaskan bug apa pun, dan boleh memperbaiki bug yang tidak sedang saya pakai untuk belajar. Untuk dua atau tiga bug seminggu yang sedang saya pakai belajar, prediksinya ditulis lebih dulu — penyebab, bukti, pengecekan yang membantah — dan agent hanya kebagian memeriksanya. Reviewer memegang ujung lain dari aturan yang sama dengan menanyakan apa saja yang sudah disingkirkan, karena fix yang tidak bisa dipertanggungjawabkan siapa pun adalah technical debt yang kebetulan lolos tests.