AI: Ketidakmampuan yang Dipercepat

• Ketergantungan berlebihan pada LLM dalam rekayasa perangkat lunak dapat meningkatkan kecepatan jangka pendek, tetapi melemahkan berpikir kritis dan kemampuan memecahkan masalah
• Risiko yang lebih besar daripada keluaran yang salah adalah menerima begitu saja prompt yang cacat, sehingga utang teknis dan penurunan kapabilitas pengguna menumpuk dengan cepat
• LLM tidak dapat mengingat atau menginternalisasi teori program melampaui context window saat ini, sehingga model mental bersama yang dibutuhkan untuk desain dan pemeliharaan tetap menjadi ranah engineer manusia
• Kompleksitas terus meningkat selama proses pemeliharaan, dan LLM sebagai prediktor token pada level teks dapat meningkatkan entropi program melalui perubahan yang tidak perlu atau aneh
• AI dapat digunakan sebagai alat, tetapi tidak boleh dijadikan tongkat penopang; kita harus terus berinvestasi pada kapabilitas rekayasa dasar dan pemikiran mendalam yang sudah bernilai pada 2019

---

Risiko rekayasa akibat ketergantungan pada LLM

• Sikap menyebut LLM seperti “teman” bukanlah kemitraan nyata, melainkan lebih mirip eufemisme bahwa ia memberi manfaat bagi pengguna
• Engineer dengan sudut pandang seperti ini umumnya memprioritaskan kecepatan, atau berada di bawah tekanan untuk memprioritaskannya
• LLM dapat membuat banyak kode dengan cepat, tetapi penggunaannya disertai ekor panjang risiko

Lima risiko yang tampak dalam pembuatan kode

• Risiko keluaran

  • LLM dapat menghasilkan hasil yang jelas salah, seperti kode yang tidak bisa dikompilasi
  • Kasus yang lebih berbahaya adalah hasil yang salah secara halus dan sulit dideteksi, seperti bug logika
  • Risikonya meningkat ketika penulis prompt tidak memiliki kualifikasi untuk mengevaluasi hasilnya
  • Contohnya adalah situasi ketika seorang project manager meminta source code

• Risiko masukan

  • LLM tidak membantah prompt yang berisi pertanyaan menggiring, asumsi keliru, atau konteks yang tidak lengkap
  • Misalnya, permintaan “berikan implementasi daftar thread-safe di C#” bisa menghasilkan kode 200 baris yang tampak meyakinkan, padahal pertanyaan sebenarnya mungkin “bagaimana membuat kode ini thread-safe?”
  • Dalam kasus ini, jawabannya bisa berupa satu baris kode yang memakai System.Collections.Concurrent
  • Karena tidak diminta, LLM tidak mengenali bahwa ini adalah contoh XY Problem

• Perlambatan di masa depan

  • LLM dapat menurunkan kualitas codebase dengan sangat cepat
  • Tanpa guardrail yang kuat, kode buatan LLM bisa tampak baik-baik saja dari luar, tetapi di dalamnya berubah menjadi ruang yang tidak higienis dan tidak fungsional
  • Ini diperlakukan sebagai masalah yang lebih mendesak daripada pembahasan utang teknis pada umumnya

• Infantilisasi pengguna

  • Pada individu dan organisasi yang menyerahkan pemikiran dan pemecahan masalah kepada LLM, talenta dapat menghilang
  • Senior engineer dapat kehilangan kesempatan belajar melalui pergulatan yang produktif, sehingga kemampuan memecahkan masalah dan berpikir kritis melemah
  • Junior engineer tidak mengembangkan kapabilitas tersebut sejak awal, lalu akan sulit pula membimbing junior di masa depan
  • ThoughtWorks Technology Radar Volume 32 membahas bahwa kepercayaan diri berbasis AI terkadang mengorbankan berpikir kritis
  • Coding as Craft: Going Back to the Old Gym menekankan kolaborasi AI yang disengaja untuk mempertahankan coding sebagai kerajinan
  • Thoughts on Thinking memandang bahwa LLM bisa memberikan pemikiran yang sudah jadi, tetapi tidak memberi pertumbuhan intelektual yang dikembangkan sendiri

• Hilangnya kesenangan

  • Banyak developer melaporkan bahwa penggunaan AI merampas kondisi flow dan kesenangan berkreasi
  • Kode buatan AI bisa menjadi kode yang menyakitkan untuk dibaca dan diubah
  • Artikel terkaitnya adalah The Hidden Cost of AI Coding

Dua kapabilitas yang tidak dapat digantikan LLM

• Menanggapi kekhawatiran bahwa engineer berpengalaman akan menjadi tidak diperlukan karena AI, kapabilitas pemrograman yang tidak dapat diberikan LLM dirangkum menjadi dua
• Kapabilitas tersebut adalah teori program dan entropi program

Teori program: kode bukanlah program itu sendiri

• Programming as Theory Building karya Peter Naur memandang pemrograman sebagai aktivitas membentuk wawasan atau teori tentang masalah
• Dari sudut pandang Naur, program bukanlah source code, melainkan konstruksi mental bersama, yaitu teori atau desain
• Kode diturunkan dari desain tersebut, tetapi keluaran yang bernilai ada pada desain, bukan pada kode

• Eksperimen pemikiran dua tim

  • Dua tim dengan kemampuan yang sama, A dan B, berada di ruangan terpisah tanpa saling berkomunikasi
  • Tim A menulis program seperti game catur berbasis terminal, sementara Tim B menunggu atau bermain catur sungguhan
  • Setelah Tim A selesai, source code diberikan kepada Tim B, dan kedua tim harus menambahkan fitur seperti pemain catur virtual
  • Tim yang akan menghasilkan solusi lebih baik adalah Tim A
  • Tim A memiliki model mental yang segar tentang program yang baru saja mereka buat
  • Tim B tidak memiliki model seperti itu
  • Karena program terus dimodifikasi setelah pembuatan awal, jika hanya ada source code tanpa pemahaman desain yang sudah diinternalisasi, biaya perubahan akan meningkat
  • Ini terkait dengan pengalaman saat pertama kali masuk ke codebase besar yang sudah ada: produktivitas hampir nol, lalu meningkat seiring teori program dimuat ke dalam kepala

• LLM dan teori program

  • LLM saat ini tidak dapat mengingat melampaui context window, sehingga tidak dapat menguasai teori, desain, atau konstruksi mental
  • Yang dapat memperoleh dan mempertahankan teori program adalah manusia

Entropi program: kemampuan mengurangi atau menahan kompleksitas

• Kompleksitas adalah kekuatan fundamental yang berlawanan dengan pemrograman, dan berkaitan dengan entropi
• The Mythical Man-Month karya Fred Brooks memandang pembangunan program sebagai proses penurunan entropi, dan pemeliharaan sebagai proses peningkatan entropi
• Dari sudut pandang Brooks, perubahan pada program setelah pembangunan awal niscaya membuat source code menjadi lebih kompleks
• Namun perubahan yang selaras dengan desain dapat memperlambat laju peningkatan kompleksitas

• LLM dan entropi program

  • LLM adalah prediktor token dan hanya bekerja pada level teks
  • LLM tidak dapat bernalar pada level konsep seperti ide, diagram, atau spesifikasi kebutuhan
  • Siapa pun yang pernah memasukkan potongan kode besar ke LLM akan melihat kecenderungan LLM menerapkan perubahan yang tidak perlu dan aneh
  • Semakin panjang percakapan, hasilnya bisa semakin menyimpang
  • Kemampuan untuk mengurangi kompleksitas kode atau menahan kompleksitas ada pada manusia

Cara menggunakan AI dalam rekayasa

• Jika Anda berharap AI akan membawa karier rekayasa ke level berikutnya, efeknya bisa justru sebaliknya
• LLM dapat mempercepat ketidakmampuan, tetapi tidak dapat menggantikan rekayasa manusia
• Daya tarik bisnis AI terletak pada komoditisasi rekayasa untuk mengurangi biaya
• Namun, seperti pemanfaatan talenta rekayasa luar negeri yang menghasilkan hasil campuran, LLM juga membawa batasan dan risiko
• Siklus hype AI pada akhirnya dapat mencapai puncaknya
• Perusahaan yang saat ini menggunakan AI secara berlebihan akan menanggung biaya berekor panjang, lalu mungkin berubah arah atau menghilang
• Proposisi nilai jangka panjang manusia dalam rekayasa tidak berubah
  • Dunia masih membutuhkan kemampuan teknis dan pemikiran mendalam
  • Dunia akan membayar untuk kapabilitas tersebut
• AI akan tetap ada, tetapi harus digunakan sebagai alat, bukan diandalkan seperti tongkat penopang
• Kita harus terus berinvestasi pada kapabilitas rekayasa dasar yang dianggap bernilai pada 2019

[GN⁺]

Opini Hacker News

• Wacana tentang coding dengan AI terkadang terasa mencerminkan perbedaan antara software engineer dan data scientist/machine learning engineer
  Keduanya menangani kebutuhan yang tidak jelas dan bug yang sulit ditangkap, tetapi secara umum software engineer membangun perangkat lunak yang harus selalu berperilaku dengan cara tertentu, sehingga reproduksibilitas, pengujian, dan alat yang matang menjadi penting
  Sebaliknya, machine learning engineer menangani model yang pada dasarnya probabilistik, dan pengujiannya pun berpusat pada metrik evaluasi seperti “output yang benar dalam 90% kasus”, bukan apakah menghasilkan output tertentu
  Karena itu, pola pikir menghadapi AI yang tidak selalu dapat dipercaya terasa lebih alami di sisi machine learning, dan asisten coding dinilai dengan cara seperti “80% benar sehingga mengurangi pekerjaan, dan 20% sisanya saya tangani sendiri”

  • Dari pengalaman saya, ini kira-kira setengah benar. Ada software engineer hebat yang menggunakan machine learning dengan baik dalam sistem nyata, sementara ada juga orang yang percaya bahwa machine learning akan menggantikan sistem yang dipahami dengan baik dan dibuat oleh pakar domain
    Saat bekerja di Amazon, solusi berbasis machine learning sering cocok untuk masalah nyata yang tidak memiliki pendekatan klasik. Misalnya, prediksi gerak berbasis peta grid atau klasifikasi gambar/peta grid berguna karena terintegrasi dengan baik ke pipeline estimasi dan kontrol yang sudah ada
    Sebaliknya, di sebuah startup, saya terus ditegur oleh manajer tingkat bawah karena meragukan pendekatan berbasis pembelajaran untuk masalah memperkirakan orientasi bidang diam seiring waktu. Karena tim tidak memahami dasar-dasar mapping atau filtering dan berasumsi “kalau datanya ditambah, masalahnya selesai”, seluruh pipeline kontrol kendaraan diberi estimasi rotasi acak yang berkedip-kedip dan meloncat-loncat
    Kesenjangan ini benar-benar besar, dan alangkah baiknya jika ada cara yang lebih baik untuk menyaringnya dalam wawancara
  • Dalam suasana sekarang, machine learning engineer tampaknya memperoleh kekuatan untuk memaksakan pola pikir mereka ke organisasi lain yang tidak cocok dengannya
    Dulu saya pernah mendengar senior architect perusahaan mengeluh setelah rapat; bagi produk perusahaan kami, akurasi dan kebenaran selalu menjadi nilai jual besar, tetapi tim machine learning di kantor lain tidak memahami hal itu dan menganggap akurasi 80–90% sudah cukup bagi pelanggan
    Ini mengingatkan pada perdebatan apakah tingkat fatalitas 1% pada penyakit pandemi itu kecil atau besar. 1 memang bilangan bulat terkecil, tetapi 1% dari 300 juta orang adalah 3 juta orang
  • Yang dibicarakan di sini adalah perbedaan antara perilaku deterministik dan perilaku probabilistik, dan sebagian wacana memang cocok dengan penjelasan itu
    Namun menurut saya tulisan ini tidak hanya membahas itu. Tulisan ini membahas kekhawatiran tingkat meta yang dimiliki orang-orang yang melakukan software engineering dan bagaimana AI cocok di dalamnya, dan menurut saya ia tepat sasaran saat membicarakan “entropi program”
    Bagian besar dari membangun produk perangkat lunak adalah mengelola entropi. Menambah kode dan orang sambil tetap menjaga laju kemajuan yang layak, serta memastikan semua orang memahami bagaimana potongan-potongan saling terkait dan bagaimana menambahkan potongan baru. Suatu hari AI mungkin bisa mempermudah ini, tetapi saat ini justru sering memperburuk entropi
  • Ada terlalu banyak use case yang sama sekali tidak cukup dengan 90% jawaban benar
    Ini tidak akan menjadi masalah besar seandainya para pihak yang berkepentingan tidak mencoba meyakinkan orang bahwa “bukan begitu, AI bisa langsung dipakai untuk semuanya”
    Asumsi ini begitu absurd sampai sulit dibantah dengan logika, dan sejauh ini sangat berhasil sebagai narasi berbasis keyakinan untuk menarik investasi besar dan membungkus optimalisasi tenaga kerja yang berfokus pada profit
  • Software engineer juga selalu menggunakan probabilitas. Apakah race condition akan diperbaiki secara struktural atau dampaknya dipersempit, berapa p99 dari panggilan database, A/B test, semuanya adalah penilaian probabilistik

• Saya sangat setuju dengan premis tulisan dan sebagian besar argumen konkretnya, tetapi dalam keseharian saya menggunakan LLM dan juga melihat sisi positifnya. Sebagai konteks, saya sudah bekerja di industri software sekitar 30 tahun
  Saat menangani kode yang dihasilkan AI, kita jadi membaca kode. Pengembangan menjadi lebih mirip rangkaian code review daripada perjalanan mencipta dari awal, dan bagi developer solo, ada keuntungan karena dapat meniru dan mempelajari tanggung jawab yang biasanya lebih mudah dipelajari di dalam tim
  Selain itu, untuk bekerja dengan LLM, developer dengan cepat menyadari bahwa mereka harus memahami masalah dalam lapisan-lapisan yang jelas dan terstruktur dengan baik. Jika menyuruhnya mengerjakan sesuatu yang besar sekaligus, biasanya kita menembak kaki sendiri, sehingga pendekatan dari sudut pandang desain, menulis spesifikasi rinci, dan mengimplementasikan per bagian membantu menentukan batas dan antarmuka blok konseptual
  LLM dapat dilihat sebagai akselerator kuat yang membantu developer junior tumbuh menuju peran senior. Dengan arahan yang tepat, ia memperlihatkan alur kemajuan dari pelajaran yang dipelajari orang yang lebih berpengalaman setelah menghabiskan banyak waktu. Saya tidak melihat semuanya suram, AI juga tidak akan menggantikan developer, dan meski saat ini sangat disruptif, pada akhirnya tampaknya akan menempati suatu tempat di antara alat-alat lain

  • Saya sepakat dengan posisi yang seimbang ini. Developer yang membaca kode lebih sedikit daripada kode yang ia tulis menurut saya sedang melakukannya dengan keliru. Membaca kode adalah inti dari pertumbuhan software engineer
    Jika meninjau kode yang dibantu dibuat oleh LLM, orang bisa mengatakan kita membaca kode yang lebih hambar, tetapi saya tetap merasa belajar darinya. Saya sudah banyak membaca kode buatan LLM, dan sering mempelajari idiom yang belum familiar atau pemanggilan library yang sebelumnya tidak saya ketahui
    Bagi developer senior pun, LLM adalah akselerator yang lebih kuat. Karena mereka tahu apa yang ada dan apa yang tidak perlu dicoba, mereka bisa memberi prompt dengan lebih baik
  • Daripada menjadi rangkaian code review, rasanya lebih seperti seseorang melakukan prototyping untuk kita. Bagus untuk mengatasi masalah halaman kosong, tetapi bukan sesuatu yang bisa langsung direview dan di-commit apa adanya
  • Masalahnya, kalau meminjam gaya Scott Kilmer, perusahaan itu mati dari leher ke atas. Kesimpulan perusahaan bukanlah bahwa AI membantu junior, melainkan mereka tidak akan merekrut junior dan akan menuntut produktivitas 10x yang ajaib dari senior dengan bantuan AI. Bahkan senior pun diberhentikan karena AI
    Dari berita terbaru saja, PHK terus terjadi di Big Tech, perusahaan teknologi menengah, dan perusahaan teknologi kecil

• Ingat masa ketika orang bilang pencetakan 3D akan menggantikan semua manufaktur?
  AI lebih dekat dengan sentimen ini daripada dengan singularitas

  • Analogi yang bagus. Pencetakan 3D adalah teknologi yang keren dan sangat berguna, dan benar-benar mengubah dunia. Namun injection molding tetap ada
  • Mungkin tidak akan mengarah ke singularitas, tetapi di dunia akademik, dalam hal pemberian tugas, penilaian, dan catatan kuliah, AI sudah memberi dampak besar, entah baik atau buruk
    Bisa juga dilihat bahwa LLM bukan memperbaiki sesuatu, melainkan hanya menyingkap cacat sistemik, tetapi dampaknya sendiri jelas. Puluhan alur perkuliahan yang dua tahun lalu masih standar kini tidak lagi berfungsi
    Ini terutama mencakup seluruh pendidikan online dan jarak jauh; ironisnya, ChatGPT muncul tepat ketika banyak universitas mulai berinvestasi di sana setelah Covid. Dampaknya berskala seluruh ranah pendidikan tinggi dan menengah di seluruh dunia
  • Ini lelucon yang mudah dilontarkan, tetapi cukup keliru. Pencetakan 3D adalah terobosan besar di berbagai industri dan secara fundamental mengubah keadaan yang ada
    Dirgantara adalah contoh yang bagus. Banyak hal yang dilakukan SpaceX dan startup muda di bidang ini tidak akan mungkin tanpa komponen hasil pencetakan 3D. Komponen seperti nozzle, ruang bakar, dan turbopump sering dicetak
  • Mirip juga dengan klaim bahwa Bitcoin akan menggantikan bank. Pada akhirnya bank-bank justru menjual alat keuangan berbasis Bitcoin
  • Sejujurnya saya tidak ingat masa itu. Mungkin siklus hype itu terjadi sebelum era saya
    Meski begitu, perbandingan ini tampak tidak adil. Saat saya dulu mengerjakan teknik mesin, pencetakan 3D justru membuat kemampuan engineering saya lebih baik karena memungkinkan saya membuat prototipe dan melakukan kesalahan dengan lebih cepat dan murah
    Memang tidak menggantikan semua manufaktur, tetapi berperan penting dalam desain, dan tidak membuat kemampuan penggunanya merosot

• LLM luar biasa untuk menulis kode, tetapi buruk sekali dalam memiliki dan memelihara kode itu
  Setiap baris yang diterima tanpa dipahami adalah pemahaman pinjaman, dan akan dibayar kembali dengan bunga tinggi saat pemeliharaan. Rasanya seperti kecepatan gratis, tetapi sebenarnya lebih mirip utang teknis dengan bunga sekitar 40% per tahun
  Kelompok kita perlu menemukan cara memakai AI untuk mengotomatiskan pengetikan, tetapi tidak mengotomatiskan pemikiran

  • Agar bisa disebut “pemahaman pinjaman”, LLM harus benar-benar memahami apa yang ditulisnya dalam arti pemahaman yang diterapkan pada engineer manusia
    Namun tidak demikian, dan dari cara kerjanya pun tidak mungkin demikian
    Karena itu, setiap baris dari LLM yang diterima tanpa dipahami sebenarnya adalah pemahaman yang tidak ada. Itu hanya sebaris kode yang dimuntahkan model probabilistik, dan tetap tidak dipahami sampai dilihat oleh entitas yang benar-benar dapat memahami konteks, sistem, dan desain codebase. Saat ini, satu-satunya entitas yang dikenal demikian adalah manusia
  • Tergantung pekerjaannya, penulisan kodenya sendiri pun buruk
  • Analogi yang sangat bagus. Rasanya tingkat bunga ini bisa cukup ditekan dengan TDD dan mengecilkan ukuran subsistem yang terisolasi. Lama-lama itu bisa mulai terlihat seperti microservices
    Dalam pengembangan tradisional, saya tidak terlalu menyukai keduanya, tetapi LLM saat ini membuat keduanya lebih mudah dan berguna
    Dan “rule of three” pada dasarnya berhenti berlaku di antara komponen. Dampak kode harus entah bersifat lokal, atau menjadi bagian dari library dasar yang sangat kokoh. Kasus di tengah-tengah membuat kompleksitas refactoring meledak

• “LLM tidak membantah prompt yang menggiring” adalah risiko input yang sejauh ini paling menyakitkan.
  Yang lebih menjengkelkan adalah kita bahkan bisa tidak menyadari bahwa kita sedang menggiringnya ke arah tertentu. Kalau dipikir dari cara kerja LLM, ini masuk akal, tetapi satu kata yang ditulis samar saja bisa membuat hasilnya condong ke arah yang buruk, bergerak berlawanan dari yang kita inginkan, lalu masuk ke lubang kelinci yang keliru.
  Saat sadar, kita sudah berada di tengah kubangan kode yang dirangkai asal-asalan, yang entah bagaimana nyaris berjalan. Bahasa manusia sangat ambigu dan tidak spesifik, sehingga ini hampir sama seperti alasan kita menciptakan bahasa formal berbasis aturan yang sejak awal memungkinkan presisi.
  Secara pribadi, saya juga merasa keterampilan saya cepat merosot karena alat AI. Dulu, karena malas, saya mengulurkan tangan ke AI untuk setiap hal kecil, tetapi setelah mundur selangkah, ternyata waktunya juga tidak terlalu banyak dihemat; sebaliknya, saya jauh lebih cepat lelah karena harus membaca puluhan atau ratusan baris kode, memikirkan bagaimana AI salah, lalu memperbaikinya.
  Saya tidak mengukurnya, tetapi secara keseluruhan rasanya waktu yang terbuang karena alat AI jauh lebih banyak daripada waktu yang dihemat.
  Masalah sebenarnya adalah AI memang berguna untuk banyak pekerjaan, tetapi penggunanya terbagi dua. Satu pihak memakainya untuk pekerjaan kompleks yang kesalahan kecilnya cepat menumpuk, sementara pihak lain terutama tipe manajer: melihat AI memuntahkan 200 baris kode yang tidak mereka pahami, menganggap aplikasi TODO yang nyaris berjalan sebagai “MVP”, lalu berpikir, “kalau ini bisa dibuat, pekerjaanmu juga pasti mudah.”
  Kalau mau memberi jawaban umum seperti saya salah memakainya atau modelnya yang salah, sebaiknya baca dulu komentar lama saya https://news.ycombinator.com/item?id=44055448 untuk konteks pengalaman saya dengan alat-alat ini.

  • Dari pengalaman saya sejauh ini, AI membantu memberi sudut pandang lain tentang cara memecahkan masalah, dan pada akhirnya saya yang mengerjakannya. Atau, jika saya memberi instruksi yang sangat spesifik dan masalah yang relatif kecil, AI menulis kodenya, lalu saya melakukan code review dan memperbaikinya agar sesuai standar saya.
    Dengan kata lain, AI adalah asisten saya, tetapi tanggung jawab untuk menghasilkan keluaran yang berkualitas dan mudah dipelihara tetap ada pada saya.
    Namun dari sudut pandang publik, pikirkan saja kalkulator sederhana. Kalkulator merusak kemampuan orang berhitung di luar kepala. AI akan melakukan hal yang sama pada kemampuan menulis dan berkomunikasi, kemampuan memecahkan masalah, dan sebagainya.
  • Lega rasanya mengetahui bukan hanya saya yang merasa satu kata ambigu bisa membuat hasilnya condong ke arah buruk.
    Model-model ini tampaknya menempel pada kata kunci tertentu di suatu tempat dalam alur prompt, meninggalkan logika tradisional, lalu mendorong kita ke jalur yang lebih sempit yang bahkan tidak benar-benar menyelesaikan masalah awal. Pada akhirnya, yang bertambah hanya frustrasi dan ketidakbahagiaan di sisi manusia.
    Untuk mencegah kemerosotan keterampilan, saya berusaha memakai AI hanya untuk tugas kecil dan jelas yang biasanya saya selesaikan dengan pencarian StackOverflow. Alih-alih mencari “bagaimana cara melakukan X?”, saya menanyakan hal yang sama ke model, lalu memakai jawabannya bukan sebagai jawaban benar, melainkan sebagai panduan pemecahan masalah.
  • Saya sangat paham perasaan bahwa tiang gawangnya bergeser dari “AI bisa melakukannya” menjadi “model o2.7 seharusnya bisa melakukannya kalau dipakai di IDE dengan RAG dan prompt-nya juga sudah diberi tahu caranya.” Pada titik tertentu, nilai dibanding usahanya menjadi lebih rendah daripada saya menulis kodenya sendiri.
    Meski begitu, ada hal-hal yang memang dibuat lebih mudah oleh AI hari ini. Misalnya, jika ada contoh yang bisa dipakai seperti “buat seperti halaman ini, tetapi gunakan data x alih-alih y”, sering kali itu lebih cepat daripada mencari dokumentasi. Dengan catatan bisa berhalusinasi, tetapi peluangnya juga besar untuk membaik seiring waktu.
    Perbaikan yang ingin saya lihat adalah akurasi yang secara umum lebih baik, sekaligus kemampuan mencari solusi paling sederhana tanpa harus diberi tahu setiap kali. Kelemahan terbesar saat melepas ChatGPT, Claude, dan sejenisnya adalah mereka cepat menghasilkan banyak sampah, dan tidak berhenti dengan mengatakan, “ini akan menjadi terlalu rumit untuk ditangani nanti.” Tulisan aslinya berargumen bahwa hanya manusia yang memahami keseluruhan desain yang dapat melawan entropi; saya tidak tahu apakah bagian ini tidak akan pernah membaik, tetapi saat ini rasanya inilah masalah terbesar.
  • Saat ingin menghindari “penggiringan tak terduga” seperti ini, saya lebih dulu meminta LLM: “ajukan pertanyaan klarifikasi sebanyak 5 buah per putaran, selama 3 putaran.”
    Pada putaran pertama, biasanya asumsi utama yang dibuat model akan terlihat, dan dari situ kita bisa mempersempit serta memperjelasnya.
    Setelah membaca komentar lama yang menunjukkan sudah mencoba banyak hal, pengalaman Anda dengan LLM tampak jauh lebih luas daripada saya. Namun saya tidak melihat teknik ini di sana, jadi saya tinggalkan di sini kalau-kalau berguna bagi seseorang.
  • Manusia juga punya bias serupa. Hanya saja, bias LLM jauh lebih mudah diuji daripada bias manusia, sehingga kita lebih menyadari bias LLM.

• Pernyataan seperti “tidak bisa menalar ide, diagram, dan spesifikasi kebutuhan” atau “hanya manusia yang bisa mengurangi kompleksitas” tampak seperti kasus ketika sebuah konsep menarik ditempeli klaim detail yang jelas keliru.
  Ini sangat mudah dilakukan. Cukup minta kode yang lebih sederhana. Saya sering menggunakannya untuk mendapatkan pendapat kedua dan mendapat hasil yang baik.
  Jika tidak bertanya kepada model, Anda tidak akan mendapat jawaban kompleks maupun jawaban sederhana. Bertanya dengan opsi default juga merupakan sebuah pilihan, bukan sesuatu yang melekat pada konsep LLM.
  Saya juga memakainya dengan baik untuk mengonversi kode dan ide/diagram satu sama lain. Saya tidak mengerti mengapa orang membuat klaim kuat yang setiap hari dibantah orang-orang dalam praktik nyata.

  • Menurut saya meme bahwa “LLM tidak bisa menalar dengan konsep” seharusnya sudah hilang. LLM secara harfiah adalah implementasi dari konsep, dan ini telah dibuktikan secara eksperimental dalam berbagai cara, termasuk metode untuk mengidentifikasi, menekan, atau memperkuat konsep tertentu selama penalaran.
    Tulisan itu juga mengulang logika aneh yang tampak benar di permukaan, tetapi tidak bertahan jika dilihat lebih dekat. Kisah Naur kini sudah menjadi meme dan diulang-ulang seolah sebagai wawasan tentang realitas, tetapi melupakan aturan fundamental dan praktis lain dalam rekayasa perangkat lunak: program yang tidak sepele akan segera melampaui kemampuan satu orang untuk menyimpan seluruh teorinya di kepala.
    Kita hampir tidak pernah bekerja dengan teori program yang benar-benar utuh. Bahasa pemrograman, teknik, metodologi, dan alat semuanya berkembang ke arah yang membantu orang bekerja lebih baik tanpa memahami sebagian besar kode.
    Dalam hal ini, manusia juga berbagi keterbatasan yang sama dengan LLM; kita hanya mengelolanya lebih baik karena tidak perlu menunggu sampai diizinkan menjalankan satu loop penalaran lagi untuk mendapatkan sudut pandang lain.
  • Masalah besar yang terus saya temui saat me-review kode engineer junior bukanlah kualitas kode itu sendiri, melainkan arah penyelesaiannya. Saya tidak yakin apakah model LLM bisa bertanya balik, “mengapa mau melakukannya dengan cara itu?” seperti jawaban terkenal ala StackOverflow.
  • Saya penasaran apakah mengubah kode menjadi diagram dilakukan secara manual, atau ada alat otomatisasi. Saya sedang mencari yang terakhir.

• Saya rasa logika serupa juga bisa diterapkan pada teknologi peta seperti Google Maps atau Apple Maps. Argumennya: memakai alat semacam ini membuat kemampuan menjelajahi dunia fisik, sense of direction, dan sense geografis kita merosot
  Sebenarnya itu tidak sepenuhnya salah. Sekarang banyak orang kesulitan mencari jalan tanpa penopang seperti Google Maps, dan hubungan kita dengan dunia fisik juga berubah dalam banyak hal
  Namun dulu pun banyak orang tidak terlalu jago mencari jalan. Terutama di wilayah yang tidak dikenal, kemampuan rata-rata untuk pergi dari titik A ke titik B dengan aman dan stabil jelas meningkat pesat
  Dan bagi segelintir orang yang memang berbakat dalam geografi dan navigasi, alat seperti Google Maps tidak menggantikan kemampuan mereka, melainkan melengkapinya
  AI sepertinya akan berakhir mirip seperti itu, hanya dalam skala yang lebih besar. Jelas ada trade-off dan sebagian keterampilan serta kemampuan akan berkurang, tetapi jauh lebih banyak orang akan bisa melakukan hal-hal yang sebelumnya tidak bisa mereka lakukan, dan segelintir orang akan menjadi lebih baik dalam pekerjaan mereka

  • Masalahnya, perangkat lunak peta bisa dipercaya dan pada dasarnya tidak mengeluarkan hasil seperti generator angka acak. Kita bisa bergantung pada output-nya seperti mempercayai kalkulator
    Tentu tidak selalu begitu. Memetakan seluruh dunia adalah pekerjaan yang sangat kompleks dengan banyak sekali pengecualian dan kasus tepi. Tetapi dibandingkan dengan output LLM, perbedaannya besar. Bahkan jika temperature disetel ke 0 dan prompt yang sama diregenerasi berkali-kali, output-nya tetap bisa sangat berbeda
    Selain itu, LLM mencakup rentang konsep yang jauh lebih luas, sehingga orang akan memakainya sebagai pengganti pikiran mereka sendiri dalam banyak situasi yang seharusnya benar-benar tidak boleh begitu. Untuk peta saja ada orang yang mengemudi masuk ke danau karena Google Maps bilang itu jalan; saya bahkan tidak bisa membayangkan apa yang akan terjadi ketika orang mempercayai output LLM secara membabi buta dan menggantikan pemikiran mereka sendiri dengannya
  • Dari pengalaman pribadi, justru kebalikannya. Berkat perangkat lunak peta, saya bisa berjalan ke arah mana saja lalu dengan percaya diri memperbaiki rute saat perlu, dan rute yang pernah saya lalui sekali jadi lebih mudah diingat
  • Perbedaan reliabilitasnya terlalu besar, jadi analoginya kurang tepat
    Di tempat saya tinggal, Google Maps lebih baik daripada sopir taksi dalam 90% kasus
    AI bahkan tidak lebih baik daripada orang yang baru melakukan pekerjaan itu beberapa hari
  • Apakah ada bukti bahwa kemampuan rata-rata untuk pergi dari A ke B dengan aman dan stabil di wilayah yang tidak dikenal telah meningkat pesat?

• Secara realistis, 70% karyawan mengerjakan pekerjaan terlalu asal-asalan, sehingga AI sering kali bisa melakukan setara atau lebih baik
  Kesulitan sebenarnya adalah orang-orang yang sejak awal asal-asalan tetap tidak berguna meski memakai AI, sementara sisanya belajar dan berkembang bersama AI

  • Narasi yang sangat berpusat pada diri sendiri. Apakah dia berasumsi dirinya termasuk 30% itu?
  • Orang yang mengalihdayakan pekerjaannya ke AI bukan hanya membuktikan bahwa program komputer bisa melakukan pekerjaan mereka dengan lebih baik, tetapi juga membukakan jalannya; itu hampir sama dengan meminta untuk di-PHK
  • Di perusahaan besar, ini benar, dan mungkin salah satu pandangan terbaik tentang coding dengan AI yang pernah saya baca sejauh ini
    Full Self-Driving juga mirip. FSD lebih baik daripada pengemudi manusia yang payah, mabuk, atau sedang mengetik pesan, dan ada banyak pengemudi seperti itu di jalan

• Saya penasaran dari mana penulis mendapat kesan bahwa “[AI] tidak bisa bekerja pada level konsep”
  Yang berulang kali dibuktikan LLM terbaru adalah bahwa mereka jelas bisa bekerja pada level konsep, misalnya menerjemahkan konsep dari satu bahasa ke bahasa lain dengan benar sesuai konteks
  Pernyataan bahwa mereka tidak “memahami” konsep seperti manusia adalah hal lain. Karena tidak pernah mengalami rasa sakit, mereka mungkin tidak “memahami” rasa sakit, tetapi manusia juga terus-menerus membicarakan hal-hal yang tidak mereka alami langsung. Apakah itu boleh dilakukan adalah topik lain

  • LLM beroperasi dalam ruang token dengan struktur metrik yang diberikan sebagai proksi konsep. Dari satu titik di ruang ini, ia bisa berjalan menuju titik-titik yang mengelompok di sekitar token “dog”
    Ini adalah model lemah untuk sebagian karakteristik konsep, seperti asosiasi. Misalnya “dog” berasosiasi dengan “cat”. Namun ia tidak memodelkan komposisionalitas, intensi, atau peran istilah dalam kalimat kondisional kontrafaktual
    Meski begitu, jika pertanyaannya mirip dengan data pelatihan, kemampuan konseptual yang tampak dari luar bisa diperoleh dengan brute force. Jika seseorang pernah menanyakan “apakah anjing akan bahagia jika bermain di Mars?” atau sekumpulan pertanyaan yang cukup mirip, maka “dog” bisa ditempatkan di sekitar klaster “fakta literal” dan klaster sebagian kontrafaktual yang sudah diketahui
    Untuk melihat perbedaan antara ini dan kemampuan mental yang nyata, cukup perhatikan bahwa kombinasi konsep dengan kedalaman arbitrer bersifat tak terbatas, dan bisa terdiri dari jumlah kontrafaktual yang tak terbatas. Seorang anak yang hanya memiliki komponen dasar dan imajinasi bisa mengevaluasi keragaman tak terbatas ini
    Karena itu LLM paling banyak dipakai di bidang sempit tempat “pekerjaan konsep” yang diperlukan terdokumentasi dengan sangat baik dan cukup stabil, terutama rekayasa perangkat lunak
  • Dalam contoh ekstrem, bahkan tanpa pengalaman langsung pun kita bisa membicarakan dan memahami konsep seperti afantasia, sinestesia, dan buta warna

• Saya makin kuat berpikir bahwa 90s.dev harus diubah menjadi komunitas tanpa AI. Tempat yang berfokus pada keterampilan kuno menulis perangkat lunak dengan baik, dan menyambut semua orang yang mengasah keterampilan itu
  Apa yang diperlukan untuk memulainya? Forum? Mailing list? Cara seperti hackernoon yang mengumpulkan blog dari banyak penulis?
  Saya membuat mailing list sementara untuk orang yang tertarik di https://github.com/sdegutis/90s.dev/issues/2; kalau ingin menerima email tentang topik itu, silakan subscribe atau berkomentar di sana

  • Subscribe atau komentar? Ini cocok dengan target pasar saya. Hanya saja hampir tidak ada kata yang lebih memadamkan niat untuk melakukan sesuatu daripada kata “subscribe”
    Forum sudah rusak oleh LLM dan bot, jadi opsi itu gugur. Agar hal semacam ini berjalan, aksesnya harus berbasis undangan, dan setiap pemberi rekomendasi harus bertanggung jawab atas pohon undangannya sendiri
    Komunitasnya harus cukup bagus sehingga kehilangan akses menjadi pendorong perilaku baik. Di komunitas tertentu di internet, cara ini bekerja sangat baik
  • Pakai saja perangkat lunak forum OG yang dulu menjalankan forum-forum klasik pada masa itu. Akan bagus kalau dibuat bergaya retro dengan elegan