Insinyur yang Cuma Bilang “Tidak” Ternyata Fenomena ZIRP

• Insinyur yang cuma bilang “tidak” adalah arketipe senior yang pada dasarnya menghambat perubahan kode, menunda fitur yang kompleks, dan berusaha agar kode yang ditulis sesedikit mungkin
• Pada era ZIRP, kerugian produktivitas kurang dianggap penting berkat suku bunga rendah dan ekspansi perekrutan, sehingga peran yang menahan usulan teknis yang ekstrem berguna bagi perusahaan
• Setelah suku bunga naik, perusahaan teknologi memberhentikan 5~20% insinyurnya, dan ketika pendapatan lebih diprioritaskan daripada harga saham, pelindung yang biasa menggantikan kata “tidak” pun berkurang
• LLM meningkatkan tekanan lewat PR buatan AI dan kode yang cukup layak dipakai, tetapi perubahan kuncinya bukan AI melainkan insentif ekonomi yang berubah akibat berakhirnya ZIRP
• Peran ini tidak hilang, tetapi lebih cocok untuk wilayah rekayasa murni, dan harus menerima cakupan yang lebih terbatas serta visibilitas yang lebih rendah dibanding era 2010-an

---

Peran “insinyur yang cuma bilang tidak”

• Insinyur yang cuma bilang “tidak” adalah arketipe yang berada di antara senior engineer dan staff engineer, dan perannya dekat dengan memperlambat pengembangan fitur, mencegah perubahan yang menambah kompleksitas, serta menjaga agar sesedikit mungkin kode ditulis
• Lawannya, insinyur yang cuma bilang “ya”, menekankan kecepatan bergerak, pada dasarnya menyetujui perubahan kode, cenderung lebih mementingkan MTTR daripada MTBF, dan gemar mendorong banyak kode ke produksi
• Sebagian besar insinyur berada di antara dua kutub ini, tetapi fokus di sini adalah pada insinyur yang sangat mengidentifikasikan diri dengan peran yang mengatakan “tidak”
• Di era AI, mereka bukan hanya harus menolak PR dari engineer junior, tetapi juga kode buatan AI dalam jumlah besar, dan kadang harus menolak kode yang dibuat manajer atau VP sehingga secara politik lebih sulit ditolak
• Untuk pertama kalinya dalam karier mereka, ada tekanan besar untuk menurunkan standar dan mengatakan “ya”, tetapi penyebab utamanya bukan AI itu sendiri melainkan berakhirnya ZIRP

Lingkungan yang dibentuk ZIRP

• ZIRP adalah singkatan dari “zero interest-rate policy”, dan merujuk pada era pengembangan software antara 2008 hingga 2022 ketika bank meminjamkan uang kepada perusahaan dengan suku bunga yang nyaris nol
• Investor menyalurkan uang pinjaman itu ke hampir apa pun, dan perusahaan teknologi punya insentif besar untuk terus merekrut engineer demi proyek yang tampak berisiko rendah dan berimbal hasil tinggi
• Perusahaan yang sukses menambah jumlah engineer dari puluhan menjadi ribuan, lalu memberi mereka pekerjaan seperti proyek open source pinggiran, migrasi teknologi tanpa akhir, atau penulisan ulang ke bahasa lain
• Bagi software engineer, itu adalah masa dengan daya tawar besar, dan hampir pekerjaan apa pun bisa dibayar sangat tinggi
• Eksekutif kesulitan memperhatikan detail karena tim tumbuh terlalu cepat, dan karena bertambahnya jumlah engineer sendiri membantu harga saham, banyak aktivitas tidak terlalu dipermasalahkan
• Jika terlalu banyak engineer bergerak bebas, sistem bisa menjadi tak terkendali, dan di titik inilah “insinyur yang cuma bilang tidak” menjadi berguna bagi perusahaan

Mengapa “tidak” bernilai pada era ZIRP

• Karena kehilangan produktivitas bukan masalah besar, perusahaan bisa menoleransi bahkan jika separuh engineer-nya terjebak dalam loop mengusulkan perubahan lalu ditolak
• Cara ini juga membuat engineer tidak terlalu menyentuh sistem inti bisnis
• Ini juga membantu mengendalikan 5% engineer yang terlalu mabuk kebebasan teknis hingga mengusulkan hal ekstrem seperti migrasi ke database buatan sendiri
• Reputasi sebagai perusahaan dengan standar teknis yang sangat tinggi juga membantu perekrutan, dan pada era ZIRP semua perusahaan teknologi selalu sedang merekrut
• Ungkapan “junior membuat banyak kode, senior membuat sedikit, staff menghapus kode” terdengar menarik karena memberi kesan bahwa para ahli nyaris tak perlu bergerak, tetapi itu tidak tepat karena staff engineer juga harus mampu menghasilkan banyak kode yang benar-benar berjalan dengan sangat cepat saat dibutuhkan

Perubahan setelah ZIRP berakhir

• Ketika bank menaikkan suku bunga, hampir semua perusahaan teknologi segera memberhentikan 5~20% engineer mereka
• Mempertahankan organisasi engineering yang gemuk demi menopang harga saham tidak lagi menguntungkan, dan perusahaan kini benar-benar harus menghasilkan uang
• Di sini, “menghasilkan uang” tidak selalu berarti harus untung, tetapi setidaknya harus mendatangkan pendapatan
• Mengakui bahwa ratusan engineer diberi pekerjaan yang tidak menghasilkan uang bukanlah penjelasan publik yang baik untuk PHK
• Karena berakhirnya ZIRP kira-kira bertepatan dengan kebangkitan ChatGPT, perusahaan bisa menjelaskan PHK itu sebagai akibat kekuatan AI
• Pesan seperti “berkat teknologi transformatif ini, kita bisa memberi nilai 10 kali lipat dengan separuh engineer” terdengar kuat, tetapi jika itu benar, maka muncul pertanyaan mengapa tidak mempertahankan engineer dan memberi nilai 20 kali lipat

Perusahaan makin fokus, pelindung makin tipis

• Perusahaan teknologi kini lebih fokus daripada kapan pun dalam 20 tahun terakhir, dan sekarang mati-matian mengejar kemampuan dan fitur baru yang benar-benar bisa menghasilkan uang, alih-alih mengerjakan banyak hal acak
• Lingkungan baru ini aktif merugikan insinyur yang cuma bilang tidak
• Dulu, insinyur seperti ini mendapat dukungan implisit dari eksekutif, dan jika ada yang mengeluh, responsnya bisa seperti, “kami tahu apa yang dia kerjakan, jadi kalau dia bilang tidak, kami percaya”
• Kini dukungan itu hilang, dan perilaku yang sama justru dikritik eksekutif atau dibatalkan secara aktif
• Mereka diminta lebih menjadi team player, mencari cara untuk mengatakan ya, atau bahkan tidak lagi diajak berkonsultasi dalam keputusan penting
• Perilaku yang sebelum 2022 dihargai kini berujung pada penilaian buruk, dan sering kali perubahan budaya baru menyusul beberapa tahun setelah perubahan insentif ekonomi
• Perubahan ini tidak bergantung pada AI; bahkan jika LLM tidak muncul dekade ini, perusahaan tetap akan memberhentikan engineer, dan engineer yang bertugas mengatakan “tidak” akan tetap bingung mengapa perilaku yang sama kini dihukum

Guncangan tambahan dari AI

• Jika ZIRP belum berakhir, LLM mungkin justru memberi pembenaran kuat bagi “insinyur yang cuma bilang tidak”
• Perusahaan yang sulit secara terbuka maupun internal meragukan coding berbantuan AI kemungkinan akan sangat bergantung pada insinyur ini untuk mencegah tsunami kode AI menenggelamkan perusahaan
• Kenyataannya, LLM lebih berperan seperti menabur garam di luka lama
• Mereka kini harus menyaksikan PR buatan AI yang sebelumnya akan diblokir justru di-merge, dan juga dituntut memakai alat seperti itu sendiri
• Yang lebih buruk, alat AI umumnya memang bekerja
• Sampai sekarang belum menyebabkan bencana tertentu, dan meski kodenya agak kurang rapi serta pemahamannya sedikit lebih rendah, hasilnya tetap cukup layak dipakai
• Terutama di lingkungan perusahaan yang banyak mencoba hal baru lalu membuang yang gagal, kode yang “cukup bagus” memang bisa lolos
• Bahkan jika insiden belakangan ini tampak meningkat, kita bisa saja keliru, atau faktor lain dari berakhirnya ZIRP seperti peningkatan kecepatan dan PHK bisa menjadi penyebab yang lebih utama
• Insinyur yang cuma bilang tidak menghadapi ancaman bukan hanya terhadap mata pencaharian, tetapi juga identitasnya
• Mereka dipaksa menerima bahwa peran teknisnya bergantung pada kondisi ekonomi yang sangat khas di industri teknologi, atau terus bersikeras bahwa kiamat sudah di depan mata

Rekayasa murni dan rekayasa tidak murni

• Insinyur yang cuma bilang tidak tidak akan hilang, tetapi tidak lagi cocok untuk semua perusahaan teknologi
• Dalam Pure and impure software engineering, rekayasa murni dibedakan sebagai pekerjaan dengan cakupan yang jelas dan tujuan yang terutama teknis, seperti compiler atau language runtime
• Rekayasa tidak murni adalah pekerjaan dengan cakupan yang tidak jelas dan tujuan yang digerakkan pelanggan, seperti mencoba fitur baru yang keberhasilannya tidak bisa dipastikan
• Pada era ZIRP, perusahaan teknologi jauh lebih banyak mengerjakan pekerjaan murni seperti React), dan cenderung memperlakukan pekerjaan tidak murni seolah-olah itu juga pekerjaan murni
• Insinyur yang cuma bilang tidak sangat cocok untuk pekerjaan murni
• Sebab codebase yang murni membutuhkan standar kualitas yang jauh lebih tinggi dan mampu menoleransi siklus pengembangan yang lebih lambat
• Sebagian besar perusahaan teknologi masih memiliki semacam pekerjaan murni di area seperti infrastruktur inti
• Pekerjaan ini penting, tetapi tidak membutuhkan tim engineering yang sangat besar, dan juga jarang mendapat sorotan
• Jika ingin tetap menjadi “insinyur yang cuma bilang tidak”, orang perlu pindah ke peran seperti ini, sambil menerima cakupan yang lebih sempit dibanding era 2010-an

Perdebatan dan sudut pandang yang dilengkapi

• Di lobste.rs dan Reddit, ada kritik bahwa dampak kode AI baru akan terlihat seiring waktu sehingga terlalu dini menyimpulkan bahwa ia “umumnya bekerja”
• Bantahan “masih terlalu dini untuk bilang” memang sulit dibantah, tetapi setidaknya tampak jelas bahwa kode AI belum langsung memicu kegagalan fatal
• Ada juga bantahan bahwa arketipe insinyur yang cuma bilang tidak sudah ada selama puluhan tahun sebelum ZIRP, dengan Linus Torvalds sering dijadikan contoh
• Arketipe itu sendiri bukan diciptakan ZIRP, tetapi ZIRP secara artifisial memperlebar ceruk bagi peran tersebut, dan sekarang ceruk itu menyempit kembali
• Ada pula bantahan bahwa penggunaan bahasa dinamis serta alat observabilitas dan feature flag yang belum matanglah yang menciptakan ceruk bagi peran ini
• Di Hacker News, banyak yang berpendapat teori ini membutuhkan bukti yang lebih kuat
• Sudut pandang ini didasarkan pada jendela kecil berupa pengalaman pribadi, dan generalisasi tentang seperti apa industri sebelum dan sesudah ZIRP bisa berbeda bagi tiap orang
• Untuk memverifikasinya, kita bisa mensurvei ratusan engineer senior ke atas pada 2010 dan 2026, lalu menanyakan berapa kali per minggu mereka mengatakan “tidak” dan seberapa sering penolakan itu dibatalkan
• Mengatakan “tidak” tetap penting baik sebelum maupun sesudah ZIRP, tetapi setelah ZIRP perbedaannya adalah eksekutif dengan cepat mengembangkan kemampuan itu sendiri, sehingga kebutuhan akan kelompok engineer yang mengatakannya atas nama mereka menjadi lebih kecil

[GN⁺]

Komentar Hacker News

• Kode adalah utang. Saat engineer mengatakan “tidak”, itu bukan karena mereka terobsesi secara subjektif pada kualitas kode, melainkan karena mereka berusaha mengurangi kompleksitas
  Belakangan ini manajemen sering salah paham dengan istilah “kualitas”. Kualitas berarti tingkat upaya yang tepat untuk membuat produk secepat mungkin dengan biaya serendah mungkin, dengan mempertimbangkan juga apakah tim engineering bisa dengan mudah menambah atau mengubah kode
  Penjelasan yang lebih baik ada di sini: https://www.nair.sh/guides-and-opinions/communicating-your-e...

  • “Kualitas” sulit didefinisikan secara sederhana. Ini semacam ranah Zen dalam pemeliharaan sistem, dan kode yang berkualitas baik lebih dekat pada sesuatu yang ditulis programmer yang berpengalaman dan bijak
    Upaya untuk mengkodifikasikan secara kaku apa yang mereka lakukan dan mengapa mereka melakukannya pada akhirnya pasti gagal
  • Dalam dunia AI agenik, utang itu bisa berkurang atau malah bertambah. Tim yang mampu memitigasi risiko AI dengan baik dapat menghasilkan kode yang berkelanjutan dalam jumlah sangat besar

• Masalah dengan ekonomi ala meja kerja seperti ini adalah logika bisa dibangun ke dua arah
  Orang juga bisa mengatakan “berakhirnya era suku bunga nol dan bangkitnya engineer yang berani bilang tidak”. Karena biaya modal menjadi lebih mahal, perusahaan harus menggunakan uang itu dengan lebih bijak, dan makin membutuhkan penilaian engineer yang mengatakan tidak agar uang tidak terbuang untuk hal yang tidak perlu

  • Tambahan lagi, engineer itu entah dipercaya dan penilaiannya dihargai oleh manajemen, atau tidak. Jika tidak, posisinya memang sudah buruk sejak awal
  • Saat melihat tulisan seperti ini, saya merasa komunitas HN dan alur komentarnya benar-benar bagus
    Semakin dibaca, saya makin merasa “ini punya semua istilah yang terdengar meyakinkan, bicara soal era ZIRP dan engineer yang cuma bilang tidak sehingga tampak penuh wawasan, tapi ketika digali lebih dalam sama sekali tidak cocok dengan pengalaman saya di lapangan software engineering pada masa itu, dan juga gagal mendiagnosis dengan tepat perubahan besar yang sedang terjadi sekarang karena AI”. Dengan kata lain, ini terdengar seperti omong kosong penuh jargon, jadi menyenangkan bahwa komunitas menyorotinya sebagai pengganti tidak adanya tombol downvote pada artikelnya sendiri
  • Pandangannya mirip. Setiap perusahaan punya preferensi waktu yang berbeda antara keberhasilan jangka pendek dan jangka panjang
  • Sean mungkin engineer yang baik, tetapi ekonomi tampaknya berada di luar bidang keahliannya
  • Suku bunga tinggi berarti urgensi yang lebih tinggi, dan menunjuk pada investasi jangka pendek yang cepat balik modal. Jika ditambah LLM yang sangat cocok dengan urgensi seperti itu, hasilnya adalah produksi massal sampah AI
    Sekalipun proyek AI gagal, itu tidak masalah selama kegagalannya cukup cepat sehingga orang bisa beralih ke hal lain. Melakukan semuanya dengan benar sejak awal hanya menjadi penting untuk proyek jangka panjang yang memerlukan investasi awal besar

• “Bahwa setengah engineer di perusahaan terjebak dalam loop tak berujung mengusulkan perubahan lalu ditolak itu sepenuhnya tidak masalah. Mereka toh tidak perlu produktif, dan dengan cara itu mereka juga tidak memengaruhi sistem inti bisnis” ya, itu memang satu sudut pandang. Cukup sinis

  • Ada banyak cerita bahwa pada masa itu FAANG merekrut orang agar talenta tidak pergi ke pesaing. Tapi lalu apa yang harus diberikan kepada orang-orang yang direkrut seperti itu? Dan bagaimana mencegah mereka menimbulkan masalah?
    Kalau dipikir kembali sekarang memang terdengar sinis, tetapi saat itu orang menjelaskan kumpulan fakta yang sama dengan cara berbeda yang tidak terlalu melukai perasaan orang
  • Betul. Dan menghubungkan fenomena ZIRP dan “no-man” itu keliru, bahkan mungkin korelasi paling aneh di sini. Saya termasuk orang yang suka menemukan kaitan tak terduga, tetapi fenomena ini tidak ada hubungannya dengan ZIRP dan sudah ada jauh sebelumnya
  • Banyak bagian dari tulisan ini sejak awal memang tidak bisa diverifikasi
    Apakah orang yang mengerjakan Metaverse di Facebook adalah personel kunci yang sedang memprototipe model bisnis baru, atau hanya melakukan pekerjaan yang terlihat sibuk, itu baru akan jelas belakangan

• Ini tafsiran yang cukup ekstrem. Jika ZIRP berakhir dan fokus meningkat, bukankah kesimpulan yang alami justru bahwa kita harus lebih sering menolak, bukan lebih jarang?
  Kalau mau berargumen bahwa ZIRP menciptakan segala macam pekerjaan palsu, lalu juga menciptakan lapisan untuk mengendalikan pekerjaan palsu itu, perlu memelintir logika cukup keras

  • Periode tersebut bahkan bukan contoh yang bagus dari suku bunga mendekati nol. Setidaknya begitu jika inflasi ikut diperhitungkan, dan ada periode lain ketika suku bunga riil rendah atau bahkan negatif

• Saya suka pembedaan antara “engineer yang asal iya” dan “engineer yang asal tidak”, serta sudut pandang memprioritaskan MTTR dibanding MTBF
  Saya jelas berada di kubu “asal iya”, tetapi ada catatan bahwa pilihan arsitektur yang buruk bisa sangat menyakitkan untuk diperbaiki nanti, dan fitur jauh lebih sulit diperbaiki setelah punya pengguna daripada sebelum dirilis. Jadi saya juga agak condong ke “asal tidak”, atau setidaknya ke “mari pikirkan sebentar dulu”
  Keseimbangan antara “asal iya” dan “asal tidak” sangat bergantung pada proyeknya. Kalau di bidang keuangan atau kesehatan, mungkin lebih baik default-nya “tidak”, tetapi kalau itu ide startup yang nyeleneh, ya YOLO

  • Sikap “asal iya” seperti itu pada akhirnya akan mengarah pada bencana yang nyaris pasti. Waktu untuk memperbaiki produk tidak akan pernah datang
    Meminta waktu untuk merapikan sebenarnya setara dengan mengatakan tidak. Kepala engineering harus punya wewenang untuk itu dan memang harus menggunakannya. Jika tidak pernah digunakan, pada praktiknya sama saja dengan tidak punya wewenang itu

• Jangan menjadi engineer yang hanya berkata “tidak” tanpa menawarkan alternatif. Itu bukan engineer yang baik, melainkan orang malas yang ingin terlihat bagus
  Engineer sering mengusulkan solusi yang memang tidak ideal tetapi perlu karena adanya legacy. Dan tidak, kita tidak bisa menulis ulang seluruh sistem lalu membuatnya dengan “cara yang benar”. Hanya dengan mengatakan “tidak” atau menunjukkan bahwa solusi itu tidak ideal tidak otomatis membuat seseorang menjadi jenius supercerdas

  • Saya langsung teringat seorang manajer pengembangan software yang persis seperti itu. Orang yang sangat paham sistem itu kemudian menjadi manajer, lalu mulai terus-menerus mengatakan tidak kepada berbagai manajer produk dan developer lain
    Dalam rapat dengan orang bisnis, dia bersikap mengintimidasi karena bisa ngoding, dan yang paling buruk adalah saat dia tidak setuju dengan sebuah usulan, dia sama sekali tidak menawarkan alternatif. Sulit sekali bekerja dengannya
    Mungkin orang seperti itulah yang dimaksud tulisan ini sebagai manusia ZIRP

• Jika ada kekurangan pada LLM dan agen, ada arus yang mendorong menurunkan standar alih-alih menunggu perbaikan. Semacam “fokuslah pada MTTR”
  Kodenya jelek? Jangan dibaca, jangan ditinjau, keluarkan orang yang jadi bottleneck dari loop. Narasi seperti ini menyebar di mana-mana
  Teknologi ini cukup berguna, jadi alih-alih hanya menangani gejalanya, saya berharap fokus diberikan pada cara bekerja lebih baik dengan alat ini dan pada perbaikan proses yang menyesuaikannya

  • Bukankah keduanya memang sedang dilakukan? Lab AI pasti sedang melakukan perbaikan dari sisi mereka, dan ada juga orang-orang yang membuat agen yang lebih baik. Individu pun bisa meningkatkan kemampuan atau menyesuaikan AGENTS.md
    Hal yang bisa dilakukan tidak ada habisnya, tetapi masalahnya adalah bagaimana membagi waktu antara memakainya di proyek nyata dan menghabiskan waktu untuk perbaikan semacam itu

• Katanya, “semakin banyak insinyur, semakin baik bagi harga saham… ketika bank menaikkan suku bunga… mempertahankan organisasi insinyur yang gemuk demi mendongkrak harga saham tidak lagi menguntungkan”; apakah ada mekanisme yang dikenal yang menghubungkan jumlah software engineer dan harga saham? Atau ini hanya fenomena yang diamati secara empiris?

• “Dulu cukup bilang tidak pada PR yang ditulis manual oleh engineer junior, tetapi sekarang kode buatan AI membanjir, dan sebagian di antaranya dibuat oleh manajer dan VP yang secara politis sulit ditolak,” astaga
  Saya pernah bekerja di perusahaan teknologi besar, tetapi meninggalkan industri sebelum InstructGPT dan semacamnya muncul, jadi saya belum pernah mengalami pembuatan kode dengan LLM di dalam organisasi. Benarkah hal seperti ini sedang terjadi? Manajer senior dan VP benar-benar mengusulkan perubahan kode yang dibuat dengan LLM? Saya rasa saya tidak akan sanggup

  • Ini benar-benar terjadi. Seorang teman bercerita bahwa ia harus menghadapi PR 25 ribu baris yang diajukan seorang manajer produk
    Beban politiknya juga nyata. Anda tidak bisa begitu saja berkata, “tidak bisa,” tetapi cukup sulit melakukan review yang bermakna terhadap PR 25 ribu baris yang diajukan oleh seseorang yang bahkan tidak terlalu paham apa yang ia lakukan dan tidak bisa menjawab pertanyaan
  • CEO Shopify mengajukan PR di repositori publik: https://github.com/Shopify/liquid/pull/2056
    Agar adil, ia memang ikut membangun liquid dan banyak bagian Shopify secara langsung pada masa awal perusahaan, jadi ia bukan orang yang tidak berpengalaman, tetapi tetap saja begitu

• Ini tampak seperti hipotesis yang sulit diverifikasi. Jika sebuah perusahaan benar-benar ingin menyelesaikan sesuatu, bukankah masuk akal jika ada orang yang membantu menetapkan prioritas dengan memberi tahu keputusan mana yang menimbulkan biaya jangka panjang?