- Sistem teknologi modern telah berkembang menjadi struktur yang terlalu kompleks sehingga tidak bisa dipahami sepenuhnya oleh satu individu
- Seiring meningkatnya pengembangan perangkat lunak dan pemanfaatan AI, makin banyak kasus ketika pengembang membangun sesuatu tanpa memahami mekanisme internalnya
- Simon Wardley menyoroti risiko membangun sistem tanpa pemahaman, Adam Jacob menilai AI sedang mengubah cara pengembangan, dan Bruce Perens menunjukkan bahwa kompleksitas sudah melampaui batas sejak lama
- Louis Bucciarelli melalui contoh sistem telepon menunjukkan bahwa teknologi terjalin dalam banyak lapisan sehingga tak seorang pun dapat mencapai pemahaman yang sepenuhnya utuh
- Tulisan ini menekankan bahwa AI memang memperdalam kompleksitas ini, tetapi pada kenyataannya manusia sudah lama berurusan dengan teknologi hanya lewat pemahaman parsial
Kompleksitas Teknologi dan Batas Pemahaman
- Setelah kemunduran Twitter, diskusi tentang pemahaman teknologi dan kompleksitas menjadi ramai di LinkedIn
- Postingan Simon Wardley, Adam Jacob, dan Bruce Perens diperkenalkan sebagai topik yang saling berkaitan
- Wardley memperingatkan bahaya membangun sistem tanpa mengetahui prinsip dasarnya
- Istilah “Magic” digunakan secara kritis untuk menyebut framework yang menyembunyikan cara kerja internal, dengan Ruby on Rails disebut sebagai contoh representatif
- Jacob menyoroti bahwa AI sedang mengubah cara pengembangan perangkat lunak secara mendasar
- AI meningkatkan efisiensi, tetapi juga cenderung membuat pengembang bekerja tanpa memahami lapisan di bawahnya
- Perens menyebut bahwa situasi yang dikhawatirkan Wardley sebenarnya sudah menjadi kenyataan
- Karena kompleksitas CPU dan sistem operasi modern, banyak pengembang salah memahami prinsip kerja yang sebenarnya
Contoh ‘Telepon’ dari Louis Bucciarelli
- Dalam buku tahun 1994 Designing Engineers, Bucciarelli membahas batas literasi teknis
- Kebanyakan orang tidak mampu menjelaskan cara kerja telepon pada tingkat fisik
- Ada unsur berlapis seperti routing, pemrosesan sinyal, transmisi satelit, operasi perusahaan, dan struktur regulasi yang saling terkait dalam jaringan komunikasi
- Ia sampai pada kesimpulan bahwa “tak seorang pun benar-benar tahu sepenuhnya bagaimana teleponnya bekerja”
- Ini melambangkan bahwa sistem teknologi yang kompleks melampaui kemampuan manusia untuk memahami secara utuh
Wawancara Teknis dan ‘Batas Pengetahuan’
- Penulis mengenang percakapannya dengan Brendan Gregg saat bekerja di Netflix
- Gregg mengatakan bahwa dalam wawancara ia menilai batas pengetahuan kandidat dan bagaimana mereka meresponsnya
- Ia melakukan wawancara dengan asumsi bahwa “tak seorang pun memahami seluruh sistem secara sempurna”
- Pendekatan ini menunjukkan bahwa sikap mengakui apa yang tidak diketahui sama pentingnya dengan kemampuan teknis itu sendiri
Hakikat Kompleksitas dan Dampak AI
- Pandangan Wardley, Jacob, Perens, dan Bucciarelli mengungkap keniscayaan kompleksitas dari lapisan yang berbeda-beda
- Wardley: risiko membangun tanpa pemahaman
- Jacob: efisiensi dan jarak yang dibawa AI
- Perens: realitas kompleksitas yang memang sudah ada
- Bucciarelli: kemustahilan memahami keseluruhan sistem
- Tulisan ini mengakui bahwa AI akan memperparah masalah ini, sambil mengingatkan kembali pada realitas lama manusia yang selalu menangani teknologi dengan pemahaman parsial
Ringkasan Diskusi Pembaca
- Di kolom komentar, banyak yang mengungkap kekhawatiran bahwa AI melemahkan proses belajar dan pemahaman
- Sebagian berpendapat bahwa “LLM menulis kode sebagai pengganti manusia sehingga rantai pemahaman terputus”
- Wardley menjelaskan bahwa “sebelumnya pemahaman dipertahankan dalam rantai yang hierarkis, tetapi LLM menghapus rantai itu”
- Pembaca lain membantah bahwa terlalu dini untuk memastikan “manfaat AI lebih besar daripada risikonya”
- Secara umum, hilangnya pemahaman teknis di era AI dan terputusnya proses belajar muncul sebagai poin utama diskusi
1 komentar
Komentar Hacker News
Yang mengkhawatirkan dalam pemrograman belakangan ini adalah makin banyak "pengembangan lapisan tengah": tidak paham lapisan atas (tujuan produk) maupun lapisan bawah (cara implementasinya)
Dulu, meski tidak paham bisnisnya, setidaknya kita mengerti arti kodenya; sekarang ada suasana seolah tidak masalah bahkan jika tidak tahu bagaimana kode itu bekerja
Saat memakai Claude, terasa kemampuan memahami konteks perlahan menurun. Dalam budaya pengembangan yang merasa cukup asal tes lolos dan tombol bisa diklik, aku merasa seperti tidak ada lagi yang bisa kupelajari atau kusumbangkan
Terutama di perusahaan besar, transparansi sering kurang. Pernah juga aku lembur demi mengejar tenggat, padahal tanpa sepengetahuanku jadwalnya sudah diundur
Kalau aku diperlakukan hanya sebagai alat, ya aku akan menjalankan peran itu saja. Tapi kalau benar-benar menginginkan ownership, harus ada kursi di meja pengambilan keputusan
Dulu banyak waktu habis untuk pekerjaan setup yang berulang, sekarang aku bisa fokus hanya pada fitur inti. Karena itu, aku malah bisa lebih baik menjaga gambaran arsitektur keseluruhan di kepala
Misalnya, memilih beberapa baris di IDE lalu mengatakan dengan suara, "ubah bagian ini jadi seperti ini," dan hasilnya langsung diterapkan
Kalau cukup cepat, kontrol mouse+suara juga akan sangat bagus sebagai alat aksesibilitas
Aku malah berpikir LLM bisa membantu mengurangi kompleksitas seperti ini. Aku suka abstraksi yang pas, tapi tidak suka benar-benar tidak tahu apa yang terjadi di dalamnya
Tulisan ini membahas fenomena orang memakai abstraksi (abstraction) tanpa memahami bagian dalamnya
Tapi itu adalah proses perkembangan yang wajar. Seseorang merancang abstraksi itu dan membuatnya bisa dipakai oleh lapisan di atas
Logika seperti "aku tidak tahu driver Wi-Fi, jadi tidak perlu tahu kode juga" jelas tidak berlaku
Dulu kita mengasah cara berpikir dengan langsung menangani 'kompleksitas yang memang perlu', tetapi sekarang sering kali hanya menjadi penghubung pipa saja
Solusinya adalah membungkus abstraksi itu dengan DSL (bahasa spesifik domain) alih-alih bahasa serbaguna. Untuk SaaS, menurutku pendekatan DSL-first lebih baik daripada API-first
Aku tidak merasa AI lebih buruk dari itu. Yang penting adalah memahami abstraksi yang menjadi fondasi kita
Dependency tree sebenarnya yang paling sering menimbulkan masalah besar
Lihat saja proyek Node.js, bisa punya ratusan paket dependensi. Biasanya tak masalah walau kita tidak tahu isi dalamnya, tetapi jadi berbahaya jika antarmukanya sering rusak
Banyak tim juga tidak melacak EOL (akhir dukungan) atau kerentanannya. Realitanya, bahkan pertanyaan "ini masih dipelihara tidak?" pun sering tidak terjawab
Tapi bahkan sebelum AI pun, sudah banyak proyek yang jatuh ke dependency hell akibat konflik versi
Orang memang tidak perlu tahu segalanya, tetapi ketidaktahuan yang membuat dasar hilang itu berbahaya
Ambil contoh memasak: kita tidak harus menanam gandum sendiri, tapi kalau bahkan tidak tahu cara menggoreng telur, itu masalah
Kalau perusahaan memasak semua makanan dengan standar yang seragam, apakah itu kemajuan atau justru kemunduran?
Kalau suatu hari robot sepenuhnya menggantikan produksi makanan, mungkin tidak tahu cara memasak pun tak lagi penting
Toh untuk menghindari ketergantungan, bukan berarti kita harus paham sampai ilmu materialnya juga, kan?
Lapisan bawah seperti instruksi CPU dan cache sudah puluhan tahun diverifikasi dan didokumentasikan dengan sangat baik
Sebaliknya, kode buatan LLM tidak bisa dipercaya sampai tingkat itu, dan mungkin besok pun sudah perlu direfaktor
Aku memang tidak tahu detail kerja lapisan bawah, tetapi aku paham bagaimana kodeku sendiri bekerja
Tidak tahu lapisan di bawah itu sangat berbeda dengan tidak tahu area tanggung jawabku sendiri
Sekarang, yang benar-benar berbahaya adalah munculnya potongan kode yang tidak dipahami siapa pun
Aku tidak setuju bahwa AI membuat keadaan jadi lebih buruk
Justru karena LLM telah mempelajari hampir semua pengetahuan, ia bisa menjelaskan secara sistematis pertanyaan seperti "bagaimana telepon bekerja?"
Manusia punya batasan karena bahkan tidak tahu apa yang tidak diketahuinya, tetapi LLM bisa menangani hampir semua pengetahuan yang pernah diekspresikan dalam bahasa
Tentu penalaran dan generasi kodenya masih lemah, tetapi kemampuan mengintegrasikan pengetahuan lebih unggul daripada manusia
Itu tidak bisa menggantikan dokumentasi asli. Tapi seperti manusia, ia sangat berguna untuk memberi tahu "apa yang perlu dicari"
Desain yang baik adalah yang membuat sistem tetap bekerja meski tidak perlu memahami keseluruhannya
Masalahnya bukan sistem buatan AI, melainkan kita masih belum benar-benar memahami mode kegagalan dan batasannya
Pada akhirnya, yang penting adalah kemampuan desain organisasional untuk mengoordinasikan manusia dan AI agar bisa membangun sistem yang dibutuhkan
Aku memang tidak sepenuhnya memahami bagian dalam komputer, tetapi aku menyelesaikan masalah dengan otomatisasi skrip yang praktis
Tanpa mempelajari assembly x86 pun, aku bisa mengelola infrastruktur dengan Python
Namun menurutku, pengembang berpengalaman punya tanggung jawab untuk membagikan pengetahuan itu. Aku juga ingin meneruskan peran itu suatu hari nanti
Jangan kehilangan rasa ingin tahu, dan aktiflah berdiskusi dengan pengembang senior
Tapi kenyataan bahwa pentingnya pemahaman fondasi terus diabaikan, betul-betul membuat frustrasi
Aku benar-benar bisa menjawab pertanyaan seperti "apa yang terjadi saat kita memasukkan URL?"
Aku pernah bekerja sebagai teknisi reaktor kapal selam Angkatan Laut AS, mempelajari semuanya dari teori elektronika sampai troubleshooting sistem
Setelah beralih ke IT pun, aku tetap menggali sampai tuntas lewat dokumentasi dan eksperimen dengan sikap yang sama
Berkat kebiasaan ini, menghubungkan pengetahuan acak sangat membantu saat memecahkan masalah
Dokumen wiki VMEbus juga layak dilihat
Hanya saja, aku memang tipe orang yang tidak tahan kalau ada hal yang tidak kupahami, jadi mungkin aku kasus yang agak pengecualian