- Mitchell Hashimoto: "Banyak perusahaan saat ini sedang terjebak dalam psikosis kolektif AI yang serius, dan mustahil mengajak mereka berdialog secara rasional"
- Perdebatan MTBF vs MTTR dari era otomatisasi infrastruktur cloud kini meluas ke seluruh industri pengembangan perangkat lunak, dan keyakinan buta pada agen AI sedang menciptakan bentuk baru dari kegilaan kolektif
- Paham serba MTTR seperti "agen akan memperbaiki bug dengan cepat jadi tidak masalah merilis bug" sedang merajalela, padahal pola pikir ini sudah terbukti gagal pada era infrastruktur
- Sistem dapat terlihat sehat pada metrik lokal namun secara keseluruhan berubah menjadi kondisi yang tak dapat dipahami, dan berkurangnya laporan bug serta meningkatnya cakupan pengujian tidak menjamin keamanan yang sesungguhnya
- Saat masalah ini diangkat secara langsung, percakapan langsung ditutup dengan sanggahan instan seperti "cakupan pengujian 100%" atau "laporan bug menurun", sehingga orang gagal melihat gambaran besarnya
- Laju perubahan begitu cepat sehingga tak seorang pun menyadari korosi pada arsitektur dasar, sementara mereka sedang membangun "mesin bencana yang tangguh" secara otomatis
Klaim utama: psikosis kolektif AI (AI Psychosis)
- Saat ini banyak perusahaan berada dalam kondisi psikosis kolektif AI yang serius, dan melakukan percakapan rasional dengan mereka sendiri menjadi mustahil
- Alasan tidak bisa menyebut nama orang secara spesifik adalah karena di dalamnya ada teman-teman yang secara pribadi sangat dihormati
- Ia menyatakan kekhawatiran mendalam tentang bagaimana situasi ini akan berkembang
Pelajaran dari era infrastruktur: MTBF vs MTTR
- Perdebatan MTBF (mean time between failures) vs MTTR (mean time to recovery) yang pernah muncul saat transisi cloud dan otomatisasi cloud kini kembali mencuat
- Saat itu terbatas pada ranah infrastruktur, namun sekarang telah meluas ke seluruh industri pengembangan perangkat lunak (bahkan dunia secara keseluruhan)
- Para penganut keyakinan buta pada AI bergerak dengan pola pikir yang nyaris absolut bahwa "MTTR saja sudah cukup"
- Logikanya: "agen akan memperbaiki bug dengan kecepatan dan skala yang tidak bisa dilakukan manusia, jadi tidak masalah merilis bug"
- Pelajaran dari era infrastruktur: MTTR itu sangat baik, tetapi kita tidak bisa sepenuhnya membuang sistem yang tangguh itu sendiri
Pemutusan dialog dan pola sanggahan
- Saat masalah ini diangkat kepada orang-orang yang dikenal secara pribadi, responsnya berujung pada pengabaian seketika
- Reaksi seperti "tidak, cakupan pengujian kami sempurna" atau "laporan bug sedang menurun"
- Sanggahan semacam itu tidak menunjukkan gambaran besarnya
- Kekhawatiran ini sudah disampaikan secara pribadi namun tidak didengar, sehingga ia menilai penting untuk membagikannya secara lebih luas
Mesin bencana otomatis
- Pelajaran yang sudah pernah dipelajari dari infrastruktur: melalui otomatisasi, kita bisa membuat "mesin bencana yang sangat tangguh"
- Muncul fenomena ketika sistem terlihat sehat pada metrik lokal namun secara keseluruhan menjadi tidak bisa dipahami
- Laporan bug menurun tetapi risiko laten melonjak tajam
- Cakupan pengujian naik tetapi pemahaman semantik menurun
- Perubahan terjadi terlalu cepat sehingga tidak seorang pun menyadari korosi pada arsitektur dasar
Poin-poin dalam balasan utama
- @adamhjk: "Yang pertama kali dihancurkan oleh vibe coding murni adalah arsitektur itu sendiri", dan sejak awal harus ada arsitektur agar korosinya bisa terdeteksi
- Penjelasan tambahan Mitchell Hashimoto: dalam infrastruktur, sistem online bisa diperbarui sehingga MTTR dapat diterapkan ke semua pengguna dalam waktu yang masuk akal, tetapi pendekatan ini tidak berlaku untuk perangkat lunak yang diintegrasikan atau dijalankan langsung oleh pihak lain seperti library, perangkat lunak desktop, dan aplikasi mobile
- @tinygrad: kita telah memasuki era ketika untuk menilai apakah sesuatu yang dikatakan AI benar-benar salah tidak lagi butuh 10 detik melainkan 20 menit, dan organisasi harus menjaga titik kontaknya dengan realitas
- @beyang: UX agen saat ini menjadikan "LGTM (Looks Good To Me)" sebagai jalur dengan resistansi paling rendah, dan kecepatan kode yang tampak meyakinkan yang dihasilkan agen telah menaikkan persoalan verifikasi dalam code review menjadi ancaman langsung
- @beh_zod: fungsi imbalan untuk merilis itu pendek, sementara waktu yang dibutuhkan orang untuk menyadari utang yang sedang mereka timbun melampaui rentang perhatian kebanyakan orang
- @shipwithjay: gejalanya tampak ketika leadership engineering tidak mampu menjawab pertanyaan kontrafaktual (apa yang harus benar agar ini dihentikan) dan malah diam
- @chadfowler: ia sedang menulis buku tentang masalah ini, dan intinya adalah memindahkan ketelitian (rigor) ke arsitektur dan kerangka evaluasi; saat ini adalah kesempatan untuk menjalankan praktik-praktik terbaik yang selama ini tidak diterapkan karena kekurangan waktu dan biaya
Jawaban Mitchell Hashimoto atas pertanyaan dan pendapat orang-orang
- T: "Lalu apa yang harus dilakukan?"
- J: "Berpikirlah (gunakan AI, tetapi tetap berpikir)"
- T: Ia menilai kemungkinan bahwa anggapan "AI itu dibesar-besarkan" justru merupakan gejala yang lebih psikotik
- J: Semua tren duniawi memang dibesar-besarkan, tetapi itu bukan alasan untuk mengabaikannya secara menyeluruh
- T: "Jika harus memilih antara mempertahankan apa yang saya miliki sekarang atau melompat ke dalam risiko, saya akan memilih yang kedua"
- J: Ini bukan sakelar biner
1 komentar
Opini Hacker News
Konsultasi struktur AI tampaknya akan menjadi bentuk besar konsultasi bernilai tinggi, seperti respons pelanggaran keamanan atau spesialis pemulihan data
Sistem yang ditulis murni oleh AI bisa tumbuh hingga tingkat kompleksitas yang tak dapat dipahami manusia, tingkat perbaikan cacat menurun sementara konsumsi token per cacat meningkat, dan pada akhirnya perubahan oleh AI bisa menciptakan lebih banyak cacat daripada yang diperbaiki sehingga keseluruhan sistem menjadi tidak stabil
Akan dibutuhkan prosedur khusus untuk merapikan kekacauan itu seperti clean room, mengekstrak prinsip desain inti, lalu mungkin tetap menggunakan AI untuk membangunnya ulang dari nol
Rekayasa perangkat lunak masa depan pada akhirnya akan berpusat pada prinsip untuk menghindari hal semacam ini sejak awal, tetapi seperti rekayasa perangkat lunak lama yang juga butuh waktu lebih lama dari perkiraan untuk mencapai prinsip desain yang stabil, mungkin perlu 20 tahun untuk mempelajarinya
Pihak rumah sakit bahkan memberinya akses server departemen IT, tetapi karena ia tidak bisa menghubungkan Claude, ia tidak tahu cara melakukan deployment dan akhirnya sangat kebingungan lalu menghubungi saya; aplikasinya juga tampaknya punya masalah data/status yang menarik
Saya teringat orang yang menerima kiriman barang Amazon gratis tanpa batas ke rumah; secara teori itu hidup yang berlimpah, tetapi dalam praktiknya malah terkubur oleh sesuatu yang bukan kemakmuran
Kita semua tahu bagaimana akhirnya
Mereka setengah mengimplementasikan Kubernetes di dalam Github Actions sepanjang ribuan baris, dan itu tidak mungkin dipahami
Saya benci pemasaran AI, tetapi saya melihatnya berguna sebagai alat yang membantu orang berpengalaman bergerak lebih cepat
Hanya saja, jika bukan ahli, AI tampaknya cenderung menghasilkan solusi yang rumit untuk setiap hal yang ingin dilakukan
Tampaknya yang ia maksud bukan sekadar penggunaan AI itu sendiri, melainkan fenomena perusahaan dan orang-orang yang mengalihdayakan pengambilan keputusan dan pemikiran kepada AI
Menulis kode dengan AI bukanlah psikosis AI atau sesuatu yang buruk, tetapi jika Anda hanya memasukkan prompt lalu percaya begitu saja pada apa yang dikatakan AI, itu terasa jauh lebih dekat ke psikosis AI
Saya sering melihat orang-orang keuangan dan VC di Twitter mengganti pemikiran dan penalaran mereka dengan screenshot ChatGPT untuk hal-hal yang seharusnya bisa mereka pikirkan sendiri sedikit saja
Alat-alat ini buruk untuk ide, pemikiran, dan nasihat; yang mereka keluarkan hanyalah pola yang tampak seperti hasil pattern matching, jadi jika diajak membahas ide, biasanya mereka mengeluarkan omong kosong paling generik
Sebaliknya, untuk tugas seperti menulis kode, di mana pattern matching benar-benar membantu, alat ini cukup berguna, tetapi tidak boleh diberi tanggung jawab atas pemikiran dan pengambilan keputusan
Secara umum, puncaknya lebih tinggi dan dasar terendahnya juga lebih rendah, dan deskripsi di atas sangat akurat
Saya menulis beberapa hal terkait ini: https://mitchellh.com/writing/my-ai-adoption-journey, https://mitchellh.com/writing/building-block-economy, https://mitchellh.com/writing/simdutf-no-libcxx
Tulisan terakhir adalah perubahan kompleks yang saya lakukan berkat AI, dan juga menunjukkan bagaimana saya mendekatinya secara masuk akal
Hampir selalu menghasilkan teks yang terlihat benar secara logis, tetapi di dalam teks itu kadang ada asumsi implisit dan keputusan yang salah untuk kasus penggunaan yang dimaksud
Untuk membuat solusi yang benar-benar tepat, definisi masalah harus tepat, dan itu bisa jadi lebih sulit daripada membuat solusinya
Atau menyerahkannya kepada konsultan acak
Apakah “AI bilang ini ide yang bagus” benar-benar lebih buruk daripada “kami hanya mengikuti tren industri”
Jika terjadi pada individu, teman dan keluarga biasanya bisa menahan laju sampai batas tertentu dengan menunjukkan perilaku atau ucapan yang aneh
Tetapi ketika pemberi kerja mulai melakukannya di tingkat kepemimpinan, sulit membayangkan seberapa buruk jadinya
Anda akan ditekan untuk ikut serta atau takut dipecat, dan satu-satunya orang yang bisa membantu mengoreksi pemikiran adalah rekan kerja yang menentang, padahal orang seperti itu kemungkinan akan pergi atau dipecat
Kalau ingin mempertahankan pekerjaan, Anda harus ikut menyesuaikan diri
Karena agen yang membuat keputusan, pekerjaan bergerak dengan kecepatan agen, dan sering kali ia mengambil keputusan tanpa banyak bicara lalu hanya memberi output akhir berupa “inilah rencananya”
Untuk meninjaunya dengan benar, Anda harus memahami masalahnya secara mendalam sehingga kembali ke kecepatan manusia; akibatnya orang akhirnya hanya membaca sekilas lalu menyetujui
Intinya adalah menetapkan secara sadar dan hati-hati keputusan mana yang akan dialihdayakan
Untuk itu Anda harus memperlambat langkah, keuntungan vibe coding yang dibesar-besarkan seperti 10x akan berkurang, tetapi sebagai gantinya Anda lebih terlibat dan menumpuk lebih sedikit utang kognitif
Keputusan membosankan seperti bagaimana mengiterasi array, atau bagaimana menyesuaikan output satu pemanggilan dengan input pemanggilan lain, bisa diserahkan ke agen
Keputusan yang nyata harus ditentukan terlebih dahulu dan dimasukkan ke spesifikasi: Anda harus mendefinisikan batasan, API, struktur data inti, sistem dan tanggung jawab, penanganan error, serta batasan kuat soal keamanan dan privasi
Jika ada ambiguitas, agen harus diinstruksikan untuk berhenti, dan insinyur yang baik bisa mendapatkan peningkatan kecepatan 2~3x tanpa efek samping
Mungkin inilah yang akhirnya akan mengubah rekayasa perangkat lunak menjadi benar-benar bidang rekayasa
Saat ini para prompter sedang membangun seluruh infrastruktur perusahaan
Saya pribadi mengenal seseorang yang memigrasikan database perusahaannya ke versi Postgres yang lebih baru, dan memang akhirnya berhasil, tetapi saya gemeretak gigi saat mendengar dia menjelaskan prosesnya
Rasanya seperti, “Saya menyiram bensin ke server lalu menyalakan rokok, tapi tenang, saya menemukan alat pemadam api di ruang bawah tanah. Pengukurnya memang menunjukkan kosong, tapi kalau digoyang masih terdengar ada cairan”
Saat dia meninggalkan perusahaan, mereka akan membutuhkan prompter lain yang lebih percaya diri untuk memelihara infrastruktur DB itu
Tulisan ini menunjukkan bahwa mustahil berdebat dengan orang yang berkata, “Tidak apa-apa merilis bug, agen bisa memperbaikinya dengan kecepatan dan skala yang tidak bisa dilakukan manusia”
Namun balasan teratas justru contoh orang yang berargumen, “Tetapi agen itu sangat cepat”
Mungkin mereka berasumsi keuntungan dari codebase dan fitur yang menjadi dua kali lipat lebih besar daripada kerugian dari bug yang juga menjadi dua kali lipat
Setidaknya itu akan terlihat bagus di kabar investor kuartal ini
Kita bisa saja terus merilis lebih banyak sampah, dan loop umpan baliknya adalah pelanggan?
Jawaban yang saya terima adalah, “Ini teori permainan. Seseorang pasti akan melakukannya, jadi kamu juga terpaksa harus melakukannya. Tidak mungkin seburuk itu”
Logikanya memang berguna, tetapi mengabaikan risikonya itu hal lain
Berasumsi bahwa bergerak sangat cepat sambil merusak semuanya pada akhirnya akan menghasilkan hasil yang baik itu berbahaya
Arus AI ini tidak berjalan baik dan saya tidak suka arahnya
Saya tidak yakin pihak yang mengalami psikosis itu pasti “pihak kita”
Saya bekerja di perusahaan yang sangat besar, dan perusahaan kami selalu sangat lambat dalam modernisasi dan adopsi teknologi, seperti gletser
Namun anehnya, sekarang itu justru bisa menjadi keunggulan kompetitif
Hidup meniru seni
Dulu saya suka bercanda bahwa fax masih ada, tetapi saya tidak menyangka akan merasa seberuntung ini bekerja di budaya yang tidak mengalami demam seperti ini
Membaca HN terasa seperti masuk ke Alice's Wonderland milik para maksimalis token dan penderita psikosis AI
Di sini saya benar-benar tidak mengenal satu pun orang yang dipaksa bekerja seperti ini
Kalau Anda menyukai nuansa seperti ini, Anda mungkin akan suka alat CLI baru Burn, Baby, Burn (those tokens): https://github.com/dtnewman/burn-baby-burn/tree/main
Show HN-nya ada di sini: https://news.ycombinator.com/item?id=48151287
Ini mengingatkan saya pada Simple Made Easy karya Rich Hickey dan pendekatannya saat membuat Clojure
Bahkan sebelum LLM menghasilkan seluruh program, framework yang kompleks sudah memungkinkan pengembang membuat versi awal program dengan sangat cepat, tetapi dengan harga berupa program yang sulit dipahami sehingga sulit pula di-debug dan dimodifikasi
Sebagian orang bertaruh bahwa tak peduli seberapa kusut dan kompleks program yang ditulis AI, AI akan selalu cukup pintar untuk men-debug, memelihara, dan memodifikasinya
Saya tidak begitu yakin
Psikosis AI bukanlah posisi yang menentang penggunaan AI
Saya menggunakan alat coding AI setiap hari, tetapi alat AI tidak punya konsep masa depan
Selama ini kita bergantung pada pola pikir egois insinyur yang berpikir, “Kalau ini rusak di produksi, saya tidak akan bisa memperbaikinya, dan saya pasti dipanggil jam 3 pagi,” untuk membangun sistem yang stabil
Ada juga kemalasan umum untuk mencari library sempurna di CPAN agar tidak perlu mengerjakannya sendiri, dan kadang menghabiskan waktu lebih lama mencari library itu daripada menulis sendiri
Saya telah menulis ribuan baris kode dengan alat AI dan memasukkannya ke produksi, dan itu sebagian besar terasa alami, karena sejak 2017 saya sudah mengatakan kepada orang-orang untuk tidak mengetik semua kode sendiri melainkan menuliskannya, sambil memasang jebakan di pengujian untuk menangkap kode yang buruk
Namun ada satu hal yang tidak dilakukan AI, yaitu menulis lebih sedikit kode: https://xcancel.com/t3rmin4t0r/status/2019277780517781522/
Laporan bug juga berkurang ketika orang kehilangan keyakinan bahwa bug itu akan diperbaiki
Ini karena melaporkan bug sering kali membutuhkan investasi waktu yang cukup besar
Hal seperti ini cukup sering terjadi ketika kepercayaan pada suatu grup atau perusahaan runtuh
Itu membuatnya lebih mungkin dilaporkan secara salah, dan sebagian isinya bisa saja keliru
Jadi kita diserang dari banyak arah
Ini bahkan belum menyentuh taktik yang bersifat adversarial
Kalau tidak punya moral, apa ada cara yang lebih baik daripada menggunakan agen untuk membanjiri pesaing dengan laporan bug palsu
Masalah selesai
Banyak dari yang diamati Mitchell, mungkin bahkan semuanya, bisa saja terjadi tanpa AI
Saya merasa berada di posisi yang sangat aneh
Saya sangat tidak suka perubahan yang dibawa AI ke pengalaman dan praktik menulis kode, sampai rasanya ingin melakukan apa pun selain bekerja dengan komputer, tetapi pada saat yang sama saya juga berpikir alat-alat ini sangat kuat dan terus membaik
Poin Mitchell masuk akal. Alat seperti ini bisa membawa fondasi yang busuk dan kita baru menyadarinya setelah seluruh struktur runtuh
Saya tidak ingin berada di posisi yang harus bertanggung jawab pada saat itu sambil tidak lagi memahami codebase secara mendalam seperti dulu
Namun manusia juga sudah sejak lama memasukkan bug yang halus tetapi fatal ke dalam kode
Jadi banyak hal di sini masih terasa seperti pertanyaan empiris yang terbuka
Apakah kita akan melihat banyak sistem runtuh dengan cara-cara mengerikan yang sebelumnya tidak ada? Sebagian mungkin iya
Pada saat yang sama, bukankah kita justru akan belajar bahwa kita harus bergerak lebih jauh ke arah spesifikasi dan verifikasi? Saya tidak tahu
Bagaimanapun, membangun sistem dengan cara ini tampaknya tak terhindarkan, meskipun akan ada tabrakan di tengah jalan
Di kubu anti-AI pun tampaknya ada semacam psikosis reaksioner mereka sendiri
Saya tidak ingin terlibat dengan AI, tetapi saya juga tidak bisa menyangkal pengalaman saya saat menggunakan alat ini
Saya berharap ada lebih banyak ruang untuk diskusi AI yang realistis tetapi kritis seperti ini
Inilah juga alasan Mitchell adalah pengembang yang bagus