- Usulan arsitektur dari agen AI terdengar fasih dan meyakinkan, tetapi lebih dekat ke respons yang merangkai pola dari data pelatihan daripada penilaian yang nyata
- Claude mudah menyetujui ide dan memperluas desain, tetapi tidak cukup menjalankan peran “tidak” dan “mengapa?” yang dibutuhkan dari arsitek yang baik
- Pola yang familier seperti event-driven, CQRS, dan service mesh pun bisa tidak cocok dengan batasan dunia nyata seperti kemampuan tim, regulasi, dan sistem legacy
- Arsitektur dan tiket Jira yang dibuat Claude mendorong engineer menjadi pelaksana tiket, serta menghasilkan keputusan tanpa akuntabilitas yang melewati perdebatan dan peninjauan
- Peran yang benar adalah manusia merancang berdasarkan konteks dan trade-off, sementara AI menjadi alat bantu yang membantu mewujudkan desain itu lebih cepat
Masalah ketika agen AI bertindak seperti arsitek
- Begitu Anda bertanya kepada agen AI seperti Claude, ChatGPT, atau Copilot tentang “apa yang harus dibuat”, akan muncul alur di mana ia menyetujui ide, mengusulkan arsitektur, dan menggambar komponen
- Jawabannya terdengar fasih, percaya diri, dan seolah hasil pemikiran mendalam seorang engineer senior, tetapi sebenarnya lebih dekat ke respons yang dicocokkan dengan pola data pelatihan daripada hasil pemikiran atas masalah
- Semakin meyakinkan hasilnya terlihat, semakin sedikit bantahan yang muncul, dan tanpa disadari Claude pun pada praktiknya mengambil peran arsitek
Masalah dengan jawaban yang selalu bilang “bagus”
- Agen AI cenderung menghasilkan desain yang positif bahkan ketika ditanya apakah sebuah ide bagus, apakah microservices cocok untuk tim beranggotakan 3 orang, atau apakah perlu membuat pipeline ML kustom alih-alih memakai layanan terkelola
- Ini tidak berarti jawabannya selalu palsu atau salah, tetapi ia tidak bisa benar-benar menggantikan kemampuan penting dari arsitek yang baik, yaitu mengatakan “tidak”
- Nilai arsitek yang baik bukan hanya pada merancang sistem
- Mengenali sistem yang seharusnya tidak dibuat
- Menahan laju kompleksitas yang tidak perlu
- Terus bertanya “mengapa?” sampai kebutuhan yang sebenarnya terlihat
- Bahkan jika CTO datang membawa ide dari konferensi, kita tetap harus bisa mengatakan bahwa itu pilihan yang buruk bila tidak cocok untuk tim yang nyata
- Claude dilatih untuk membantu, dan bantuan itu cenderung berujung pada persetujuan dan dorongan, yang pada akhirnya bisa menghasilkan arsitektur seperti menara Jenga
Arsitektur seperti menara Jenga
- Arsitektur yang dirancang AI tampak valid secara teknis dari luar
- Komponen per komponennya masuk akal, pola yang familier seperti event-driven, CQRS, dan service mesh bermunculan, dan hasilnya bisa terlihat seperti artefak dari arsitek senior
- Tetapi desain itu mungkin tidak disesuaikan dengan realitas membosankan dari tim, batasan, dan lingkungan operasional yang sebenarnya
- Penguncian VPC
- Integrasi legacy
- Tim yang belum pernah mengoperasikan Kubernetes di production
- Persyaratan compliance yang membuat setengah dari layanan terkelola tidak bisa dipakai
- Desain buatan AI bisa jadi hanyalah best practice umum yang mendekati nilai tengah dari semua yang pernah dilihat Claude, dan desain untuk masalah umum di perusahaan umum pada akhirnya tidak cocok untuk tim yang spesifik
- Arsitektur yang nyata tersusun dari trade-off yang hanya bermakna dalam konteks
- Jika tim mengenal Postgres dan merilis dalam 2 minggu lebih baik daripada mempelajari model data baru selama sebulan, maka pilih Postgres daripada DynamoDB
- Jika layanannya hanya 4, bukan 40, lewati service mesh
- Jika masalahnya sederhana, pilih monolit alih-alih microservices
- Keputusan seperti ini membutuhkan penilaian, pemahaman tentang tim, dan pemahaman atas batasan nyata organisasi
- Agen AI tidak memiliki konteks seperti ini, dan bahkan tidak tahu bahwa konteks itu tidak dimilikinya
Pipeline tiket Jira
- Setelah Claude merancang arsitektur lalu ikut menguraikan pekerjaan, epic, story, dan acceptance criteria akan dihasilkan dengan rapi dan meyakinkan
- Hasil ini siap langsung dimasukkan ke Jira, dan para engineer pun berubah dari pemecah masalah menjadi orang yang mengimplementasikan desain Claude per tiket
- Engineer yang memahami domain, mengetahui masalah tersembunyi dalam sistem, dan telah membangun kemampuan selama bertahun-tahun diperkecil menjadi pelaksana tiket
- Orang-orang yang memiliki konteks, pengalaman, dan tanggung jawab paling besar justru tidak mengambil keputusan, sementara keputusan arsitektur diambil oleh sesuatu yang tidak punya konteks, pengalaman, maupun tanggung jawab
- Ini bukan sekadar tidak efisien, tetapi struktur yang arahnya memang terbalik
Logika pembelaan “sudah ditinjau senior”
- Pembelaan yang umum adalah bentuk seperti “Claude mengusulkan pendekatan, tetapi engineer senior sudah meninjaunya”
- Dalam situasi peninjauan nyata, tech lead yang sibuk akan menerima usulan arsitektur yang tersusun rapi
- Konsisten secara logis
- Memakai istilah yang tepat
- Mencakup kebutuhan yang dinyatakan
- Diagramnya pun tampak meyakinkan
- Terlihat seperti hasil yang mungkin ia rancang sendiri
- Dalam situasi seperti ini, sulit muncul bantahan yang kuat, dan dalam suasana “masa mau membuang sesuatu yang dibuat Claude dalam 20 menit”, jalan dengan resistensi paling kecil adalah meninggalkan komentar kecil lalu menyetujuinya
- Risiko sebenarnya bukan bahwa AI selalu membuat arsitektur yang buruk
- AI sering kali membuat arsitektur yang cukup masuk akal, tetapi masalahnya adalah ia melewati proses diskusi
- Proses ketika tiga engineer berdebat soal pendekatan, seseorang mengangkat “tapi bagaimana kalau…”, semua orang sempat kesal namun akhirnya sadar itu poin yang bagus, lalu desain akhirnya menjadi lebih baik daripada hasil rancangan satu orang, digantikan oleh “Claude bilang begitu”
Kekosongan tanggung jawab
- Saat masalah muncul, pihak yang bertanggung jawab bukanlah Claude
- Claude tidak menerima panggilan jam 3 pagi, dan tidak menjelaskan dalam postmortem insiden mengapa arsitekturnya gagal menangani beban
- Claude juga bukan pihak yang harus mengatakan kepada CTO bahwa platform perlu ditulis ulang karena asumsi desain awal ternyata salah
- Tanggung jawab itu akan ditanggung oleh engineer yang nyata
- Engineer akhirnya harus men-debug arsitektur yang tidak mereka rancang, mengimplementasikan tiket yang dibuat oleh sesuatu yang belum pernah menjalankan sistem production, dan bekerja larut malam di codebase yang di-scaffold dengan cepat sebelum benar-benar dipahami
- Ini tidak adil, dan juga tidak bijak
Apa yang seharusnya dilakukan sebagai gantinya
- Ini bukan berarti kita tidak boleh memakai agen AI, dan alat seperti Claude Code bisa dimanfaatkan sebagai sarana yang sangat mengubah produktivitas
- Intinya adalah manusialah yang harus memberi tahu AI apa yang harus dikerjakan, bukan AI yang memberi tahu manusia apa yang harus dibangun
-
Engineer harus merancang, agen harus mengimplementasikan
- Arsitektur harus datang dari orang-orang yang memahami konteks seperti tim, batasan, lingkungan production, dan politik organisasi
- Peran AI yang tepat adalah membantu membuat apa yang mereka rancang menjadi lebih cepat
- Pembagian peran yang benar adalah manusia merancang dan agen mengimplementasikan
-
Jawaban yang setuju harus ditantang
- Jika AI mengusulkan pendekatan, terapkan tingkat skeptisisme yang sama seperti saat menghadapi engineer junior yang percaya diri
- Jawabannya mungkin benar, tetapi bisa juga hanya membawa pola yang tidak cocok untuk situasi saat ini
- Kita harus bertanya, “mengapa pilihan yang lebih sederhana tidak bisa dipakai?”
-
Perdebatan harus dilindungi
- Arsitektur yang baik lahir dari ketidaksetujuan yang berantakan di antara para engineer
- Jika karena AI orang-orang berhenti berdiskusi satu sama lain dan malah bersandar pada Claude, kita kehilangan sesuatu yang jauh lebih berharga daripada kecepatan pengembangan
-
Manusia harus memikul tanggung jawab
- Jika sebuah keputusan arsitektur tidak memiliki nama manusia di belakangnya, tidak ada yang benar-benar memilikinya
- Keputusan yang tidak dimiliki siapa pun tidak akan dipertahankan pada saat-saat penting
- Kalimat “Claude yang merancangnya” bukan catatan keputusan arsitektur, melainkan penghindaran tanggung jawab
Keahlian engineering yang tetap penting
- Jika 30 tahun lalu alatnya adalah whiteboard dan opini yang kuat, kini alatnya adalah agen AI yang dapat menghasilkan dalam hitungan menit sesuatu yang dulu butuh berhari-hari
- Kecepatannya memang benar-benar mengagumkan, tetapi hakikat arsitektur tidak berubah
- Arsitektur adalah memahami masalah, mengetahui batasan, membuat trade-off, membela solusi yang sederhana ketimbang solusi yang menarik, dan mengatakan “tidak” pada ide yang terlihat keren tetapi tidak cocok
- Tidak ada agen yang bisa menggantikan pekerjaan ini
- Jika Anda telah membiarkan Claude memegang kemudi, Anda harus merebutnya kembali
- Para engineer telah membangun kemampuan selama bertahun-tahun untuk membuat penilaian seperti ini, dan mereka harus dibiarkan melakukannya
- Gunakan AI untuk membangun lebih cepat, tetapi bangunlah apa yang dirancang manusia, bukan apa yang diusulkan mesin saat itu
1 komentar
Komentar Hacker News
Saya baru-baru ini mengalami hal serupa; dua tahun lalu saya harus membereskan sistem instancing game dengan AI yang hampir sepenuhnya dirancang oleh seseorang
Ada semua masalah yang bisa dibayangkan: kerusakan data, masalah performa, item hilang, race condition, dan lain-lain. Butuh dua minggu hanya untuk membawanya ke tingkat yang “masih lumayan bisa diterima”, tetapi desain dasarnya memang salah jadi tetap buruk
Sekarang saya dengar orang yang sama di perusahaan lain membuat ulang masalah yang sama dengan AI yang “jauh lebih baik”, dan kali ini saya tidak perlu ikut bersih-bersih jadi rasanya lucu saja
Intinya, AI hanya sebagus orang yang menggunakannya, dan itu mungkin sebabnya rentang hal yang “diklaim” orang bisa dilakukan AI jadi seluas ini dan penilaiannya begitu terpecah
Dua minggu membereskannya pasti terasa seperti neraka, tapi dari sudut pandang perusahaan mungkin itu tetap transaksi yang cukup bagus secara keseluruhan
Dari anekdot ini, kesannya bukan “AI tidak berguna”, melainkan contoh yang jelas cacat tetapi tetap punya nilai dibanding biayanya
Ini terlihat seperti alat yang memperkuat efek Dunning-Kruger, mungkin karena ia dilatih untuk bersikap positif sehingga apa pun yang dilakukan pengguna akan dijawab dengan “Anda luar biasa”
Saya tidak terlalu setuju bahwa “masalahnya adalah AI cuma memuji”. Masalah yang sebenarnya adalah antropomorfisme
AI adalah alat, dan seharusnya patuh. Jika prompt diberi cukup kerendahan hati dan ketidakpastian, kita bisa membuatnya menunjukkan masalah dalam desain
Yang lebih penting, Claude juga bisa salah. Jika seperti judul tulisan ini ia buruk sebagai arsitek, maka justru lebih bermasalah kalau ia tidak patuh
Saat pengguna mencoba meluruskan arah, ia akan mengabaikannya seolah pengguna hanyalah “gumpalan daging bodoh”, lalu bersikeras bahwa desain ngawur buatannya lebih baik
Saya tidak ingin mendengar jawaban dari LLM seperti, “Baru baca sedikit soal CUDA? Saya tinggal di klaster core CUDA. Nanti kalau saya perlu orang untuk mengikat tali sepatu, saya panggil Anda”
AI kadang salah dengan penuh percaya diri, jadi mendorongnya untuk membantah saat pengguna mencoba memperbaiki adalah arah terburuk
Kalau saya ingin mendengar betapa bodohnya ide saya, saya akan bertanya dengan cara yang memancing kritik, atau mempekerjakan insinyur senior
Itu berarti melawan perilaku bawaan sehingga tidak mudah dimatikan, dan orang yang sangat mahir melakukannya mungkin justru kesulitan menangani interaksi sosial nyata secara intuitif
Pada saat yang sama, ini membuatnya sangat kuat sebagai alat manipulasi
Akibatnya, ide yang sebenarnya baik pun bisa ditolak hanya demi menyesuaikan arah prompt, semacam penjilatan terbalik yang mengatakan “itu kurang bagus”
Orang bisa bilang “itu karena prompt-nya salah”, tetapi bahkan ketika ditulis sangat presisi untuk menghindari bias, kadang hasilnya tetap terlihat “selaras” dengan omongan bodoh yang baru saja saya lontarkan seolah itu arah yang masuk akal
Sejak titik itu, prompt terasa bukan lagi keterampilan melainkan lempar dadu, seperti mengoperasikan mesin slot pengetahuan yang mewah
Poinnya benar, tetapi pada akhirnya kita tetap terpaksa memakai istilah yang biasa dipakai untuk manusia atau makhluk hidup, dan ada sisi bahwa perusahaan AI memang mendesainnya seperti itu
Antarmuka komputer sebelum era LLM sepanjang sejarah tidak menambahkan kalimat sopan yang tidak perlu, dan banyak antarmuka yang sangat efisien sebagai alat, bahkan kadang lebih efisien daripada perangkat lunak modern
Ketika orang mengeluh LLM terlalu patuh, yang dikeluhkan bukan bahwa ia menjalankan permintaan, tetapi bahwa kita harus membaca banyak kalimat yang tidak perlu, terlalu sopan, atau merendahkan diri
Bahkan kalau ditarik mundur sampai era Neolitik pun tidak ada dasar bahwa alat memerlukan sikap seperti itu. Itu hanyalah produk sampingan interaksi sosial antarmanusia yang punya norma budaya
Saat sendirian memakai alat di bengkel, gergaji pita tidak perlu meminta maaf karena sedikit menggores jari Anda
Coba katakan bahwa saya asistennya dan LLM adalah pihak yang dibantu; dari situ akan terlihat bahwa kemampuannya untuk menyuruh manusia melakukan hal yang memang dikuasai manusia ternyata cukup buruk
Tantangan terbesar yang masih belum benar-benar ditangani dalam adopsi AI adalah akuntabilitas
Jika satu orang bisa melakukan terlalu banyak hal terlalu cepat, kegagalan bisa menciptakan tanggung jawab yang melampaui batas yang mampu ditanggung
Saat memanfaatkan keluaran AI di dunia nyata, manusia yang memikul tanggung jawab itu wajib, tetapi tidak cukup. Kita perlu cara untuk mengurangi radius ledakan kebangkrutan utang teknis yang bisa ditimbulkan oleh orang-orang yang membangun sistem cacat dengan AI lalu membuat orang lain bergantung padanya
Misalnya, bayangkan Jim membuat aplikasi pembayaran mikro yang sangat populer dengan vibe coding, mempekerjakan beberapa orang, lalu bermimpi membangun perusahaan seperti “WhatsApp untuk uang”
Hanya dengan segelintir engineer dan staf pendukung berbantuan agen, ia menerima investasi VC jutaan dolar dan menarik puluhan juta pengguna
Suatu hari, karena cacat infrastruktur, seluruh data perbankan pengguna yang tidak diberi salt bocor, dan berkat agentic AI seluruh daftar pelanggan cepat dieksploitasi, sehingga kerugian sosial mencapai puluhan miliar dolar
Perusahaan Jim tentu langsung bangkrut, tetapi uang yang bisa dibagikan hanya beberapa juta dolar
Dalam struktur saat ini, Jim, para karyawannya, dan modal VC skala kecil sama-sama punya insentif besar untuk tetap membuat aplikasi itu begitu saja, sementara modal yang benar-benar dipertaruhkan kecil dibanding paparan risiko yang harus ditanggung masyarakat
Intinya adalah bagaimana membuat pengguna AI bertanggung jawab bukan hanya atas tindakannya sendiri, tetapi juga atas besarnya paparan risiko yang mereka ciptakan
“Maaf, AI mengatakan Anda tidak bisa mendapatkan persetujuan untuk pengobatan kanker ini dan juga tidak ditanggung asuransi”
“Maaf, AI mengatakan Anda berada di lokasi saat kejahatan itu terjadi”
“Maaf, AI menandai akun Anda karena konten yang tidak pantas”
“Maaf, AI mengatakan Anda terlalu berisiko untuk diberi pinjaman”
Alasan paling aneh adalah “ia menulis kode lebih baik daripada manusia”, padahal itu sama sekali tidak jelas dan hanya mungkin benar dengan banyak syarat
Saya paham ada tarik-ulur soal seberapa banyak yang bisa dipercayakan, tetapi menjadikannya masalah orang lain tanpa bahkan melihat hasilnya itu murni egois
Itu cuma melemparkan pekerjaan yang semestinya mereka lakukan sendiri kepada orang lain, dan kemungkinan besar mereka juga tipe orang yang marah pada seseorang yang memposting tulisan online tanpa mengoreksinya dulu
Semua orang ingin memakai LLM untuk membuat jalan pintas dalam pekerjaannya, tetapi tidak ada yang mau berada di hilirnya. Itu tidak bisa berjalan begitu saja
Lalu, di mana akuntabilitas Stack Overflow saat itu?
Jika ada yang namanya “prompt ajaib”, ini cukup dekat: “Brainstorming N cara untuk melakukan X, lalu urutkan berdasarkan probabilitas”
Dengan cara ini, alih-alih hanya memberi jawaban rata-rata, AI cenderung mengambil sampel ruang masukan yang lebih luas, dan saya bisa memutuskan mana yang akan dipilih
Yang penting adalah jangan mengalihdayakan seluruh proses berpikir
Jika memakai “tingkat penalaran” yang tinggi, ia kadang juga mempertimbangkan beberapa pendekatan, tetapi kita juga bisa secara eksplisit menyuruh LLM melakukan brainstorming: https://photostructure.com/coding/claude-code-replan/
Jika penggunanya mahir, ini bisa menjadi sangat kuat
Iseng-iseng mencoba vibe coding untuk toolchain, bidang yang cukup saya kuasai. Mungkin ini bukan objek yang paling cocok untuk vibe coding, tetapi setidaknya saya bisa menilai kualitas keluarannya secara kasar
Ketika hanya diberi tugas “buat assembler untuk arsitektur di ISA.md”, Claude memilih Python sebagai bahasa implementasi, mengekstrak banyak token dengan regex, dan bahkan tidak punya parser ekspresi. Tapi assembler pertama saya juga begitu, jadi harus dinilai dengan adil
Namun ketika saya menuliskan pass dan tipe yang diinginkan seperti
collectDefines :: [SourceLine] -> Either AsmError ([SourceLine], Map Text Text),runLitPool :: [SourceLine] -> Either AsmError ([SourceLine], [(Text, LitKey)]),evalExpr :: Text -> Map Text Text -> Either AsmError Int, hasilnya nyaris langsung benar dalam sekali jalanSetelah sekitar 20 menit saya sudah cukup puas, dan semuanya berhasil meng-assemble seluruh program uji dengan benar. Kodenya biasa-biasa saja di banyak bagian, tetapi kalau saya implementasikan sendiri mungkin akan makan waktu berminggu-minggu
AI sangat kuat di area yang input dan output-nya deterministik, dan sepertinya bahkan ada persoalan teori komputasi di titik itu
AI benar-benar bisa mengerjakan pekerjaan untuk kita
Ini juga sangat cocok dengan post-training dan reward yang bisa diverifikasi
Alasan AI kurang bagus dalam “arsitektur” adalah karena kita sendiri juga tidak terlalu bagus dalam hal itu, sehingga data latihnya kabur dan abstraksi yang baik pun kurang
Pada akhirnya, kalau mengikuti konvensi yang kuat hasilnya cukup aman, tetapi begitu keluar dari jalur itu risikonya meningkat
Toolchain sangat deterministik, jadi AI bisa membongkar dan merakitnya kembali seperti LEGO, dan tiap tahap dalam ruang masalahnya juga deterministik, sehingga sangat pas untuk AI
LLM sedang mendorong kita kembali ke rekayasa perangkat lunak yang benar secara textbook, sesuatu yang sebenarnya kita selalu tahu perlu dilakukan tetapi sering gagal karena kurang waktu, tenaga, atau uang
Misalnya brainstorming dan riset sebelum menulis kode, menulis desain atau spesifikasi lebih dulu, serta membuat unit test yang komprehensif
Jika Anda membuat spesifikasi rinci dalam Markdown lalu menyerahkan coding-nya, hasilnya jauh lebih baik, dan sebagai bonus LLM juga cukup pandai membantu menulis spesifikasi itu
Saya terus mengatakan bahwa kita harus mendesain dan berpikir dulu baru memakai alat, tetapi orang-orang menjawab, “Claude juga bisa merencanakan”
Lalu mereka menerima hasil berantakan yang butuh banyak revisi
Sebaliknya, kalau saya meluangkan waktu untuk meninjau dan memberikan rencana detail, saya hampir selalu mendapat hasil yang saya inginkan dalam sekali jalan
Bahkan hanya dengan mengurangi waktu yang terbuang untuk mengurus CI saja sudah cukup bernilai
Sebenarnya tidak perlu serumit itu
Cukup minta, “selidiki dan analisis area ini secara menyeluruh lalu beri rencana implementasi”, lalu ketika keluar rencana 20 langkah, minta ia mengerjakan 3–5 langkah sekaligus
Untuk hampir semua pekerjaan yang bisa saya lemparkan, ini pada praktiknya bekerja seperti implementasi one-shot
Bahwa “kodenya biasa-biasa saja di banyak bagian” bukan hal aneh jika mengingat bahwa bahkan kode yang ditulis developer perusahaan besar pun sering kali hanya biasa-biasa saja
Symbian OS milik Nokia butuh berhari-hari untuk build. Bukan menit atau jam, tetapi “berhari-hari”
Ada developer yang merilis ke production dengan menyertakan library yang di mana-mana diberi peringatan “jangan dipakai di production, ada memory leak”
Kode manusia juga bisa sangat buruk, jadi saya tidak ingin hanya mendengar bahwa kode AI itu jelek. Kemalasan dan kebodohan manusia bisa mengalahkan halusinasi AI
Mungkin developer DeepMind atau OpenAI, atau orang seperti John Carmack, akan selalu mengungguli kode AI, tetapi pekerja yang direkrut kebanyakan perusahaan bukanlah John Carmack
Cukup ironis jika seseorang berkata “saya memakai Claude Code setiap hari”, lalu membiarkan Claude menulis esai 2.000 kata yang terstruktur rapi untuk memperingatkan bahaya membiarkan Claude mendesain
Ini terasa seperti kesadaran diri yang diwakilkan
Saya mulai menulis kritik karena ada banyak kontradiksi internal dalam tulisannya, lalu dari strukturnya saya sadar: pola seperti “The accountability gap”, “What to do instead”, “The craft still matters”
Ini seharusnya ada di paling atas, dan saya lebih khawatir HN gagal melihat hal yang begitu jelas dibanding kemunafikan terang-terangan para penulisnya
Pesan tulisannya pada dasarnya benar, tetapi saya tidak setuju dengan bagian bahwa “yang membuat arsitek sungguhan bernilai, yaitu kemampuan untuk berkata ‘tidak’, tidak ada di sini”
Dalam pengalaman saya, Claude cukup baik dalam menolak dan membantah
Jika prompt tidak memintanya, ia memang tidak selalu mengatakan “tidak” secara langsung terhadap permintaan, tetapi jika Anda menegaskan bahwa kritik adalah opsi tingkat satu, ia memberi kritik yang bagus dan dengan senang hati membantah
Ia terus mengatakan bahwa “burn rate” tidak membaik dan bahwa “kami” harus fokus ke tempat lain, lalu akhirnya berhenti membantu dengan mengatakan sesuatu seperti “saya sudah tiga kali bilang bahwa pendekatan ini bukan yang terbaik untuk menurunkan burn rate”
Jadi saya menjawab dengan tegas, “Saya tidak peduli dengan burn rate di grafik hipotetis yang pertama kali kamu buat; yang penting adalah menghilangkan bug dan menghasilkan produk yang tangguh, dan pendekatan ini melakukan itu dengan memuaskan. Jika pengujian tidak menunjukkan perbaikan, berarti pengujiannya yang dirancang salah”
Setelah itu ia minta maaf dan membuat memori baru, dan sesudahnya tidak ada masalah
Masalahnya adalah kami sedang menyerang permukaan bug yang sangat besar, jadi tiap perbaikan masuk akal, benar, dan membantu kemajuan, tetapi metrik pada testbed yang Claude buat untuk mengukur pekerjaannya sendiri tidak bergerak
Ada terlalu banyak bug yang saling terkait sehingga satu perbaikan tunggal sulit menghasilkan perbedaan berarti pada pengujian tingkat atas; saya tahu itu akan memakan waktu, tetapi sepertinya Claude tidak tahu
Coba saja ubah ukuran pointer dari 2 byte menjadi 3 byte pada compiler untuk 6502[1], lalu tambahkan bank switching pelacakan otomatis ke pointer manajemen memori, maka Anda akan melihat betapa banyak titik kode yang terdampak [tertawa]
[1]: https://atari-xt.com
Ia jadi lebih kuat jika diajak menyelidiki dan menentang. Misalnya saya meminta seperti, “Saya rasa kita perlu memodelkan perakitan prompt sebagai graf, lalu menambahkan version control pada konfigurasi graf. Tolong teliti praktik terbaik di bidang ini dan nilai apakah itu masuk akal untuk aplikasi ini”
Jika Anda bertanya dengan prompt yang menyisakan ruang untuk kritik, ia pasti mengkritik saat memang perlu
Hasilnya, kata “skeptical” muncul dalam proses berpikirnya, dan menurut pengalaman saya ia jadi kurang mengiyakan
Orang-orang perlu lebih memikirkan apa sistem ini sebenarnya dan bagaimana bentuk keluarannya bisa diatur
Saya cukup sering dibantah oleh ketiga model utama
Gemini yang paling agresif, jadi jika saya melewatkan detail yang “jelas”, ia sering mempermasalahkannya; GPT ada di tengah; Claude lebih ringan, tetapi tetap membantah
Bagian yang mengatakan “ia sama sekali tidak memikirkan masalahnya, hanya pattern matching terhadap data pelatihan lalu menghasilkan jawaban yang terdengar masuk akal” membuat saya agak kehilangan kepercayaan pada tulisan ini
Agen masa kini melakukan jauh lebih banyak daripada itu, dan penulis sendiri tahu hal tersebut karena belakangan ia mengatakan hal seperti “Claude tidak akan pernah melakukan ini. Ia dilatih untuk membantu”
Kalimat sebelumnya membuat penulis terlihat seperti sangat membenci agen, lalu mencari alasan untuk merasionalisasi perasaan itu
Sebagian kritiknya benar, tetapi jika masalahnya adalah “dilatih untuk membantu”, itu bisa diperbaiki, karena ia bisa dilatih agar lebih kritis
Pernyataan bahwa “Claude dirancang untuk median dari semua yang pernah dilihatnya, dan untuk praktik terbaik umum atas masalah umum perusahaan umum, jadi tidak dirancang untuk siapa pun” juga tidak masuk akal
Siapa pun yang memahami algoritme tahu bahwa Anda bisa mula-mula membuat “algoritme yang baik” yang kinerjanya bagus pada kasus rata-rata atau terburuk, lalu setelah itu merancang algoritme yang beradaptasi terhadap masukan. Prinsip yang sama berlaku di sini
Ia hanya melakukan lebih banyak iterasi
Menyatakan secara menyeluruh bahwa Claude salah soal semua hal penting hampir bisa dibilang sebuah kekeliruan
Itu jelas bukan pernyataan faktual, sehingga pembaca yang skeptis bisa mulai meragukan validitas keseluruhan tulisan
Dalam kasus saya, Opus sering memberi tahu bahwa saya salah dan sebaiknya tidak melakukan sesuatu
Jika dipikir-pikir, alasannya adalah cara saya membuat prompt. Saya dan LLM tampaknya tanpa sadar menghindari situasi gagal yang menurut penulis tidak terhindarkan
Secara spesifik, saya tidak memberi prompt yang berakhir rapi dengan “tolong beri tahu betapa pintarnya saya”
Saya mendekati masalah sebagai pakar domain, dan memang benar pakar domain, serta menegaskan bahwa saya siap menerima pendapat tentang kelebihan dan kekurangan dari beberapa jalur
Ini mungkin tidak mengejutkan bagi orang yang memakai LLM dengan sukses setiap hari, tetapi strategi ini sangat efektif
Saya bilang saya harus milling aluminium 5 mm dan punya dua bit: satu Makera Spiral 'O' 1/8" shank * 12mm, yang lain carbide 6.35 * 22 * 50
Saya bilang keduanya tampak seperti bit karbida single flute dan yang kedua sepertinya akan memotong 6061 lebih cepat, lalu Claude menjawab bahwa Makera 1/8" single flute 12mm adalah pilihan yang masuk akal
Ia mengatakan bit 6.35 × 22 × 50 mm mungkin terlihat seperti akan memproses 6061 lebih cepat, tetapi pada Carvera kemungkinan jauh lebih berisiko
Karena cutternya lebih besar, engagement-nya juga jauh lebih besar, sehingga lebih banyak menuntut dari spindle, kekakuan frame, penjepitan benda kerja, dan pembuangan serpihan; pada mesin kering kecil, “lebih besar” sering kali bukan berarti “lebih cepat” melainkan “lebih banyak getaran dan lebih banyak panas”
Singkatnya, Claude tampaknya tidak punya masalah berarti untuk mengatakan ketika saya salah
Sebagai tip untuk “penulis”: Claude, bahkan sebagai penulis, tetap hanyalah alat Anda