Dua dekade kita mengukur nilai seorang developer dari seberapa cepat ia mengubah ide menjadi kode yang berjalan. Ukuran itu baru saja berhenti relevan.
Kalau kamu memakai asisten AI hari ini, kamu tahu rasanya: kode muncul dalam hitungan menit, tapi verifikasi, integrasi, dan tanggung jawab atas apa yang ditulis mesin menghabiskan sisa hari. Di tim dengan adopsi AI tinggi, waktu review pull request tumbuh hampir 91%, data Faros AI dari lebih dari 10.000 developer dan 1.255 tim.
Lihat developer yang sama, dua hari kerja. Tahun 2019: delapan jam di editor, debug baris per baris, boilerplate bermil-mil. Hari ini: satu jam menulis spesifikasi, tiga instance agent berjalan di latar belakang, sisa hari membaca dan menyetujui hasilnya.
Itu bukan pekerjaan yang lebih sedikit. Itu pekerjaan yang berbeda, dan pekerjaan baru itu punya aturan main sendiri.
Inti Perubahannya: Bottleneck Berpindah
Dalam era spec-driven development, hambatan utama bukan lagi menulis kode. Hambatannya ada di mendefinisikan niat dan memverifikasi hasilnya.
Artinya bukan coding akan mati. Artinya nilai kamu berpindah dari seberapa cepat kamu mengetik menjadi seberapa presisi kamu bisa menyatakan apa yang kamu mau, dan seberapa ketat kamu memeriksa apakah kamu benar-benar mendapatkannya.
Analogi yang paling saya suka: kamu berhenti menjadi tukang yang menyusun bata dengan tangan, lalu menjadi arsitek yang mengawasi pembangunan. Kamu menghasilkan cetak biru (spesifikasinya) memesan pengerjaan ke tim agent AI, lalu menandatangani berita acara teknisnya. Kode adalah salah satu kemungkinan realisasi desain, bukan desainnya itu sendiri.
Jebakannya ada di satu kalimat: "semua test lulus" tidak sama dengan "sesuai dengan niat saya". Menjaga selisih di antara keduanya adalah pekerjaan baru yang lebih sulit.
Kalau kamu menghemat satu jam untuk menghasilkan kode tapi tidak tahu cara memverifikasi bahwa kode itu melakukan persis apa yang kamu maksud, kamu belum menghemat waktu. Kamu hanya menundanya menjadi utang tak terlihat yang akan kembali dengan bunga.
Peran Lama vs Peran Baru
Titik berat pekerjaan bergeser dari menerjemahkan logika ke kode menjadi merumuskan niat. Ini pergeseran yang bisa diamati, bukan slogan pemasaran vendor tooling. Sampai baru-baru ini, biaya utama rekayasa perangkat lunak adalah proses mengubah logika bisnis menjadi sintaks. Model frontier mengubah itu: draft pertama kode menjadi murah, dan nilainya pindah ke tempat lain.
Di susunan baru, kamu masuk ke peran penulis niat, peran yang keluaran utamanya adalah spesifikasi yang presisi dan bisa dibaca mesin, bukan kode. Kamu menulis spesifikasinya; AI yang menghasilkan dan mengimplementasikan kodenya.
Varian paling radikal dari ini sering disebut spec-as-source: kamu hanya menyunting spesifikasi, dan kode hasilnya ditandai "jangan diedit manual". Sebagian besar tim berada di antara spec-first dan ujung ekstrem itu.
Di bawah semua itu ada satu pergeseran filosofis yang layak disebut langsung. Bertahun-tahun asumsinya adalah "kode adalah sumber kebenaran" (kode satu-satunya deskripsi yang bisa dipercaya tentang apa yang benar-benar dilakukan sistem. Spec-driven development membalik hierarki itu: niat menjadi sumber kebenaran, dan kode adalah artefak hasilnya. Spesifikasi yang baik mulai berfungsi sebagai kontrak) ia mendefinisikan apa arti "benar" sebelum apa pun dibangun.
Skalanya bukan lagi ceruk. Porsi kode yang ditulis bersama AI tumbuh dari beberapa persen pada 2023 menjadi puluhan persen hari ini, dan lebih dari separuh engineer profesional melaporkan memakai alat AI setiap hari. Ini bukan masa depan yang sedang kita renungkan, tapi masa kini yang sudah kita kerjakan.
Sean Grove dari OpenAI menangkap pergeseran ini paling tajam: menulis kode itu sendiri kira-kira 10–20% dari nilai yang dibawa seorang engineer, sementara 80–90% sisanya adalah "komunikasi terstruktur", artikulasi niat yang tertata. Proporsi angkanya bisa diperdebatkan. Arahnya sulit dibantah: kode yang lebih sedikit bukan berarti kerja yang lebih sedikit, melainkan kerja yang berbeda, dengan niat sebagai intinya.
Skill yang Baru Naik Nilainya
Polirisasi kompetensi itu nyata. Ini bukan "akhir dari coding", melainkan pergeseran premi ke skill yang lebih sulit diotomasi. Kent Beck merumuskannya dengan tajam: sembilan puluh persen skill-nya kehilangan nilai, dan sepuluh persennya naik seribu kali lipat. Itu sengaja dibesar-besarkan, tapi asimetrinya terasa.
Yang naik:
- Berpikir arsitektural: merancang batas sistem dan mengambil keputusan yang tidak akan diambil agent untukmu.
- Presisi kebutuhan: kemampuan menerjemahkan "pokoknya jalan" menjadi spesifikasi yang tidak ambigu dan bisa diuji.
- Verifikasi dan judgment, yang oleh Beck disebut "taste", kemampuan menilai apakah hasilnya benar-benar bagus, bukan cuma benar secara teknis.
- Context engineering: memberi agent konteks yang tepat pada saat yang tepat.
- Orkestrasi agent: mengoordinasikan beberapa instance paralel yang mengerjakan bagian berbeda dari satu tugas.
Yang paling tidak jelas adalah context engineering, jadi layak dibongkar. Secara intuitif: kualitas agent hanya sebaik konteks yang kamu berikan. Secara mekanis: kamu menyuplai spesifikasi, batasan, contoh, dan potongan sistem yang relevan (dalam urutan dan jumlah yang tepat) supaya model bernalar dari bahan yang benar. Tanpa itu, agent menyerahkan huruf dari prompt, bukan niatmu. Di situlah lahir sebagian besar bug yang kamu temukan saat review.
Yang turun adalah yang bertahun-tahun jadi makanan sehari-hari: menulis boilerplate, menerjemahkan kebutuhan ke kode secara manual, debug baris per baris, menghafal sintaks dan API. Bukan berarti pengetahuan itu jadi tak berguna, tanpa itu kamu tidak bisa menilai keluaran agent. Hanya saja, kefasihan mengetiknya bukan lagi keunggulan kompetitif.
Satu aturan yang saya ulang ke tim: jangan commit kode yang tidak bisa kamu jelaskan. Kedengarannya klise sampai kamu melihat betapa mudahnya menyetujui tiga ratus baris yang "kelihatan oke" dan lolos test.
Yang Tetap, yang Hilang, dan Jebakan yang Jarang Dibahas
Bottleneck-nya tidak hilang, hanya berpindah ke verifikasi. Saat produksi kode melonjak dari ratusan ke ribuan baris per hari, menulis bukan lagi batasannya, review, integrasi, dan akuntabilitas yang jadi batasan. Simon Willison menyebutnya dengan pas: seluruh siklus hidup perangkat lunak dirancang dengan asumsi bahwa menghasilkan beberapa ratus baris kode butuh sehari, dan sekarang tidak lagi.
Praktiknya kembali ke satu aturan brutal: siapa pun yang menekan "merge", dialah pemilik tanggung jawabnya. Kamu tidak bisa memanggil mesin untuk mempertanggungjawabkan outage. Jadi semakin banyak kode yang dihasilkan AI, semakin mahal nilai hal yang tidak bisa dilakukannya: menanggung konsekuensinya.
Pertanyaan berikutnya yang semua orang ingin dijawab sederhana: apakah AI benar-benar mempercepat kita? Datanya terlihat bertentangan sampai kita melihat kondisinya.
| Kondisi | Temuan | Sumber |
|---|---|---|
| Tugas baru dan sederhana (greenfield) | Jauh lebih cepat dengan asisten | Peng et al., n=95 (arXiv.06590) |
| Eksperimen lapangan skala besar | Pull request yang di-merge naik sekitar 26% | Studi lapangan, ~5.000 developer |
| Repo besar milik sendiri (brownfield) | 19% lebih lambat, meski developer merasa 20% lebih cepat | METR, n=16 (belakangan direvisi karena galat pemilihan sampel) |
| Persepsi kualitas | 76% developer melaporkan halusinasi sering dan kepercayaan rendah | Qodo, State of AI Code Quality 2025 |
Angka tanpa konteks menyesatkan. AI mempercepat tugas sederhana dan proyek baru, tapi bisa memperlambat sistem besar yang sudah berjalan bagi engineer berpengalaman. Itu kondisi yang berbeda dengan hasil yang berbeda, bukan kondisi sama dengan hasil bertolak belakang.
Yang lebih menarik adalah paradoks kepercayaan: AI ikut menulis porsi signifikan kode produksi, sementara 76% developer melaporkan halusinasi sering dan kepercayaan rendah pada kode AI. Jarak antara besarnya delegasi dan rendahnya kepercayaan itulah tempat lahirnya utang verifikasi, biaya tersembunyi ketika waktu yang dihemat untuk menulis kembali sebagai audit melelahkan atas pekerjaan orang lain.
Ada satu keyakinan saya dua tahun lalu yang ternyata salah. Saya pikir "spesifikasi adalah kode yang baru", bahwa belajar menulis spesifikasi bagus akan melarutkan masalahnya. Itu ternyata sebagian salah. Bahkan salah satu pendukung paling lantang pendekatan berbasis spesifikasi, Guy Podjarny, menggeser narasinya dari "spec" ke "context" (podcast Tessl, episode 101). Bahasa alami terlalu ambigu untuk sepenuhnya menggantikan presisi formal, dan model generasi berikutnya tidak akan memperbaikinya, karena itu sifat bahasa, bukan sifat model.
Kegagalan yang biayanya tidak pernah dianggarkan biasanya seragam bentuknya: kode hasil AI masuk produksi tanpa review engineer berpengalaman, dan beberapa jam kemudian ada yang menghitung kerugian. Kesimpulan praktisnya bukan menolak AI, melainkan merancang prosesnya dengan waktu verifikasi sudah diperhitungkan sejak awal.
Menyiapkan Diri dan Tim
Keberhasilan tidak bergantung pada apakah kamu memasang tool-nya, tapi pada apakah anggota tim menjadi integrator aktif alih-alih delegator pasif. Itu tugas seorang pemimpin, bukan tugas konfigurasi. Kamu bisa mewajibkan penggunaan AI. Kamu tidak bisa mewajibkan kepercayaan atau judgment.
Di level individu, semuanya bermuara pada satu keputusan: apakah kamu memperlakukan agent sebagai partner berpikir, atau sebagai generator yang kamu setujui? Sebuah studi percontohan Shen dan Tamkin (Anthropic, 2026) dengan sekitar lima puluh peserta yang mempelajari library baru menunjukkan bahwa developer yang memakai AI untuk menyelidiki "mengapa" mendapat skor pemahaman jauh lebih baik daripada mereka yang pasif menekan "accept". Penggunaan aktif membangun pemahaman; delegasi pasif menggerusnya.
Di level tim, ada beberapa tuas konkret yang layak dipakai sengaja:
- Kebijakan penggunaan AI yang eksplisit: di mana delegasi otonom diizinkan, di mana review manusia diwajibkan.
- Review wajib untuk kode kritis dan keamanan: bukan tempat untuk auto-accept.
- Batch kecil dan umpan balik cepat: supaya kesalahan agent tertangkap sebelum menyebar.
- Menilai kualitas spesifikasi, bukan jumlah baris: ukur apa yang sekarang benar-benar jadi bottleneck.
- Hari tanpa AI secara berkala: supaya kemampuan inti tidak berkarat.
Ada satu jebakan yang bahkan tim terkelola baik bisa terperosok: mandat "pakai AI" dari atas yang dijatuhkan tanpa perancah budaya bisa lebih merugikan daripada menguntungkan. Riset Cat Hicks tentang AI Skill Threat (tekanan dan ketidakpastian identitas profesional menghadapi AI) menunjukkan fenomena ini menyentuh 43–45% engineer (studi pada lebih dari 3.200 developer). Budaya belajar dan rasa memiliki menurunkan ancaman itu, sementara tekanan berbasis kompetisi dan "bakat bawaan" malah memperbesarnya. Pemimpin yang membangun budaya belajar menurunkan resistensi; yang hanya menekan menaikkannya.
Artinya untuk Karier
"In times of change, learners inherit the earth, while the learned find themselves beautifully equipped to deal with a world that no longer exists." , eric Hoffer, Reflections on the Human Condition (1973)
Pasar sedang terpolarisasi, dan bar-nya naik, bukan turun. Jumlah peran junior sederhana di perusahaan dengan adopsi AI tinggi menyusut, sementara premi upah untuk kompetensi AI dan arsitektur tumbuh. Pada saat yang sama, sebagian prakiraan menunjukkan lapangan kerja industri ini tetap tumbuh. Keduanya benar sekaligus, tergantung lapisan pasar mana yang kamu lihat.
Biaya psikologisnya nyata, dan itu bukan tanda kelemahan. Berpindah dari peran pencipta yang "memegang kode di tangan dan membentuknya seperti tanah liat" ke peran peninjau pekerjaan orang lain menyerang identitas yang dibangun di atas craft. Kecemasan soal peran sendiri adalah respons normal terhadap perubahan nyata, bukan alasan untuk malu.
Sejarah memberi pemeriksaan realitas yang cukup kuat. Setiap lapisan abstraksi dalam pemrograman lahir dengan ramalan yang sama (bahwa ia akan menghapus peran developer) dan setiap kali ramalan itu salah. Compiler diramalkan membuat analis bisnis menulis programnya sendiri tanpa spesialis. Bahasa generasi keempat dan alat CASE menjanjikan aplikasi yang dihasilkan langsung dari spesifikasi. DevOps diramalkan menghapus peran administrator database. Setiap kali, hasilnya berbeda dari ramalan.
Polanya konsisten: hambatan masuk yang lebih rendah menambah volume perangkat lunak yang dibangun, yang menaikkan permintaan untuk engineer yang lebih canggih. Compiler tidak menghapus developer (ia menghapus kebutuhan menulis assembly dengan tangan dan menaikkan level tempat kita bekerja. Peran administrator database tidak hilang dengan DevOps) ia berubah menjadi platform engineer. Spec-driven development adalah lapisan berikutnya, bukan "akhir" yang pertama.
Di situlah Hoffer tepat. Dalam perubahan seperti ini, pemenangnya bukan yang paling menguasai craft lama, melainkan yang memperlakukan peran baru sebagai sesuatu yang dipelajari dari nol. Yang berpegang pada identitas "saya yang menulis kode paling cepat" berakhir siap menghadapi dunia yang sedang lenyap. Yang mengambil identitas penulis niat sekaligus verifikator mewarisi dunia yang sedang datang.
Ringkasan
Kembali ke dua hari kerja di pembuka. Bedanya bukan developer hari ini bekerja lebih sedikit, tapi titik berat nilainya bergeser dari kecepatan menulis kode ke presisi niat dan ketelitian verifikasi.
Lima hal yang layak dibawa pulang:
- Naik: arsitektur, presisi kebutuhan, judgment, dan orkestrasi. Turun: boilerplate, debug baris per baris, hafalan sintaks.
- Bottleneck-nya berpindah, bukan hilang: "test lulus" bukan "sesuai niat", dan penghematan tanpa verifikasi adalah utang, bukan keuntungan.
- Perhitungkan waktu verifikasi sejak awal di estimasi, bukan berpura-pura generasi kode adalah akhir pekerjaan.
- Sebagai pemimpin, bangun budaya belajar, karena integrator aktif mengungguli delegator pasif di semua metrik yang penting.
- Profesi ini tidak berakhir: bar-nya naik, dan preseden historis mendukungnya.
Pekerjaan penulis niat lebih sulit daripada pekerjaan eksekutor, tapi juga lebih menarik. Waktu untuk mengetik apa yang sudah kamu tahu bagaimana menulisnya berkurang; waktu untuk hal yang benar-benar menuntut berpikir bertambah: apa yang ingin kita bangun, dan bagaimana kita membuktikan kita mendapatkannya.
Kalau kamu sedang mengatur beberapa agent sekaligus, dua tulisan lain di blog ini melanjutkan bagian praktisnya: menjalankan Claude Code seperti tech lead dan kebiasaan prompting yang sudah kedaluwarsa. Untuk gambaran lebih makro soal bagaimana pasar terbagi tiga, ada Rekayasa Perangkat Lunak Terbagi Tiga.
