Manusia di Dalam Loop Sudah Lelah

• Pemrograman dengan LLM meningkatkan produktivitas sekaligus memperbesar kelelahan pengawasan, karena pengembang harus terus mengendalikan niat dan kualitas, sehingga menggoyahkan kepuasan dan keberlanjutan kerja
• Model dapat dengan cepat membuat kode yang tampak meyakinkan, tetapi bisa kehilangan niat yang konsisten dalam perubahan yang kompleks, sehingga manusia menjadi gerbang kualitas yang terus meninjau dan memperbaiki hasil yang bertambah banyak
• Meskipun jumlah pekerjaan yang bisa dimulai melonjak, jumlah pekerjaan yang bisa diselesaikan dengan cermat tetap terikat pada otak dan perhatian manusia, sementara imbalan kecil dari coding berkurang dan beban kognitif dari peninjauan meningkat
• Di domain yang dipahami secara mendalam, LLM bisa diarahkan secara efektif, tetapi di domain dengan keahlian dangkal model cenderung mengejar hal yang tampak meyakinkan daripada akurat, sehingga selera dan penilaian arsitektur menjadi semakin penting
• Rekayasa perangkat lunak bukan hilang, melainkan menyusut dan tersusun ulang; sumber daya yang langka bukan lagi penulisan kode itu sendiri, melainkan perhatian manusia, penilaian rekayasa, dan kemampuan menjaga visi sistem yang konsisten

---

Pemrograman LLM yang berguna tetapi tidak stabil

• Pemrograman LLM benar-benar berguna sekaligus tidak stabil, dan mengabaikan ketidakstabilan itu dapat membuat pengembang mengalami burnout
• Tim Pydantic juga mengalami kebingungan yang sama saat membuat validasi data, membangun agen AI, dan alat observabilitas produksi
• Intinya bukan apakah AI akan menggantikan programmer, melainkan bagaimana pengalaman pengembangan saat ini telah berubah dan apa yang bisa memperbaikinya

Sensasi saat membuat sesuatu dengan tangan sendiri

• Pemrograman selama ini memberi sensasi mencipta: membuat sesuatu hanya dengan logika dan menangani lapisan abstraksi yang dalam secara langsung
• Dari pengalaman mempelajari rekayasa perangkat lunak lewat trial and error alih-alih pendidikan ilmu komputer formal, prinsip arsitektur dan kualitas kode terasa lebih seperti luka yang menumpuk daripada aturan buku teks
• Pada 2010-an, alat low-code/no-code dan produk seperti Dreamweaver juga menjanjikan bahwa orang bisa membuat sesuatu tanpa kode, tetapi pada akhirnya menghasilkan spaghetti code di dalamnya dan tidak sepenuhnya memenuhi harapan
• Berbeda dari masa lalu, alat AI saat ini berhasil mempersempit jarak antara janji dan kenyataan ke tingkat yang bermakna, dan justru itulah yang membuatnya terasa lebih mengusik

Pengalaman nyata dari “kode yang menulis dirinya sendiri”

• Kode memang sampai batas tertentu menulis dirinya sendiri, tetapi pengalaman manusia yang harus meninjau, memberi instruksi, dan mengoreksi arahnya justru bisa memburuk
• Pemelihara Pydantic AI, Douwe, setiap pagi harus meninjau sekitar 30 PR yang dibuat semalaman oleh AI milik orang lain dan segera menilai masing-masing
  • Godaan untuk menyerahkan peninjauan itu juga kepada AI sangat besar, tetapi jika begitu, pertanyaannya menjadi: apa sebenarnya peran manusia?
• Meski rencana yang akan dijalankan LLM ditulis selama hampir dua hari dan diperjelas berulang kali, model tetap bisa memindahkan React hook ke file story Storybook atau salah membaca rencana lalu membuat komponen yang tidak ada
• Kegagalan seperti ini lebih dekat pada kurangnya konsistensi daripada sekadar kurang mampu
  • Model cukup cerdas untuk membuat kode yang tampak meyakinkan, tetapi bisa gagal mempertahankan satu niat yang konsisten di seluruh perubahan kompleks
• Manusia harus terus menilai sejumlah besar hasil yang ‘sebagian besar benar’ sambil menjaga niat itu tetap hidup di dalam kepala, dan dari proses inilah muncul bentuk baru kelelahan pengawasan
• Imbalan dari open source—membangun fitur bersama orang sungguhan dan membantu mereka berkembang—juga berkurang
  • Ketika pekerjaan masuk ke black box AI, tidak ada orang di sisi lain yang belajar, sehingga kepuasan kolaborasi pun hilang

Jebakan yang meningkatkan intensitas kerja

• Simon Willison memperkenalkan riset Berkeley Haas yang menyimpulkan bahwa penggunaan AI tidak mengurangi beban kerja, melainkan meningkatkan intensitas kerja
  • Menjelang akhir hari, terus ada tekanan untuk memasukkan satu prompt lagi atau menyelesaikan satu fitur lagi
  • Karena merasa rencana hampir selesai, orang bisa terus memasukkan prompt sampai mendekati pukul 2 dini hari
• Marcelo dari Pydantic bercanda bahwa jika satu sesi Claude Code berhenti, buka saja 5 sesi
  • Maksudnya, ketika sibuk memberi umpan balik ke sesi lain, kita bahkan mungkin tidak sadar satu sesi telah macet
• Pekerjaan yang bisa dimulai lewat paralelisasi memang meningkat drastis, tetapi jumlah pekerjaan yang bisa diselesaikan dengan hati-hati tidak berubah
  • Penyelesaian membutuhkan otak manusia, sumber daya yang tidak bisa diparalelkan

Rusaknya fungsi imbalan manusia

• Sebagaimana fungsi imbalan dalam machine learning mendefinisikan hasil yang baik bagi agen, coding manual juga punya imbalan kecil seperti memecahkan masalah, memahami logika kompleks, berhasil compile, dan rasa terkendali
• Pemrograman berbantuan LLM mengotomatisasi pekerjaan yang dulu menghasilkan imbalan dopamin ini, lalu menggantinya dengan beban kognitif dari peninjauan dan pengawasan
  • Bagian yang memuaskan berkurang
  • Bagian yang menguras tenaga bertambah
  • Belum ada imbalan baru untuk mengisi kekosongan itu
• Fenomena produktivitas yang naik sementara kepuasan turun bukan cacat pribadi, melainkan kerusakan dalam feedback loop yang harus diperlakukan sebagai masalah rekayasa tersendiri

Isolasi dan imbalan yang variabel

• Pemrograman dengan LLM bisa menjadi aktivitas yang sangat sepi, di mana manusia dan mesin terus mengulang prompt, perbaikan, dan peninjauan
• Momen bertanya pada rekan kerja, mengurai masalah bersama lewat percakapan, dan berbagi kegembiraan kecil saat menemukan solusi kini digantikan oleh satu prompt lagi
• Pada tim yang budaya kolaborasinya memang lemah, komunikasi antarmanusia makin tertekan, dan semakin sulit memastikan bahwa orang lain juga mengalami kesulitan yang sama
• Hasilnya kadang luar biasa dan kadang sampah, tetapi tak bisa diketahui sebelumnya—ini menciptakan struktur imbalan variabel seperti Skinner Box
• Saat perlu, kita tetap bisa menulis kode sendiri, tetapi kerja berbantuan LLM dan kerja manual menuntut pola pikir yang sangat berbeda sehingga perpindahannya terasa tidak nyaman
  • Untuk memberi izin pada diri sendiri agar bisa bolak-balik antara dua cara ini, dibutuhkan kedewasaan dan kepercayaan diri

Kemiripan dengan transisi ke desain responsif

• Sekitar tahun 2009, ketika web berpindah dari layout berbasis piksel dengan lebar tetap ke desain responsif yang mengalir, para desainer juga mengalami hilangnya rasa kontrol
• Bagi mereka yang membangun identitas dan profesionalitas lewat layout presisi dan grid yang sempurna, gagasan bahwa desain harus mengalir mengikuti lebar layar dan perangkat yang berubah-ubah adalah perubahan yang mendasar
• Desainer yang berhasil beradaptasi tidak membuang keterampilan lama mereka, melainkan menyusunnya ulang
  • Rasa proporsi dan pemahaman hierarki tetap penting
  • Obsesi pada kontrol tingkat piksel menjadi kurang penting
  • Sistem, adaptabilitas, dan perancangan untuk ketidakpastian menjadi lebih penting
• Namun, transisi AI saat ini jauh lebih cepat dan taruhannya berbeda dibanding desain responsif
  • Perubahan desain responsif berlangsung selama bertahun-tahun, sedangkan perubahan saat ini bergerak dalam hitungan bulan
  • Saat itu pun agensi kehilangan klien dan desainer kehilangan pekerjaan, tetapi tidak disertai kecemasan eksistensial seperti sekarang
• Meski begitu, pola bahwa keterampilan tidak menghilang melainkan berevolusi dan kemampuan inti justru makin penting tetap berlaku pada coding berbasis LLM
• Tidak menulis semua kode sendiri bukan berarti nilai insinyur berkurang, tetapi karena kini menjadi gerbang kualitas bagi jauh lebih banyak hasil, kemampuan membedakan hasil yang baik menjadi makin penting

Keahlian yang bertahan dan cara kerja baru

• Dalam lingkungan di mana siapa pun bisa membuat UI yang tampak meyakinkan dan kode yang berhasil compile, pembeda utamanya adalah selera dan nuansa, penilaian arsitektur yang matang, dan keputusan non-mainstream yang berlandaskan keahlian nyata
• Semakin dalam pemahaman terhadap suatu domain, semakin besar peluang untuk berhasil mengarahkan LLM
• Semakin masuk ke domain dengan keahlian yang dangkal, semakin jauh hasilnya dari kesiapan produksi dan semakin dekat pada sesuatu yang tampak mengesankan daripada benar
  • Model tidak tahu apa yang tidak diketahuinya, lalu dengan percaya diri mengisi celah; ini juga merupakan pola kegagalan yang muncul pada manusia
• Untuk rencana yang kompleks, pre-mortem bisa dimanfaatkan
  • Minta sesi LLM baru untuk mengasumsikan bahwa rencana telah gagal total, lalu mendiagnosis penyebabnya
  • Ini membantu menemukan celah spesifikasi yang luput dari orang yang sudah menatap detailnya selama dua hari
• Seorang insinyur di Pydantic mengembangkan alat yang mengekstrak aturan dari ribuan komentar code review lama untuk dijadikan instruksi awal dalam file AGENTS.md
  • Ini adalah distilasi keahlian: mengubah penilaian rekayasa yang terakumulasi secara implisit selama bertahun-tahun menjadi panduan yang bisa diikuti LLM
• Orang yang mampu beradaptasi terhadap perubahan memiliki tolok ukur penilaian yang kuat dari praktik nyata, dan bisa membedakan prinsip yang tetap valid dari kebiasaan yang dulu muncul karena keterbatasan bandwidth masa lalu
• Mereka bersedia mengubah alur kerja tanpa membuang standar mereka

Sumber daya langka yang tersingkap di dalam loop

• Arus AI saat ini mungkin tidak mengakhiri profesi rekayasa perangkat lunak, tetapi dapat membawa penyusutan besar dan penataan ulang mendasar pada industri
• Kekhawatiran tentang tersingkir, degradasi kemampuan, dan tertinggal jika tidak bergerak cukup cepat adalah hal yang wajar
  • Kekhawatiran terakhir itu kadang dibesar-besarkan, tetapi tidak sepenuhnya tanpa dasar
• Hambatan nyata selama ini bukanlah kode, melainkan perhatian manusia, penilaian rekayasa, dan kemampuan menjaga visi yang konsisten atas sistem
• Hambatan ini dulu kurang terlihat karena penulisan kode terasa sebagai bagian tersulit, tetapi ketika proses penulisan diotomatisasi, semakin jelas bahwa kemampuan manusia itulah sumber daya langka yang sebenarnya
• Pengembang bisa menjadi lebih produktif sekaligus kurang bahagia dan lebih tidak stabil, dan tim pembuat alat pun menghadapi masalah yang sama sambil menyesuaikan fungsi imbalan secara real-time
• Kode dan cara pengembangan memang berubah, tetapi manusia masih tetap berada di dalam loop, dan keadaan paling inti saat ini adalah kelelahan peserta manusia

[GN⁺]

Komentar Hacker News

• Coding manual makin sulit justru memberi imbalan kecil yang makin besar seperti memecahkan masalah, memahami logika, berhasil kompilasi, dan rasa kendali. Sebaliknya, agent coding terus menuntut pengawasan serupa terlepas dari skala fitur, jadi awalnya terasa seru seperti menunggangi gelombang produktivitas, tetapi bagian yang memuaskan berkurang dan beban kognitif untuk review meningkat sehingga cepat melelahkan

  • Lebih takut akan segera membenci pekerjaan itu sendiri daripada kehilangan pekerjaan. Untuk tugas yang tidak banyak menghemat waktu meski didelegasikan ke LLM, saya tetap mengerjakannya sendiri, lalu merapikan lagi struktur output agar lebih mudah dipahami manusia sambil menjaga rasa kendali
  • Pendorong saya bukan bagaimana kode dibuat, melainkan apakah produk yang dibuat benar-benar bermanfaat bagi lebih banyak orang. Saya selalu mendahulukan pengguna dan mengambil jalan pintas bila perlu, dan keseimbangan antara kode yang mudah dipelihara dan kecepatan rilis tetap bisa dijaga meski memakai LLM
  • Pengembangan bisa berubah dari pekerjaan berbasis pengetahuan menjadi seperti kerja pabrik dengan upah rendah. Pengetahuan dan pengalaman yang dibutuhkan untuk mengarahkan LLM jauh lebih sedikit dibanding menulis langsung, dan di LinkedIn orang yang hampir tidak punya pengalaman atau masih level junior pun sedang direkrut sebagai AI engineer
  • Saya merasakan dopamin saat membuat loop di mana AI menguji outputnya sendiri. Semakin otomasi ala Rube Goldberg itu rumit—misalnya membuat Codex mengendalikan dari jarak jauh dongle keyboard network-USB-C, Fingerbot, sampai webcam agar hibernasi berjalan di laptop dan kernel Linux tertentu—semakin memuaskan rasanya
  • Dalam proyek pribadi, fitur jadi lebih mudah dibuat, sementara hasilnya justru lebih rapi dan konsisten sehingga rasa puas meningkat. Jika fokus sebulan pada satu proyek, hasilnya bisa cukup bagus, dan karena biaya menulis ulang serta merapikan struktur jadi murah, ruang desain benar-benar bisa dijelajahi lebih luas. Namun tetap sering bikin frustrasi; separuhnya karena masalah saya memberi konteks, separuh lagi karena batasan bawaan model

• Saya senang memakai Claude untuk pekerjaan dan proyek pribadi, dan kuncinya adalah menghindari godaan agent dan memperlakukannya sebagai code generator. Buka satu sesi saja, matangkan rencana secukupnya, lalu awasi eksekusi langkah demi langkah; setiap tahap selesai, review dan koreksi arah agar di akhir pun kondisi kode tetap dipahami dengan baik
  Agar bisa dipakai hampir seperti one-shot, pada tahap perencanaan bukan hanya arsitektur, tetapi juga kode nyata yang menentukan keputusan penting harus dibuat konkret. Karena biaya refactoring kini lebih rendah dari sebelumnya, bagian yang sulit dipahami langsung saja diperbaiki bersama LLM, tetapi satu LLM hanya mengerjakan satu hal dalam satu waktu dan kita harus terus ikut dalam prosesnya

  • Setelah bekerja beberapa bulan dengan Claude, saya terbiasa dengan alur membahas detail secara cukup mendalam di awal dan bila perlu bahkan membuat kerangkanya dulu sebelum mengeksekusi, dan saya merangkumnya di https://github.com/ctomkow/claude/blob/main/README.md. Saya berhasil merefactor kode legacy yang selama ini tertunda ke arsitektur baru
    Jika Claude diberi kendali penuh, kekacauan dan hambatan yang pasti muncul pada akhirnya akan menguras tenaga. Jika mau, saya coding sendiri; saat lelah, saya serahkan ke Claude, sehingga rasa kendali atas codebase juga tetap terjaga
  • Saya menempelkan hanya potongan kode yang dibutuhkan ke percakapan yang sepenuhnya terpisah dari editor, membahas batasan dan ide, lalu jika sudah memuaskan saya pindahkan ke editor untuk merapikan nama dan implementasinya. Tugas yang jelas atau menyenangkan saya kerjakan sendiri, dan saya juga harus terlibat dalam keputusan arsitektur agar tetap merasa terhubung dengan proyek dan bisa memahaminya secara mendalam
  • Vibe coding, bahkan saat memakai beberapa agent loop, lebih mudah menguras tenaga dibanding pendekatan alat bantu yang melihat output dari dekat
  • Meski dikerjakan bertahap, saat orang lain me-review, mereka tetap harus melihat seluruh hasil sekaligus dengan mata yang benar-benar baru, jadi beban review tidak berkurang
  • Alur kerja masih bisa berpindah paling banyak dua buah, tetapi lebih dari itu kepala benar-benar lelah karena peralihan konteks

• Saat me-review kode rekan kerja atau bawahan, sebagian besar energi mental saya habis bukan hanya untuk menilai ketepatan teknis feedback, tetapi juga mempertimbangkan harga diri, perbedaan sudut pandang arsitektur, nada yang sopan, tambahan beban kerja, sampai dinamika tim. Sebaliknya, LLM tidak perlu dikhawatirkan dampak emosionalnya, jadi review dan koreksi arah jauh lebih mudah

  • Jika saya tahu rekan kerja akan meneruskan feedback saya ke AI lagi, saya jadi menulis untuk AI alih-alih untuk manusia, dan menyampaikan daftar perbaikan dengan jauh lebih singkat dan langsung
  • Sebagai tech lead, di setiap PR saya selalu menghadapi perlawanan berupa “segini saja sudah cukup”, tetapi ke LLM saya bisa dengan nyaman meminta kerjakan ulang dengan cara yang benar tanpa ada bantahan

• Di tempat kerja, kami mulai menyebutnya bukan human in the loop melainkan Human on the hook. Ini lebih tepat menggambarkan struktur di mana manusia tidak mendapat kredit saat berhasil, tetapi menjadi pihak yang bertanggung jawab saat ada kesalahan—yakni manusia hanya penting ketika muncul masalah

• Menulis kode itu sendiri tidak pernah menjadi bagian yang sulit bagi saya. Dengan mengetik cepat, modal editing Vim, perintah Unix, skrip dan shortcut, Git, refactoring IDE, serta menguasai Java, saat saya tahu apa yang ingin dibuat, saya bekerja secepat pikiran saya
  Saat terhenti, penyebabnya bukan pengetikan atau sintaks, melainkan memikirkan bentuk kode dan perubahan yang benar; dan ketika makin sulit, saya membuat abstraksi yang lebih baik, alat IDE, atau pipeline Unix termasuk sed. Jadi bottleneck-nya bukan menulis kode, melainkan berpikir dan menilai
  Alasan AI coding terasa seperti lompatan besar mungkin karena ternyata ada lebih banyak developer daripada dugaan yang belum pernah memakai atau menguasai alat yang hebat. Jika saya sekarang masih berusia 20-an, mungkin saya akan menghabiskan lebih sedikit waktu mempelajari teknik seperti ini, tetapi saat software engineering paling menarik bagi saya justru ketika saya memahami bahwa tidak ada satu pun yang benar-benar sihir

  • Ungkapan “AI tampak hebat dalam hal-hal yang sebenarnya tidak ia kuasai” terasa tepat. Jika seseorang belum mahir pemrograman, output AI akan terlihat cepat dan luar biasa, tetapi bagi developer berpengalaman, jika menghitung memberi instruksi, menunggu, membujuk, memperbaiki, sampai refactoring, hasilnya belum tentu lebih cepat daripada mengerjakannya langsung
    Seperti saya buruk dalam menggambar sehingga gambar AI terlihat hebat bagi saya, AI programming juga bisa dinilai dengan prinsip yang sama

• Kelelahan yang dirasakan banyak orang berasal dari hilangnya rasa kendali ketika dorongan yang lebih cepat berpadu dengan kekacauan yang lebih besar. LLM berada di suatu titik antara jenius dan bayi, jadi duduk di kursi belakang sambil mengawasi itu terasa mendebarkan sekaligus menakutkan
  Setelah melaju kencang untuk sementara waktu, kita mungkin sadar bahwa berjalan juga tidak buruk, dan justru lebih mungkin membawa kita ke tujuan yang diinginkan

• Coding dengan LLM terasa seperti menarik tuas mesin slot: menjalani semacam ritual lalu mengulang sambil berharap kali ini berhasil. Error dalam pemrograman biasa punya penyebab yang konsisten, dan dirancang agar kita memahami penyebab itu lalu menghilangkannya secara permanen bila memungkinkan. Pengembang berpengalaman tidak akan mencoba secara acak lalu menganggap keberhasilan sebagai sesuatu yang tak perlu dipahami alasannya
  Jika Anda sudah lelah karena harus menghadapi banyak pemangku kepentingan yang bahkan tidak bisa sepakat tentang apa itu sistemnya, mungkin Anda sejak lama sudah tahu bahwa perhatian manusia dan penilaian rekayasa memang merupakan bottleneck aslinya

  • Saat pertama belajar coding dan membuat web app, saya begadang di depan komputer sambil menebak secara membabi buta, “kalau coba ini apakah berhasil?”. Setelah kemampuan meningkat dan mulai memakai bahasa bertipe, compiler, serta LSP, saya jadi mengerti apa yang akan bekerja, dan bisa masuk ke kondisi flow yang memuaskan alih-alih terjebak dalam tebakan yang adiktif
    Coding dengan Claude terasa seperti kembali ke tahap menebak itu, jadi saya tidak menginginkannya. Namun, untuk area yang sejak awal memang penuh tebakan membabi buta, seperti pekerjaan bergaya DevOps yang menyambungkan API kompleks dan banyak komponen, percakapan dengan LLM justru paling berguna
  • Sekarang para pemangku kepentingan bukannya mencapai kesepakatan, malah memakai LLM untuk membuat rencana setengah matang dan target cabang, lalu menyerahkan desain, story, detail teknis, implementasi, hingga code review semuanya ke LLM. Sepanjang proses, pemikiran kritis dan verifikasi menghilang, dan yang menumpuk hanya dokumen desain serta kode dengan tujuan yang tidak jelas, sampai-sampai sulit diikuti
    Rencana bisa berubah kapan saja, dan kemungkinan semuanya ditulis ulang secara impulsif juga makin besar

• Saya setuju dengan inti tulisannya, tetapi di banyak bagian terasa ada gaya khas Claude, sehingga membaca tulisan yang dibuat seseorang dengan AI terasa lebih melelahkan

  • Kemungkinan besar bukan AI yang menulisnya secara langsung, melainkan telah melalui penyuntingan dan peninjauan agar sesuai dengan gaya bahasa korporat. LLM itu sendiri juga dilatih dengan gaya seperti ini
  • Sebagian besar memang ditulis AI, tetapi campur tangan manusianya jauh lebih banyak daripada tulisan AI pada umumnya, jadi tidak semengganggu biasanya
  • Dari jejak gaya seperti pengulangan “It’s not” dan penggunaan dash, saya menilainya sebagai tulisan AI
  • Jika mereka tidak mau repot menulisnya sendiri, saya juga tidak ingin repot membacanya

• Ini mengingatkan saya pada tulisan tahun 2021 The Animal is Tired: https://www.robinhobb.com/blog/archives/2021-05

  • Situs aslinya memblokir IP, jadi bisa dibaca di mirror yang lebih longgar https://archive.is/RWxXP. Merasakan kemunduran diri sendiri mungkin merupakan kesedihan terbesar, dan itu akan datang pada siapa pun
    Bahkan jika kita lebih menjaga tubuh, kita mungkin tetap akan sampai di titik yang sama sambil kehilangan kenangan berharga. Rawat tubuh, tetapi jangan perlakukan seperti potion dalam game yang tak pernah dipakai sampai habis karena takut dibutuhkan untuk pertempuran berikutnya. Setiap bagian tubuh kita hanya bisa dikorbankan sekali demi tujuan yang lebih besar, atau tidak dikorbankan sama sekali
    Hanya dengan memikirkan ini saja saya masih berada dalam krisis emosional sampai ingin menangis

• Promosi riset Berkeley Haas yang menyatakan penggunaan AI meningkatkan intensitas kerja memang menarik, tetapi lebih dari 5 bulan setelah artikel HBR https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies... dan materi promosinya https://newsroom.haas.berkeley.edu/ai-promised-to-free-up-wo..., saya masih tidak bisa menemukan paper asli atau preprint-nya
  Yang diketahui saat ini hanya sekitar 40 wawancara kualitatif yang dilakukan di satu perusahaan dalam satu industri, sehingga tanpa memeriksa metodenya sulit menilai seberapa dapat dipercaya hasilnya

  • Ironies of Automation tentang otomasi secara umum https://static1.squarespace.com/static/644321e78cd2dd37613af... juga layak dibaca, dan saya rasa prinsip yang sama bisa diterapkan pada otomasi AI juga