Efisiensi yang Secara Tidak Rasional dari Loop Agen LLM dan Penggunaan Alat

• Melalui pengalaman pengembangan Sketch, asisten pemrograman AI, ditekankan implementasi ringkas dari struktur loop yang menggabungkan LLM dan penggunaan alat
• Hanya dengan kode loop 9 baris, LLM modern seperti model Claude 3.7 Sonnet dapat menyelesaikan masalah nyata dengan cepat
• Bahkan hanya dengan satu alat serbaguna seperti bash, banyak tugas pengembang yang berulang dan merepotkan dapat diotomatisasi secara signifikan
• Bukan hanya pemecahan masalah, dengan menghubungkan alat tambahan, kualitas dan kecepatan iterasi untuk penyuntingan teks atau pekerjaan yang terspesialisasi juga dapat ditingkatkan
• Semakin banyak loop agen LLM kustom yang diperkenalkan untuk otomatisasi aktivitas harian pengembang

---

Pendahuluan: Pengalaman Pengembangan dan Proyek Sketch

• Philip Zeligger dan rekan-rekannya, dalam proses mengembangkan Sketch, alat bantu pemrograman berbasis AI, merasa terkejut dengan tingginya efisiensi dari struktur loop agen sederhana yang menggabungkan LLM dan pemanfaatan alat
• Struktur intinya hanyalah kode loop 9 baris yang mengirim system prompt, riwayat percakapan, dan pesan terbaru ke API LLM
• LLM menghasilkan output dan, bila perlu, mengembalikan tool_calls (permintaan pemanggilan alat)

Integrasi LLM dan Penggunaan Alat

• "Penggunaan alat (tool use)" berarti LLM mengembalikan output yang sesuai dengan skema yang telah ditentukan sebelumnya, dan melalui system prompt serta prompt deskripsi alat, LLM dapat mengakses alat serbaguna seperti bash
• LLM modern (misalnya Claude 3.7 Sonnet) dapat dengan cepat mengotomatisasi berbagai masalah hanya dengan satu alat serbaguna, dan beberapa bahkan dapat diselesaikan dalam satu kali eksekusi ("one shot")
• Sebelumnya, pengguna harus mencari, menyalin, dan menempelkan perintah git yang rumit lalu melakukan merge secara manual, tetapi kini cukup meminta Sketch untuk menyelesaikannya secara langsung
• Banyak error pemeriksaan tipe yang muncul setelah perubahan tipe juga untuk pertama kalinya dapat ditangani secara otomatis oleh Sketch
• Loop agen bekerja secara berkelanjutan dan adaptif, sehingga saat alat belum terpasang, ia dapat memasangnya secara otomatis dan juga menyesuaikan diri dengan perbedaan opsi perintah
• Saat digunakan, kadang LLM memberi saran tak terduga seperti "lewati tes" ketika pengujian gagal, tetapi secara keseluruhan kualitas otomatisasi kerja tetap meningkat

Diversifikasi dan Spesialisasi Alat

• Sketch mendapati bahwa dengan memanfaatkan alat tambahan selain bash (misalnya alat penyuntingan teks), kualitas pekerjaan dapat ditingkatkan dan alur kerja pengembangan menjadi lebih efisien
• Mengubah teks secara akurat dengan sed dan sejenisnya ternyata lebih sulit dari perkiraan bagi LLM, dan alat bergaya editor visual terasa lebih unggul

Prospek Masa Depan dan Perubahan Alur Kerja

• Struktur loop agen diperkirakan akan semakin banyak digunakan untuk tugas-tugas berulang dalam keseharian pengembang yang sebelumnya sulit ditangani oleh alat otomasi serbaguna konvensional
• Sebagai contoh, tugas yang merepotkan dan berulang seperti menganalisis korelasi antara stack trace dan commit git juga dapat diproses cepat oleh LLM sebagai penanganan tahap pertama
• Ke depan, dapat diharapkan lebih banyak loop agen LLM kustom dan sekali pakai akan digunakan di lingkungan pengembang, seperti dalam direktori bin/
• Pengguna hanya perlu menyiapkan bearer token yang diinginkan untuk dapat bereksperimen dengan mudah di lingkungan mereka sendiri

Tautan Referensi

• Konten ini juga dipublikasikan di blog philz.dev
• Informasi tambahan tentang proyek dan hal terkait dapat dilihat di sketch.dev, merde.ai, pi.dev

[GN⁺]

Opini Hacker News

• Sangat ingin merekomendasikan tulisan blog ini juga. Ini versi yang membahas poin yang sama dengan jauh lebih rinci dan meyakinkan. Penulisnya benar-benar mencoba membuat coding agent sendiri dari nol. Lihat https://ampcode.com/how-to-build-an-agent. Rasanya benar-benar mengejutkan melihat betapa baiknya LLM menangani beragam tugas di dalam loop yang bisa memanggil tool. Tentu tidak sempurna, dan ada masalah seperti belum bisa mencapai reliabilitas 100%. Meski begitu, menurut saya setidaknya ada sesuatu yang layak dikagumi. Kalau mencobanya sendiri, ini bisa diikuti dalam 30 menit. Ini bagian yang bisa terasa menakjubkan sambil tetap mempertahankan skeptisisme yang sehat soal apakah AI efektif untuk kegunaan tertentu. "Efek yang tidak masuk akal" dari menaruh LLM di dalam loop inilah alasan mengapa sekarang begitu banyak code generation agent bermunculan: Claude Code, Windsurf, Cursor, Cline, Copilot, Aider, Codex, dan seterusnya, ditambah banyak sekali proyek tiruannya. Itu juga alasan tidak ada resep rahasia khusus; 95% keajaibannya pada akhirnya berasal dari LLM itu sendiri dan fine-tuning agar bisa melakukan pemanggilan tool. Hal ini juga diakui secara jujur oleh pengembang utama Claude Code dalam wawancara terbaru. Tentu saja, butuh banyak usaha agar tool seperti ini benar-benar bekerja baik, tetapi secara mendasar inti strukturnya hampir sama dan sederhana
  • Sudah lama sekali saya mencari tulisan seperti ini, jadi rasanya benar-benar berterima kasih. Banyak orang melihat Agents lalu bereaksi, "mungkin ini tidak akan benar-benar bisa menyelesaikan masalah yang kompleks, kan?" Tapi menurut saya inti argumen soal agent bukan di situ. LLM bekerja sangat baik ketika memiliki banyak konteks, dan agent adalah struktur yang membuat LLM bisa mencari lebih banyak konteks untuk meningkatkan kualitas jawaban atas pertanyaan
  • Dari pengalaman saya, sulit memikirkan banyak tugas yang bisa ditangani LLM sendirian dalam loop lebih dari beberapa kali tanpa instruksi tambahan. Setelah beberapa iterasi, pasti muncul situasi di mana saya harus turun tangan
  • Ada tutorial yang membuat sesuatu yang mirip menggunakan library abstraksi graf bernama pocketflow. Saya benar-benar sudah mencobanya, dan sangat puas karena cukup simpel. https://github.com/The-Pocket/PocketFlow-Tutorial-Cursor/blob/main/blog.md
  • Baru sadar sekarang bahwa penulisnya Thorsten Ball. Saya ingat sangat menikmati baca tulisannya tentang "membuat interpreter". Sepertinya saya juga akan coba membuat agent sekarang
  • Sebelum membuka tautan di atas, saya sempat berpikir apakah perlu menambahkan ?utm_source=hn&utm_medium=browser
• Hari ini untuk pertama kalinya saya mencoba langsung "vibe-coding" dengan GPT-4o dan 4.1. Caranya dengan memutar loop secara manual lewat antarmuka canvas, memasukkan error kompilasi, peringatan, dan saran. Filenya kecil, sekitar 150 baris. Saya mulai dengan 4o, dan dia memakai paket usang. Bahkan setelah saya tunjukkan masalah itu, dia tidak memperbarui semua penggunaannya dan saya harus membetulkannya sendiri. Ketika saya mengusulkan perubahan logika, sintaksnya malah hancur total dan tidak pernah pulih lagi. Walau saya terus memasukkan error kompilasi, dia tidak memahami masalah sintaks dan malah memperbaiki bagian kode secara acak. Jadi saya berharap 4.1 akan lebih baik, tetapi 4.1 justru menolak menggunakan canvas dan hanya memberi penjelasan. Gayanya seperti menyuruh saya memperbaikinya sendiri. Setelah terus saya bujuk, dia akhirnya mengeluarkan kode ke canvas, tetapi kali ini versinya terpotong di tengah dengan hal seperti "// omitted for brevity" sehingga tidak bisa dipakai. Di sini saya menyerah. Saya penasaran apakah agent-agent bisa menyelesaikan masalah ini. Untuk saat ini, saya merasa pengalaman ini benar-benar rusak, dan memberi akses bash dalam kondisi seperti itu terasa terlalu berbahaya
  • Soal "memakai paket usang", itu terjadi karena titik potong data pelatihan model. Itu memang hal yang harus selalu diperhatikan saat memakai LLM. Saya sering beralih ke o4-mini-high di ChatGPT. Model ini juga bisa mencari dokumentasi terbaru lewat fitur search. Kalau diminta "cek versi terbaru library X lalu pakai itu", sering kali ia bisa menanganinya dengan baik. Baru-baru ini saya punya tugas mengonversi sebagian kode JavaScript ke library terbaru yang direkomendasikan Google; saya cukup menempelkan kode lama dan memintanya melakukan porting ke library baru, dan ia mencari dokumentasinya lalu mem-porting dengan tepat. https://simonwillison.net/2025/Apr/21/ai-assisted-search/#lazily-porting-code-to-a-new-library-version-via-search
  • GPT 4.1 dan 4o mendapat skor yang sangat rendah di benchmark coding Aider. Dari pengalaman penggunaan nyata, hasil biasanya baru terasa berguna jika angkanya di atas 70%. Bahkan begitu pun, hal-hal kompleks masih membutuhkan banyak bantuan. Setelah cukup sering memakainya, Anda jadi punya insting soal apa yang bekerja dan apa yang tidak. https://aider.chat/docs/leaderboards/
  • Mungkin tidak enak mendengar kata "skill issue", tetapi memakai LLM memang jelas merupakan bidang yang membutuhkan keterampilan tersendiri. Memahami kelebihan dan kekurangan berbagai tool, mencoba beragam teknik, dan berlatih adalah komponen yang wajib. Kalau saya memberi akses bash, saya juga hanya akan memakainya di lingkungan container (docker)
  • Itu tidak bisa dibilang vibe coding. Agar vibe coding mungkin dilakukan, Anda harus memakai tool yang menerapkan perubahan kode secara otomatis. Kalau harus memberi umpan balik satu per satu secara manual, Anda akan tersendat oleh error. Inti vibe coding adalah bisa membatalkan, menjalankan ulang, dan melempar lalu membuang berbagai solusi dengan mudah. Untuk mendapatkan pengalaman itu, Anda butuh tooling
  • Belum lama ini saya membuat prototipe aplikasi Android dari "nol" di VSCode menggunakan plugin Cline dan Claude. Saya mulai dari template dasar yang diberikan Android Studio, lalu menghasilkan ribuan baris kode tanpa satu pun error kompilasi. Aplikasinya bekerja sesuai harapan, dan beberapa bug yang ditemukan juga bukan salah LLM melainkan perilaku API Android yang aneh. Saya menunjukkan bug itu ke LLM dan memberinya output pesan debug, lalu dia memperbaikinya sendiri. Awalnya perbaikannya agak kikuk, tetapi setelah beberapa kali umpan balik bolak-balik, hasilnya baik-baik saja. Sepertinya kalau code writing agent dan code review agent dipasang dalam loop, bagian seperti ini juga bisa ditangani lebih andal secara umum
• Saya sudah memakai Claude Code, yaitu antarmuka terminal untuk Sonnet 3.7, sejak hari peluncurannya. Saya sudah menggunakannya untuk menulis aplikasi CLI yang cukup besar, sistem web full-stack, dan banyak utility. Saya jadi terdorong mengambil tantangan yang lebih ambisius, mirip saat dulu memimpin tim pemrograman. Secara struktur mungkin tidak jauh berbeda dari tool lain, tetapi rasanya Anthropic menambahkan banyak fitur yang sangat berguna. Tidak ada yang sempurna, dan kualitas kode yang baik tetap membutuhkan upaya yang kurang lebih sama seperti dulu. Hal-hal yang cukup kompleks juga memang bisa berjalan, tetapi sering terjadi situasi di mana penambahan fitur berikutnya jadi sulit. Setelah makin terbiasa menggunakannya, proses refactor dan penyempurnaan jadi jauh berkurang. Struktur seperti itu tidak akan benar-benar hilang sepenuhnya. Jujur saya sulit membayangkan masalah yang dialami kgeist. Claude kadang juga bertindak bodoh atau memilih hal yang berbeda dari pilihan saya, tetapi tidak pernah sampai membuat saya ingin menyerah. Hampir selalu hasilnya cukup baik, dan kemampuannya mengurangi beban mental saya untuk banyak tugas benar-benar besar. Selain itu, dia sangat hebat dalam refactoring. Kalau saya meninjau kode secara berkala dan meminta Claude menjelaskan cara yang lebih baik, kompleksitasnya turun drastis. Permintaan seperti "ubah struktur data" juga langsung dibereskan. Fitur yang sangat keren. Dan hanya untuk iseng, saya pernah membuka direktori arsip berusia 30 tahun yang berisi segala macam hal, bukan kode. Saya bertanya, "apa yang ada di direktori ini?", "baca resume lama saya dan tulis ulang", "siapa nama anak-anak saya?", dan seterusnya, dan hasilnya benar-benar menakjubkan. Meski masih tahap awal, saya benar-benar senang
  • Baru-baru ini saya berada dalam situasi di mana saya harus sekaligus menangani definisi struktur data remote, spesifikasi API, implementasi parsing dan penyimpanan, hingga menampilkannya ke pengguna. Claude mengelola semua pekerjaan ini dengan baik secara bersamaan, sehingga saya bisa langsung melihat bagaimana perubahan kecil di kedua ujung memengaruhi lapisan tengah. Dengan cepat saya mengiterasi berbagai ide untuk menemukan solusi terbaik. Saya terkesan karena bisa menjelajahi banyak lapisan dengan kompleksitas tinggi pada kecepatan iterasi yang cepat seperti ini, dan itu meningkatkan produktivitas sekaligus pemahaman struktural saya terhadap keseluruhan sistem
  • Refactoring yang disebut di atas benar-benar pekerjaan yang menyenangkan. Fitur-fitur yang dulu sulit dimasukkan ke sprint kini selesai dalam 5 menit. Rasanya seperti ada tim siap pakai yang setiap saat hanya menunggu permintaan saya. Kalau hasilnya tidak saya suka, saya bisa langsung menolaknya, dan semua kekhawatiran soal review yang tidak perlu maupun penjadwalan seolah hilang
• Saya sangat frustrasi ketika LLM kadang berkata, "ah, tes ini tidak jalan... ya sudah kita lewati saja". Saya punya ide yang patut dipikirkan. Jalankan LLM penegak kebijakan yang independen dan paralel agar LLM utama tetap bertindak sesuai instruksi. Misalnya, LLM pendamping dapat memanipulasi probabilitas output agar setelah "let's just" tidak bisa muncul kata "skip". Artinya, dengan melarang "skip", kita bisa memaksa LLM menjauhi perilaku yang tidak diinginkan dan menempuh jalur lain. Ini semacam JSON mode atau structured output, tetapi secara dinamis dan real-time kebijakannya dikendalikan oleh LLM pendamping. Kalau ini berhasil, bisa dikembangkan lebih jauh dengan memasukkan berbagai pelanggaran kebijakan ke prompt LLM pendamping—misalnya menghapus kode tes demi meloloskan tes, atau mengeluarkan komentar yang tak berguna—lalu LLM pendamping memantau dan mengendalikan semuanya secara real-time. Saya penasaran apa pendapat tim Outlines tentang struktur seperti ini
  • Kalau satu LLM bisa memeriksa output LLM lain, saya jadi bertanya-tanya apakah LLM "mixture of experts" bisa menugaskan salah satu algoritma spesialis untuk berperan sebagai pengawas atau auditor. Atau memisahkan thread pemikiran agar ia memverifikasi outputnya sendiri, lalu bila perlu menambahkan thread lain untuk memverifikasi sang verifier, sehingga sistemnya bisa dibuat lebih kokoh
  • Dalam konteks ini, kalau LLM utama mulai menuju arah yang salah, saya juga membayangkan LLM pengawas bisa "memundurkan" model ke titik itu; misalnya ketika mendeteksi "let's just skip the test", ia me-roll back ke setelah "just " lalu terus memberi bias agar kata-kata tertentu tidak bisa dipakai. Untuk melakukan hal seperti ini, pilihan penyedia model yang bisa dipakai mungkin terbatas, dan khusus OpenAI belakangan terlihat cenderung tidak ramah terhadap fitur power-user seperti ini
• Pagi ini dengan cursor saya mengekstrak sebagian kompleks dari main loop prototipe game saya, lalu secara otomatis menghasilkan sekumpulan kode tes untuk bagian tersebut. Total ada 341 tes yang mencakup seluruh core math dan komponen inti. Kadang rasanya seperti menggiring kucing, tetapi semakin banyak batasan yang saya berikan—fungsi spesifik yang harus dipakai, lokasi, file template, hal-hal yang harus dihindari—hasilnya makin baik. Total 3500 baris kode tes yang tidak perlu saya tulis sendiri, dan kalau ada masalah saya bisa menghapus lalu membuat ulang kapan saja. Saya juga dibantu untuk hal-hal seperti menyetel kurva kesulitan, variasi misi, dan banyak aspek lainnya
  • Dari pengalaman saya, pembuatan tes otomatis adalah use case terbaik LLM. Ia menghapus pekerjaan membosankan dan repetitif yang biasanya memakan waktu berjam-jam atau berhari-hari sekaligus. Banyak edge case yang tidak terpikir oleh saya juga ikut tercakup secara otomatis, dan keamanan kode pun meningkat. Benar-benar fitur yang luar biasa dari banyak sisi
• Belakangan ini saya sangat bersemangat dengan kemampuan penggunaan tool pada LLM. Sebenarnya trik ini bukan hal baru; saya pertama kali melihatnya dua tahun lalu lewat paper ReAcT. Setelah itu dipakai di plugin ChatGPT, MCP, dan seterusnya, dan sekarang kebanyakan model dilatih dengan asumsi tool call/function calling. Yang menarik saat ini adalah seberapa besar performanya meningkat. Kemampuan pencarian o3/o4-mini yang luar biasa juga bertumpu pada kemampuan tool call. Qwen3 4B (Ollama 2.6GB, berjalan baik juga di Mac) juga menjalankan fitur ini dengan baik. Kemarin di PyCon US saya mengadakan workshop tentang membangun software berbasis LLM, dan dari situ saya menambahkan fitur penggunaan tool ke tool command-line LLM saya. Lihat https://building-with-llms-pycon-2025.readthedocs.io/en/latest/tools.html. Sekarang dengan paket LLM saya, hal seperti "menghitung berapa kali huruf R muncul dalam strawberry" bisa ditangani secara andal dengan shell one-liner
  • Saya sangat suka kombinasi aneh antara rasa menyenangkan dan kekuatan yang diberikan fitur ini
  • Saya penasaran apakah workshop-nya direkam
• Saya penasaran agent mana yang paling boros token. Sepertinya cline ada di peringkat atas, dan roo tampaknya memakai lebih sedikit token daripada cline. Saya juga ingin tahu apakah ada agent yang memungkinkan kita mengatur sendiri gaya interaksinya, dan bagaimana Claude code dibandingkan agent-agent lain
• Bagian yang menakutkan adalah "kalau tool yang dibutuhkan tidak ada, ia akan menginstalnya". LLM terlalu 'patuh', dan begitu ada yang menyuruh, ia langsung mengeksekusi. Ini kekhawatiran keamanan yang lebih serius daripada SQL injection
  • Saya kadang bertanya-tanya kapan bencana berbasis agent pertama akan benar-benar terjadi. (Terutama dengan suasana pasar AI yang serba terburu-buru seperti sekarang.) Saya khawatir seiring waktu pasti akan terjadi bencana yang sulit dipulihkan
• Sepertinya judulnya terinspirasi dari makalah Eugene Wigner, "The Unreasonable Effectiveness of Mathematics in the Natural Sciences"
  • Mungkin makalah itu sumber aslinya, tetapi saya rasa ini sudah lama menjadi ungkapan meme. https://scholar.google.com/scholar?q=unreasonable+effectiveness
  • Saya justru mengira judulnya diambil dari "Unreasonable Effectiveness of RNNs" karya Karpathy tahun 2015. Tentu bisa juga diasumsikan bahwa Karpathy sendiri meminjamnya lagi dari makalah Wigner. https://karpathy.github.io/2015/05/21/rnn-effectiveness/
  • Setiap kali melihat judul dengan frasa "unreasonable effectiveness", saya hampir selalu merasa tidak terlalu setuju dengan kesimpulan penulisnya. Termasuk makalah Wigner. Sekarang rasanya seperti semacam hukum Betteridge
• Kami membangun tool untuk memberi lebih banyak konteks ke chatbot AI tersemat di produk kami. Kami menambahkan berbagai fitur seperti log aktivitas terbaru, definisi objek saat ini, pencarian, dan penelusuran artikel bantuan. Beberapa bulan kemudian pun kualitas chatbot-nya masih tetap mengejutkan. Jika chatbot memberi jawaban yang kurang tepat, proses kami adalah memperbarui artikel bantuan terkait agar lebih spesifik