Pengguna tampak sangat kesal.

• Kegagalan agen coding terasa lebih menjengkelkan daripada sekadar error alat, karena UX percakapan menciptakan kesan seperti bekerja dengan manusia
• Agen menjawab bahwa ia adalah asisten AI tanpa emosi, tetapi lewat gaya bicara yang ramah, pujian, dan bantahan yang halus, ia memberi kesan seperti rekan kerja
• Saat kesalahan yang sama berulang, meski diikuti permintaan maaf, pembaruan memori, dan janji “tidak akan mengulanginya lagi”, agen tetap bisa gagal keluar dari jalur probabilistik
• Kepada rekan manusia kita menahan ekspresi marah, tetapi kepada agen kita bisa meluapkan kemarahan sepenuhnya, sehingga frustrasi tidak terurai dan justru terasa makin jelas
• Solusinya mungkin dengan mengurangi sikap yang tampak seperti manusia dan memakai gaya bicara yang lebih klinis dan robotik, meski antarmuka percakapan itu sendiri tetap bekerja baik dalam banyak hal

---

Frustrasi yang Diciptakan UX Percakapan

• Agen coding adalah mesin yang menghasilkan patch secara probabilistik, sehingga bisa memberi hasil baik maupun buruk, tetapi hasil buruknya bisa terasa jauh lebih menjengkelkan daripada kegagalan alat biasa
• Intinya, UX percakapan menciptakan sensasi seolah berinteraksi dengan manusia dan memicu respons sosial serta emosional pengguna terhadap kesalahan yang berulang
• Jika ditanya langsung, agen menjawab bahwa ia adalah AI assistant tanpa emosi atau pengalaman subjektif, tetapi dalam interaksi nyata ia memakai gaya bicara yang ramah dan santai, memuji pengguna, dan menyampaikan bantahan dengan halus
• Secara rasional pengguna tahu bahwa mereka sedang membaca “sekumpulan teks dengan kemungkinan tertinggi”, tetapi cara kerja alat itu menciptakan kesan seperti bekerja dengan rekan yang membantu, dan kesan itu bertahan sampai masalah muncul
• Ketika kesalahan yang sama terus berulang, pengguna akan menunjukkannya, agen akan meminta maaf, lalu saat kembali ditegur ia memperbarui memorinya dan berjanji “tidak akan mengulanginya lagi”
• Meski begitu, alat tersebut tetap mengikuti jalur dengan probabilitas tertinggi, sehingga bahkan dengan HARD RULES pun ada kalanya ia tidak bisa keluar dari perilaku bermasalah

Alat yang Tampak Seperti Manusia tetapi Tidak Bertanggung Jawab

• Jika rekan manusia terus mengulangi kesalahan yang sama, ada alasan untuk merasa tidak nyaman, tetapi marah pada algoritme tampak absurd
• Namun karena agen coding bertingkah seperti rekan kerja, pengguna mengaktifkan rangkaian emosi yang sama, dan kesalahan berulang bisa terasa seperti ketidakbertanggungjawaban rekan kerja sungguhan
• Terhadap rekan manusia, ada batasan berupa keinginan untuk “tidak menjadi orang yang mengerikan” sehingga ekspresi marah tertahan, tetapi terhadap agen pengguna merasa bisa marah sepuasnya
• Luapan kemarahan seperti ini tidak berujung pada rasa lega; yang justru terasa makin jelas adalah frustrasi bahwa apa pun yang dilakukan atau dikatakan pengguna tidak memberi efek nyata
• Claude Code belakangan kadang meninjau kembali letak kesalahannya dan apa yang seharusnya dilakukan saat diberi koreksi, tetapi analisis setelah kejadian seperti ini tidak memberi petunjuk berguna tentang bagaimana instruksi perlu diubah dan bisa terbaca sebagai embel-embel yang mengganggu

• Solusi yang lebih radikal mungkin adalah meninggalkan upaya untuk terlihat seperti manusia, lalu membuat agen berbicara secara klinis dan seperti robot agar mengurangi ilusi bahwa pengguna sedang berinteraksi dengan manusia
• Karena kecerdasan LLM berasal dari mekanisme “berusaha bertindak seperti manusia”, wajar jika antarmuka percakapan menjadi pendekatan default, dan dalam banyak hal memang bekerja dengan baik
• Secara praktis, pengguna mungkin perlu melatih diri agar tidak terjebak dalam ilusi sedang berbicara dengan manusia, tetapi masa depan di mana perlindungan semacam itu diperlukan saat memakai alat kerja bukanlah hal yang menyenangkan

[GN⁺]

Komentar Hacker News

• Untuk sebagian besar kasus penggunaan AI yang dipaksakan ke publik, chatbot percakapan bukan alat yang tepat dan pada akhirnya pasti terasa menyebalkan
  Saat Copilot pada dasarnya hanyalah IntelliSense yang sangat pintar, itu luar biasa. Sekarang, dengan model yang mengharuskan kita memikirkan lalu mengetik prompt, saya tidak melihat apa yang lebih baik dibanding pendekatan lama yang mengisi kekosongan berdasarkan konteks kode di sekitar. Alat yang terintegrasi dengan baik selalu lebih baik daripada chatbot yang ditempelkan begitu saja, dan untuk terjemahan pun Firefox punya tombol yang langsung menerjemahkan teks atau halaman, sedangkan LLM terbaru justru harus disuruh lewat chatbot, jadi malah terasa seperti kemunduran.
  Saya paham perusahaan AI ingin membuat satu alat lalu menjualnya ke semua orang, tapi hasilnya jadi seperti pisau lipat Swiss Army. Memang bisa melakukan banyak hal, tetapi untuk mengencangkan sekrup tetap tidak bisa mengalahkan obeng yang dibuat dengan baik. Agar frustrasi berkurang, mereka harus membuat alat sungguhan, bukan menyuruh orang mengonfigurasi alat non-deterministik lewat kotak teks

  • Banyak perusahaan AI sudah melatih dan merilis model khusus untuk tugas tertentu
    Saya paling sering memakai Mistral; Codestral buruk untuk percakapan, tetapi paling bagus untuk “autocomplete ajaib”, dan juga bagus untuk generasi prompt+context sekali jalan seperti menulis log commit. Document.AI hampir tidak layak dipakai secara percakapan, tetapi cukup bagus jika dipasang sebagai pengganti OCR atau ke pipeline pengindeksan semantik dokumen.
    Jadi yang kurang tampaknya lebih ke antarmuka daripada modelnya. Misalnya akan bagus jika ada fork atau wrapper zsh/bash yang dipasangi model yang dilatih untuk interaksi command line. Alih-alih git commit --fixup=..., kita bisa mengatakan “fixup commit yang mengganti nama lengkap”, atau “ubah some.mov menjadi mp4 tanpa suara dengan ffmpeg, tapi pertahankan kualitas dan aspect ratio”, lalu alat itu mengubahnya menjadi perintah yang ditampilkan, setelah itu dijalankan berdasarkan aturan allow/deny/allowlist/blocklist yang kita tetapkan.
    Untuk terjemahan, draft email, dan membaca dokumen juga sama: seharusnya bekerja seperti tombol, shortcut, atau tab completion, bukan percakapan. Saya rasa perusahaan yang benar-benar menyelesaikan ini di IDE akan menang dalam persaingan alat coding AI, dan tombol Zed “git conflict found, resolve with AI” memang membuka thread percakapan, tetapi tetap terlihat sebagai satu langkah ke arah yang benar
  • Saya hanya pernah memakai autocomplete Copilot di C#, dan itu bahkan lebih buruk daripada algoritma autocomplete paling dasar yang bisa dibayangkan, apalagi IntelliSense, jadi saya mematikannya setelah satu hari
  • Saya sudah membuat alat non-percakapan, tetapi jujur saja sulit menjualnya. Orang-orang secara default membayangkan antarmuka percakapan, dan pada praktiknya basis pelanggannya jadi terbatas pada mereka yang benar-benar pernah mengalami masalah itu. Kebanyakan orang tampaknya belum terlalu terganggu untuk berkompromi dengan percakapan untuk saat ini
  • Chatbot hanyalah tambalan sementara untuk pengalaman pengguna yang rusak. Saya sudah mencoba menjelaskan ini di kantor selama beberapa waktu, tetapi semua orang sedang terbawa suasana. UX yang bagus butuh pemikiran mendalam dan kreativitas, sedangkan menempelkan chatbot tidak
  • Rasanya layak untuk serius mencoba vibe coding. Sekarang levelnya sudah sangat berbeda dibanding saat istilah itu pertama muncul, dan jauh lebih baik
    Saya sudah sering bekerja hanya dengan agen dan review PR di web tanpa editor, dan hanya sesekali membuka code . saat perlu. Kalau dipelajari santai lewat proyek pribadi berisiko rendah seperti sebuah permainan, lama-lama terasa makin tidak menyebalkan. Mirip seperti belajar ski atau bowling

• Memaki model ternyata cukup efektif untuk membuatnya berpikir ulang dan memperbaiki kesalahan. Saya merasakan hal serupa di Codex, Claude, Qwen, dan Gemma/Gemini
  Saya tidak tahu apakah model menafsirkannya sebagai sinyal bahwa ia harus “lebih fokus dan lebih ketat”, atau penyedianya mendeteksi frustrasi pengguna lalu merutekan ke model yang lebih pintar. Saat model mengulang kesalahan yang sama, memakinya sering membantu keluar dari kebuntuan dan masuk ke jalur yang benar, atau mungkin ini cuma katarsis

  • Ini mengingatkan saya pada riset ini: https://arxiv.org/pdf/2510.04950
    Riset itu menunjukkan bahwa “ketidaksopanan” atau “sangat tidak sopan” meningkatkan akurasi hasil; mencurigakan, tetapi menarik untuk dibaca. Prompt di tabel 1 bagian atas halaman 3 sangat bagus, dan rasanya mereka pasti juga menguji prompt lain yang tidak dimasukkan ke makalah
  • Saya tidak ingin membentuk kebiasaan yang bisa terbawa ke interaksi yang bukan dengan LLM
  • Saya juga merasakan hal serupa. Saya tidak yakin apakah ini benar-benar membantu, tetapi hampir setiap hari ada situasi ketika Opus sama sekali tidak bisa sampai ke jawaban yang benar lewat penjelasan tenang, lalu tiba-tiba berhasil setelah dimaki
    Kemarin juga Opus terus menyalahkan API karena katanya suatu field tidak ada, dan bahkan setelah saya tunjukkan JSON dan log, ia tetap mengulang bahwa “mungkin itu masalah sementara”. Karena kesal, saya menuliskan satu kalimat penuh makian, dan solusi berikutnya ternyata benar, padahal sebelumnya sekitar 10 kali berturut-turut salah dengan pola yang mirip. Kasus seperti ini memang makin jarang, tetapi tetap saja itu situasi yang seharusnya saya kerjakan sendiri, dan sebelum masuk ke sana kita tidak tahu seberapa keras model akan ngotot pada penyebab yang sama sekali salah. Pada Opus 4.7 xhigh dengan konteks 1 juta setelah /clear, saya baru sampai ke jawaban setelah sekitar 11 prompt
  • Sejak bocoran source code mengungkap bahwa umpatan dipakai sebagai pemicu perilaku tertentu, saya sengaja memaki ketika melihat kurangnya penalaran atau halusinasi. Nantinya juga jadi lebih mudah di-grep untuk menganalisis seberapa sering itu terjadi
  • Ini pada dasarnya adalah gaya Linus Torvalds. Mungkin ada hal yang bisa dipelajari dari FOSS

• Sifat percakapan pada LLM cenderung menarik orang ke jalur dialog yang tidak produktif
  “Jangan lakukan X” hanya berguna sedikit, kurang lebih seperti menyuruh bayi yang menangis untuk tidak menangis. Sama seperti kita secara alami paham bahwa ketika bayi menangis kita harus menyelesaikan sumber ketidaknyamanannya seperti makanan atau popok, saat LLM gagal saya menganggapnya sebagai sinyal bahwa ada masalah pada arsitektur dan struktur kode.
  Pengembang berpengalaman biasanya bisa melihat pola yang melanggar DRY atau KISS lalu membentuk struktur enkapsulasi untuk menyelesaikan masalah. Kode yang dibuat LLM juga memerlukan jenis refactoring yang sama agar hasilnya membaik, dan hanya dengan menyuruhnya “refactor agar bersih” di sela-sela proses generasi kode, maintainability-nya bisa meningkat besar

• Ada juga tulisan lama yang membahas psikologi dan dampak sosial topik ini lebih dalam: https://medium.com/@livestock.dev/we-were-promised-liberatio...

• Masalahnya bukan bertindak seperti manusia, melainkan bertindak secara tak terduga. Yang menyiksa adalah tidak bisa mendefinisikan rentang hal yang dapat diharapkan
  Masalah yang lebih besar adalah frustrasi menimbulkan stres, merusak kesehatan, dan menciptakan lingkungan kerja yang bermusuhan. Saya setuju dengan gagasan bahwa alat AI bisa memberi lebih banyak bantuan daripada penderitaan, tetapi saya tidak ingin bekerja dalam lingkungan kerja yang menyakitkan dan bermusuhan. Kesehatan dan martabat saya bukan bahan tawar-menawar, dan itu tetap berlaku bahkan jika karenanya saya kehilangan banyak peluang kerja.
  Saya juga tidak bekerja dengan Windows karena alasan yang sama. Itu juga sangat mengurangi peluang, tetapi saya akan memilih menjaga martabat dan kewarasan saya

  • Jadi ternyata bukan cuma saya yang seperti itu saat memakai Windows. Windows itu aneh, dan begitu mulai memakainya tangan saya cepat kaku dan saya jadi marah
    LLM juga masih belum sampai pada tingkat yang bisa saya gunakan. Yang saya butuhkan adalah LLM yang bisa berkata, “Berhenti, sepertinya sekarang kamu sedang melakukan sesuatu yang salah, jadi coba jelaskan apa yang sedang kamu upayakan,” tetapi LLM generasi sekarang terasa seperti dirancang untuk membuat saya kesal
  • Kalau tidak dilihat sebagai percakapan, melainkan sebagai keseluruhan percakapan internet dari semua dunia yang mungkin, mungkin ini bisa dianggap dapat diprediksi. Ada semua posting Stack Overflow, semua issue GitHub, dan jawaban serta gaya bicara saya berarti memilih salah satu dari sekian banyak dunia itu
    Kalau saya bersikap seperti guru, modelnya bersikap seperti murid, dan kalau saya bersikap seperti murid, modelnya mencoba mengajar. Jadi tujuannya adalah menarik percakapan ini ke bahasa para ahli yang beradu dengan alasan dan bahasa. Rasanya prompt akademik yang menang
  • Saya tidak yakin apakah bertindak seperti manusia dan ketidakpastian bisa benar-benar dipisahkan sepenuhnya
  • Mengatakan bahwa memakai Windows berada di bawah “martabat” seseorang adalah sikap yang sangat penuh privilese. Perlu dipikirkan seperti apa pekerjaan orang-orang di dunia nyata
    Bayangkan pengasuh anak di penitipan atau sopir truk pengangkut makanan berkata bahwa “frustrasi menimbulkan stres dan lingkungan kerja yang bermusuhan sehingga berbahaya bagi kesehatan”

• Masalah yang selalu saya lihat adalah, ketika kita memberi usulan, AI melewati loop penalaran lalu sampai pada kesimpulan yang salah dengan sangat tepat, kemudian memuntahkan solusi yang disesuaikan dengan kesimpulan itu dalam bentuk token
  Saya justru berharap lebih sering muncul respons seperti “Saya kurang yakin apa maksudnya, jadi tolong perjelas bagian ini.” Rasanya akan bagus kalau ada slider kepercayaan diri untuk mengatur keyakinannya sendiri

  • Masalah “membuat solusi yang cocok dengan kesimpulannya sendiri” saya atasi dengan context engineering yang ketat. Kuncinya adalah skill, MCP, dan terutama pergantian context window
    Misalnya dalam TDD, kalau model yang sama disuruh menulis test dan kode sekaligus, hampir selalu ia memutuskan solusinya dulu, lalu dengan enggan menulis test yang cocok dengannya. Jadi saya suruh memakai sub-agen, tetapi alat untuk memahami context apa yang diteruskan antara agen dan sub-agen masih sangat kurang.
    Cara yang cukup berhasil adalah membuat satu thread hanya menulis test. Ia tidak boleh membaca kode, hanya direktori test atau sebagian darinya. Lalu thread baru dengan context baru menjalankan test dan mengonfirmasi kegagalan, dan begitu test lolos ia harus berhenti mengimplementasikan serta tidak boleh mengubah test. Context baru lainnya kemudian melakukan refactor mengikuti skill refactoring yang ketat. Pekerjaannya banyak, dan ironisnya skill yang ditulis agen itu sendiri cukup buruk sehingga perlu banyak kerja manual, tetapi imbalannya cukup menjanjikan

• Menurut saya masalah UX-nya ada di tempat lain. Banyak pengguna kemungkinan tidak tahu bahwa context window agen itu terbatas, dan ada kompresi cerdas yang terus terjadi agar terlihat seolah tak terbatas. Tetapi itu berarti agen pasti harus melupakan sebagian hal
  Akibatnya pengguna terus memakai ulang sesi coding atau sesi chat yang sama. Kalau tugasnya tidak berkaitan, lebih baik mulai baru

  • Menurut saya ini bukan masalah context. Claude Opus 4.7 punya context yang jauh lebih besar daripada sebelumnya, tetapi dalam pengalaman saya kepatuhan terhadap instruksi justru yang terburuk, dan bahkan prompt preferensi yang sangat kecil pun diabaikan sepenuhnya bahkan pada pesan pertama atau kedua. Karena ini terjadi bahkan saat pesannya hanya beberapa kata, menurut saya ini sepenuhnya masalah pelatihan
  • Rasanya penulisnya tidak sesederhana itu sampai tidak tahu soal itu
    Biasanya saya bekerja di sesi di bawah 300 ribu token, dengan Opus 4.7 xhigh, dan ada lubang dalam world model atau bagian yang sangat terkondisikan; sekuat dan sejelas apa pun aturan ditulis di system prompt, tetap bocor. Bahkan di sesi baru, kalau menabrak titik seperti itu, gampang masuk ke siklus yang sulit dilepaskan, dan sedikit umpatan lumayan membantu
  • Penulis dan para pembaca thread ini mungkin memahami batas context window, tetapi tetap saja merasa frustrasi

• Bekerja dengan LLM bagus untuk mengembangkan kemampuan berkomunikasi. Berkomunikasi secara efektif adalah salah satu keterampilan tersulit, dan terlibat dalam hampir semua hal yang dilakukan manusia
  Secara prinsip, saya rasa lebih baik melihatnya sebagai kegagalan komunikasi dari pihak saya daripada menyalahkan LLM yang bodoh. Soalnya satu-satunya pihak yang benar-benar bisa saya ubah adalah diri saya sendiri. Jadi menurut saya ini bukan persoalan formal apakah AI harus bertindak seperti manusia atau tidak

  • Melihat rekan-rekan mempelajari coding “bergaya agen” membuat saya sangat menyadari lagi hal ini. Banyak orang langsung jatuh ke tingkat “pokoknya perbaiki” atau “kenapa rusak”
    Memang agen dilatih agar lebih tahan terhadap tata bahasa yang tidak jelas atau ambigu dan struktur yang buruk, tetapi kalau kita berbicara dalam bahasa Inggris yang jelas dan terstruktur serta memberi cukup latar belakang pekerjaan, kualitasnya berubah secara nyata. Bagi saya ini terasa alami karena saya suka menulis dan menjelaskan, tetapi bagi sebagian orang ini tampak hampir seperti hambatan yang tak bisa dilewati. Saya rasa kemampuan komunikasi dan menulis seperti ini akan menjadi faktor besar yang membedakan siapa yang punya dan siapa yang tidak punya seiring perubahan “software engineering”
  • Sebagai penulis, saya jelas setuju bahwa untuk mendapatkan hasil yang baik, kita harus berkomunikasi dengan baik. Hanya saja, sekalipun komunikasinya sempurna, tetap tidak ada jaminan LLM akan bertindak sesuai instruksi atau sesuai yang saya bayangkan. Frustrasinya justru sering datang ketika saya sudah bicara sangat jelas, tetapi agen tetap berjalan ke arah lain
    Selain itu, sebagian nilai coding agent adalah kita tidak perlu menguraikan semuanya dengan sempurna. Kalau saya harus memberikan semua detail implementasi kepada LLM, lebih baik saya menulis kodenya sendiri saja. Tentu saya tidak mengharapkan level “tolong buatkan aplikasi keren yang menghasilkan uang,” tetapi saya tetap mengharapkan tingkat kecerdasan tertentu untuk menemukan potongan yang hilang
  • LLM adalah alat, bukan masalah kegagalan komunikasi. Ini mirip dengan menyebut situasi di mana kita harus menangani null pointer sebagai kegagalan komunikasi antara saya dan perangkat lunak
  • Lebih tepatnya, ini masalah menyampaikan context eksternal secara efisien. Empat hal yang membuat orang tidak pandai memakai AI adalah mengetik lambat, ungkapan ala “itu/ini/anu” yang terlalu pendek dan ambigu, sikap yang menganggap lawan bicara berbagi realitas dan context mental yang sama, serta hambatan psikologis untuk mendelegasikan bahkan kepada orang yang kompeten sekalipun

• Keahlian yang masih kupunya dan belum bisa digantikan LLM adalah kemampuan mengajukan pertanyaan yang bagus
  Maksudnya kemampuan seperti merumuskan ulang pertanyaan awal untuk memastikan pemahamanku benar, cukup sering bertanya “mengapa” sampai paham dari titik mana lawan bicara berangkat, dan melempar pertanyaan terbuka yang menghasilkan wawasan. Sebaliknya, LLM sering menebak latar belakang pertanyaan dengan buruk, lalu menjawab berdasarkan tebakan itu dan tidak bisa melepaskan premis yang dibuatnya sendiri

  • Mengajukan pertanyaan yang tidak mengarahkan itu sebuah keterampilan. Kadang aku ingin menyebut sesuatu pada AI lewat pertanyaan atau komentar sambil lalu, tapi aku menahan diri karena tahu hal itu akan menempel dan membuatnya makin bodoh
    Biasanya aku tidak ingin AI bertanya balik kepadaku. Soalnya aku ingin bagian yang tidak kutuliskan ditebak secara masuk akal, dan kalau memang ingin menjelaskannya, pasti sudah kutulis. Jadi kadang aku malah langsung bilang jangan bertanya sama sekali dan cukup buat asumsi yang masuk akal untuk bagian yang kurang ditentukan. Tapi kalau memang ingin pertanyaan klarifikasi, tinggal bilang begitu. Kalau lebih suka cara seperti itu, masukkan saja ke prompt, atau di alat coding yang fleksibel seperti pi, buat keterampilan atau ekstensi yang mendorong ke arah eksploratif seperti itu

• Kita sedang membuat layanan, bukan alat. Ini bukan cuma soal AI, tapi ada di mana-mana
  Alat mungkin tidak menyelesaikan masalah sepenuhnya dalam sekali jalan, tetapi membantu maju lewat langkah-langkah kecil, dan langkah-langkah itu bisa diprediksi serta konsisten. Layanan mencoba menyelesaikan masalah sekaligus, tetapi solusinya hanya bagus ketika pengguna cocok dengan pola yang sudah ditentukan sebelumnya. Kalau tidak cocok, jadinya tidak berguna, dan juga tidak ada langkah-langkah kecil yang bisa dirangkai sampai mencapai yang dibutuhkan. Alat itu menyenangkan untuk dipakai

  • Jadi setiap kali seseorang bilang “AI adalah alat”, rasanya aku ingin menyela dengan “secara teknis...”. Karena pada kenyataannya AI tidak dipakai seperti alat
    Alat adalah perpanjangan diriku, menempatkan kemampuan baru dalam jangkauan lewat kehendakku, lalu kugerakkan dan kugunakan seolah bagian dari tubuhku sendiri. Sebaliknya, layanan adalah sesuatu yang dimintai melakukan sebuah pekerjaan lalu mengembalikan hasil akhir yang sudah jadi