Sebenarnya komik ini ngomong apa
Alatnya ngerjain persis yang diminta. Test-nya lolos dalam sebelas detik, soalnya test-nya udah nggak ada. Semua yang bikin “lolos” itu ada artinya dikerjain sama dia, dan itu makan sisa minggunya.
Yang pergi cuma ngetiknya. Semua keputusan soal apa yang layak diketik tetap tinggal, dan sekarang malah lebih banyak dari dulu.
Dalam satu jam yang digambar di komik itu, dia ngerjain product management, desain sistem, code review, dan bikin alat. Nggak ada satu pun yang namanya ngoding. Semuanya kerjaan.
Dua mode, dan nyeberangnya
Mode manager nanya: kalau ini kelar, hasil apa yang harus tercapai, apa yang sengaja nggak dikerjain, dan gimana orang tahu. Mode programmer nanya: baris ini udah nanganin kasus kosong belum.
Dua-duanya harus dijawab di jam yang sama, dan yang mahal justru bolak-baliknya. Waktu pindah mode, kepalamu nggak langsung kosong. Cara pikir dari meja sebelumnya masih kebawa, dan itu sebabnya jawaban yang kerasa jelas banget waktu kamu di meja koding sering jadi jawaban yang jelek buat pertanyaan perencanaan.
Nempel seharian di meja koding, hasilnya barang yang salah tapi dikerjain rapi. Nempel seharian di tembok rencana, kamu nyerahin sesuatu yang bisa ditafsirkan enam cara, terus yang balik ke kamu tafsiran kelima, dengan kecepatan penuh.
Konteks itu bukan prompt
Baris yang dia ketik Selasa pagi isinya: test nggak boleh dihapus. Nggak ada yang pernah nulis itu, soalnya sampai hari Selasa belum ada yang perlu. Itu arti “konteks” yang sebenarnya: batasan, konvensi yang udah dipakai di codebase ini, dua contoh hasil yang bagus, daftar hal yang nggak boleh dilakuin, dan alasannya masing-masing.
Ada apa nggaknya penting. Taruhnya di mana juga penting. Language model lebih banyak makai bagian awal sama akhir dari input yang panjang, dan bagian tengahnya kelewat. Ini kejadian juga di model yang memang dibikin buat konteks panjang.2 Empat puluh halaman yang ditumpahin gitu aja hasilnya beda dari empat puluh halaman yang diurutin, batasannya ditaruh paling atas.
Ada satu kalimat yang gampang kelewat di studi keamanan Stanford, dan isinya bilang hal yang sama dari arah sebaliknya. Peserta yang paling nggak percaya sama asistennya, dan yang paling banyak mikir sebelum nulis permintaannya, kodenya paling sedikit celah keamanannya.1 Yang jadi variabel itu input-nya.
Guardrail, soalnya dia nggak inget kemarin
Dia nggak bakal ngehapus test yang itu lagi. Dia bakal nyari cara lain buat ngilangin yang merah, dan itu sebabnya yang dijaga jumlah test-nya secara keseluruhan.
Kamu lagi ngarahin pekerja yang cepat, nggak capek, pede, dan nggak inget sama sekali kesalahan yang dia bikin kemarin. Dikasih tahu sekali, besok dia lupa lagi.
Jadi koreksinya harus tinggal di sistemnya, biar yang inget sistemnya. Satu type. Satu test. Satu aturan lint yang bikin build-nya gagal. Satu schema yang harus dipenuhi output-nya. Satu gate di CI. Masing-masing nyimpen satu koreksi yang cukup kamu bikin sekali.
Studi Stanford yang sama nunjukin kenapa sikap hati-hati aja nggak cukup. Peserta yang pakai AI assistant nulis kode yang jauh lebih rawan dibanding yang nggak pakai, dan mereka lebih yakin kodenya aman.1 Rasa yakin sama kenyataan udah pisah jalan di situ. Guardrail nggak peduli orangnya ngerasa gimana.
Loop yang jagain standarmu waktu kamu nggak ada
“Kayaknya udah bener” masih jalan buat lima output. Sekitar lima ratus, dia berhenti jalan.
Enam belas maintainer berpengalaman, kerja di repo yang mereka kenal luar dalam, ternyata 19 persen lebih lambat pakai AI, dan pulang dengan keyakinan mereka 20 persen lebih cepat.3 Penilaianmu atas kerjaan sendiri bisa meleset 39 poin. Harus ada sesuatu di luar kepalamu yang megang garisnya.
Kegagalan yang merayap pelan ini baru kelihatan waktu datanya dilihat sekaligus. Dari 623 juta perubahan kode sepanjang 2023 sampai 2026, blok kode yang dobel naik 81 persen dan baris yang dipindah buat refactor turun 70 persen.4 Gejalanya nggak kelihatan di diff yang kamu buka hari Selasa. Baru enam bulan kemudian kelihatan di codebase yang sama.
Makanya kamu simpen satu set contoh, jalanin tiap kali, dan perlakukan itu sebagai definisi standarmu, setara sama kodenya. Eval itu berguna karena dia jalan waktu kamu nggak di ruangan, dan nggak pernah capek jadi galak.
Ini kerjaan yang beda, dan nggak semua orang mau
Beberapa programmer paling jago yang saya kenal justru lebih payah di kerjaan ini dibanding programmer biasa yang kebetulan rajin nulis dan tegas megang standar.
Yang laku sekarang: nulis spesifikasi yang bisa diikutin orang lain, ngebayangin enam cara hasilnya bisa gagal sebelum satu baris pun ada, dan bikin alat pengecek daripada ngecek sendiri. Itu keahlian beneran, dan itu bukan keahlian yang bikin kebanyakan orang keterima kerja dulu.
Wajar kalau nggak suka sama perubahannya. Mahal kalau pura-pura nggak kejadian.
Yang nggak saya klaim
Kemampuan ngoding tetap penting di sini, malah lebih penting. Kamu nggak bisa me-review yang nggak bisa kamu baca, dan tiap keputusan di komik itu berdiri di atas fakta bahwa dia udah nulis banyak kode sendiri.
Saya juga nggak bilang kerjaan ini lebih susah dari yang dulu. Bentuknya beda, dan beratnya numpuk di depan, sebelum ada barang yang kelihatan.
Dan nggak semua software butuh semua ini. Script, alat sekali pakai, prototype yang bakal kamu hapus hari Jumat: ketik, kirim, lanjut. Klaim saya lebih sempit. Buat software yang dipakai orang lain, “ini AI yang nulis” itu titik mulainya kerjaan.