Rekomendasi untuk Agentic Coding

• Berbagi contoh penggunaan nyata untuk agentic coding
• Terutama menggunakan model Claude Code Sonnet, dan lebih menyukai pendekatan mendelegasikan seluruh pekerjaan ke AI daripada integrasi IDE
• Bahasa Go sangat direkomendasikan khususnya untuk proyek backend baru berkat struktur yang ramah agen dan stabilitas ekosistemnya
• Kecepatan dan kesederhanaan adalah inti dari agentic coding, dan cache pengujian serta sistem alat yang sederhana sangat penting
• Kode harus disusun agar sederhana dan dapat diparalelkan, dan untuk memaksimalkan performa agen, pemilihan waktu refactoring sangatlah penting

---

Preface

• Jumlah pengembang yang membagikan pengalaman terbaru mereka dengan agentic coding meningkat pesat
• Saat ini saya menggunakan model Claude Code Sonnet dengan paket Max ($100/bulan)
• Peran IDE berkurang, saya kembali memakai Vim, dan alurnya adalah menyerahkan pekerjaan ke Claude lalu hanya memeriksa hasilnya
• Karena laju inovasi sangat cepat dan isi tulisan ini bisa cepat usang, fokusnya adalah pada konsep yang akan bertahan lama

The Basics

• Perintah claude --dangerously-skip-permissions diatur sebagai alias claude-yolo untuk menghapus semua batasan izin
  • Ini dapat dikelola dengan aman dengan mengisolasi lingkungan dev melalui Docker
• Karena Claude menangani sebagian besar alat dasar dengan baik, MCP (Multi Capability Protocol) hanya digunakan dalam kasus khusus
  • Contoh: otomatisasi browser melalui playwright-mcp
• Alat buatan sendiri disusun sebagai skrip biasa dan sebisa mungkin mempertahankan susunan alat yang sederhana

Choice Of Language

• Setelah bereksperimen dengan agentic coding di berbagai bahasa, Go adalah pilihan paling ideal untuk proyek backend baru
  • Sistem Context: menyediakan struktur data yang mengalir dengan jelas di seluruh kode, sehingga cara penerusan eksplisit menjadi mudah bagi agen
  • Cache pengujian: dibanding bahasa lain seperti Rust, eksekusi dan cache pengujian lebih sederhana, sehingga loop kode-pengujian agen lebih efisien
  • Kesederhanaan: kesederhanaan Go sendiri juga menguntungkan bagi agen
  • Interface struktural: jika suatu tipe hanya cocok pada level metode, ia dikenali sebagai interface sehingga mudah ditangani oleh LLM
  • Tingkat perubahan ekosistem yang rendah: versi yang bertahan lama dan perubahan yang eksplisit membantu mengurangi pembuatan kode usang secara otomatis
• Python menimbulkan banyak masalah
  • Fixture, penanganan async, eksekusi yang lambat, dan hal lain menurunkan efisiensi dalam agentic loop
• Untuk frontend digunakan Tailwind + React + Tanstack Query/Router + Vite
  • Simbol $ dalam nama file Tanstack Router membingungkan agen dan menyebabkan masalah

Tools, Tools, Tools

• Kriteria alat adalah sebagai berikut
  • Cepat
  • Memberikan pesan error yang ramah
  • Tetap berjalan stabil meskipun digunakan secara keliru oleh LLM
  • Dapat diamati dan mudah di-debug
• Menyediakan perintah seperti make dev, make tail-log, dll. berbasis Makefile
  • Untuk mencegah duplikasi status proses, mengelola pid dengan versi fork shoreman
  • Log dicatat baik ke stdout maupun file sehingga agen bisa mengekstrak informasi langsung dari log
• Contoh: tautan verifikasi email juga dicatat ke log sehingga prosedur verifikasi email dapat dijalankan lewat otomatisasi browser

It's All About Speed

• Ketidakefisienan terbesar dalam agentic coding adalah biaya inferensi dan penggunaan alat yang tidak efisien
• Kecepatan respons alat adalah inti produktivitas
• Jika agen membuat dan memakai alat sementara sendiri, kecepatan eksekusi/kompilasi yang tinggi sangat meningkatkan efisiensi kerja
• Di lingkungan yang lambat, lebih menguntungkan memakai alternatif seperti dynamic module loading (misalnya pemantauan modul file untuk Sentry dan eksekusi otomatis)
• Log harus diatur agar ringkas dan jelas untuk mengoptimalkan konsumsi token dan kecepatan, dan bila perlu akan membantu jika ada antarmuka yang memungkinkan LLM menyesuaikan level log
• Penting untuk merancang sejak tahap pembuatan kode agar menghasilkan log/observabilitas yang bermakna

Stability and Copy/Paste

• Stabilitas ekosistem sangat penting untuk kemampuan pakai ulang kode dan mencegah kebingungan pada agen
  • Disarankan menggunakan bahasa/framework yang perubahannya kecil dan dapat diprediksi seperti Go dan Flask
• Waspadai upgrade pustaka otomatis, karena komentar atau alur kode yang ditinggalkan agen bisa rusak
• Sebisa mungkin disarankan strategi menulis kode sendiri → meminimalkan dependensi

Write Simple Code

• Agen lebih mampu menangani kode yang sederhana dan eksplisit
• Pedoman yang disarankan
  • Lebih menyukai penggunaan fungsi dengan nama fungsi yang deskriptif dan panjang, serta menulis berbasis fungsi daripada kelas
  • Hindari pewarisan dan trik yang rumit
  • Disarankan memakai SQL murni; agen cukup mahir dalam SQL, dan ini memudahkan perbandingan serta pelacakan lewat log
  • Pemeriksaan izin yang jelas harus disusun agar tampak intuitif di dalam kode (jangan dipisahkan ke file/konfigurasi terpisah)

Make It Parallelizable

• Kecepatan pemrosesan agen individual tidaklah tinggi, tetapi efisiensi keseluruhan dapat ditingkatkan lewat pemrosesan paralel
  • Contoh: menyalin checkout berdasarkan sistem file
  • Perlu memikirkan cara memisahkan sumber daya bersama seperti Redis atau DB
  • Contoh alat: pemisahan sesi berbasis Docker menggunakan container-use
• Pekerjaan paralel berbasis CI dan background agent milik Cursor juga merupakan alat yang patut diperhatikan

Learn To Refactor

• Dalam pendekatan agentic, refactoring pada waktu yang tepat itu penting
  • Saat kompleksitas meningkat, agen tidak bisa lagi menangani kode dengan baik
  • Contoh: sebelum class Tailwind tersebar di 50 file, ubah menjadi pustaka komponen
• Refactoring yang terlalu dini maupun terlalu terlambat sama-sama tidak efisien, jadi perbaikan struktur perlu diarahkan pada timing yang tepat

What Next?

• Agentic coding berkembang sangat cepat, dan prinsip intinya adalah ‘kesederhanaan, stabilitas, visibilitas, dan paralelisme’
  • Sekalipun alat dan metodologinya berubah, prinsip ini tetap berlaku
• Tujuannya bukan hanya meningkatkan produktivitas, tetapi juga mengejar kualitas kode yang lebih baik
• Kualitas kode yang ditulis agen meningkat jauh dibanding beberapa bulan lalu
• Hadapi perubahan secara fleksibel dan perluas pengalaman coding

[helloppfm]

Saya juga sejauh ini baru memakai AI untuk menanyakan hal-hal seperti kode pengujian sederhana atau contoh, tetapi sekarang terus bermunculan orang-orang yang mencoba menerapkannya secara menyeluruh.

Mungkin masih terlalu dini, tetapi beberapa tahun lagi ini akan menjadi hal yang wajar.

[GN⁺]

Komentar Hacker News

• Saya sedang merasakan agentic coding dengan memakai Copilot dan Claude Sonnet 4 bersama di VS Code Nightlys. Meskipun setengah hari saya habis untuk rapat, dari git history saya orang tidak akan menyadarinya karena peningkatan produktivitasnya terasa sebesar itu. Sekarang saya sudah sampai di tahap bukan lagi fokus pada implementasi detail, melainkan memikirkan apakah perubahan benar-benar bekerja, apakah saya bisa memahami kode ini, bagaimana sebaiknya strukturnya agar lebih mudah dipahami, dan apa lagi yang bisa ditambahkan ke markdown konvensi AI untuk mengurangi salah paham dari Agent. Tadi malam saya menyerahkan sebuah file yang punya 38 error mypy kepada Agent, lalu saya pergi ngobrol dengan keluarga selama 15 menit, dan ketika kembali Agent merangkum apa yang diperbaiki beserta alasannya. Saya sempat berdebat soal salah satu perubahan, tetapi akhirnya saya menilai pendapat Agent yang benar. Pemeriksaan mypy juga lolos. Sekarang saya juga sedang berusaha membuat tim memahami potensi nyata dari teknologi ini, tetapi ada juga orang-orang yang menentang karena skeptis dan karena AI tidak sempurna. Namun meminjam kata-kata seorang teman, "hari ini adalah hari terburuk yang akan kamu alami bersama teknologi ini mulai sekarang", dan saya rasa justru itu bukti adanya inovasi

  • Error type checker pada dasarnya adalah bagian yang seharusnya memakan waktu paling sedikit dalam pekerjaan development, jadi saya penasaran kenapa bagian itu sampai menyita waktu selama itu. Saya rasa kalau semua diskusi soal pemakaian AI bisa memperlihatkan dengan jelas masing-masing dipakai untuk tugas apa saja dalam praktiknya (seperti postingan cloudflare), dampaknya akan jauh lebih besar

  • Secara pribadi saya lebih percaya Agent untuk kode Rust daripada Python. Analisis statis Python tidak sebagus clippy atau rust-analyzer, jadi semua jalur kode harus saya jalankan sendiri setiap kali

  • Anda bilang walau setengah hari habis untuk rapat itu tidak terlihat dari git history, tapi kalau saya adalah karyawan di perusahaan Anda, saya akan ingat bahwa hasil sebesar ini sebentar lagi akan terus diharapkan dari Anda

  • Saya penasaran dengan workflow-nya. Saya sudah mencoba Claude Code untuk eksperimen proyek pribadi, dan dengan akun kantor saya juga mencoba Copilot di mode agent VS Code sambil mencampur 3.5, 3.7 Sonnet, sampai 04-mini. Saya memakainya pada proyek Go besar, tetapi selain urusan test, hasilnya sangat buruk. Saya sempat berpikir mungkin saya salah memakai alatnya, jadi saya mencoba semua "best practice terbaru": gonta-ganti konteks, gonta-ganti model, menetapkan aturan, sampai memperbaiki prompt, tetapi tetap tidak ada peningkatan

  • Anda bilang mungkin masih bisa menambahkan hal-hal ke markdown konvensi AI untuk mengurangi kesalahan Agent; saya penasaran apakah itu file yang dilampirkan sebagai konteks pada setiap pekerjaan, atau konvensi resmi dari VS Code Copilot Agent. Saya juga ingin tahu apakah ada referensi yang dipakai untuk menyusun struktur dokumennya, atau itu hasil yang Anda perbaiki sendiri seiring waktu berdasarkan kesalahan yang berulang dari AI

• Sangat menggembirakan bahwa sebagian besar teknik yang membuat agentic coding efisien juga meningkatkan efisiensi manusia saat ngoding. Dulu ada kekhawatiran soal kode "gumpalan lumpur raksasa" yang hanya bisa dipahami AI, tetapi kenyataannya justru sebaliknya. Kode yang jelas kini jauh lebih penting bagi produktivitas AI juga, dan akibatnya perbedaan produktivitas bisa terlihat jelas dalam angka. Kita bahkan bisa menunjukkan secara kuantitatif seberapa baik Claude bekerja pada tiap codebase, sehingga perdebatan soal apakah kode sudah terstruktur dengan baik tidak lagi sekadar beda pendapat, melainkan bisa dibicarakan dengan dasar yang objektif

  • Kekhawatiran bahwa kode akan menjadi "gumpalan lumpur" sebenarnya sudah menjadi kegelisahan sepanjang sejarah pemrograman (lihat ceramah Rich Hickey). Orang memilih "yang penting sekarang gampang" lalu besok menanggung technical debt yang sangat besar. Berkat LLM, memproduksi boilerplate yang tampak berarti padahal tidak juga menjadi semakin mudah. Kalau rasa sakitnya berkurang, orang mungkin bahkan kehilangan dorongan untuk memperbaikinya

  • Saya juga ingin meninggalkan catatan bahwa "kekhawatiran bahwa nanti kodenya hanya bisa dipahami AI, kalau bukan sekarang, entah bagaimana di masa depan" tetap perlu disampaikan

  • Bagian ini benar-benar saya rasakan. Error message yang bagus, tool yang cepat, ekosistem yang stabil, kode yang sederhana dan tanpa "sihir", sampai SQL yang intuitif, itulah lingkungan development yang dulu saya impikan. Agent bekerja begitu cepat sampai-sampai setiap jeda kecil terasa, jadi saya rasa teknologi seperti ini bisa mengangkat level keseluruhan pengalaman development

• Saya mendengar bahwa kalau memakai Agent, orang secara alami akan terdorong ke Go dan Tailwind. Karena data latihannya melimpah, AI memang bisa menanganinya dengan baik. Maka saya juga khawatir, di masa depan ketika semua orang memakai alat ini, apakah akan muncul efek bahwa bahasa, framework, atau library baru menjadi lebih sulit untuk lahir. Akan lebih sulit bersaing melawan solusi lama, dan komunitas manusia seperti StackOverflow juga bisa saja menghilang

  • Saya tidak setuju dengan kekhawatiran bahwa bahasa atau framework baru tidak akan pernah muncul lagi. LLM sangat kuat dalam penerjemahan, jadi bahkan tanpa data latihan, framework yang unik tetapi strukturnya jelas bisa langsung dipelajari dari codebase. Saya sendiri pernah melihat LLM menangani framework C# saya yang sangat idiosinkratik (yang belum pernah dilihat siapa pun) dengan sangat baik. Tentu karakteristik unik seperti lifetime di Rust mungkin tidak langsung cocok, tetapi hal sederhana seperti Go cepat diadaptasi. Ke depan, mungkin saat membuat bahasa baru kita memang perlu sejak awal mempertimbangkan kompatibilitas LLM (desain, tooling, dokumentasi, dan sebagainya)

  • Ini pertanyaan yang sangat penting. Dengan kata lain, ketika internet dipenuhi data buatan LLM dan data latihan berkualitas menurun, developer yang ramah LLM bisa jadi lebih tertarik pada teknologi lama yang "kurang radioaktif" seperti JS/React. Di masa depan, JavaScript/React mungkin menjadi COBOL masa depan tetapi tanpa perlu konsultan mahal, karena maintenance semuanya bisa ditangani LLM. Kalau ingin menghindari tren AI, membuat bahasa baru, terutama bahasa aneh seperti Lisp+DSL yang tidak bisa langsung dipelajari LLM, mungkin cukup aman setidaknya sampai era AGI tiba

  • Siklus tradisional software stack biasanya seperti ini. (1) Stack lama menjadi rumit karena mencoba merangkul semua niche, lalu para ahli membanjiri dengan "architecture astronautics" yang tidak perlu. (2) Karena itu muncul stack baru yang jauh lebih sederhana dan jelas untuk menyelesaikan tren baru, lalu menjadi populer. (3) Seiring waktu stack baru itu pun akhirnya menjadi berat karena masalah yang sama, lalu siklus buruk berulang lagi. Menurut saya AI coding juga tidak akan mudah mematahkan siklus ini karena perluasan konteks berkembang sangat cepat

  • Klaim bahwa Go dan Tailwind dipaksakan sebenarnya banyak mencerminkan preferensi pribadi penulis. Hanya karena Sonnet bermasalah di CLI cargo test, bukan berarti Rust, cargo, atau lebih jauh lagi AI secara keseluruhan yang bermasalah. Dalam pengujian PHP nyata juga, Junie memang tidak terlalu bagus memakai runner bawaan, tetapi setelah dibuatkan skrip bin/test-php, ia bisa memakainya dengan baik. Memang membantu jika requirement ditulis eksplisit dalam guideline, tetapi lebih tepat dilihat sebagai perbedaan sifat: ia cenderung keras kepala memakai tool bawaan. Soal pengalaman Stack Overflow juga, AI assistant saya punya kelebihan tidak akan menutup pertanyaan sebagai duplikat. Upaya kurasi SO memang bagus, tetapi juga benar bahwa hal itu membuat banyak pengguna pergi

  • Kemarin saya juga meminta Claude (memakai Zed) membuat proyek baru elixir phoenix hanya dengan memberikan syarat-syaratnya, dan semuanya berjalan baik tanpa masalah. Untuk CSS memang dipakai tailwind, tetapi sepertinya itu karena phoenix memang memberi setup default seperti itu. Jadi saya tidak setuju dengan klaim bahwa AI mendorong orang ke Go. Justru kalau bertanya tanpa konteks, usulan ke Python jauh lebih banyak, dan bahkan elixir yang komunitasnya lebih kecil pun bisa dipakai dengan baik dalam pengalaman saya

• Saya sudah bereksperimen sekitar seminggu dengan Rust code memakai Claude Code Sonnet 4.0, tetapi hasilnya di bawah ekspektasi (apalagi lewat Bedrock jadi mahal). Ia menghabiskan banyak waktu membuat rencana awal, tetapi kenyataannya sering hanya menyelesaikan setengahnya. Saya penasaran apakah saya melewatkan sesuatu

  • Saya juga hampir merasakan hal yang sama. Di mode Cursor Edit/Agent, perubahan yang saya inginkan hampir selalu keluar dalam sekali jalan sehingga sangat efisien, tetapi di lingkungan CLI terasa sangat tidak nyaman. Saya penasaran apakah Anda memakai Claude Code dengan menyerahkan pekerjaan 10–15 menit lalu hanya mereview diff, atau Anda tetap benar-benar melakukan code review juga

  • Saya juga mengalami hal yang sama persis. Bahkan ketika saya sengaja mencari use case yang mungkin cocok, tetap saja tidak bekerja dengan baik, jadi saya benar-benar heran

  • Seharusnya itu tidak terasa mahal. Paket Pro harganya 20 dolar per bulan, dan Max 100–200 dolar, jadi strukturnya lebih murah dibanding memakai API sampai lebih dari seribu dolar per bulan

• Saya cukup senang melihat penggunaan container disebutkan. Saya ikut terlibat di dagger/container-use, dan di tim kami juga ada mantan anggota Docker serta pendiri docker. Saya rasa menjalankan Agent secara paralel akan menjadi titik percabangan kemajuan teknologi yang besar (kalau nanti bisa dimanfaatkan secara andal). Bahkan sebelum sampai ke sana, kalau selama Agent bekerja Anda ingin mengerjakan hal lain atau khawatir Agent akan menyentuh bagian yang aneh-aneh, sangat berguna untuk mengontainerisasi lingkungan development Anda. Teknologi penggunaan container ini juga masih di tahap awal, tetapi berkembang sangat cepat, dan saat ini fokusnya adalah meningkatkan stabilitas, mengurangi konflik git, serta memperkuat interaksi antara manusia dan Agent

• Pandangan saya soal pemilihan bahasa seperti ini. 1) Java paling komprehensif karena ukuran dan lamanya dataset yang bisa dijadikan referensi oleh LLM (meski itu tidak berarti selalu paling akurat). 2) Yang terpenting, gunakan bahasa yang paling Anda kuasai, supaya Anda bisa cepat menangkap saat LLM salah bernalar, melakukan error, atau berhalusinasi

  • Pendapat bahwa Java punya dataset paling besar, paling tua, dan paling jelas tampaknya hanya relevan jika LLM tidak punya alat untuk mencari API/dokumentasi/source code pihak ketiga. Kalau tool-nya bisa otomatis mencari apa yang harus dipakai, maka bahasa apa pun pada akhirnya tidak masalah selama Agent bisa membaca source-nya. Tetapi untuk poin kedua (pakai bahasa yang Anda kuasai), saya sepenuhnya setuju. Tetap saja, peninjauan teliti oleh manusia itu wajib, dan kalau bahasanya familiar akan lebih mudah menilai apakah ada error

  • Kenapa Java dianggap punya dataset terbesar? Apakah karena proyek open source Java memang yang paling banyak (mungkin karena seluruh suite Apache?), atau karena dokumentasi library open source Java sangat kaya? Saya penasaran

  • Saya justru selama ini mengira dataset yang paling banyak adalah kode Python. Kalau tidak ada arahan khusus, kebanyakan LLM cenderung merekomendasikan Python lebih dulu

• Ada kritik terhadap klaim bahwa context system Go (yang dirancang agar data eksplisit dibawa mengikuti jalur eksekusi kode) memberi kesederhanaan bagi AI agent, yaitu bahwa "menaruh data selain tracing data ke dalam context.Context sebenarnya bukan praktik yang baik"

  • Setuju. Di chromedp (driver headless chrome untuk Go), context.Context dipakai sebagai argumen pertama, tetapi strukturnya mengharuskan kita memakai context yang didapat dari factory khusus, bukan sekadar context.Background(). Pengaturan timeout saja yang ditangani terpisah lewat context.WithTimeout, jadi pada praktiknya ia dipakai hampir seperti pointer void*

  • Saya bukan sampai level ahli Go, tetapi kenyataannya banyak library memang menaruh data seperti koneksi database, konfigurasi, rate limiter, atau backend cache ke dalam context, jadi untuk saat ini saya sendiri tidak terlalu merasa itu masalah besar

• "Menulis kode yang cukup sederhana agar bisa dipahami AI" bukanlah titik inovasi yang saya harapkan. Saya juga penasaran bagaimana ini berbenturan dengan tulisan saya sebelumnya tentang ugly code

  • Cara menulis kode yang sederhana/jelas seperti ini pada dasarnya selalu membantu kerja tim. Ada saat-saat ketika kita memang harus sangat fokus atau menulis dengan kreatif, tetapi itu pengecualian dan harus dekat dengan nilai bisnis. Sebagian besar kode itu jawabannya adalah "hal yang jelas bagi siapa pun". Developer lambat bukan karena mengetik, melainkan karena banyaknya "konsep" yang harus dipegang sekaligus di kepala. Jangan overengineering interface, tunda abstraksi, izinkan copy-paste dan perakitan sederhana, pattern cukup ikuti dokumentasi resmi, dan jangan pernah berusaha terlihat pintar. Intinya, kode jangan disusun agar indah, tetapi agar jelas/sederhana; dan yang benar-benar sulit biasanya bukan kodenya, melainkan "produk"-nya

• Seperti yang ditulis penulis tentang Claude Code, sebenarnya ada berbagai alternatif lain (OpenCode, goose, Codex, Devin, Cursor background agent, dan lain-lain). Ada pertanyaan tentang solusi open source + LLM lokal yang mirip dengan Claude Code

  • Untuk saat ini belum ada solusi open source + LLM lokal yang benar-benar bisa saya rekomendasikan kuat. Namun UX OpenCode dari SST berkembang cepat, dan jika nanti muncul model lokal yang lebih bagus, penerapannya juga akan mudah. Masalah terbesarnya adalah hampir tidak ada model bagus yang benar-benar unggul dalam "penggunaan tool". Alasan Sonnet terasa sangat hebat juga karena pelatihannya memang difokuskan pada penggunaan tool. Gemini pun masih jauh tertinggal, jadi saya rasa ini pada akhirnya masalah yang akan selesai begitu model yang bagus muncul

  • Dalam kasus Aider, sebenarnya sudah sangat dekat, hanya saja sengaja tidak dibuat sepenuhnya agentic. Ia bisa menjalankan test/analisis statis otomatis, memperbaiki error otomatis, dan juga menangani spesifikasi proyek penuh berbasis to-do list. Saat ini ada batas jumlah loop refleksi yang di-hardcode (3 kali), tetapi bisa diakali untuk diperpanjang sesuka hati, dan kalau self prompting ditambahkan, ia praktis bisa menjadi agent yang sepenuhnya otomatis

  • Aplikasi saya yang akan segera rilis menurut saya juga akan menjadi alternatif yang bagus. Strukturnya cukup unduh satu file tanpa instalasi, bisa dipakai di Mac, Windows, Linux, dan Docker. Bisa memakai semua model yang kompatibel dengan OpenAI API (termasuk yang dijalankan sendiri), berbasis browser sehingga sama nyamannya dengan Claude Code, dan juga bisa membuat aplikasi konsol berbasis perintah. Selain itu terminal bisa dibuka langsung untuk dihubungkan ke layanan. Saat ini masih closed alpha, tetapi kalau ingin mencoba silakan hubungi saya lewat email

  • Hampir setiap hari ada alternatif baru (atau percobaan baru) yang dirilis, jadi saya berharap sebentar lagi kita bisa memakai alternatif yang benar-benar "pas". Misalnya app.build baru saja diluncurkan oleh tim Neon (sekarang Databricks) dan terlihat cukup menjanjikan

  • Plugin Neovim CodeCompanion juga belakangan berkembang ke arah yang lebih agentic. Ia sudah mendukung auto-submit loop, tool bawaan, dan integrasi MCP. Memang bukan tool CLI mandiri, tetapi justru punya keunggulan besar karena bisa langsung memakai lingkungan editor penuh (terutama jika suka mengutak-atik, mengustomisasi, atau lebih suka editor ringan)

• 100–200 dolar per bulan terlalu mahal untuk AI penulis kode yang belum terbukti. Pengalaman pribadi saya juga tidak terlalu memuaskan, ditambah lagi ada kontroversi etis, jadi itu menjadi hambatan untuk mulai mencoba

  • Claude Code bisa dipakai dengan API key, atau cukup dengan langganan Pro 20 dolar per bulan

  • Saya sarankan mencoba Aider dengan skema biaya API. Ukuran context bisa dikendalikan (/clear, /add, /drop) sehingga bisa dibatasi sekitar 25K. Model yang dipakai juga bebas (misalnya Sonnet 4, Gemini 2.5 Pro). Untuk skrip sederhana biasanya selesai dengan biaya di bawah 1 dolar, dan bahkan saat membuat tool yang sangat besar pun total prompt + kode + sekitar 100 pengujian tetap bisa di bawah 6 dolar. Setelah terbiasa menulis kode dengan AI, barulah saya sarankan pindah ke Claude Code (lebih kuat, tetapi justru bisa terasa lebih mahal kalau tidak sering dipakai)

  • Dengan langganan 20 dolar untuk sebulan, Anda sudah cukup untuk menguji beberapa proyek kecil dan menilai apakah layak mempertimbangkan paket 100 dolar. Atau Anda juga bisa menunggu beberapa bulan lagi sambil melihat ulasan pengalaman nyata dari pengguna lain