Catatan Coding Agent Juli 2026

Ini sekedar catatan dan tips saya saat ini untuk memakai coding agent. Perkembangan coding agent ini sangat cepat, jadi apa yang saya tulis sekarang mungkin tidak akan berlaku lagi di masa depan. Saya ingin menuliskan ini karena siapa tau berguna untuk orang lain, dan juga nanti bisa saya lihat lagi di masa depan seperti apa situasi coding agent di pertengahan 2026.

Sejak tulisan terakhir saya, saya merassa:

• Agent makin pintar mandiri
• Semakin penting untuk memahami harness/coding agent supaya hasilnya optimal

Memilih coding agent

Saat ini ada banyak sekali coding agent, dengan berbagai kelebihan dan kekurangannya. Saya sendiri senang berganti-ganti, tidak setia pada satu tool. Saat ini yang paling sering saya pakai:

• Claude Code: wajib kalau memakai subscription anthropic, bisa diakali supaya bisa dipakai bersama coding agent lain, tapi account berisiko kena ban
• Codex: sebenarnya tidak wajib untuk memakai subscription OpenAI, tapi fitur-fitur baru akan muncul lebih dulu, contoh: Usage Reset, langsung ada di Codex sebelum ada di coding agent lain
• Opencode: integrasinya dengan aneka provider sangat bagus, open source, jadi bisa dipercaya. Mudah mengekspor session saat ini menjadi markdown.
• Pi (pi.dev), sangat minimalis (tapi opsi pluginnya banyak). Bagi saya ini cocok untuk task sederhana (misalnya: pi "commit this repo")

Saya juga masih mencoba-coba yang lain, misalnya:

• Antigravity CLI (dari google), tapi ini limitnya terlalu kecil, dan model yang ada dari Google kurang cerdas
• Grok Build : resmi dari X.AI, sempat ada insiden di mana mereka mengupload seluruh repository kita (dengan semua secrets) ke cloud (sekarang sudah dimatikan fiturnya, dan sudah diopensourcekan)
• Maki.sh: sangat lightweight, lebih ringan dari Pi, tapi fiturnya juga lebih sedikit. Sangat terasa ketika dipakai di ponsel (coding agent lain butuh beberapa detik baru selesai startupnya)

Masih banyak yang lain yang saya install, lalu saya remove lagi karena saya tidak melihat kelebihannya

Memilih model

Sebagai background: saat ini saya banyak mengerjakan hal-hal yang berhubungan dengan security:

• Pentest (misalnya: pentest web, reverse engineering APK, dsb)
• Membuat presentasi security
• Programming kernel custom untuk Android (untuk keperluan pentest)

Saya juga memakai LLM untuk aneka hal pribadi, terutama aneka program kecil.

Saya memakai banyak model, dengan aneka alasan:

• Claude Fable: sangat bagus untuk pekerjaan kompleks. Sayangnya Fable tidak mau mengerjakan apapun yang berhubungan dengan security. Bahkan membantu mereview file presentasi perkenalan security untuk pemula juga tidak mau.
• Claude Opus: Claude Opus masih mau mengerjakan aneka hal security, tapi kadang bisa tiba-tiba menolak.
• GPT-5.6 (sol/terra): berguna untuk berbagai pekerjaan secara umum. Secara umum saat ini limit OpenAI lebih murah hati dari Anthropic
• GLM 5.2: model openn source yang sudah sangat dekat dengan Opus, dan tidak pernah menolak melakukan pekerjaan security. Masalahnya: kebanyakan provider cukup lambat, dan GLM ini juga cerewet, sering memikirkan hal yang sama berulang-ulang. Sebaiknya kita lebih eksak dalam memberikan prompt, karena biasanya meskipun akhirnya GLM bisa menebak maksud kita, tapi proses ini butuh waktu lama (membuang banyak token)
• Deepseek 4 Flash/Pro: model yang sangat murah dan cepat, cukup untuk melakukan banyak hal (biasanya saya memakai ini dengan Pi)
• Xiaomi Mimo 2.5-pro (karena kebetulan saya sudah punya token plan ketika dirilis): fungsinnya sama seperti DeepSeek: berguna untuk aneka pekerjaan sederhana. Di Thailand, saya merasa model ini sangat cepat.

Tools ekstra

Secara umum, saya tidak menginstall tool ekstra untuk coding agent. Banyak orang menyarankan aneka tools ekstra. Kategori tool yang sering dipakai orang:

• managemen memori, supaya agen ingat yang kita kerjakan dan disimpan permanen
• penghemat token: memfilter output perintah CLI agar tokennya lebih sedikit
• pengindeks kode: supaya agen bisa menemukan dan mengedit kode dengan cepat

Setelah mencoba-coba, kesimpulan pribadi saya (mungkin kesimpulan Anda berbeda):

• Masalah memori: saya tidak memakai ini. Tiap pekerjaan saya unik, saya tidak ingin memori mencemari aneka pekerjaan. Hal-hal spesifik sebuah project cukup masuk ke AGENTS.md, dan itu cukup
• Masalah penghemat token: saya tidak memakai ini. Tadinya memakai rtk, tapi gain yang diperoleh sangat kecil. Perlu diketahui bahwa RTK dan sejenisnya hanya menghemat token pada *output* tool (yang akan menjadi *input* LLM). Jika LLM memakai built in tool coding agent (Read/Write File), maka tool ini tidak berguna
• Masalah pengindeks kode: bagi saya ini lebih merepotkan, karena kita perlu mengindeks lagi kodenya setelah setiap perubahan. Belum lagi kalau kita ketemu bug di tool indexing-nya.

Tujuan akhir dari semua tool itu adalah: menghemat token. Saat ini di Claude kita bisa melihat pemakaian token kita sebenarnya karena apa, dan di opencode ada plugin third party “tokenscope” yang bisa memperlihatkan berapa banyak token yang sebenarnya kita pakai, dan untuk apa token tersebut.

SKILLS

Teorinya skill bisa berguna, tapi saya merasa bahwa dalam 90% kasus, lebih mudah membuat skrip plus file markdown di direktori proyek saat ini. Tidak perlu memanage direktori skill per agent, tidak perlu memanage skill dari third party, dan lebih transparan.

Saya mengkategorikan aneka skill yang dirilis menjadi dua hal:

• Skill yang real, misalnya bagaimana mengkonversi file tertentu, dengan command apa
• Skill yang mengawang-awang, ini seperti jaman prompt engineering dulu, di mana orang-orang berusaha membuat LLM lebih pintar dengan aneka teknik prompting (sebagus apapun kita memprompt GPT-3.5, hasilnya tetap akan jelek, apalagi dulu ukuran konteksnya cuma 4096 token)

Di github ada banyak skill yang makan puluhan ribu token, dan menurut saya itu useless. Kalau ada skill yang menarik, saya akan mencari prompt-nya apa, lalu mempelajari apakah prompt itu bisa saya pakai atau tidak di kasus saya.

Tools CLI

Saya sering memperhatikan bagaimana agent bekerja, di mana agentnnya stuck dan harus mencoba cara lain. Menurut saya ini cara terbaik menghemat token: dengan menginstall aneka tool yang sesuai pikiran agent.

Contoh: jika coding agent diminta memproses PDF, lalu tool yang pertama dipakai adalah qpdf, lalu gagal, maka agent akan mencoba lagi tool lain (dan jika gagal, tool lain lagi). Jika ini sering terjadi, maka ini akan membuang token. Solusinya:

• Dengan memberi tahu bahwa tool tidak ada (di system instructions)
• Dengan menginstall tool tersebut

Solusi saya adalah dengan menginstall tool-tool standard yang dipakai oleh agent, seperti: rg dan fd.

System instructions

Kebanyakan optimasi yang saya saya lakukan adalah pada system instruction: instruksi untuk LLM yang akan dikirimkan di awal interaksi. Tiap coding agent punya caranya sendiri menambahkan ini.

Intinya saya memberi tahu hal-hal di mana Agent harus berpikir lama. Contoh: dalam reverse engineering, saya lihat GLM 5.2 sering sekali berpikir lama untuk meng-assemble opcode tertentu, saya memberikan instruksi “to assemble arm64 code do this: rasm2 -a arm -b 64 ‘ret'”

Untuk hal-hal yang jarang sekali saya lakukan, saya biarkan saja agent mencari tahu cara terbaik. Kalau ada hal menarik yang dilakukan oleh agent, akan saya catat untuk project itu.

MCP

Menurut saya MCP sangat berguna untuk tool-tool yang tidak punya interface CLI.

Untuk tool dengan interface CLI, ini sering kurang berguna. Salah satu contoh yang saya lihat adalah MCP untuk radare2: sering error dan akhirnya agentnya langsung menjalankan CLI r2. Dalam kasus seperti ini saya menambahan instruksi sistem bahwa: r2 available untuk reverse engineering (dan saya beritahu juga bahwa r2ghidra tersedia untuk dekompilasi).

Untuk tool GUI seperti: Ghidra, IDA Pro, Burp, MCP sangat berguna. Sayangnya biasanya ada dua masalah, antara masalah 1 atau masalah 2:

1. Tidak semua fungsionalitas app biasanya bisa diakses dari MCP. Akhirnya user diminta melakukan sesuatu manual. Contoh sederhana: MCP Burp tidak bisa menambahkan comment di list history, jadi LLM tidak bisa menambahkan catatan langsung supaya bisa diverifikasi
2. Terlalu banyak fungsionalitas masuk MCP: ini akan memakan konteks terlalu banyak. Misalnya ada yang bangga dengan tagline “tool pentest dengan 200 MCP”, padahal LLM akan kesulitan memilih tool yanng bisa dipakai

Salah satu MCP yang bagus menurut saya adalah ida pro: ada fungsi dasar, tapi juga memberikan kemampuan untuk menjalankan skrip python apapun. Jadi jika ada fungsi yang tidak bisa diakses, LLM bisa menulis skrip yang akan dieksekusi sebagai script python oleh IDA Pro.

Sekarang ini saya memakai MCP seperlunya saja, per project. Pastikan juga MCP bisa dipakai, karena jika tidak bisa, flownya adalah:

• agent berusaha memanggil MCP
• MCP gagal
• agent berusaha memanggil lagi, atau memakai tool lain

Intinya: sering kali MCP gagal ini membuang-buang token, jadi pastika bisa diakses.

Penutup

Banyak hal yang saya tulis di sini hanya opini saya, dan silakan masing-masing memiliki pendapat sendiri sesuai workflow masing-masing. Ini sekedar catatann saya saat ini, dan di masa depan mungkin pendapat saya akan berubah.

Nasihat saya: jangan terlalu percaya apapun yang tertulis di internet tentang Agent dan LLM, tapi coba sendiri, lalu lakukan pengukuran sendiri, kalau perlu buat benchmark sendiri untuk hal-hal yang penting untuk pekerjaan kita. Contohnya: saya punya benchmark sendiri untuk reverse engineering, jadi saya bisa menilai apakah sebuah model bagus atau tidak untuk tujuan pemakaian saya.