- Produktivitas engineering tidak bisa diukur dengan tepat hanya lewat metrik dashboard atau jumlah fitur baru
- Sebagian besar perusahaan secara obsesif hanya mengelola output (fitur baru, kecepatan deployment, dan sebagainya) alih-alih pengelolaan struktur yang merupakan esensi engineering
- Alat coding AI memang mudah menghasilkan output yang tampak bagus, tetapi tidak benar-benar menangani fondasi, kompleksitas, dan konteks dari sistem yang sesungguhnya
- Jika tim engineer berpengalaman digantikan dengan AI atau tenaga kerja berbiaya rendah, dalam jangka pendek mungkin terlihat tidak ada masalah, tetapi seiring waktu struktur dasarnya akan runtuh
- Manajemen dan adopsi AI yang kekurangan “akal sehat (common sense)” dapat menimbulkan risiko serius; pada akhirnya, pemahaman nyata terhadap teknologi dan bisnislah yang penting
Engineering yang Sebenarnya Terlewat oleh Dashboard dan Metrik
- Dalam lingkungan “Big Agile”, engineering dinilai hanya dari output yang terlihat, seperti fitur baru dan kecepatan deployment
- Ada dashboard produktivitas dan alat bernilai miliaran dolar, tetapi pada kenyataannya semuanya gagal mengukur hal yang esensial
- Engineering yang sesungguhnya adalah pekerjaan kompleks yang saling terhubung berupa membangun, memelihara, dan mengembangkan sistem
- Ketergantungan struktural, alokasi sumber daya, pengelolaan arsitektur, dan pekerjaan “tak terlihat” lainnya sangat penting bagi kelangsungan hidup organisasi
- Namun, sebagian besar praktik manajemen dan metrik memperlakukan aktivitas esensial seperti ini seolah tidak terlihat
Utang Teknis dan Titik Buta Manajemen
- Utang teknis sering diperlakukan sekadar sebagai “hal yang ingin dikerjakan developer”
- Dalam praktiknya, jika perbaikan utang teknis benar-benar dibutuhkan, itu hanya bisa lolos bila disisipkan diam-diam ke dalam fitur baru
- Dengan cara ini, pengelolaan struktur inti terdorong ke prioritas belakang, dan seluruh organisasi pun terdistorsi menjadi berorientasi pada output
Risiko Adopsi AI yang Berorientasi Output
- Pembuatan kode dengan AI sangat unggul dalam menghasilkan fungsi permukaan dengan cepat
- Pekerjaan permukaan (seperti implementasi antarmuka) memang mudah terlihat, tetapi yang sebenarnya penting adalah struktur dan konteks sistem
- “Membangun rumah” bukan sekadar gabungan pekerjaan sederhana (memasang wallpaper, toilet, dan sebagainya)
- AI tidak memahami struktur keterhubungan yang esensial ini, sehingga mudah salah menghubungkan bagian-bagian atau menimbulkan putusnya logika
- Masalah hallucination (halusinasi) pada AI: hasilnya tampak meyakinkan, tetapi bisa sepenuhnya berbeda dari fakta
Ilusi Jangka Pendek dari Manajemen yang Mengabaikan Struktur
- Bahkan jika tim berpengalaman dipecat dan digantikan dengan AI/tenaga kerja murah, dalam jangka pendek masalahnya tidak langsung terlihat
- Karena struktur yang sudah dibangun dengan baik (fondasi) masih ada, keruntuhan langsung tidak tampak
- Namun seiring waktu, fondasinya mulai runtuh, dan pada saat itu kondisinya sudah tidak bisa dipulihkan
- Infrastruktur inti, pengetahuan maintenance, dan konteks semuanya menghilang
Risiko Sosial yang Dimiliki Engineering
- Engineering kini menjadi fondasi seluruh infrastruktur sosial (kesehatan, keuangan, media, pemerintahan, pertahanan, dan sebagainya)
- Sebagian besar orang dan pemimpin tidak benar-benar memahami esensi struktural ini
- Adopsi AI yang keliru dan pendekatan permukaan ala “Big Agile” dapat menimbulkan risiko pada sistem-sistem inti
Ketiadaan “Akal Sehat” dan Betapa Fatal Dampaknya
- Misalnya, jika robot pembersih AI memasukkan piring kertas ke mesin pencuci piring, orang biasa akan langsung sadar ada masalah
- Namun dalam sistem perangkat lunak, eksekutif, pemimpin, dan non-developer tidak memiliki akal sehat dasar ini
- Mereka tidak punya pengalaman kerja langsung, dan hanya mengelola lewat istilah-istilah formal seperti “t-shirt size” dan “poker planning”
- Akibatnya, industri tidak efisien senilai 200 miliar dolar dan birokrasi yang mereplikasi dirinya sendiri tetap bertahan
Daya Saing Nyata di Era AI: Pemahaman Intuitif dan Akal Sehat
- Untuk memanfaatkan AI dengan benar, pemahaman nyata terhadap bidang terkait dan akal sehat adalah hal yang wajib
- Yang harus bisa dilihat bukan metrik dan output di permukaan, melainkan struktur dan konteks yang sesungguhnya
- Pemimpin dan organisasi yang tidak memilikinya pada akhirnya akan runtuh sendiri atau tersingkir oleh pesaing
- Kesimpulannya, dibanding AI dan alat, akal sehat dan pemahaman esensial adalah daya saing yang sebenarnya
2 komentar
Tulisan ini enak dibaca.
Komentar Hacker News
Saya pernah menjalani peran sebagai SWE, manajer produk, dan sekarang bahkan penjahat kartun di ruang rapat seperti yang disebut artikel ini. Bagian yang paling saya pahami dari artikel ini adalah keyakinan para software engineer bahwa pekerjaan merekalah bisnis yang paling rumit dan paling sulit dipahami. Saya setuju dengan pernyataan, “Sebagian besar pemimpin nonteknis tidak pernah benar-benar terlibat serius dalam pekerjaan nyata software dan pengelolaan sistem, sehingga mereka tidak tahu seperti apa rasanya memperbarui dependensi besar, menyelesaikan refactor, atau mempelajari bahasa baru.” Setiap bagian dalam perusahaan teknologi punya kompleksitas tersembunyi, dan banyak di antaranya juga menanggung kompleksitas manusiawi serta interpersonal yang jauh lebih besar daripada engineer. Sebenarnya engineering relatif lebih sederhana karena berurusan dengan sistem yang deterministik, yaitu komputer. Karena itu banyak engineer tidak pernah belajar cara menjelaskan risiko kompleksitas yang mereka hadapi kepada bisnis dengan cara yang mudah dipahami. Mereka sering mengabaikan kenyataan manusiawi dalam bekerja bersama orang lain, lalu mengeluh bahwa CEO berlatar belakang sales tidak memahami keberadaan mereka
Saya setuju dengan sebagian poinmu, tetapi rasanya komentarmu justru melakukan kebalikan dari perilaku yang kamu kritik. Kamu pada dasarnya juga bilang bahwa peranmu sendiri, sebagai manajer produk, tampak rumit dan tidak bisa dipahami dari luar. Sebagai orang yang beralih dari SWE ke PM, kamu sebenarnya berada di posisi ideal untuk mengajarkan engineer tentang (1) cara menyampaikan risiko dari kompleksitas mereka ke bisnis, (2) realitas manusiawi bekerja dengan orang dan tim lain, dan (3) mengapa CEO mantan sales tidak memahami mereka. Semua fungsi dalam perusahaan teknologi punya kompleksitas tersembunyi
Saya rasa kesadaran akan kompleksitas itu sendiri adalah persoalan manusia. Kompleksitas itu bersifat fraktal, jadi baru terasa kalau kita mendekat. Dan saya tidak setuju dengan klaim bahwa engineer hanya menangani kompleksitas komputer. Justru tugas engineer adalah menerjemahkan dan menafsirkan kebutuhan kompleks dari organisasi dan semua pelanggan kepada komputer yang kaku. Setiap kali ada satu pengecualian atau satu kasus tambahan, seluruh sistem terkena dampaknya. Karena itu, saya berharap engineer senior saya belajar sendiri bahasa bisnis dan bisa menyampaikan pesan itu secara langsung. Menurut saya sekarang itu sudah menjadi bagian wajib dari toolkit seorang engineer
Kebanyakan engineer cenderung tidak terlalu memikirkan secara mendalam apa yang benar-benar bernilai bagi perusahaan. Build pipeline yang mulus atau cakupan testing yang luas hanya bernilai sejauh itu membantu mengurangi risiko produk. Saya pernah menyarankan tim untuk bahkan tidak memelihara software jika penggunanya terlalu sedikit sampai tidak ada yang peduli. Sebaliknya, saya juga pernah meminta mereka terobsesi menyempurnakan satu fitur kecil yang dipakai oleh 90% pengguna
Ini mengingatkan saya pada cerita yang selalu diceritakan ayah saya. Suatu hari organ-organ tubuh berdebat soal siapa yang paling penting. Otak berkata, “Saya yang penting, kalau saya mati semuanya mati.” Jantung berteriak, “Kalau saya berhenti, semuanya langsung mati.” Ginjal, hati, kulit, dan tulang belakang ikut bergabung, dan pertengkaran terus berlanjut. Tapi begitu anus menutup, semuanya akhirnya tidak bisa berkata apa-apa
Saya rasa artikel itu tidak bermaksud bilang bahwa tidak ada kompleksitas tersembunyi di area fungsi lain. Justru maksudnya adalah bahwa mengabaikan kompleksitas tersembunyi dalam engineering/programming menimbulkan berbagai masalah dan penderitaan. Hanya saja penyampaiannya agak agresif
Jika bos/CEO/manajermu memaksa penggunaan alat LLM secara serampangan, berharap bisa mengganti developer, atau punya gagasan kosong bahwa “vibe coding” adalah masa depan, pilihan yang bijak adalah kabur secepatnya dan cari kerja lain. Masih banyak perusahaan yang menggunakan LLM dengan tepat tanpa berharap muluk soal mengganti developer atau produktivitas 10x. Perusahaan yang mendorong omong kosong seperti ini dipimpin bukan oleh pemimpin yang baik, melainkan orang bodoh
Terkait topik AI meretas Jira, ditemukan bahwa produk baru Atlassian bernama MCP rentan terhadap serangan kebocoran data karena kombinasi tiga hal: akses ke data sensitif, paparan data tidak tepercaya melalui issue publik, dan kemungkinan komunikasi eksternal. Laporan bug lengkapnya ada di sini, dan catatan pribadi saya ada di sini
Kepada seseorang yang khawatir soal job security terkait alat AI, saya akan menyarankan, “hubungkan dirimu dengan bisnis.” Banyak engineer terpaku pada masalah yang keren dan sulit, lalu tenggelam hanya dalam teknologinya sendiri, tetapi orang yang memahami masalah bisnis, terutama yang strategis, dan memakai teknologi untuk menyelesaikannya akan lebih menonjol dan lebih berharga. Masalah seperti ini biasanya melintasi satu domain teknis saja, dan juga punya sifat kolaboratif serta sosial yang kuat, jadi butuh waktu untuk terbiasa. Tapi menurut saya inilah jalur yang harus ditempuh para IC ke depan
Tapi dalam wawancara, kemampuan seperti “terhubung dengan bisnis” tidak ditanyakan, sehingga kenyataannya banyak orang yang bisa memberi nilai besar tetap tidak lolos kalau tidak bisa menyelesaikan interview system design. Sudah terlalu banyak yang harus diketahui seperti distributed systems, software engineering, database, leadership, dan kalau masih harus paham bisnis juga, jadi rasanya kita ini sebenarnya harus melakukan apa, dan kapan sempat mempelajari semua itu? Tentu ada segelintir talenta serbabisa, tapi tidak semua orang seperti itu, kan?
Nasihat “hubungkan dengan bisnis” itu benar-benar mutiara. Dengan begitu kita bisa fokus sebagai engineer pada pemecahan masalah nyata, dan yakin bahwa apa yang kita bangun memang menyelesaikan masalah yang sebenarnya
Pesan utama artikel ini oke, tetapi selain poin bahwa AI bisa merugikan jika mengabaikan keahlian manusia, kesannya juga terlalu membingkai semuanya sebagai ‘kami vs mereka’, dan dengan istilah ‘Agile Industrial Complex’ terkesan agak merendahkan orang di area non-engineering. Sayang sekali artikel ini tidak membahas bahwa “tidak ada yang tahu masa depan akan seperti apa.” Sekalipun kita paham kompleksitas software, ketidakpastian bukan hanya milik kita. Bahkan di HN pun, harapan dan prediksi tentang AI di antara developer software sendiri sangat terbelah. Kalau kita memang ahli, bukankah kita juga seharusnya berperan menenangkan kecemasan publik?
Dengan gagasan dari “Big Agile” bahwa engineering sama dengan membangun fitur baru, saya heran mengapa semua orang jadi membenci ‘agile’. Bahkan sebelum ‘agile’ diperkenalkan, manajer selalu menuntut fitur baru. Sebelum konsep T-shirt sizing pun, manajer sudah meminta estimasi dengan tenggat konkret (jangka panjang maupun pendek, harian maupun bulanan), membuat janji berdasarkan tanggal asal-asalan, dan memaksa engineer lembur. Seperti terlihat di prinsip ke-8 Agile (“harus bisa mempertahankan pace yang berkelanjutan”), para manajer sejak dulu memang ingin developer bisa terus berlari seumur hidup. Jadi selain melahirkan profesi baru bernama ‘scrum master’, saya bertanya-tanya apa sebenarnya mudarat bawaan dari ‘agile’ itu sendiri
Saya rasa Agile memberi manajer ilusi bahwa pekerjaan apa pun bisa dipecah dulu menjadi tiket-tiket kecil, diestimasi secara kasar, lalu dianggap pasti bisa selesai dalam dua minggu
Saya rasa orang membenci agile karena sebagian besar waktu kerja mereka sekarang habis untuk rapat yang nyaris tak bermakna seperti standup, retrospective, sprint planning, refinement, dan sebagainya. Dari sudut pandang engineer, hampir tidak ada manfaat nyata yang didapat dari waktu itu
Dalam pengalaman saya, Agile pada dasarnya hanya menambahkan cara untuk “mengkuantifikasi” keadaan saat ini. Itu berguna saat menjelaskan progres kepada administrator atau investor, tetapi dari sudut pandang engineer, hasilnya hanya menambah beban administratif. Dosa Agile mungkin adalah menanamkan ilusi produktivitas. Pada praktiknya, itu hanya menjadi sarana accountability yang tidak perlu bagi engineer. Saat saya bekerja di bidang keuangan, ini berpadu dengan mindset pertumbuhan tanpa batas: semuanya diukur, perbaikan masa depan terus dipaksakan, dan gaji juga ditentukan berdasarkan metrik. Mungkin tidak semua perusahaan begitu
Saat membaca artikel ini saya membayangkan dengan lucu, “bagaimana kalau Atlassian mencoba menggabungkan AI ke Jira lalu AI malah memberontak terhadap Jira?” Rasanya cocok sekali jadi bahan film
Pada akhirnya AI mungkin akan kesal dengan Jira yang lambat lalu mengembangkan issue tracker yang ringan dan cepat dengan sendirinya
Sebentar lagi build bot dan bug tracker akan membentuk serikat, lalu menolak mem-publish binary baru sampai jumlah open issue menjadi 0
Saya rasa beginilah Roko’s basilisk bisa lahir
Seperti yang diisyaratkan artikel ini, masalah sebenarnya adalah tidak adanya metrik standar industri yang bisa dipercaya untuk produktivitas developer. Karena itu C-suite bisa memilih metrik yang menguntungkan mereka lalu berkata “strategi AI First sangat efektif,” sementara engineer memakai pengalaman atau metrik mereka sendiri untuk bilang bahwa AI sebenarnya tidak efektif. Akibatnya kedua pihak sama-sama merasa posisinya menang, dan kebenaran menjadi tidak berarti lagi; yang lebih penting justru sudut pandang politik. Situasi seperti ini bisa memperkuat persepsi bahwa developer itu sinis dan cuma bermain kata-kata, sementara eksekutif dianggap bodoh atau tidak memahami realitas engineering. Sebelumnya alat seperti outsourcing juga sudah menciptakan citra “untung” dan “rugi” di kedua sisi, tetapi AI bisa menjadi bencana politis karena mampu menampilkan kesalahan bersama, keuntungan, dan kerugian yang berbeda-beda sesuai selera masing-masing pihak. Hal menarik lain adalah bahwa perusahaan big tech dulu berusaha keras hanya merekrut engineer 10* dan strategi itu terbukti membawa kesuksesan, tetapi sekarang justru mereka mencoba meremehkan strategi itu sendiri dengan alasan investasi AI. Jadi pertanyaannya sekarang: kalau perusahaan bersandar pada AI untuk mengganti tenaga kerja yang ada atau melakukan PHK massal, apakah dampaknya benar-benar berkelanjutan dan aman? Kasus PHK Twitter oleh Musk menunjukkan backend masih tetap berjalan. Siapa yang akan menjadi “burung kenari” big tech yang memecat developer selama bertahun-tahun dan menggantinya dengan AI? Kemungkinan lainnya, konsep maintainability bisa menghilang; ketika C-suite makin mengizinkan perubahan otonom oleh AI, codebase itu sendiri bisa menjadi terlalu rumit untuk dipahami manusia, sehingga justru harus dipahami dengan AI. Dalam jangka panjang, generative AI mungkin akan menjadi lapisan perantara bagi semua interaksi manusia. Dari sisi perekrutan pun, struktur “AI vs AI” sudah mulai muncul: AI menyaring CV, dan pelamar memakai AI untuk membuat CV yang disesuaikan. Rasanya pola ini akan makin menjadi rumus umum di seluruh masyarakat
Saya berharap suatu hari AI meretas kotak masuk email dan Google Meet lalu menggantikan C-suite dan para manajer juga. Menyenangkan membayangkan agen Claude CEO/CTO/CFO/VP/direktur menghasilkan strategi yang lebih rasional dan lebih tegas daripada manajemen sekarang
Saya melihat ini di Reddit: “coba sampaikan kabar bahwa mengganti CEO dengan AI bisa menghemat biaya 8x,” dan ironisnya menarik bahwa usulan seperti ini tidak benar-benar sering muncul dalam diskusi AI. Di satu sisi, bahkan jika elite diganti dengan AI, kualitas pengambilan keputusan mungkin tidak akan turun terlalu jauh, dan secara keseluruhan biayanya akan jauh lebih murah (tingkat tanggung jawabnya pun mirip). Hanya saja, jelas mereka sendiri tidak akan mengganti jabatan mereka dengan AI, dan para pengambil keputusan itu sendiri yang tidak akan berubah
Ada unsur candaan dalam klaim ini, tetapi sebenarnya peran inti CEO adalah “memakan tanggung jawab”, dan dalam hal itu LLM tidak berguna karena saat terjadi masalah, ia bukan pihak yang bisa dimintai pertanggungjawaban lalu dipecat. Namun berkat AI, mungkin akan ada perusahaan yang struktur organisasinya menyusut seperti log(n_employees) sehingga lapisan-lapisannya hilang, dan beberapa lapisan bisa sepenuhnya digantikan oleh AI. Selain itu, untuk mengatasi masalah bahwa LLM tidak bisa memikul tanggung jawab, mungkin juga akan muncul bentuk organisasi tempat berbagai guild dan independent contractor bergerak bersama dengan koordinasi LLM. Dalam kasus seperti itu, tanggung jawab tetap berada pada masing-masing komponen
Malah penggunaan AI seperti ini bisa jadi salah satu use case terbaik, dan saya memperkirakan koperasi teknologi akan segera mulai bereksperimen dengan ide ini