- Agen AI bukan benar-benar melakukan pemrograman, melainkan meniru distribusi pemrograman, dan output yang rusak menjadi makin sulit dikenali
- Sudah dicoba untuk menulis sebagian tinygrad dan me-reverse chip USB <-> PCIe, tetapi tetap ada kecurigaan bahwa melakukannya sendiri mungkin akan lebih baik dan lebih cepat
- Agen mempercepat kemajuan di awal, tetapi pada tahap penyelesaian justru membuat kita bergantung pada percobaan berulang seperti menarik tuas mesin slot, dan gagal mencapai akhir
- Organisasi besar bisa mengalami kerusakan kualitas yang lebih besar daripada individu berperforma tinggi karena loop umpan balik yang lambat dan output 10x tanpa pemeriksaan diri
- AI berguna untuk pencarian dan prototipe cepat, tetapi sulit dianggap sebagai software engineer sungguhan, dan yang penting adalah tahu kapan harus memakainya dan kapan tidak
Kritik utama terhadap agen AI
- Arus untuk mengadopsi agen AI dalam pengembangan perangkat lunak bisa menjadi kesalahan yang sangat mahal, dan agen lebih dekat dengan model statistik canggih yang meniru distribusi pemrograman, bukan pemrograman itu sendiri
- Hasil keluarannya rusak, tetapi rusak dengan cara yang makin sulit dideteksi, dan semakin akurat model statistiknya, semakin sulit pula masalah seperti ini dikenali
- Selama 6 bulan terakhir, agen digunakan untuk menulis sebagian tinygrad dan me-reverse chip USB <-> PCIe, tetapi tetap ada kecurigaan bahwa mengerjakannya sendiri mungkin akan lebih baik dan lebih cepat
- Agen mempercepat kemajuan awal, tetapi pada tahap akhir membuat orang terus berharap hasilnya membaik dengan mengulanginya seperti menarik tuas mesin slot, tanpa pernah benar-benar sampai selesai
- Karena sudah mencoba banyak model, harness, dan prompt, bantahan bahwa ini “dipakai dengan cara yang salah” terdengar kurang meyakinkan, dan mirip dengan mengatakan bahwa kita bisa menang mesin slot jika bertaruh dengan cara tertentu
- AI sendiri tetap berguna; dalam banyak pencarian ia bekerja seperti Google yang lebih baik, dan untuk prototipe cepat yang tidak terlalu peduli pada tingkat penyelesaian, ia sangat cepat
- Namun sulit menganggapnya sebagai software engineer, dan ia bahkan tidak mendekati standar perusahaan mana pun yang pernah diajak bekerja sama; yang penting adalah mengetahui kapan memakainya dan kapan tidak
Dampak pada organisasi dan kualitas
- AFL menemukan lebih banyak bug daripada LLM, tetapi para developer tidak takut kehilangan status, dan catur serta Go juga justru makin populer setelah AI, jadi sulit melihat kritik terhadap AI semata-mata sebagai kecemasan status
- Masa depan dengan asisten robot yang andal untuk merapikan kode layak dinantikan, tetapi tampaknya ketakutan akan kehilangan dimanfaatkan untuk menjual agen dengan cara yang dapat menggerakkan perusahaan-perusahaan besar
- Dibanding individu berperforma tinggi atau organisasi kecil, organisasi besar kemungkinan akan mengalami kerusakan yang lebih besar akibat agen
- Orang berperforma tinggi dapat memperbaiki kesalahan, cenderung menyadari saat outputnya rapuh, dan kecuali pada area yang sangat terbatas, tetap menjaga cara kerja dengan membaca dan memahami setiap baris secara cermat
- Organisasi besar memiliki loop umpan balik yang lambat dan alignment yang lemah, sehingga ketika orang berkinerja rendah menghasilkan output 10x dengan agen tanpa pemeriksaan diri, kualitas rata-rata output bisa menurun
- Agen akan menghasilkan lebih banyak kode, aplikasi, dan fitur daripada sebelumnya, tetapi ini bisa menjadi era penumpukan massal output rapuh alih-alih permata berkualitas tinggi
- Cerita bahwa Apple mendorong semua engineer memakai AI seharusnya dilihat bukan sebagai harapan abstrak, melainkan sebagai pertanyaan konkret seperti “apakah macOS akan menjadi lebih baik atau lebih buruk dalam 2 tahun ke depan”
- Orang secara implisit mengasumsikan bahwa pencipta sebuah output telah melalui keadaan mental dan proses yang manusiawi, tetapi pada output AI asumsi itu tidak lagi tepat
- Unsur-unsur yang dulu dipakai sebagai indikator pengganti kualitas, seperti tata bahasa dan sintaks, menjadi kurang berguna di hadapan output AI, dan perbedaannya tampak saat kita berinteraksi dengannya secara manusiawi atau membangun sesuatu di atasnya
- Untuk LLM, pandangannya menjadi lebih dekat ke kubu LeCun/Marcus, dan ini mengarah pada kesimpulan bahwa model seperti ini tidak bisa melakukan pemrograman, dan bahwa proses itu penting
- Deep learning masih bisa menjadi solusi, tetapi untuk agen pemrograman sungguhan dibutuhkan world model, bukan RLVR yang menonaktifkan failing test dengan komentar lalu mengatakan semua tes lolos
- Inti zaman ini bisa jadi adalah siapa yang mampu bertahan tanpa mencederai dirinya sendiri di tengah euforia kolektif terhadap AI
1 komentar
Opini Hacker News
Masalah besar dalam wacana saat ini adalah terlalu hitam-putih. Kalau meragukan LLM disebut Luddite, kalau percaya disebut “ai pilled”
Dalam kebanyakan kasus, LLM bisa mengantar sampai 80~95%, kadang kurang dari itu atau malah lebih baik. Sesekali bahkan bisa membawa ke arah yang sama sekali salah
Namun orang-orang tampaknya hanya berdebat soal apakah LLM bisa menjadi software engineer sempurna sendirian di dalam lemari, lalu memakai itu sebagai dasar untuk menolak potensi besar di skenario lain
Jika dipikirkan seberapa jauh organisasi bisa lebih produktif hanya dengan memanfaatkan apa yang sudah diberikan internet, banyak perusahaan nyata bahkan tidak mampu melakukan sebagian kecil dari yang sebenarnya mungkin. Saya juga melihat LLM dari sudut pandang itu
Yang salah bukan model bahasanya, melainkan kita sendiri
Pada awalnya, para Luddite terutama memprotes mesin yang digunakan untuk membuat barang bermutu rendah secara “curang dan menipu”, mengakali standar tenaga kerja, dan merampas mata pencaharian para perajin terampil
Saya tidak memakai agen; saya membangun perangkat lunak pada tingkat fungsi melalui antarmuka chat sederhana dan percakapan lanjutan. Workflow yang dihasilkan cukup “chimera”, dan sangat diuntungkan oleh pengalaman serta keahlian saya. LLM hanya memperlancar prosesnya
Dalam kasus saya, ini bekerja dengan baik, dan saya tidak ingin kembali ke cara lama
Orang-orang yang disebut “Luddite” dalam wacana saat ini umumnya hanyalah mereka yang berani meragukan hype “AI”. Biasanya mereka juga bukan aktivis
Pada tingkat kemampuan AI saat ini, menurut saya lebih berguna melihatnya sebagai pencarian yang sangat bagus yang bekerja di atas pengetahuan yang sudah ada. Terasa seperti langkah berikutnya dalam ketercarian dari buku referensi, Stack Overflow, dan GitHub
Programmer lebih sering menggunakan kembali dan menemukan ulang teknik yang sama dibanding profesi mana pun yang bisa saya pikirkan, jadi mereka memang cocok dengan alat yang sangat bagus untuk menelusuri prior art. Fakta bahwa AI bisa menyesuaikan prior art itu ke use case tertentu membuatnya lebih kuat lagi
Namun, sama seperti menyambung potongan kode hasil salin-tempel dari Stack Overflow tidak otomatis menghasilkan kesuksesan besar, AI saat ini juga belum bisa benar-benar membangun keseluruhan proyek
Jika codebase-nya legacy, tua, dan kurang banyak dipakai, misalnya Anda bisa meminta agen AI membaca kode untuk menjawab “bagaimana aplikasi X melakukan Y”. Tapi saya tidak akan membiarkannya sembarang membuat fitur atau menangani refactor
Kalau begitu, commit akan jadi terlalu banyak dan tim pengembang akan bingung, sehingga hasilnya kemungkinan lebih buruk daripada campur aduk yang sebelumnya sudah mereka tangani. Belakangan saya agak kecewa dengan AI, dan penjelasan ini merangkum pengalaman saya dengan baik
Hal tersulit dalam software engineering adalah memecahkan masalah yang benar. Menurut saya, kemampuan mengidentifikasi masalah apa yang harus diselesaikan itulah yang membedakan engineer senior tingkat atas
Untuk menyederhanakan di sini, itu berarti masalah yang, ketika diselesaikan, memberi nilai terbesar pada produk dibanding kompleksitas dan biaya sampingannya
Dulu saya pernah bekerja pada sebuah produk web, dan awalnya seorang desainer junior menganggap akan keren jika backend bisa dikelola dengan alat LDAP. Akibatnya, skema dan struktur database produk itu meniru OpenLDAP dan memakai kunci CN majemuk, lalu seluruh codebase harus menangani struktur itu setiap kali membaca dan menulis ke DB. Saat merancang skema DB, kompatibilitas LDAP bukanlah masalah yang benar untuk dipecahkan
Perangkat lunak yang memecahkan masalah yang benar bisa sulit diidentifikasi. Biasanya karena cara kerjanya terlihat terlalu jelas, sehingga tidak tampak bahwa desain lain sebenarnya bisa saja dipilih
Seiring waktu, yang biasanya membatasi radius ledakan desain yang memecahkan masalah yang salah adalah friksi yang dihasilkannya. Pengembangan melambat, dan pengembangan untuk memecahkan lebih banyak masalah yang salah juga ikut melambat. Ini semacam efek pembatasan diri
Inilah yang sangat saya khawatirkan dari agen coding LLM. Mereka menutupi friksi itu. Bukan memperbaikinya, melainkan menunda biayanya
Akibatnya, kita mendapatkan codebase yang kompleksitasnya bisa tumbuh tanpa batas dibanding nilai yang diberikannya, dan tidak ada mekanisme untuk mengendalikannya
Para junior jadi tidak mengalami feedback loop yang membentuk naluri dan selera engineering untuk menilai apakah suatu masalah memang masalah yang benar untuk diselesaikan dalam desain tertentu
Pada skala seluruh bidang, kita bahkan bisa melupakan bahwa konsep memecahkan masalah yang benar itu pernah ada
Saya tidak tahu harus bagaimana. Mungkin saya perlu mulai merencanakan pensiun dini
Saat ini ada orang-orang yang membeli peptida pasar abu-abu lalu menyuntikkan zat yang berlabel “bukan untuk konsumsi manusia” hanya berdasarkan anekdot meragukan dan firasat, misalnya untuk membuat kulit lebih bersih dan menambah massa otot
Apakah mereka semua tiba-tiba berubah jadi zombie? Tidak. Apakah mereka benar-benar tahu apa yang akan terjadi pada tubuh mereka beberapa tahun lagi? Juga tidak. Mungkinkah itu berakibat katastrofik? Bisa saja
Analogi ini terlintas ketika memikirkan bagaimana dalam sekitar 6 bulan terakhir industri beralih secara agresif ke AI sebagai generator utama kode. AI adalah peptidanya, dan codebase adalah tubuhnya. Secara harfiah tak seorang pun tahu seberapa dapat dipeliharanya pendekatan ini. Belum cukup waktu berlalu untuk mengetahuinya
Bisa saja baik-baik saja, atau bisa juga jadi kekacauan total. Bisa saja seluruh tim engineering tertidur sambil melepas kemudi, mengira mereka memahami apa yang mereka bangun padahal sebenarnya tidak, lalu ketika LLM tak lagi mampu menanganinya, mereka sama sekali tak punya kekuatan untuk memperbaiki atau memeliharanya
https://www.bbc.co.uk/news/articles/cdr268m5pxro
Untuk codebase pribadi saya, saya tidak lagi melakukannya kecuali saya benar-benar tidak peduli pada maintainability atau umur pakainya
Saat ini saya berada di kubu yang “sudah lama tidak menulis kode sendiri”. Saya ingin melihat contoh masalah yang cukup besar sampai membuat saya kembali ke coding manual
Masalah utama saya adalah kualitasnya naik turun di tiap rilis model, dan terutama pada alat command line yang cenderung menyelipkan API atau dokumentasi lama
Saya paham model kesulitan di monorepo sejuta baris dengan tumpukan sampah 10 tahun. Tapi saya tidak terlalu bisa membayangkan kenapa ia akan begitu kesakitan di codebase baru
Coding tidak begitu sulit, jadi sering kali lebih mudah langsung coding daripada membaca dan menulis bahasa Inggris. Tapi saya hanya memakai Haskell, jadi mungkin saya bias
Salah satu risiko manajemen engineering adalah itu bisa membuat seseorang menjadi orang yang tak lagi mampu melakukan pekerjaannya
Tapi apakah itu penting?
Meski begitu, saya sedikit lebih optimistis daripada penulisnya. Rasanya mungkin untuk mengelola proses agar hal itu tidak terjadi
Lingkungan eksekusi agen baru ada sekitar setahun lebih sedikit, dan baru sekitar setengah tahun ini menjadi cukup bisa diandalkan, tetapi rasa lelahnya sudah besar. Menurut saya, ini lebih menunjukkan kelelahan mental dari pemrograman berbantuan AI daripada apakah LLM benar-benar bisa memprogram
Untuk benar-benar mengikuti apa yang dilakukan agen terhadap codebase, frekuensi pengambilan keputusan jadi tinggi, dan kita harus membaca jumlah kode dan prosa yang luar biasa banyak
Kelelahan pribadi dan psikologis ini, beserta emosi negatifnya, sedang secara tidak akurat dipindahkan menjadi pandangan pesimistis terhadap kemungkinan perkembangan teknologinya sendiri
Jika semua orang yang memakainya dengan benar merasa frustrasi, dan yang menyukainya justru menumpuk aduk-aduk yang tak bisa dipelihara setinggi gunung, kita akan segera membuangnya ke tong sampah sejarah
Banyak hal punya “potensi”, tetapi pada akhirnya banyak juga yang tidak jadi apa-apa
Saya akan terus memakai LLM, tetapi menurut saya kegunaan coding bergaya agen sudah melewati puncaknya
Sebagian dari pekerjaan saya adalah mencari cara agar model-model seperti ini bisa produktif di perusahaan besar tempat saya bekerja. Ini terasa seperti melempar tomat ke dinding, dan sampai tingkat tertentu saya melihat masalah seperti yang dia katakan, seolah output-nya memang punya keterbatasan tertentu
Pada saat yang sama, di tulisannya tidak ada potongan kode atau artefak konkret yang bisa dijadikan pegangan untuk mengatakan, “modelnya buruk sekali di bagian ini dan seharusnya begini.” Cara mengkritik seperti ini terlihat seperti pola yang berulang dalam tulisan blog dan Twitter tipe “LLM sama sekali tidak bisa diandalkan”
Jelas model-model ini lebih baik daripada autocomplete, dan dalam pengembangan sehari-hari saya pun mereka menghasilkan sebagian besar codebase yang tampaknya bisa dibuat oleh engineer junior atau menengah
Kalau tidak ada yang mengutip secara spesifik kesalahan nyata yang dibuatnya, bagaimana kita bisa memahami kemampuan sebenarnya?
Hampir selalu menghasilkan kode yang jalan, dan biasanya memang melakukan hal yang diminta. Tapi ada sedikit-sedikit yang salah dengan cara yang sangat menjengkelkan sampai bikin ingin melempar kursi. Dan parahnya lagi, ia bahkan tidak punya selera untuk menyadari apa yang salah dan bagaimana salahnya
Jadi kalau memberi contoh konkret salah, tapi kalau tidak memberi contoh konkret juga salah. Kalau begitu, permainannya selesai
Saya tahu saya sedang melakukan kekeliruan atribusi kelompok, tapi tetap saja begitu rasanya
Bahan seperti itu pasti ada, jadi kalau ada yang tahu konten yang menunjukkan contoh yang bagus, saya ingin diberi tahu
Saya tidak meragukan bahwa beberapa persen coder teratas bisa menulis jauh lebih baik daripada Claude atau Codex. Tapi saya penasaran seberapa jauh lebih buruk model-model itu dibanding developer biasa yang rata-rata
Dugaan saya, model-model ini akan terus membaik
Saat mulai coding bergaya agen 1~2 tahun lalu, saya yakin ini hanya berguna setingkat autocomplete. Awal tahun ini sesuatu terjadi, dan model-model ini mencapai tingkat kemampuan baru
Sekarang semua orang yang saya kenal melakukan coding bergaya agen, dan itu benar-benar mengejutkan. Saya pikir kita harus mendorongnya sejauh mungkin. Rasanya seperti percepatan umat manusia sudah di depan mata
Selama 2 tahun terakhir, pusat data baru setara sekitar 6GW telah diumumkan, tetapi yang benar-benar menyala dan mulai melayani masih kurang dari 1GW. Jadwal pengiriman sisanya terus mundur
Selain itu, pusat data berbicara seolah chip di dalamnya akan bertahan 6 tahun, tetapi kini mulai terlihat bahwa itu pun tidak realistis
Tolong hentikan omongan seperti “percepatan umat manusia.” Tidak ada orang yang menyelesaikan kanker, perubahan iklim, ketimpangan, atau masalah nyata penting lainnya dengan LLM
Jika teknologi ini cukup bagus untuk meningkatkan produktivitasmu, itu karena pekerjaanmu memang bukan sesuatu yang baru, mutakhir, atau inovatif. Satu-satunya alasan LLM bisa mengerjakan pekerjaanmu adalah karena kode itu sudah cukup sering muncul secara harfiah di data latihnya
Coba tulis C++26, HDL, atau stack yang sangat niche dengan LLM, itu akan jadi pemeriksaan realitas
Bukan AFL yang menemukan lebih banyak kerentanan daripada LLM. AFL bersama praktisi terampil yang menemukannya
AFL memicu bug, dan banyak atau bahkan sebagian besar di antaranya tidak bisa dieksploitasi. Manusia, dan sekarang agen, harus menyaring dan menilainya
Lagi pula, itu terjadi pada korpus perangkat lunak lama yang tidak memory-safe dari era sebelum AFL. Masa kejayaan AFL adalah 10 tahun lalu, dan sekarang semua target sudah menjadi lebih sulit
Sebagai konteks tambahan, penulisnya adalah George “geohot” Hotz. Dia punya riwayat eksploit yang panjang, dan mungkin paling dikenal karena membangun comma.ai untuk mobil swakemudi hampir seperti vibe coding dengan anggaran kecil, jauh sebelum vibe coding AI yang sebenarnya muncul
https://en.wikipedia.org/wiki/George_Hotz