- Koneksi alat dengan pendekatan MCP diklaim sebagai "masa depan", tetapi dalam praktiknya masih lebih efisien menulis kode secara langsung karena keterbatasan berupa kurangnya komposabilitas dan konsumsi konteks yang berlebihan
- Bahkan di era LLM, untuk otomatisasi dan pekerjaan berulang, menghasilkan/memanfaatkan kode tetap unggul dari sisi keandalan dan verifikasi
- LLM lebih kuat untuk pembuatan kode dan eksekusi berulang daripada otomatisasi berbasis inferensi, dan proses berbasis kode unggul dalam identifikasi masalah, verifikasi, dan skalabilitas
- Beberapa alat seperti Playwright (pendekatan MCP) meningkatkan ketidakpastian dan kesulitan debugging di setiap tahap yang berbasis inferensi, sementara membuat/memodifikasi skrip langsung dengan kode meningkatkan repetabilitas, kecepatan, dan keandalan
- Alur "kode-tinjau-ulang" di mana LLM menghasilkan kode, lalu LLM lain meninjau dan menjelaskannya, pada praktiknya merupakan alur otomatisasi yang paling kuat
Cukup dengan kode
- Jika Anda mengikuti saya di Twitter, Anda mungkin tahu bahwa belakangan ini saya tidak terlalu positif terhadap Model Context Protocol (MCP)
- Alasannya bukan karena saya menolak idenya, melainkan karena MCP tidak seefektif yang diiklankan
- MCP punya dua cacat utama
- Tidak benar-benar memberikan komposabilitas (composable)
- Karena menuntut pemberian konteks yang berlebihan, konsumsi konteksnya justru lebih besar daripada menulis dan menjalankan kode secara langsung
- Hal ini bisa dikonfirmasi lewat eksperimen sederhana
- Misalnya, jika Anda mencoba menyelesaikan tugas dengan GitHub MCP lalu melakukan pekerjaan yang sama dengan alat gh CLI, yang kedua menggunakan konteks jauh lebih efisien dan mencapai hasil yang diinginkan lebih cepat
But MCP is the Future! : Tapi MCP adalah masa depan!
- Saya ingin membahas umpan balik yang saya terima terhadap posisi ini, yaitu klaim bahwa kode lebih baik
- Saya telah bereksperimen secara mendalam dengan MCP dalam konteks agentic coding, dan menilainya pada titik di mana keterbatasannya terlihat paling jelas
- Salah satu masukan yang saya terima adalah bahwa "MCP sebenarnya tidak terlalu dibutuhkan untuk pembuatan kode umum, karena model sudah cukup hebat dalam menulis kode." Di sisi lain, saya juga menerima pendapat bahwa MCP bisa bermakna dalam aplikasi berorientasi end-user pada domain tertentu seperti pekerjaan otomatisasi di perusahaan finansial
- Pendapat lain adalah bahwa di masa depan model akan bisa mengakses lebih banyak alat dan menangani tugas yang lebih kompleks, jadi kita harus memperhatikan potensi itu
- Namun penilaian saya saat ini adalah sebagai berikut: berdasarkan data eksperimen dan pengalaman nyata saya, MCP saat ini selalu lebih sulit digunakan daripada menulis kode secara langsung
- Alasan terbesarnya adalah karena MCP bergantung pada inferensi (inference)
- Jika melihat "semua upaya untuk menghubungkan lebih banyak tool ke LLM" akhir-akhir ini, pada akhirnya selalu ada lapisan di mana LLM menerima semua tool lalu memfilternya sesuai tugas
- Sampai sekarang belum pernah ada struktur atau pendekatan yang diajukan yang lebih baik dari ini
- Jadi saya sampai pada kesimpulan ini: bahkan dalam kasus khusus seperti otomatisasi domain tertentu untuk non-developer, pada akhirnya pembuatan kode tetap selalu menjadi pilihan yang lebih baik dalam hal komposabilitas dan reusabilitas
Replace Yourself With A Shellscript
- Salah satu cara melihat masalah ini adalah: tanpa AI pun, bagi developer, alat untuk memecahkan masalah adalah kode
- Bagi non-developer, kode memang sulit, dan banyak pekerjaan yang dilakukan manual oleh orang-orang sebenarnya bisa diotomatisasi dengan software
- Masalah praktisnya adalah siapa yang akan menulis kode itu. Jika Anda berada dalam lingkungan yang khusus dan tidak bisa memrogram sendiri, sulit juga untuk belajar coding dari nol atau berharap seseorang menulis kode kustom untuk Anda
- Tentu ada beberapa tugas yang memang membutuhkan inferensi (penilaian/fleksibilitas manusia), tetapi pada praktiknya sebagian besar tugas yang berulang dan jelas bisa diotomatisasi dengan kode
- Ada ungkapan lama di kalangan developer, "menggantikan diri saya dengan shell script", dan otomatisasi seperti ini memang sudah berlangsung sejak lama
- Di era LLM dan pemrograman, kita mencoba menggantikan diri sendiri dengan LLM alih-alih shell script, tetapi di sini muncul tiga masalah (biaya, kecepatan, keandalan)
- Sebelum tiga masalah ini teratasi, kita bahkan belum sampai pada tahap untuk memikirkan penggunaan tool seperti MCP
- Dengan kata lain, yang paling penting adalah terlebih dahulu memastikan bahwa otomatisasi benar-benar bekerja dengan benar dalam cara yang bisa diskalakan
Automation at Scale : Hakikat otomatisasi dalam skala besar
- Inti otomatisasi adalah menangani pekerjaan yang berulang dan dapat dipakai ulang dengan kode
- Pekerjaan yang hanya dilakukan sekali dan tidak akan diulangi tidak perlu diotomatisasi. Otomatisasi dimulai dari pekerjaan yang akan diulang berkali-kali, yaitu pekerjaan di mana mesin benar-benar memberi keuntungan produktivitas
- Pada praktiknya, Anda melakukannya secara manual 1~2 kali, merangkum cara kerjanya, lalu membuat mesin mengulanginya ribuan kali; itulah hakikat otomatisasi
- Untuk otomatisasi berulang seperti ini, menggunakan "kode" selalu merupakan pilihan terbaik
- Jika setiap kali meminta LLM melakukannya lewat "inferensi", tugas kecil mungkin masih bisa berjalan, tetapi waktu/usaha yang dibutuhkan untuk verifikasi pada akhirnya mengurangi manfaat otomatisasinya
- Contoh: daripada meminta LLM melakukan perhitungan secara langsung, akan lebih baik jika LLM menulis kode Python lalu melakukan perhitungan dengan kode itu, karena ini meningkatkan keandalan sekaligus skalabilitas
- Dengan menggunakan kode, Anda bisa meninjau rumus/logikanya sendiri, memodifikasinya langsung jika perlu, atau meminta LLM meninjau apakah "cara ini sudah benar"
- Kita tidak perlu khawatir Python akan salah menghitung, jadi menjadi jelas bahwa pendekatan pembuatan kode lebih baik dari sisi verifikasi dan kepercayaan
- Logika ini berlaku bukan hanya untuk perhitungan sederhana, tetapi juga untuk pekerjaan pengembangan nyata
- Misalnya, baru-baru ini saya mengerjakan konversi seluruh format blog ini dari reStructuredText ke Markdown
- Saya sudah lama menundanya karena merepotkan, tetapi saya juga tidak bisa mempercayai jika konversi itu diserahkan langsung ke LLM, karena saya khawatir akan ada penghilangan halus/kesalahan atau distorsi konteks di suatu tempat
- Jadi pada akhirnya saya tidak memakai LLM untuk "langsung menjalankan konversi", melainkan memintanya menghasilkan kode konversi dan memprosesnya dengan kode tersebut
LLM → kode → LLM: praktik nyata otomatisasi verifikasi berulang
- Sebagai langkah pertama, saya meminta LLM untuk menghasilkan logika konversi inti dari reStructuredText ke Markdown
- Bukan sekadar konversi sederhana, tetapi dengan memanfaatkan AST (abstract syntax tree) secara langsung sehingga
- reStructuredText diparse menjadi AST → dikonversi ke Markdown AST → dirender ke HTML
- Dengan cara ini saya mendapatkan tahap konversi perantara, sehingga hasilnya lebih mudah dibandingkan dan diverifikasi secara langsung
- Kedua, saya juga meminta LLM menulis skrip untuk membandingkan HTML lama dan HTML baru
- Sambil menganalisis diff pada HTML hasil konversi, skrip itu dirancang untuk secara otomatis menormalisasi perbedaan kecil sebelum perbandingan dimulai, seperti spasi atau cara footnote diproses
- Saya membuat LLM ikut mempertimbangkan sendiri jenis error yang masih dapat diterima dalam proses konversi
- Contohnya, meskipun representasi HTML dari pustaka Markdown/reStructuredText bisa sedikit berbeda, skrip itu dibuat agar hanya menyaring kehilangan/error yang substansial
- Ketiga, saya juga meminta LLM menambahkan skrip batch untuk menganalisis hasil ratusan file sekaligus
- Dengan skrip ini saya menjalankan seluruh file dan melakukan peningkatan berulang (agentic loop) sampai perbedaannya makin kecil
- Keseluruhan prosesnya seperti ini:
- Awalnya saya menjalankan sekitar 10 sampel terlebih dahulu dan mengulang sampai perbedaannya berkurang banyak
- Setelah hasilnya memuaskan, saya menerapkannya ke seluruh post, dan semuanya diproses otomatis dalam sekitar 30 menit
- Kuncinya, ini bisa dipercaya bukan karena LLM benar-benar 'berhasil' melakukan konversi, melainkan karena saya bisa memverifikasi dan me-review seluruh proses itu sebagai "kode"
- Selain itu, saya juga memperoleh tingkat kepercayaan yang lebih tinggi dengan meminta LLM lain meninjau/menjelaskan kode dan perubahan yang dihasilkan
- Saya yakin konversinya dilakukan dengan benar secara mekanis tanpa kehilangan data, dan kapan pun mudah untuk melakukan sample check atau perbaikan
- Bahkan dalam skenario terburuk, yang muncul hanyalah kesalahan kecil dalam sintaks Markdown; isi teks yang sebenarnya tidak sampai rusak
- Satu hal penting lainnya adalah, biaya inferensi (inference) pada pendekatan ini tetap konstan, sehingga perbedaan beban antara jumlah file total (15 vs 150) tidak terlalu besar
- Pada tahap analisis akhir, perbedaan kecil sudah otomatis dilewati, sehingga beban verifikasi berulang pun tidak besar bahkan pada konversi massal
MCP Cannot Do That
- Inti dari penjelasan panjang ini adalah bahwa seluruh pipeline konversi dan otomatisasi berjalan dengan "kode"
- Struktur seperti input manusia → pembuatan kode → review oleh LLM → peningkatan berulang ini bisa diterapkan dengan cara yang sama pada tugas umum lainnya
- Sebagai contoh ada Playwright, kasus representatif dari pendekatan MCP
- Ini adalah alat otomatisasi untuk mengendalikan browser dari jarak jauh, membaca dan memahami halaman, menekan tombol, dan sebagainya; inferensi (inference) diulang pada setiap langkah
- Tugas semacam ini memang sulit digantikan secara sempurna dengan "pendekatan kode"
- Namun, jika struktur halamannya sudah diketahui (misalnya untuk menguji aplikasi sendiri yang sedang saya kembangkan)
- Jauh lebih cepat dan andal jika meminta LLM membuat skrip Python Playwright lalu menjalankannya
- Dengan pendekatan ini, sekali skrip dibuat, ia bisa dijalankan berulang puluhan atau ratusan kali tanpa inferensi tambahan
- Tidak perlu lagi menafsirkan layar secara real time atau mencari posisi tombol setiap saat, dan seluruh alur otomatisasi bisa dijalankan sekaligus
- Pendekatan MCP membutuhkan pemanggilan tool yang terabstraksi dan inferensi di setiap tahap, sehingga sangat sulit membuat LLM selalu bertindak benar, dan debugging pun sulit
- Misalnya, meskipun ingin menyematkan klien MCP ke shell script untuk memanggil layanan jarak jauh secara efisien, pada praktiknya saya merasakan bahwa cara ini sangat tidak efisien dan juga sulit diimplementasikan
- Pada akhirnya, saya ini manusia, bukan klien MCP.
- Kode mudah dieksekusi dan di-debug, tetapi pemanggilan MCP selalu penuh ketidakpastian dan tidak bisa diandalkan
- Dalam praktiknya, justru alat-alat kecil yang dibuat LLM selama menghasilkan kode (misalnya snippet di Claude Code) yang saya gunakan sebagai tool jangka panjang dalam proses pengembangan saya
Ke mana kesimpulan ini mengarah?
- Sejujurnya saya juga tidak tahu alur ini akan menuju ke mana. Namun sekarang adalah saat yang tepat untuk memikirkan bagaimana meningkatkan pendekatan pembuatan kode untuk "agentic coding" yang disengaja
- Ini mungkin terdengar aneh, tetapi kadang MCP benar-benar bekerja dengan sangat baik. Namun strukturnya saat ini terlalu bergantung pada "inferensi", dan terasa seperti jalan buntu yang tidak cocok untuk otomatisasi skala besar yang bisa diskalakan
- Karena itu, tampaknya kita perlu mencari cara untuk memisahkan dan mengabstraksikan dengan lebih jelas area di mana MCP benar-benar kuat, dan peran pendekatan pembuatan kode
- Untuk itu, kita juga perlu mencoba membuat sandbox (lingkungan eksekusi aman) yang lebih baik, serta mengubah desain API agar agen bisa melakukan inferensi "fan out/fan in" terhadap API dengan bebas
- Saya berpikir bahwa struktur yang ideal adalah "segala hal yang bisa dilakukan dengan kode, lakukan sebisa mungkin dengan kode", lalu setelah eksekusi skala besar selesai, LLM menilai dan me-review keseluruhan hasil
- Dan jika dalam proses pembuatan kode kita menambahkan informasi konteks yang cukup sehingga LLM dapat menjelaskan dalam bahasa alami kepada non-developer apa yang dilakukan skrip yang dihasilkan, maka alur otomatisasi ini nantinya juga bisa dimanfaatkan dengan mudah oleh non-developer
- Kesimpulannya, saya merekomendasikan untuk lebih berani memanfaatkan kemampuan pembuatan kode dari LLM alih-alih MCP, dan bereksperimen dengan kemungkinan baru
- Jika kita membiarkan LLM menulis kode secara langsung, kita bisa mengotomatisasi jauh lebih banyak hal daripada yang kita bayangkan
Referensi
2 komentar
Saya setuju, tetapi tampaknya ini lebih merupakan optimasi arah desain alih-alih masalah MCP itu sendiri. Meski fungsinya sama, tergantung MCP yang digunakan, ia bisa menghasilkan kode dan perintah secara internal sehingga mengurangi pekerjaan yang tidak perlu. Jika memakai gh cli mcp atau terminal mcp, bukan Github mcp, token memang tetap terpakai tetapi jauh lebih sedikit, dan efek yang sama bisa didapatkan; rasanya bagian ini terlewat.
Komentar Hacker News
Secara umum saya setuju bahwa arah ini memang benar. Penggunaan LLM skala besar biasanya banyak dimanfaatkan untuk mengisi celah di antara dua antarmuka yang kokoh. Kunci keandalan bukanlah hasil keluaran LLM, melainkan fakta bahwa antarmuka itu sendiri hanya mengizinkan konfigurasi tertentu.
Keluaran LLM sering kali dipaksa dikonversi menjadi nilai yang lebih deterministik seperti tipe atau primary key DB. Nilai LLM sangat bergantung pada seberapa baik kode dan tool yang sudah ada memodelkan data, logika, dan perilaku dalam domain saya.
Secara pribadi, belakangan ini saya merasa LLM mirip dengan printer 3D. Keduanya cepat menyambungkan komponen untuk prototyping cepat, tetapi jika menginginkan skalabilitas dan kekokohan, pada akhirnya insinyur atau LLM harus mengganti sambungan sementara itu dengan penopang deterministik seperti logam/kode.
Seperti ekspektasi berlebihan pada printer 3D di masa lalu, LLM juga terlihat seolah bisa menggantikan seluruh realitas operasional, padahal sebenarnya baru benar-benar berguna ketika pemodelan digital yang ada sudah menjadi fondasi yang kuat
Ada hal yang saya sadari saat memakai tool LLM. Jika masalahnya dipersempit ke dalam sandbox menjadi bentuk yang bisa dipecahkan LLM dengan memakai tool secara berulang, maka masalah itu bisa diselesaikan dengan brute force. Kuncinya adalah mengidentifikasi masalah seperti itu, lalu menentukan sandbox yang tepat, tool yang akan dipakai, dan kriteria keberhasilan.
Proses ini juga membutuhkan cukup banyak keahlian dan pengalaman, tetapi tetap jauh lebih tinggi levelnya dibanding trial and error manual satu per satu.
Saya menyadari ini saat melakukan 'eksperimen assembly Mandelbrot'.
(Link eksperimen: https://simonwillison.net/2025/Jul/…)
Idealnya harus ada kriteria evaluasi berbentuk fungsi kontinu, atau setidaknya berbagai input dan output yang diharapkan dalam bentuk kuantitatif agar otomatisasi sungguhan bisa dilakukan
Misalnya LLM lemah pada generic TypeScript, tetapi jika TSC sungguhan dijalankan, ia bisa terus memverifikasi lewat tes dan mencoba lagi sampai benar. Maintainability kode bisa menurun, tetapi secara teori ini struktur yang sangat menarik.
Selain itu, Cursor bisa melihat error TypeScript, jadi kalau hanya membuat tes utility type, Cursor sendiri bisa menulis tes dan memecahkan masalah dengan brute force pengulangan sederhana
Repo yang layak dilihat: https://github.com/davidkimai/Context-Engineering/…
Saya belum membaca semuanya, tapi cukup mengesankan
Apakah ini juga bisa dilakukan dengan model lokal, atau cukup lewat langganan seperti Claude Code Pro.
Eksperimen Mandelbrot memang menarik, tetapi tingkat kesulitannya agak berbeda dibanding codebase komersial nyata yang kompleks
Saya rasa ini bukan masalah MCP itu sendiri. Pada level AI saat ini, struktur yang melibatkan manusia di tengah proses jauh lebih unggul.
LLM kuat di tugas tertentu, tetapi sering terjebak di local minima. Karena itu, jika kita bolak-balik lewat antarmuka web menjalankan loop "tolong buat program → cek & beri petunjuk → tes", kualitasnya jelas membaik.
Kita bisa mengubah 10.000 baris kode berantakan menjadi 400 baris kode yang jelas. Untuk saat ini, itulah kenyataannya.
Tentu banyak perusahaan atau developer ingin "mengganti programmer itu sendiri dengan LLM", tetapi dalam praktiknya itu masih belum mungkin.
Efek nyatanya adalah meningkatkan kecepatan kerja programmer beberapa kali lipat, atau memungkinkan pemula cepat menjadi produktif lewat LLM. Namun "agentic coding" masih belum benar-benar bekerja.
Dalam kondisi saat ini, jawaban yang tepat adalah memakai LLM sebagai rekan kerja atau asisten. Kenyataannya saat ini ia bukan "agen AI" otonom tanpa umpan balik
Saya bekerja dengan bahasa yang type-safe, fungsional, dan terkompilasi, sehingga hasilnya selalu harus saya baca sendiri; kalau bahasanya kurang ketat, saya rasa akan lebih mengkhawatirkan.
Meski begitu, efek penghematan waktu sangat besar. Saya terutama puas karena pekerjaan bisa dipecah sehingga target besar jadi lebih mudah ditangani
Saya benar-benar mencoba mengerjakan task dengan GitHub MCP, lalu melakukan hal yang sama dengan gh CLI, dan ternyata gh CLI menggunakan konteks jauh lebih efisien sehingga jauh lebih cepat.
Saya punya file CLAUDE.md di folder "devops" yang berisi kumpulan perintah bash bersama.
Setiap kali task baru selesai, saya meminta Claude menambahkan contohnya, dan untuk pertanyaan serupa berikutnya Claude bisa menyelesaikannya sekaligus.
Isi awal CLAUDE.md saya bagikan di sini:
(Perintah spesifik diringkas)
Jadi akhirnya menjadi perangkat lunak self-healing yang menambahkan perintah untuk mengetes & memperbaiki aplikasi saat masalah muncul
Dari semua pemanfaatan MCP yang pernah saya lihat, yang paling mengesankan adalah clojure-mcp karya Bruce Hauman.
LLM diberi (a) bash, (b) persistent Clojure REPL, dan (c) tool pengeditan terstruktur.
Karena itu, saat mengedit kode Clojure, pendekatan ini bekerja jauh lebih efisien dibanding pendekatan murni berbasis diff teks.
Jika ada test suite yang memadai, pengulangan edit file, reload, dan tes berjalan sangat mirip kerja manusia, dan itu mengejutkan
Ia mendukung fitur penting seperti debug kode, evaluasi expression individual, dokumentasi tipe kembalian fungsi, dan sebagainya.
Saya jadi merasa bahasa dengan REPL yang kuat jauh lebih unggul dalam kemampuan seperti itu, dan setelah melihat potensi clojure-mcp, kesan saya terhadap AI berubah besar
Contoh GitHub CLI tidak sepenuhnya menunjukkan keunggulan MCP.
Tool seperti gh CLI yang dokumentasinya sangat mudah diakses memang secara alami lebih mudah dimanfaatkan LLM karena ia bisa dengan mudah membuat kodenya.
Namun keunggulan nyata MCP justru terlihat pada tool internal atau API niche yang hampir tidak punya dokumentasi online.
Semua dokumentasi memang bisa dimasukkan ke konteks, tetapi untuk kasus seperti ini MCP justru lebih efisien.
Jika memakai tool MCP yang dirancang baik dengan input yang tepat, beban LLM untuk memahami API, autentikasi, mengelola edge case, dan sebagainya bisa sangat berkurang.
Mungkin GitHub memang tidak butuh MCP, tetapi di lingkungan seperti API internal/tidak lengkap, tool MCP yang sudah disiapkan sebelumnya jauh lebih ampuh
Sebagai contoh, di sonnet4 batasnya terasa begitu jumlah tool melewati 15. Bahkan hanya memakai MCP resmi Playwright saja sudah memakan kapasitas tool
Pada akhirnya satu-satunya kelebihan MCP bisa jadi hanya untuk menegaskan kembali bahwa API tersebut terasa sulit semata-mata karena memang terlalu rumit
Terkait contoh Playwright,
minggu ini saya juga sempat membuat agen berbasis server Playwright MCP, lalu merasa itu lambat, tidak efisien dalam token, dan kurang andal, sehingga saya kembali ke pemanggilan Playwright langsung.
Server MCP bagus untuk menguji apa yang mungkin dilakukan, tetapi dalam praktiknya pemanggilan API lebih efisien dan stabil.
Saya bagikan contoh agen LinkedIn pribadi yang saya buat beserta demonya:
LinkedIn terkenal sebagai platform yang sangat sulit diautomasi, jadi saya penasaran apakah saat membuat agen LinkedIn pribadi Anda menemui kesulitan atau batasan tertentu
Sebenarnya saya merasa terminal saja sudah cukup.
Selama berbulan-bulan saya memakai MCP setiap hari, tetapi sekarang saya hanya memakai satu server MCP berbasis iTerm2 (terminal).
OpenAPI spec memang ada bila diperlukan, tetapi pada praktiknya hampir semua hal bisa dilakukan dengan shell command dan curl
Kritik bahwa "terlalu banyak konteks dibutuhkan" sebenarnya bisa diatasi kalau default prompt awal diatur dengan baik.
Semua tool utama termasuk Claude Code dan Gemini CLI mendukung ini
Memberikan seluruh daftar tool ke LLM lalu membiarkannya menyaring sendiri memang bukan pendekatan terbaik, tetapi
LLM terbaru terus berkembang, dan saya sendiri belum pernah mengalami kesulitan besar dalam memilih fungsi MCP yang tepat.
Soal biaya, kecepatan, dan keandalan juga:
Kita tidak perlu menghabiskan waktu langsung di percakapan
Sebagai contoh terbaru, LLM otomatis menangani banyak tool eksternal seperti Notion, Linear, git, log PR/CI GitHub, dan lain-lain,
dan saya hanya melakukan satu kali review PR.
Biayanya pun kurang dari 1 dolar
Justru menambah tool bisa membuat informasi awal yang dibutuhkan makin banyak sehingga menjadi batasan serius
melainkan masih tersembunyi, dan struktur promosi gratis/murah seperti sekarang tidak akan bertahan lama.
Misalnya Cursor sudah memperkenalkan paket bulanan $200, dan kualitas layanan di paket murah memburuk.
Saat promosi gratis selesai, semuanya akan kembali ke level aslinya
Saya bekerja dengan Julia, dan mendapat manfaat dari lingkungan sesi yang berjalan lama.
Karena fungsi dikompilasi saat pertama kali dijalankan, saya membuat MCP agar Claude Code mengirim kode ke kernel Julia (Jupyter) yang persisten.
Menjalankan kode tes jadi jauh lebih cepat, dan CC juga lebih baik memanfaatkan fungsi yang sudah ada di codebase daripada bash bespoke.
Menurut CCUsage, pemakaian token juga turun hampir 50%.
Ini tidak harus berupa MCP, tetapi intinya adalah lebih mudah menempelkan 'fungsi tertentu' ke codebase daripada menulis custom code satu per satu untuk Claude