AI tidak menyederhanakan rekayasa perangkat lunak: hanya membuat rekayasa yang buruk lebih mudah dilakukan

• LLM memang mempercepat penulisan kode, tetapi tidak mengurangi kompleksitas intrinsik rekayasa perangkat lunak
• Karena pembuatan kode menjadi lebih mudah, menyebar ilusi bahwa kebutuhan akan keahlian telah hilang, dan sebagian organisasi menggunakan ini sebagai alasan untuk mengurangi jumlah engineer
• Kesulitan yang sebenarnya bukan pada menulis kode, melainkan pada desain sistem, spesifikasi, verifikasi, dan menjaga konsistensi, dan AI justru mempercepat beban di area ini
• Ketidaksesuaian antara spesifikasi (specification), pengujian, dan implementasi (spec drift) makin cepat memburuk, sehingga risiko runtuhnya keandalan sistem meningkat
• Ini adalah pola yang berulang kali terlihat dalam lebih dari 40 tahun pengalaman; bahkan pada era Visual Basic di 1990-an, klaim yang sama tentang "tidak perlunya keahlian" juga pernah muncul, lalu pada akhirnya kebutuhan akan disiplin rekayasa kembali ditegaskan
• LLM adalah alat yang sangat baik untuk eksplorasi desain dan mempercepat implementasi awal, tetapi harus digunakan untuk memperkuat, bukan menggantikan, disiplin rekayasa

---

Kesalahpahaman berbahaya di industri

• Begitu LLM mampu menghasilkan kode, industri perangkat lunak mulai cenderung menyimpulkan bahwa rekayasa perangkat lunak itu sendiri tidak lagi diperlukan
• Disiplin seperti arsitektur, spesifikasi, dan verifikasi yang cermat diperlakukan seolah-olah hanya peninggalan zaman lama
• Di sebagian organisasi, ide ini bahkan sudah diterapkan dalam kebijakan, hingga memicu PHK engineer dalam skala besar dengan alasan kemajuan AI
• AI hanyalah alasan terbaru untuk menghindari keputusan bisnis yang buruk atau tekanan pasar
• Memberi prompt ke AI makin sering dibingkai sebagai pengganti disiplin yang selama ini mendefinisikan rekayasa perangkat lunak

Pola sejarah yang berulang

• Dalam karier lebih dari 40 tahun, pola yang sama terus berulang: muncul alat baru → diumumkan bahwa masalah sulit telah terpecahkan → produktivitas melonjak dan demo tampak mengesankan → pengurangan tenaga kerja → kompleksitas sistem meningkat → hasil akhirnya ternyata jauh dari harapan
• Alat dan klaimnya berubah, tetapi polanya sendiri hampir tidak berubah

Analogi perawatan pesawat

• Bidang perawatan pesawat telah mengalami kemajuan besar lewat perbaikan alat, diagnostik komputer, manual digital, dan interpretasi telemetri AI, tetapi kebutuhan akan teknisi terampil tetap ada
• Pesawat komersial adalah sistem yang sangat kompleks, dengan jutaan komponen dan ribuan subsistem yang saling terhubung
• Mendiagnosis masalah bukan sekadar memakai alat yang tepat atau mengikuti checklist, melainkan membutuhkan pengalaman dan penilaian tentang bagaimana sistem beroperasi dalam kondisi nyata
• Tidak ada maskapai yang, karena alat makin baik, lalu menghapus teknisi terlatih dan menyerahkan perbaikan kepada agen gate
• Namun industri perangkat lunak justru sedang membuat argumen yang sangat mirip tentang dirinya sendiri

DIY vs sistem profesional

• Proyek hobi, aplikasi kecil untuk penggunaan pribadi, dan eksperimen ide baru sama sekali bukan masalah; banyak ide paling menarik dalam sejarah komputasi lahir dari eksperimen seperti ini
• Tetapi pengembangan perangkat lunak profesional adalah kategori yang sepenuhnya berbeda: memproses pembayaran, menyimpan informasi sensitif, mengelola infrastruktur, dan menjalankan sistem yang diandalkan orang setiap hari
• Pelanggan secara wajar mengharapkan sistem bekerja dengan benar, tetap benar saat berevolusi, dan bahwa orang yang membangunnya memahami cara sistem tersebut bekerja
• Harapan ini adalah syarat dasar rekayasa profesional, titik di mana disiplin dan keahlian menjadi tak terelakkan

Kode tidak pernah menjadi bagian yang sulit

• Anggapan bahwa menulis kode adalah bagian tersulit dari pengembangan perangkat lunak adalah kesalahpahaman lama
• Mengetik syntax selalu merupakan bagian yang paling tidak menarik dari membangun sistem; pekerjaan yang benar-benar sulit adalah menentukan perilaku sistem, merancang interaksi antar komponen, dan menjaga sistem tetap dapat dipahami saat kompleksitas meningkat
• Itu bukan masalah coding, melainkan masalah rekayasa
• Berkurangnya usaha untuk memproduksi kode tidak menghilangkan masalah-masalah ini; itu hanya memungkinkan sistem yang lebih besar dan lebih kompleks dibuat lebih cepat
• Menyebut ini sebagai peningkatan produktivitas adalah ilusi: bebannya hanya berpindah ke tempat lain
  • Beban kognitif yang dibutuhkan untuk code review dan menangani kode hasil generasi bisa menjadi faktor penurun produktivitas yang lebih besar daripada menulis kode itu sendiri
  • Jika yang dipercepat hanya kecepatannya sementara perilaku dasarnya belum dipahami dengan cukup baik, maka yang terjadi hanyalah percepatan menuju titik ketika kompleksitas menjadi tak tertangani, dan hasilnya pun salah

Pola yang pernah terlihat: era Visual Basic

• Pada 1990-an, janji serupa juga muncul untuk Visual Basic: bahwa pemrograman telah didemokratisasi dan pengetahuan khusus tidak lagi diperlukan
• Memang, Visual Basic memungkinkan banyak aplikasi dibuat yang mungkin tidak akan pernah ada tanpanya
• Namun ketika sistem membesar dan makin saling terhubung, orang kembali menyadari bahwa menghasilkan artefak perangkat lunak tidak sama dengan merekayasa sistem yang dapat diandalkan
• Saat ini kita melihat versi yang diperbesar dari pola yang sama: hambatan yang diturunkan bukan hanya untuk membangun aplikasi, tetapi untuk produksi kode itu sendiri
• Dari sinilah muncul keyakinan menggoda bahwa keahlian tidak lagi diperlukan

Masalah alignment

• Perangkat lunak yang andal bergantung pada alignment yang hampir tidak pernah dibahas di luar rekayasa
• Sistem dimulai dari gagasan tentang perilakunya → didokumentasikan sebagai spesifikasi (specification) → engineer menerjemahkan spesifikasi itu menjadi pengujian dan kode produksi
• Agar keandalan jangka panjang sistem terjaga, ketiga hal ini—spesifikasi, pengujian, dan implementasi—harus selalu tetap selaras
• Ketika ketiganya mulai menyimpang, sistem perlahan kehilangan integritasnya
  • Spesifikasi menggambarkan perilaku yang sudah tidak lagi diimplementasikan
  • Pengujian hanya memverifikasi sebagian perilaku dan melewatkan sisanya
  • Engineer yang bergabung belakangan membaca kode dan menebak perilaku sistem, entah itu mencerminkan desain asli atau tidak
• Seiring waktu, tebakan-tebakan ini menumpuk, dan pada akhirnya sistem menjadi sesuatu yang tak benar-benar dipahami siapa pun
• Fenomena ini disebut "spec drift": penjelasan tentang sistem dan sistem itu sendiri makin lama makin menjauh satu sama lain
  • Kode sudah berubah, tetapi spesifikasinya tetap
  • Spesifikasi sudah berevolusi, tetapi pengujiannya tetap diam
  • Perilaku berubah sedikit demi sedikit hingga tak ada lagi yang yakin apa maksud awalnya
• Saat alignment rusak, keandalan tidak akan bertahan lama

AI mempercepat drift

• LLM mempercepat produksi kode secara dramatis, dan di situlah letak kekuatan terbesarnya sekaligus titik munculnya risiko
• Ketika kode diproduksi lebih cepat daripada disiplin rekayasa yang mengelilinginya, kekuatan yang menciptakan spec drift ikut dipercepat
• Perubahan yang dulu memerlukan pemikiran hati-hati dan implementasi manual kini bisa dilakukan dalam hitungan detik
• Seluruh bagian sistem dapat ditulis ulang sebelum siapa pun sempat memeriksa apakah perilakunya masih sesuai dengan spesifikasi
• Kodenya mungkin tampak masuk akal, bisa dikompilasi, enak dibaca, dan bahkan lolos pengujian yang ada, tetapi alignment yang selama ini mengatur sistem mungkin sudah hilang
• Apa yang tampak seperti produktivitas sebenarnya adalah kemampuan untuk bergerak menuju misalignment lebih cepat daripada sebelumnya

Area di mana AI benar-benar membantu

• LLM bukanlah kesalahan, dan bila digunakan dengan penuh pertimbangan, ia bisa secara dramatis meningkatkan cara engineer mengeksplorasi dan merancang sistem
• Area yang sangat menonjol: penalaran tentang masalah, mengeksplorasi alternatif desain, merangkum sistem kompleks, dan menghasilkan draf yang mempercepat tahap awal implementasi
• Area yang sulit: bidang yang menuntut disiplin dan konsistensi ketat dalam jangka waktu panjang
• Menjaga alignment antara spesifikasi, pengujian, dan implementasi tetap merupakan tanggung jawab rekayasa, dan tidak ada alat yang bisa menggantikan tanggung jawab ini meskipun bisa mendukungnya
• Peluang yang sebenarnya adalah menggunakan LLM bukan untuk diam-diam menggantikan proses rekayasa, melainkan untuk memperkuatnya

Rekayasa perangkat lunak yang bersifat percakapan

• Salah satu kemungkinan menarik yang dibuka LLM: sebagian rekayasa perangkat lunak dapat menjadi lebih bersifat percakapan (conversational)
• Selama puluhan tahun, alat desain sistem bersifat kaku: spesifikasi adalah dokumen, arsitektur adalah diagram, dan penalaran yang mengarah ke sana hilang dalam rapat atau percakapan lorong
• Dengan LLM, engineer dapat mengeksplorasi ide secara interaktif, menguji asumsi, dan mengerjakan desain dengan cara yang lebih dekat ke percakapan alami
• Namun percakapan bukanlah rekayasa: percakapan adalah cara mengeksplorasi ide, sedangkan rekayasa dimulai saat ide ditangkap dalam bentuk yang bisa diverifikasi, diuji, dan dipelihara
• Tantangan bagi alat rekayasa generasi berikutnya adalah mempelajari cara menghubungkan dua dunia ini tanpa kehilangan disiplin yang dibutuhkan sistem kompleks

Keahlian tetap penting

• Perangkat lunak profesional tetap membutuhkan engineer yang memahami cara kerja nyata sistem yang mereka bangun
• Alat dapat mempercepat pengembangan, tetapi tidak dapat menghilangkan keahlian yang dibutuhkan untuk merancang, menalar, dan memelihara sistem kompleks
• Industri berada sangat dekat dengan titik berbahaya untuk melupakan fakta ini
• LLM dapat membuat engineer berpengalaman jauh lebih produktif, tetapi tidak menggantikan disiplin rekayasa yang diperlukan untuk membangun sistem yang andal
• Kita harus menggunakan alat-alat ini secara efektif, bukan dengan menyembahnya

[GN⁺]

Komentar Hacker News

• Saya tidak setuju dengan premis tulisannya. Menurut saya, rekayasa secara keseluruhan memang jadi lebih mudah, baik ke arah yang baik maupun buruk. Dulu juga saya sering melihat orang yang menumpuk null check tanpa benar-benar paham. Sekarang itu hanya diperluas dalam skala besar. Sebaliknya, rekayasa yang hebat juga makin diperkuat; saya pernah melihat fitur yang dulu butuh berminggu-minggu kini bisa dibuat dalam hitungan hari

  • Menurut saya tulisannya agak berlebihan. Rekayasa yang baik juga bisa dibantu agen berbasis LLM, tetapi validasi hasil tetap menjadi tugas manusia. Rekayasa yang buruk melewati tahap itu, jadi dari sudut pandang hukum Amdahl, LLM jauh lebih mempercepat rekayasa yang buruk
  • Rekayasa yang buruk jadi jauh lebih mudah, dan rekayasa yang baik jadi sedikit lebih mudah. Akibatnya, orang yang dulu melakukan rekayasa yang baik sekarang malah membuat rekayasa buruk tiga kali lebih banyak
  • Dalam pengembangan aplikasi enterprise, saya pernah melihat mock test yang hanya memeriksa apakah nilai yang dikembalikan sesuai harapan. Saya jadi bertanya, apa sebenarnya maknanya
  • Mudah lupa bahwa LLM bukan oracle ajaib. Cara kita memperlakukan keluarannya menentukan kualitas hasil akhirnya. Kadang memang bisa langsung dipakai, tetapi kebanyakan tetap perlu revisi. Mudah sekali terjebak pada pola pikir “kalau LLM bilang begitu berarti benar,” dan itu membuat rekayasa yang buruk jadi lebih mudah
  • Bahkan kalau setuju dengan tulisan aslinya, pada praktiknya ada banyak ranah aplikasi di mana kualitas perangkat lunak, baik atau buruk, sebenarnya tidak terlalu penting. Sering kali cukup asal bisa jalan

• Ada kasus di mana bahkan seratus unit test pun sulit membuktikan kebenaran kode. Kebanyakan pengembang tidak tahu apa yang sudah cukup. Orang yang banyak memakai vibe coding bahkan menyerahkan pengujian kepada mesin. Saat masuk ke tahap perancangan sistem, dibutuhkan desain yang bisa menjamin keamanan dan invarian temporal secara menyeluruh. Tetapi kebanyakan orang hanya menggambar kotak dan panah sambil mengutip “best practice.” Perangkat lunak semakin terasa seperti ilmu alam, seperti dalam efek Sussman, sehingga kita menghabiskan lebih banyak waktu untuk observasi. Memakai GenAI sebagai alat bisa berguna, tetapi berhenti berpikir lalu bergantung pada alat itu berbahaya

  • Saya bahkan tidak tahu apa itu unit test, tetapi berkat AI saya bisa membuat program yang sangat membantu pekerjaan nyata saya. Programmer elite bahkan tidak mau membalas email meski dibayar

• Setiap beberapa tahun, setiap kali alat baru muncul, selalu ada klaim bahwa “bagian sulit dari rekayasa perangkat lunak sudah terpecahkan.” Produktivitas melonjak, demonya mengesankan, dan industri saling memuji diri sendiri. Tetapi tak lama kemudian pengurangan tenaga kerja menyusul. Akan bagus kalau ini benar-benar terobosan, tetapi kalau hasil akhirnya PHK, maka tidak ada artinya. Pada akhirnya pertanyaannya tetap sama — jika tujuannya memang mengurangi pekerjaan, lalu apa visi perusahaan ketika orang tidak lagi bisa mencari nafkah?

  • Tujuannya bukanlah lapangan kerja individu. Tujuan akhirnya adalah membangun AGI, dan dalam proses itu gaji serta lapangan kerja developer tampaknya sudah melewati puncaknya. Hanya beberapa super developer AI yang menjadi pengecualian
  • Saya rasa mustahil menghilangkan kompleksitas. Realitas dan manusia itu sendiri kompleks. Gagasan bahwa perangkat lunak bisa sederhana itu tidak realistis. Kalau dilihat dari sudut pandang yang lebih besar, tujuan akhirnya tampak seperti lenyapnya kelas menengah
  • Kalau tidak ada permintaan, ya harus mengerjakan hal lain. Kalau menolak, ya kelaparan
  • Kapitalisme bergantung pada keberadaan kelas bawah. Mereka memberi tekanan pada pekerja lain agar menerima upah lebih rendah dan kondisi kerja lebih buruk. Para programmer hanya sempat terlindungi dari kenyataan itu untuk sementara. Struktur ini juga terhubung dengan tenaga kerja migran, di mana perusahaan bisa memerintahkan pekerjaan berbahaya dan mendeportasi mereka jika tidak patuh. Pada akhirnya, semua ini adalah sistem untuk menurunkan biaya tenaga kerja

• Saya setuju dengan pernyataan bahwa “coding memang bukan bagian yang sulit sejak awal.” Para ahli sudah tahu apa yang ingin mereka bangun; yang merepotkan hanya pekerjaan berulang

  • Pemeliharaan kode tetap merupakan persoalan manusia dan pengalaman. Pertanyaan “kode seperti apa yang sebaiknya tidak ditulis” kini menjadi lebih penting. Sekarang pembuatan kode terlalu mudah, jadi kita hidup di era yang sangat mudah memproduksi spaghetti code
  • Inti perdebatan soal LLM ada di sini. Sebagian orang hanya menginginkan hasil akhir, sementara sebagian lain menginginkan kemudahan pemeliharaan dan stabilitas. Keduanya sama-sama dibutuhkan, dan peran prototipe serta produksi akan terpisah secara alami
  • Orang yang benar-benar mahir tetap ingin melakukannya sendiri. Bukan karena LLM; dari dulu memang begitu. Justru orang yang selalu bilang “memasukkan sintaks itu membosankan” adalah pihak yang paling diuntungkan. Bagi saya, mengetik itu sendiri adalah satu-satunya bagian yang menarik

• Developer junior yang terlalu bergantung pada AI akan membayar harganya nanti karena tidak memahami dasar-dasarnya. Pada akhirnya hanya orang yang berpengalaman yang akan punya keamanan kerja

• Sulit untuk setuju dengan klaim bahwa “menulis kode bukan bagian yang sulit.” Memang tidak selalu sulit, tetapi ketika ada batas waktu, penulisan kode menjadi bottleneck. AI memungkinkan percobaan yang dulu mustahil dilakukan, dan memberi kita lebih banyak waktu untuk rekayasa

  • Ada kontradiksi karena sambil bilang “sulit untuk dianggap serius,” pada akhirnya tetap setuju. Teks aslinya jauh lebih penuh nuansa yang rinci
  • Menulis kode adalah pekerjaan yang paling memakan waktu, dan AI justru menegaskan itu. Siapa pun bisa mengetik, tetapi kemampuan membaca kode adalah keterampilan yang sesungguhnya. Seperti penebang pohon yang memegang gergaji mesin alih-alih kapak, efisiensinya naik tetapi potensi kerusakannya juga lebih besar

• AI juga membuat rekayasa yang baik menjadi lebih mudah. Pada akhirnya, ia hanyalah penguat perilaku

  • Engineer yang baik jadi bisa bekerja lebih baik, tetapi kebanyakan orang bahkan tidak tahu apa itu property testing. Jadi saya ragu seberapa bergunanya AI bagi orang-orang seperti itu
  • Internet menghubungkan pengetahuan dunia, tetapi pada akhirnya manusia tenggelam dalam obrolan kosong dan konten yang menguras perhatian. Jika melihat sifat dasar manusia, AI kemungkinan akan menempuh jalan yang sama
  • Masalah kreatif sering kali justru terselesaikan dalam proses menulis kode sendiri. Jika memakai AI, sirkuit otak itu jadi kurang aktif
  • Data seperti laporan DORA juga mendukung hal ini
  • Kalimat “AI adalah penguat perilaku yang sudah ada” memang sangat tepat. Rasanya ingin saya pakai apa adanya

• Saya skeptis terhadap AI, tetapi saya tidak merasa AI akan merebut pekerjaan rekan-rekan saya. Sebaliknya, AI menghemat waktu saya. Saya memakainya sebagai alat riset yang lebih baik daripada Google, dan juga berguna untuk menjelajahi codebase, membuat helper function, serta meninjau error

  • Saya juga setuju. Menurut saya, cara inilah yang pada akhirnya menjadi tujuan akhir pemanfaatan AI

• Belakangan ini batas antara rekayasa perangkat lunak dan riset makin jelas. AI adalah alat yang luar biasa untuk riset eksploratif. Kalau terlihat ada potensi, barulah saya beralih ke mode SWE untuk memahami dan memodifikasi kode, lalu memolesnya dengan pengalaman saya sendiri. Peran AI memang terbatas, tetapi tetap berguna

  • LLM bisa menjelajahi cakupan pengetahuan yang jauh lebih luas daripada manusia secara instan. Tetapi keputusan akhir tetap bergantung pada selera dan kepekaan kualitas manusia

• Kira-kira perlu berapa model lagi sampai orang-orang seperti ini (para pesimis) akhirnya menyerah? Dua kali? Tiga kali?