Mengapa dorongan terhadap AI agentik begitu kuat? Padahal model bahkan nyaris tak bisa mengikuti satu instruksi sederhana dengan benar

• Di tengah kenyataan bahwa model AI untuk coding bahkan tidak dapat menjalankan satu instruksi pun secara andal, ekspektasi berlebihan terhadap coding agentik yang bekerja otonom di latar belakang sedang terbentuk
• Penulis mengalami masalah pada GPT-5 dan Gemini Pro yang sama-sama menghilangkan sebagian logika atau melewatkan pembaruan, meskipun sudah diberikan fungsi Golang sekitar 100 baris sebagai kode referensi
• Gagasan bahwa sistem agentik dapat menangani 50 file dan banyak fungsi secara otonom tidak realistis pada tingkat teknologi saat ini, dan justru berisiko menghabiskan lebih banyak waktu untuk debugging
• Respons komunitas terbelah antara pandangan bahwa pemanfaatan terbatas yang sukses masih mungkin dilakukan melalui prompting yang sistematis, dokumentasi, dan verifikasi bertahap, dan pandangan skeptis bahwa agentik masih belum praktis
• Saat ini LLM adalah sistem berbasis pengetahuan, bukan kecerdasan, sehingga pendekatan yang realistis adalah "pemanfaatan sebagai alat" di mana pengembang sendiri menyediakan konteks dan melakukan verifikasi langkah demi langkah

---

Masalah yang diajukan penulis asli

• Contoh kegagalan instruksi sederhana: Sebuah fungsi Golang 100 baris diberikan sebagai referensi dan model diminta memperbarui fungsi lain dengan struktur yang sama, tetapi GPT-5 dan Gemini Pro sama-sama menghilangkan sebagian logika atau melewatkan pembaruan
• Ketidakrealistisan coding agentik: Jika satu fungsi saja tidak bisa ditangani dengan benar, pendekatan agentik yang secara otonom memodifikasi banyak fungsi di 50 file dikhawatirkan akan menimbulkan lebih banyak masalah
• Pertanyaan soal pembaruan file 6000 baris: Penulis meminta pendapat komunitas tentang cara aman memodifikasi file berskala 6000 baris, seperti saat melakukan pembaruan versi Stripe

Contoh pemanfaatan positif dan metodologi

Pendekatan dokumentasi dan pengindeksan yang sistematis

• Memanfaatkan file referensi Markdown: Menyimpan referensi dalam file .md dan menginstruksikan AI untuk membacanya dapat meningkatkan konsistensi dan akurasi
  • Contoh prompt: "Rujuk file goLang_Update_reference.md yang terlampir untuk merangkum poin inti fungsi update, lalu berdasarkan itu buat draf pembaruan perangkat lunak"
• Membangun indeks lokal: Untuk file besar (6000+ baris), lakukan pemindaian per 1000 baris untuk membuat indeks yang mencakup nama fungsi dan referensi baris
  • Saat mengerjakan frontend, gunakan indeks terpisah khusus area tertentu seperti fr.index.md

Pengelolaan agen dan penataan pekerjaan

• Spesialisasi agen: Bentuk agen berdasarkan peran seperti perancang (architect), penjelajah kode (codeseeker), dan coder, lalu sediakan file aturan .md yang sesuai untuk masing-masing
• Pendekatan vertical slice: Pecah pekerjaan menjadi unit fitur kecil yang bisa diselesaikan di bawah 100 ribu token
  • Jika melebihi 100 ribu token, kemungkinan agen mengalami malfungsi meningkat tajam
• Memaksa dokumentasi pekerjaan: Wajibkan pembaruan docs/TASKS.md, docs/WORKLOG.md, dan docs/DECISIONS.md untuk menjaga kesinambungan pekerjaan

Memanfaatkan Plan Mode dan Ask Mode

• Plan Mode: Meninjau seluruh proyek dan menyusun rencana sesuai permintaan, lalu melanjutkan secara bertahap
• Ask Mode: Berguna untuk query codebase, eksplorasi ide, dan meninjau opsi; efektif sebagai pengganti Google/StackOverflow

Pendekatan mendahulukan unit test

• Pengembangan berbasis test: Tulis unit test terlebih dahulu sebelum membuat fungsi, lalu biarkan AI berulang kali menghasilkan kode yang lulus test
  • Peluang memperoleh kode yang benar secara fungsional meningkat besar, dan setelah itu biasanya hanya perlu optimasi serta perapihan

Pandangan skeptis dan kesadaran akan keterbatasan

Keterbatasan realistis agentik

• Bekerja tanpa pengawasan adalah tindakan bunuh diri: Pada tingkat teknologi saat ini, memberi tiket lalu membiarkannya bekerja otonom di latar belakang memiliki probabilitas gagal yang tinggi
• Kemungkinan berbohong: Model lebih mungkin menghasilkan halusinasi daripada keberhasilan, dan pada kasus terburuk bisa merusak kode yang sudah ada
• Redundansi Planning Mode: Meminta rencana detail dari model dasar sebenarnya sudah cukup, sehingga Planning Mode pada praktiknya tidak memberi kemampuan baru yang substansial

Batasan mendasar LLM

• Prediksi, bukan penalaran: Model bekerja dengan memprediksi kata berikutnya tanpa memverifikasi hasil, sehingga reliabilitas akan tetap tidak stabil sampai grounding, memory, dan feedback membaik
• Berbasis pengetahuan tanpa kecerdasan: LLM adalah basis pengetahuan yang sangat canggih tetapi tanpa kecerdasan; pengembang harus membawa sendiri kecerdasan (BYOI: Bring Your Own Intelligence) dan konteksnya
• Kekurangan memori: Model tidak memiliki memori sejati dan hanya bergantung pada context serta context cache, sehingga konteks akan ter-reset setiap kali memulai chat baru

Bias bahasa dan data

• Posisi Golang yang relatif kurang diuntungkan: Dibanding Python atau JavaScript, Golang memiliki lebih sedikit codebase publik sehingga model kekurangan pola dan konvensi yang telah dipelajari
  • Ini menjadi faktor struktural yang membuat hasil edit atau transformasi yang konsisten lebih sulit diperoleh

Panduan praktis untuk pemanfaatan yang berhasil

Prompting dan penyediaan konteks

• Instruksi yang jelas dan detail: Gunakan tata bahasa dan tanda baca secara tepat, serta berikan instruksi eksplisit alih-alih ungkapan yang ambigu
• Rujukan eksplisit ke semua file terkait: Jika tidak menyebutkan semua file yang harus digunakan agen, kemungkinan munculnya spaghetti code akan meningkat
• Menetapkan file aturan: Atur file aturan untuk seluruh workspace dan aturan khusus proyek agar mendorong pembuatan kode yang konsisten
• Memanfaatkan @Docs: Gunakan fitur referensi dokumen untuk memberi agen pengetahuan inti yang dibutuhkan (meski pada beberapa versi kerjanya tidak stabil)

Cakupan kerja dan verifikasi

• Pecah menjadi unit kecil: Bagi pekerjaan menjadi unit sekecil mungkin yang bisa ditangani sekaligus, lalu verifikasi setiap langkah sebelum lanjut ke tahap berikutnya
• Tinjau secara real-time: Tinjau semua kode yang dihasilkan secara real-time dan segera minta perbaikan agar spaghetti code tidak terbentuk
• Backup dan version control: Buat backup di setiap tahap dan gunakan sistem version control seperti GitHub
• Menjalankan test: Jalankan test yang terdampak secara inkremental dengan pytest --testmon -q, lalu jalankan seluruh test sebelum selesai

Modularisasi dan struktur kode

• Memecah file 6000 baris: Satu file 6000 baris tidak modular dan merugikan dari sisi penyediaan konteks, sehingga lebih efektif dipecah menjadi 12 file masing-masing sekitar 500 baris
• Mengutamakan vertical slice: Kembangkan berdasarkan unit fitur kecil yang bisa berjalan end-to-end

Pemilihan model dan pengelolaan biaya

• Mempertimbangkan Claude Sonnet 4.5 lebih dulu: Dibanding GPT atau Gemini, model ini dinilai lebih konsisten dan akurat sehingga layak terhadap biaya tambahannya
• Waspadai konsumsi token: Perencanaan skala besar menghabiskan banyak token, jadi membaginya menjadi langkah-langkah kecil saat eksekusi lebih efisien dari sisi biaya

Kasus penggunaan khusus

Pembuatan skrip sekali pakai

• Skrip analisis: Jika harus menulis ratusan skrip analisis data sekali pakai setiap hari, akurasi 50% pun tetap memungkinkan pembuatan dan eksekusi 1000 kali lebih cepat dibanding menulis manual
• Kemampuan memverifikasi hasil: Karena hasilnya bisa diverifikasi langsung, akurasi yang rendah pun masih praktis

Membangun aplikasi dari nol

• Struktur multi-agen: Saat membangun aplikasi besar dari nol, agen pengawas dapat meninjau pekerjaan agen lain untuk menjaga konsistensi
  • Efektif untuk menjaga konsistensi nama import, nama variabel, dan mencegah duplikasi kode
• Efisiensi terhadap biaya: Tetap membutuhkan banyak revisi kompleks dan refactoring, sehingga pendekatan bertahap lebih murah dalam jangka panjang

Ringkasan pendapat komunitas

Pengalaman positif (produktivitas meningkat 3–5x)

• Situs web Next.js: Membangun situs web yang sepenuhnya berfungsi dan siap deploy dari nol dalam hitungan menit
• Implementasi fitur kompleks: Menambahkan fitur threads ke aplikasi chat dalam 3–4 menit (pekerjaan yang diperkirakan memakan 3 hari)
• Dengan pendekatan sistematis: Jika dikombinasikan dengan aturan yang jelas, konteks yang memadai, dan verifikasi bertahap, peluang sukses yang konsisten tetap ada

Pengalaman negatif (saat ini belum praktis)

• Memproduksi spaghetti code: Saat diberi tujuan yang luas, sering muncul masalah seperti pembaruan dokumen yang terlewat atau file sisa yang tidak dihapus
• Kesalahan semantik: Secara teknis memang berjalan, tetapi lokasi kode tidak tepat atau fungsi yang sudah ada justru diimplementasikan ulang, sehingga menimbulkan masalah struktural
• Gagal ditelusuri lebih dari 5 menit: Jejak eksekusi panjang yang berjalan lebih dari 5 menit umumnya hanya menghasilkan keluaran yang tidak berguna

[GN⁺]

Opini Hacker News

• Dari pengalaman pribadi, saya merasa sebagian besar LLM cukup mengikuti instruksi saya. Memang perlu prompt yang dipoles dengan baik dan perencanaan sebelumnya, tetapi begitu paham tiga hal itu, agent coding seperti ini sudah sangat bisa diandalkan. Sesekali, mungkin 1 dari 10 kali hasilnya salah, tetapi dalam kasus seperti itu pun kita bisa cepat menghentikan dan mengarahkan ulang agar kembali ke jalur semula. Agak mengejutkan melihat banyak orang di HN begitu skeptis terhadap efektivitasnya. Tentu ada banyak kekhawatiran seperti biaya dan perubahan pekerjaan, tetapi tetap mengejutkan bahwa keraguan terhadap kegunaan agent coding begitu sering muncul
  • Akan bagus kalau ada video atau contoh nyata yang menunjukkan sistem agent atau LLM benar-benar menciptakan nilai yang melampaui pencarian Google atau Stack Overflow
  • Jika kita menjelaskan kondisi saat ini, hasil yang diinginkan, dan cara melangkah dengan cukup rinci, kita bisa menyusun rencana bersama agent, menyempurnakannya, lalu mengeksekusinya. Dengan cara ini, tingkat teknologi mutakhir saat ini cukup mengesankan. Tidak realistis berharap hal yang rumit selesai hanya dengan satu kalimat. Ini mirip ketika memberi tugas teknis kepada intern cerdas yang belum punya pengalaman kerja nyata: tetap butuh waktu dan usaha. Bedanya, agent AI bekerja jauh lebih cepat daripada intern manusia
  • “Sebagian besar berhasil” pada dasarnya berarti tidak ada metrik keandalan yang nyata (jumlah angka 9)
  • Barusan saat jalan-jalan dengan anjing, saya memakai Codex(gpt-5-high) untuk mengonversi aplikasi Python ke Go dalam sekali jalan. Setelah dites, hasilnya berfungsi dengan baik. Saya puas karena sekarang bisa didistribusikan sebagai satu binary tanpa virtual environment. Saya juga tidak yakin apakah perintahnya sebenarnya sangat mudah
  • Standar “sebagian besar berhasil” tidak cukup bagi saya. Masalah yang lebih serius daripada tidak mengikuti instruksi adalah ketika model tidak mau mengakui bahwa ia salah dan malah terus ngotot. Kalau saya meminta sesuatu yang tingkat kerumitannya menengah atau meminta analisis error, cukup sering ia terpaku pada kesimpulan yang salah. Bahkan sampai saya sendiri menyebutkan letak masalahnya, sering kali ia tetap tidak menemukan jalan keluar. Untuk kode sederhana atau pekerjaan boilerplate, ini benar-benar bagus, dan dengan sedikit umpan balik saya bahkan bisa membuat library baru. Tetapi karena sering salah, saya tidak ingin menyerahkan hal yang lebih kompleks. Meski begitu, saat buntu saya tetap memakainya untuk brainstorming; walau salah, setidaknya membantu menjaga motivasi
• Ketika perbedaan pengalaman antar developer terhadap LLM begitu besar, yang sebenarnya perlu kita tanyakan adalah, “kenapa pengalaman ini bisa sangat berbeda?” Penjelasan paling sederhana adalah “kamu tidak memakainya dengan benar”, tetapi sebagai developer sistem AI, saya juga heran melihat begitu banyak pengguna yang cuma menulis “tolong perbaiki ini” atau “buatkan laporan” lalu berharap hasil bagus tanpa instruksi yang kompleks. Ada juga hype berlebihan dari eksekutif soal “AI bisa melakukan apa saja”, dan ini berkaitan dengan valuasi perusahaan serta harga saham. Publik umum pun tampaknya menganggap AI sebagai “kecerdasan buatan sungguhan”. Sebenarnya, klaim bahwa LLM bahkan tidak bisa mengikuti instruksi sederhana kurang meyakinkan; yang penting adalah bahwa untuk pekerjaan kompleks, mereka masih belum benar-benar mampu
  • Teori saya yang lain adalah, setiap orang punya spec di kepalanya, lalu menuliskannya secara acak dan berharap LLM mengimplementasikannya, padahal hasil akhirnya hampir selalu melenceng dari spec itu. Ada developer yang secara retrospektif menyesuaikan spec di kepalanya atau menerima sedikit perbedaan, sementara ada juga yang kecewa karena LLM tidak cocok dengan rencana mental mereka. Semacam “ingatan palsu” secara psikologis: ada orang yang lebih fleksibel dan kompromistis, dan ada yang keras kepala. Saya sendiri mengalami dua-duanya secara bergantian
  • Sekarang saya ingin melihat lebih banyak screencast, tulisan panjang, apa pun, yang memperlihatkan seluruh proses ketika seseorang benar-benar membuat fitur yang nontrivial. Para influencer AI hampir selalu hanya menunjukkan pembuatan tool AI dengan AI, atau demo CRUD dan hello world. Bahkan developer veteran pun bilang lebih dari separuh codebase-nya dibuat AI, tetapi kemudian mengakui bahwa sebagian besar dibuang dan hanya sedikit yang dijadikan referensi. Cerita “single prompt → aplikasi selesai” cepat berubah menjadi “berguna saat butuh motivasi dari layar kosong”. Saya ingin para developer sungguhan lebih transparan soal bagaimana mereka benar-benar memakainya di pekerjaan nyata
  • Sebenarnya kategori “developer” itu terlalu luas sehingga tidak banyak artinya dalam diskusi ini. Untuk mayoritas potongan kode bergaya CRUD yang mirip-mirip, LLM bekerja lumayan baik
  • Semua orang bekerja pada codebase yang berbeda-beda. Detail penting ini hampir tidak pernah dibahas. Semakin sering dipakai, ekspektasi makin tinggi dan batasannya makin cepat terasa. Kalau hanya sesekali dipakai, memang terasa mengesankan, tetapi kalau dipakai sepanjang hari, pada akhirnya kekecewaan menumpuk. Banyak hal yang terasa “seharusnya ini bisa dikerjakan” ternyata tetap perlu dibenahi ulang
  • Saya yakin bukan hasilnya yang berbeda, melainkan ekspektasi masing-masing orang. SVP IT di perusahaan saya adalah pendukung berat AI. Baru-baru ini saya mengerjakan proyek legacy PHP yang dulu ia buat, dan saya sadar bahwa standar kualitas kode yang membuatnya puas ternyata sangat rendah. Saya sendiri memakai LLM setiap hari, tetapi selalu mengedit hasilnya. Artinya, semakin rendah standar kualitas kode, semakin puas orang terhadap hasil LLM
• Di forum Cursor, yang terus diulang cuma “kamu yang salah pakai”, padahal yang benar-benar ingin saya tahu adalah soal keandalan, proses, dan penerapan nyata di pekerjaan sehari-hari. Bahkan di sini pun kesannya kita hampir tidak pernah melihat penggunaan dalam skala besar. Kami juga kebanyakan memakai AI seperti “rekan kerja yang bodoh”, dan memanfaatkannya lebih eksperimental pada side project yang minim batasan. Kesan saya, agent itu kebanyakan hanya hype (atau sangat niche)
  • Alasan hasil OP buruk adalah karena memakai Cursor. Cursor memangkas konteks percakapan dengan brutal demi menghemat biaya. Tidak seperti penyedia model, mereka harus membayar penggunaan LLM dengan harga retail, jadi posisi harga mereka tidak kompetitif. Cursor juga tidak transparan soal seberapa banyak konteks yang dipotong, dan dari pengalaman saya mereka memangkasnya sangat agresif, sampai saya harus berkali-kali memasukkan file yang sama hanya agar model paham situasinya. Saran saya: jangan lagi menginvestasikan waktu ke Cursor. Kode yang dihasilkan Cursor cuma menambah utang teknis. Setelah pindah ke Codex dan Claude, saya jauh lebih puas
  • Saya penasaran perbaikan spesifik seperti apa yang diinginkan. Postingan aslinya tidak punya contoh konkret, prompt, atau metodologi, hanya “saya jago bikin prompt”, dan kalau begitu sulit menilai ataupun memberi saran. Saya juga paham kalau orang skeptis terhadap workflow agentic, tetapi dengan cara itu orang lain juga tidak benar-benar diberi kesempatan untuk membantah. Saya sendiri sudah beberapa bulan bekerja bersama agent, dan sampai sekarang masih belajar apa yang berhasil dan apa yang gagal. Dari pengalaman saya:
    • orkestrasi dengan framework seperti agent-os itu wajib
    • penting menjaga keseimbangan antara arahan dan otonomi
    • terutama pada kode legacy, perencanaan awal itu sangat penting
    • contoh kasus saya: di sistem legacy, context window terus terlampaui, lalu setiap kali konteks diringkas, informasi penting ikut hilang sehingga kesalahan yang sama berulang
    • metode yang efektif: strukturkan masalah dengan jelas, catat satu per satu hal yang ditemukan/dipelajari, dan pecah menjadi sub-agent yang sangat spesifik (agar context window bisa dikelola). Baru setelah itu agent benar-benar membantu untuk menjelajahi kode legacy
  • Saya pernah mengalami agent menemukan beberapa bug produksi yang tidak bisa saya temukan (bug asing yang tidak sempat saya curahkan waktu cukup banyak). Tentu jauh lebih banyak bug yang gagal ditemukan, tetapi dibandingkan satu jam waktu engineer software, biayanya nyaris gratis, jadi kalau sesekali berhasil itu sudah cukup layak sebagai strategi
  • Tulisan yang berisi contoh nyata dan spesifik akan jauh lebih bermakna, dan akan memancing jawaban yang lebih baik. Informasi yang menunjukkan masalah konkret di pekerjaan nyata dan bagaimana LLM gagal akan lebih berguna
  • Nilai bisnis nyatanya jauh lebih kecil daripada yang dibayangkan orang, dan itu membuat frustrasi. Memang untuk boilerplate atau area yang sudah familier, kadang hasilnya bisa lebih berguna daripada manusia. Tetapi masalah lain di luar itu—ketergantungan pada big tech, pencemaran data, informasi yang tak bisa diverifikasi, penurunan kreativitas, runtuhnya orisinalitas, kebodohan para fanatik AI, konsumsi energi, pencurian karya manusia, dan sebagainya—terlalu besar. Sulit percaya bahwa semua ini memberi keuntungan bersih bagi umat manusia
• Di tahun 2025, pemasaran benar-benar dilakukan dengan baik di semua forum seperti Reddit dan LinkedIn, dengan cara brand meresap ke dalam percakapan. Para CEO, “pemikir” AI, dan VC mempromosikan LLM seolah-olah sihir dan membungkus v0, Lovable, dan lain-lain sebagai inovasi generasi berikutnya. Jawaban para pemimpin juga terdengar hampir sama semua (video terkait). Tetapi pada praktiknya, seberapa pun banyaknya kita membuat hal seperti CLAUDE.md atau cursorrules, hampir tidak ada efeknya. Pada akhirnya LLM harus mengikuti instruksi, tetapi kenyataannya terasa acak. Bahkan aturan yang sangat sederhana pun hampir tidak dipatuhi, sehingga saya jadi merasa orang-orang yang menulis di forum Cursor itu tampaknya semua amatir. Dan, untuk pekerjaan coding yang benar-benar baru, LLM memang sangat buruk. Ia berasumsi memakai library yang bahkan tidak ada dan menghasilkan teks yang nyaris tak berguna. Saya sendiri benar-benar memakainya lebih seperti speech-to-text, karena LLM lebih baik dalam menangkap edge case, best practice yang saya tidak tahu, atau sintaks yang saya lewatkan
  • [1] Hasil dari pencarian, Perplexity, dan semacamnya kebanyakan hanya gumpalan materi pemasaran yang disebar tim marketing
  • Saya sepenuhnya setuju bahwa untuk pekerjaan coding baru, LLM benar-benar mengerikan. Model SOTA saat ini cukup mampu membuat boilerplate atau struktur sederhana pada framework yang sangat terkenal dan punya pola konsisten (MVC dan sebagainya). Hal yang benar-benar menonjol justru tugas menyisir banyak informasi untuk menemukan sesuatu tertentu (codebase, log, stack trace, dan sebagainya). Tetapi pemasaran bahwa “agent membangun seluruh codebase” menurut saya, setidaknya saat ini, bukan kenyataan
  • Pengalaman saya justru sepenuhnya kebalikan. Selama seminggu terakhir, Claude Code hampir secara mandiri memperbaiki masalah compiler yang saya tangani. Selain beberapa momen yang membuat frustrasi, ia secara konsisten berhasil memperbaiki bug parser dan pembuatan kode yang subtil, dan bagian yang masih perlu campur tangan saya lebih dekat ke keterbatasan alat seperti pengelolaan compaction. Ia bahkan mengimplementasikan metode yang biasanya harus dicari di buku, dan ketika saya jalankan memang terbukti bekerja. Mungkin memang tidak banyak yang benar-benar baru dan “inovatif”, tetapi faktanya hampir semua kode memang tidak benar-benar baru. Dalam pengalaman saya, kalau diberi panduan yang terstruktur dengan baik, model biasanya mengikuti dengan sangat baik. Bukan sekadar menulis sembarang hal di CLAUDE.md. Kuncinya adalah panduan proses yang teliti. Cara kerja saya terbagi menjadi 1) panduan debugging per proyek, 2) kriteria penerimaan yang jelas, 3) sering menjalankan tes dan menyuruhnya mencatat perubahan kecil per unit ke file. Dengan cara ini saya bisa menjalankan Claude selama berjam-jam hampir tanpa pengawasan (paling hanya memberi perintah “continue” di tengah atau memakai /compact). Memang tidak selalu menghasilkan kode sempurna, tetapi saya juga begitu. Tetap saja, secara umum hasilnya positif dan usaha saya jauh berkurang. Saya masih tidak merekomendasikan bootstrap dari kondisi yang belum dirancang dengan matang, tetapi kadang itu pun berhasil (meski tetap perlu review awal). Akhir-akhir ini saya bahkan mempertimbangkan membiarkan Claude bekerja tanpa henti selama berhari-hari untuk menyelesaikan masalah secara otomatis
  • Sangat menarik bahwa pengalaman tiap orang dengan LLM bisa berbeda sejauh ini. Dalam kasus saya, dengan codex-cli produktivitas terasa naik 5 kali lipat. Ia mampu mengubah sumber dengan struktur yang sangat tidak biasa dan jejak eksekusi SVG internal menjadi format grafik JSON kustom, atau mengekstrak dokumentasi secara akurat dari codebase Python/C++ kompleks (bahkan sampai kernel RISCV level rendah). Saya benar-benar penasaran apa penyebab hasil yang begitu berbeda, padahal alatnya sama
  • Saat coding dengan Claude, rasanya seperti menarik tuas mesin slot. Kadang hasil yang diinginkan keluar tepat, tetapi jauh lebih sering tidak atau meleset total. Sangat berbahaya jika dibiarkan berjalan tanpa pengawasan sama sekali
  • Menurut saya juga, nilai LLM yang paling konsisten adalah dalam menangkap kesalahan kecil, contoh terbaik, atau sintaks kode yang sering terlewat manusia. Jadi sebagai reviewer PR, dengan sedikit skeptisisme, cukup layak dipakai
• Perusahaan kami menerapkan gaya XP klasik. Saat mengembangkan fitur baru pada aplikasi brownfield, kami memecahnya menjadi hampir 8 sub-agent seperti “red-test-writer”, “minimal-green-implementer”, “refactorer”, dan lain-lain. Sekarang kami cukup mengetik ke Claude Code, “buatkan fitur X dengan proses TDD ini”, lalu dalam 30 menit hasilnya selesai sebagai kode yang jauh lebih baik, cakupan tes 90%, dan langsung dalam kondisi bisa diterima. Memang ini ditopang oleh pengalaman bertahun-tahun dengan XP, pair programming, dan TDD, tetapi selama lebih dari setahun, 95% kode produksi kami ditulis AI (termasuk fitur kompleks yang nontrivial). Tanpa rahasia khusus pun, ini berjalan baik. Bagi kami, efeknya benar-benar luar biasa
• Perbedaan pendapat di sini sangat besar. Tanpa menjelaskan masing-masing gagal di apa dan dipakai untuk tugas seperti apa, diskusi yang layak tidak mungkin terjadi. Kalau kita tidak membahas kategori konkret di mana LLM gagal/berhasil, semuanya tidak lebih dari kebisingan
  • Dalam diskusi, seharusnya dicantumkan secara rinci bahasa/framework, domain masalah, level SRE, LLM (model/versi), agentic harness (claude code, codex, copilot, dll.), kasus gagal/berhasil, sampai tingkat kemahiran memakai LLM. Selain itu, kondisinya juga bisa berbeda: apakah engineer sudah 10 tahun hanya di satu codebase, atau bolak-balik di banyak proyek; apakah ini pengembangan baru (Greenfield) atau maintenance; riset inovatif atau CRUD; dan sebagainya
• Dari sudut pandang ilmuwan, sering kali kami harus mengulang boilerplate yang sedikit berbeda untuk tiap dataset, dan agent coding sangat membantu menyelesaikan banyak dari itu. Yang mengejutkan, bahkan setelah saya menegaskan lima kali dengan huruf kapital “JANGAN SEKALI-KALI MENGADA-ADA DATA, JANGAN PAKAI np.random”, Claude kadang tetap mengabaikannya. Itu benar-benar absurd. Saat berhasil, rasanya fantastis, tetapi saat gagal, bahkan tidak ada sinyal kegagalan. Dari sudut pandang pemasaran LLM, saya bahkan membayangkan ada agent seperti ‘PIPA(Performance Improvement Plan Agent)’ yang mengawasi agent coding di belakang layar dan memantau secara real time apakah ia benar-benar bekerja. PIPA akan memeriksa performa agent coding, lalu HR atau manajemen mengelola pegawai AI (agent), dan mungkin masa depan akan datang seperti itu
  • Kalau seseorang berkata, “Jangan pikirkan gajah yang memakai tutu merah muda!”, bukankah itu justru langsung terbayang? Sebagai ilmuwan, mestinya Anda tahu bahwa secara sifat LLM memang tidak pandai memahami kalimat negatif. LLM dilatih berbasis token, jadi ketika Anda menulis “NO ELEPHANTS”, kata “gajah” tetap ada di konteks. Akibatnya model malah terdorong ke kata itu. Instruksi positif lebih menguntungkan
  • Membayangkan PIPA saja sudah menakutkan
• Kuncinya adalah prompt yang membantu model menemukan konteks yang tepat sendiri (misalnya pesan error yang baik), dan jika pekerjaan dipecah menjadi sangat kecil dan konsisten, maka hasil tes berulang/bertahap bisa diteruskan sebagai konteks ke tugas berikutnya. Sekitar 50% masalah cocok untuk cara ini, dan 50% lainnya masih cukup cocok sejauh loop LLM lebih ringan daripada otomasi tradisional, tetapi dari bagian itu pun separuhnya tidak cukup bernilai untuk dikejar dibanding investasinya. Pada akhirnya, jika ada “12,5%” kasus ajaib, pendekatan agent yang sangat dibatasi (constrained) adalah yang paling optimal
  • Jika proses itu disiarkan langsung di YouTube atau tempat lain (bukan tutorial, melainkan live coding yang alami), itu akan jadi cara yang bagus untuk berbagi insight
• Hampir 30 tahun lalu, saat saya mulai masuk ke AI, saya mendengar nasihat ini. Kalau mendengar istilah “intelligent agent”, bayangkan saja “semut yang bisa dilatih”
  • Saya ingin tahu lebih lanjut
• Bagi saya, masalah terbesar adalah performa tool AI sangat naik-turun tergantung tugas, dan sulit memprediksi di mana ia akan gagal sehingga waktu habis terbuang. Saya berharap seiring pengalaman memakai tool bertambah, kemampuan menulis prompt akan membaik, tetapi tetap terasa membuat frustrasi. Meski begitu, memang ada area tumpang tindih antara kegunaan agent dan AI (misalnya pembuatan boilerplate otomatis untuk proyek baru). Dalam kasus seperti itu, ‘agent mode’ memang lebih nyaman. Pengalaman praktik saya sendiri masih belum banyak
  • Semakin sering ia bekerja dengan baik, ekspektasi makin naik dan area pemakaian pun makin luas, tetapi ketika kemudian menabrak batasannya, rasa kecewanya justru lebih besar daripada di awal