Mengapa Software Modern Semakin Rapuh dan Tidak Dikenali

Apakah Anda masih memahami setiap baris kode yang menjalankan produk Anda hari ini?

Pertanyaan itu terdengar sederhana, tapi jawabannya mungkin mengecewakan. Di era di mana LLM bisa menghasilkan ratusan baris kode dalam hitungan detik, kita sedang menyaksikan pergeseran fundamental dalam cara manusia berhubungan dengan software yang mereka bangun. Bukan lagi sang pencipta yang memahami ciptaannya, melainkan operator yang menaungi mesin yang bahkan ia sendiri tidak sepenuhnya paham cara kerjanya.

Fenomena ini bukan sekadar masalah teknis. Ini adalah krisis epistemologi dalam software engineering. Sebuah paper terbaru dari arXiv berjudul "Constraint Decay: The Fragility of LLM Agents in Back End Code Generation" dengan gamblang menguraikan bagaimana agent AI menghasilkan kode backend yang terlihat fungsional di permukaan, namun rapuh di bawah tekanan edge cases dan constraints nyata. LLM agents cenderung "melupakan" constraint seiring waktu, menciptakan sistem yang tampak solid namun runtuh ketika diuji dengan skenario dunia nyata.

Hasilnya? Stack teknologi yang semakin tinggi, semakin kompleks, dan semakin tidak transparan.

Abstraksi yang Berubah menjadi Obskuritas

Dulu, programmer menulis assembly. Kemudian C. Lalu Python, JavaScript, dan framework di atas framework. Setiap lapisan abstraksi dimaksudkan untuk menyederhanakan. Tapi seperti yang diperingatkan dalam esai klasik "The Law of Leaky Abstractions" oleh Joel Spolsky, abstraksi bocor. Dan ketika lapisan demi lapisan menumpuk tanpa pemahaman mendalam tentang fondasinya, yang tersisa bukan kesederhanaan, melainkan kegelapan.

Saya sering teringat tulisan "I Keep Bouncing Off the Scheme Language" yang merefleksikan frustrasi seorang developer berpengalaman menghadapi bahasa yang secara filosofis elegan namun praktisnya menuntut pemahaman mendalam tentang mekanisme internal. Bukan karena Scheme buruk, tapi karena software yang benar-benar baik menuntut keterlibatan kognitif yang seringkali kita hindari di era instant gratification.

Kita sekarang hidup dalam kultur yang menghargai velocity lebih dari validity. Fitur harus rilis minggu ini. MVP harus jadi besok. Dan vibe coding memang memberikan kecepatan luar biasa. Tapi kecepatan tanpa arah hanya membuat kita tiba lebih cepat di tempat yang salah.

Revolusi Vibe Coding dan Kemunduran Software Craftsmanship

Konsep vibe coding memang revolusioner. Siapa yang menyangka kita bisa membangun aplikasi hanya dengan mengobrol? Tapi di balik euforia tersebut, ada pertanyaan tak terucap: apakah kita masih bisa disebut software engineer jika kita tidak lagi membaca, memahami, atau bahkan men-debug kode yang kita "tulis"?

Microsoft baru-baru ini merilis kode sumber 6502 BASIC ke domain publik. Kode dari tahun 1978 itu, meski primitif, memiliki keindahan transparansi: setiap baris bisa dipahami, setiap register bisa dilacak, setiap bug bisa diprediksi. Kontrasnya dengan sistem modern yang dibangun oleh committee of LLM agents dan microservices tak terhingga sangatlah mencolok. Kita bergerak dari simplicity yang elegan ke complexity yang tersembunyi.

Bukan berarti teknologi baru jahat. LLM adalah tool yang luar biasa. Tapi tool yang hebat pada tangan yang tidak memahami bahaya dan batasannya bisa menjadi senjata penghancur diri sendiri. Seperti seorang tukang kayu yang diberikan mesin CNC canggih tanpa pernah belajar tentang serat kayu, hasilnya mungkin presisi tinggi tapi struktur rapuh.

Kompleksitas, Burnout, dan Harga Tersembunyi

Fred Brooks dalam buku klasiknya The Mythical Man-Month membedakan antara accidental complexity dan essential complexity. Essential complexity adalah kompleksitas inheren dari masalah yang kita selesaikan. Accidental complexity adalah kompleksitas yang kita tambahkan sendiri melalui pilihan teknologi, arsitektur, atau proses yang buruk. Ironinya, di era modern ini, sebagian besar kompleksitas dalam codebase bukan berasal dari masalahnya, tapi dari solusi yang kita pilih.

Setiap kali kita menambahkan microservice baru, setiap kali kita memilih framework yang lebih besar, setiap kali kita membiarkan LLM menghasilkan boilerplate tanpa review, kita sedang menambah accidental complexity. Dan kompleksitas ini memiliki bunga. Bunga yang dibayar dalam bentuk burnout, waktu on-call yang tak pernah berakhir, dan keputusan teknis yang semakin terasa seperti lempar dadu daripada analisis rasional.

Saya pernah berdiskusi dengan seorang tech lead di startup Jakarta yang mengaku codebase mereka tumbuh 400 persen dalam enam bulan berkat AI-assisted development. Tapi coverage test turun 60 persen, incident rate naik tiga kali lipat, dan waktu onboarding engineer baru dari seminggu menjadi tiga bulan. Kecepatan pengembangan meningkat, tapi kecepatan pemeliharaan melambat drastis. Ini bukan trade-off, ini adalah pinjaman dengan bunga tinggi yang belum jatuh tempo.

Menuju Software yang Dikenali Kembali

Jalan keluarnya bukan dengan menolak progres, tapi dengan menuntut literasi. Kita perlu kembali ke tradisi deep work dalam engineering. Memahami fondasi. Membaca kode yang dihasilkan LLM bukan sekadar scan, tapi analisis kritis. Menanyakan: constraint apa yang terlewat? edge case apa yang diabaikan? asumsi apa yang dibuat oleh model tanpa kita sadari?

Seperti yang ditunjukkan dalam penelitian Constraint Decay, fragilitas bukan datang dari AI-nya, tapi dari human oversight yang lalai. Ketika kita menyerahkan reasoning sepenuhnya kepada mesin, kita tidak lagi membangun software. Kita sedang merakit kotak hitam yang entah mengapa berfungsi, sampai suatu hari tiba-tiba tidak.

Software yang baik adalah software yang bisa dipahami, di-debug, dan diubah oleh manusia. Bukan oleh model generasi berikutnya, tapi oleh rekan tim kita, oleh diri kita enam bulan mendatang, oleh engineer baru yang bergabung ke tim tanpa konteks penuh tentang prompt history kita.

Dunia software tidak perlu kembali ke era assembly atau monolith. Tapi dunia ini perlu developer yang masih percaya bahwa memahami adalah bagian integral dari membangun. Bukan sekadar operator, tapi craftsman. Bukan sekadar prompt engineer, tapi software engineer sejati yang kode-nya bisa dipertanggungjawabkan, dijelaskan, dan diwariskan.

Jadi, apakah kita siap mengakui bahwa kemudahan tertinggi mungkin adalah jebakan terbesar? Bahwa software terbaik bukan yang paling cepat dibangun, tapi yang paling tahan lama dipelihara? Dan apakah Anda, developer yang sedang membaca ini, masih ingin memahami kode Anda sendiri, atau puas menjadi operator prompt yang kebetulan memegang kunci produksi?