Ringkasan
- Laporan eksperimen yang menunjukkan bahwa setelah struktur kode (pattern strategi·factory, pemisahan file, penataan
.cursorrules) direfaktor dengan prompt satu baris, lalu prompt penambahan fitur yang sama dijalankan, penggunaan token AI menurun secara signifikan (Zero-context, N=5). Prompt dan source yang digunakan dalam eksperimen dipublikasikan sehingga dapat direproduksi.
Data utama
-
Claude-4 Sonnet: rata-rata 390,159 → 242,265 tokens (−37.91%)
-
GPT-5: rata-rata 315,839 → 233,634 tokens (−26.03%)
-
Acuan: Total Tokens yang ditampilkan Cursor. Membandingkan nilai absolut antar model tidak bermakna (perbedaan metode penghitungan per model).
Pengaturan (ringkas)
-
IDE Cursor 1.6.6, model GPT-5 / Claude-4 Sonnet
-
Semua prompt Zero-context, editor direstart sepenuhnya di setiap ronde
-
Penilaian berhasil: dihitung sukses bila kebutuhan terimplementasi dengan satu prompt
Mengapa ini penting
-
“Struktur kode yang baik” bukan hanya lebih mudah dibaca manusia, tetapi juga berdampak pada token, biaya, dan waktu bagi AI
-
Reproduktibilitas terjamin karena prompt dan repositori dipublikasikan (bisa langsung dimanfaatkan untuk penerapan di lapangan dan eksperimen lanjutan)
Opini pribadi
- Sebagai pengguna Cursor, saya menilai ini mengusulkan metodologi yang sangat baik yang memberikan pendekatan kunci untuk penghematan biaya.
- Seperti juga disebutkan di isi artikel, jumlah sampling yang masih kurang memadai agak disayangkan.
34 komentar
Apakah Anda sempat ikut kursus bikin judul...
Saya menikmati eksperimennya dengan senang hati.
Terima kasih.
Terlepas dari isinya, sepertinya karena judulnya menyebut hanya satu baris prompt, maksud yang ingin dilihat jadi berbeda dengan isi tulisannya.
Ya, saya juga berpikir begitu. snif
Maaf;;
Terima kasih atas perhatian besar terhadap tulisan ini. Karena tujuan utamanya adalah distribusi ke luar negeri, artikel ini ditulis dalam bahasa Inggris, dan tampaknya hal ini menimbulkan berbagai masalah.
Sebagai tindak lanjut, saya membagikan post yang telah dirangkum dalam bahasa Korea.
https://modgo.org/tokeun-sayongryang-37-91-reul-gamsosikin-dan-hanjuly…
Berikut rangkuman tambahan terkait prompt yang digunakan.
Bagaimanapun juga, ini lebih menguntungkan bagi para developer dalam menulis prompt untuk perbaikan struktur. Karena setiap program memiliki karakteristik yang berbeda, pengetahuan pengembangan perangkat lunak pada tingkat tertentu tetap diperlukan untuk melakukan perbaikan yang efisien.
Namun, ini bukan berarti para vibe coder non-developer tidak bisa menggunakan metode ini. Meskipun ada perbedaan efisiensi, bahkan dengan perintah sederhana seperti, "Tolong rapikan kode proyek. Hapus kode yang tidak digunakan.", AI juga akan memisahkan dan merapikan file serta class.
Hanya saja, karena perbedaan detail dalam perbaikan struktur dapat menghasilkan perbedaan efisiensi, Anda perlu berhati-hati saat merujuk materi.
Prompt sebaiknya hanya memuat inti secara logis. Jadi, apakah maksudnya semakin banyak hal yang ditambahkan ke prompt, semakin banyak noise yang muncul, sehingga kode yang dihasilkan juga menjadi lebih rumit dan penuh noise?
Intinya, setelah AI diarahkan untuk melakukan refaktorisasi struktur kode, jumlah token yang terpakai menjadi berkurang.
Sebaliknya, bisa juga dijelaskan bahwa jika perintah terus dilanjutkan saat masih ada cacat struktural pada kode, penggunaan token akan meningkat.
Singkatnya, yang dimaksud adalah perlu adanya perbaikan struktur pada source code, dan bukan berarti prompt harus hanya berisi inti secara logis.
Saya juga merasa pengantar ini dan teks aslinya terlalu bertele-tele dan seperti ditulis oleh orang yang kurang pandai menulis, jadi cukup sulit dibaca selama prosesnya,
intinya
"tambahkan satu baris instruksi yang memuat batasan struktural untuk mengurangi token"
kurang lebih seperti itu
Tulisan ini lebih dekat dengan sifat penelitian 'eksperimen',
sehingga semua angka yang disertakan di tulisan ini difokuskan agar semua orang yang membacanya bisa melakukan 'reproduksi'.
Karena itu, saya mencatat seluruh kode sumber asli yang digunakan, serta semua prosedur yang dipakai dalam pengujian,
dan isi tulisan ini difokuskan pada penyediaan informasi agar semua peneliti bisa mendapatkan hasil yang sama.
Melihat suasana di kolom komentar,
saya jadi berpikir apakah ke depannya saya perlu memisahkan menjadi dua tulisan: satu yang bergaya ringkasan 3 baris,
dan satu lagi untuk orang-orang yang ingin mengetahui detailnya.
Jika Anda bisa memberi tahu bagian mana dari tulisan ini yang terasa terlalu rumit, dan apakah penjelasannya terasa bertele-tele,
itu sepertinya akan sangat membantu saya saat menulis tulisan berikutnya.
Saya juga merasakan hal yang mirip.
Saya paham maksud penulisnya, tetapi dibandingkan dengan apa yang dilakukan, tulisannya terasa terlalu rumit.
Sepertinya ditulis seperti ini karena ingin memasukkan sedetail mungkin hal-hal yang digunakan dalam eksperimen ke dalam tulisan,
tetapi menurut saya kalau hanya inti utamanya saja yang diringkas, orang-orang yang tertarik pada topik seperti ini pun kemungkinan besar tetap akan memahaminya.
Menurut saya akan lebih baik jika detail-detailnya dipangkas dengan berani dan hanya poin intinya yang dirangkum.
Saya pribadi merasa maksud penulis maupun hasilnya sendiri cukup menarik.
Argumen utamanya tampaknya adalah bahwa source code yang lebih baik akan berujung pada konsumsi token yang lebih sedikit,
dan sepertinya penulis telah merancang serta menjalankan eksperimen yang terkait dengan hal tersebut.
Kalau saya hanya merangkum bagian eksperimennya sesuai pemahaman saya,
Kurang lebih seperti itu.
Dan kalau pemahaman saya benar, kesimpulannya tampaknya adalah bahwa source code yang dipraproses dengan prompt secara umum menghabiskan token lebih sedikit.
Ini memang kesimpulan yang menarik, tetapi pendapat saya tentang eksperimennya adalah sebagai berikut.
Bukan perbandingan yang adil
Secara angka memang terlihat menurun, tetapi menurut saya seharusnya dibandingkan berdasarkan jumlah token total untuk memproses source code tersebut.
Dengan kata lain, jumlah token yang digunakan untuk praproses juga tampaknya perlu diperhitungkan.
Jika jumlah token yang dipakai untuk praproses terlalu besar, pada dasarnya itu justru menghabiskan lebih banyak token sehingga menjadi tidak bermakna; dan sekalipun kecil, selisih konsumsi token yang sebenarnya kemungkinan akan jauh lebih kecil daripada yang tergambar di tulisan.
Perlu membandingkan source code sebelum dan sesudah praproses
Jika token yang digunakan untuk praproses dikecualikan, konsumsi token saat query memang tampak berkurang secara signifikan.
Namun, jika dianalisis perbedaan persis seperti apa pada source code yang menyebabkan selisih ini, makna tulisannya akan menjadi lebih besar.
Karena itu berarti optimasi prompt praproses untuk memaksimalkan perbedaan tersebut bisa dilakukan.
Penulis mengatakan bahwa refactoring struktur kode memunculkan hasil ini, tetapi saya tidak setuju, dan menurut saya itu belum bisa dipastikan.
Sebab, bisa saja pengurangan konsumsi token juga terjadi ketika AI diminta memperbaiki bagian lain selain refactoring.
Perlu eksperimen yang lebih beragam
Menurut saya eksperimen yang sama juga perlu dijalankan pada codebase lain, bukan hanya pada kode yang sekarang.
Karena kita perlu menilai apakah hasil seperti ini konsisten bagus atau tidak.
Namun, saya paham bahwa secara realistis ini bisa sulit untuk diuji, jadi menurut saya bagian ini cukup dijadikan referensi saja.
Saya sepenuhnya setuju. Kritik dalam bentuk seperti ini sangat saya sambut.
Kita tidak hidup sendirian di dunia ini, dan kemampuan maupun situasi setiap individu berbeda-beda.
Saya juga hanyalah seorang pengembang biasa, dan saya tidak bisa melakukan semua pengujian dengan biaya pribadi.
Saya berharap tulisan ini menjadi benih yang memberi dampak baik bagi banyak orang, sekaligus menjadi titik awal bagi banyak penelitian lanjutan.
Subjudulnya memang kurang sesuai dengan isinya. Jika dirapikan ulang, subjudul seperti "perlu analisis yang lebih jelas terhadap faktor-faktor yang menyebabkan pengurangan token" tampaknya akan lebih cocok.
Saya setuju dengan banyak bagian dari isi ini. Namun, karakter tulisan ini juga memuat unsur "mengusulkan cara penerapan yang realistis bagi orang-orang yang membaca tulisan ini".
Bahkan hanya dengan melihat komentar-komentar pada tulisan ini, suasananya sudah terasa. Saya juga baru mengetahui hal ini belakangan, tetapi tampaknya di antara pengguna AI ada banyak juga vibecoder non-developer.
Jika hasil yang luar biasa dibuat dari kode yang disesuaikan langsung oleh penulis tanpa melalui AI,
maka hal itu mudah terlihat sebagai penulis sedang memamerkan kemampuan pengembangannya sambil meremehkan kemampuan AI.
Karena itu, saya membahas contoh yang bisa dirasakan hasilnya oleh siapa pun melalui elemen "prompt" yang dapat dimanfaatkan oleh para vibecoder pada umumnya.
Saya harap setelah penelitian ini, akan ada penelitian lanjutan yang dapat menguraikan lebih rinci faktor-faktor yang memengaruhi penggunaan token AI.
Jika melalui 1 kali perbaikan struktur dapat diperoleh efek menurunkan tingkat konsumsi token dari n kali prompt, maka jumlah pengurangan token tersebut akan tercermin secara sama pada n kali eksekusi yang setara.
Nilai n ditentukan oleh tujuan proyek, jumlah fitur, serta banyaknya dan kompleksitas kode yang dibutuhkan untuk itu,
selain itu, karena baru-baru ini cursor / claude code agent juga menghadirkan pembaruan yang membuat unit kerja lebih kecil untuk mengatasi masalah eksekusi berulang tanpa henti atau penggunaan token AI yang berlebihan,
menurut saya penelitian mengenai nilai n yang berkaitan dengan kompleksitas proyek sebaiknya dilakukan secara terpisah.
Hal yang tidak boleh terlewat di sini adalah bahwa perbaikan struktur sama sekali bukan tindakan yang terjadi secara terpisah dari pengembangan kode.
Ini bisa menjadi bagian yang memengaruhi sebagai base context melalui prompt awal, atau melalui batasan seperti ruleset AI (
.cursorrules),dan selama siklus pengembangan proyek, 1 kali perbaikan struktur tidak bisa menyelesaikan semuanya.
Artinya, daripada merencanakan perbaikan kode secara berkala, mengarahkan struktur yang benar sebagai base context adalah arah yang lebih baik.
Selain itu, penelitian tentang ada atau tidaknya aturan instruksi pengarah struktur sebagai base context juga tampaknya sebaiknya dilakukan secara terpisah.
Untuk merangkum poin nomor 1,
maka klaim bahwa penggunaan token dari 1 kali perintah prompt perbaikan struktur harus ditambahkan ke dalam perhitungan mengandung kekeliruan.
Saya kurang memahami dengan baik apa yang Anda maksud dalam komentar. Komentar saya adalah, jika ingin membandingkan dua metode secara adil, bukankah yang harus dibandingkan adalah total jumlah token yang dikonsumsi? Refactoring juga menghabiskan token, bukan?
Selain itu, hal yang Anda sampaikan dalam balasan tampaknya juga tidak tertulis di artikel dan sepertinya belum diuji lewat eksperimen. Maksud Anda sepertinya bukan membandingkan token per satu kali kueri, melainkan bahwa saat kueri dilakukan berkali-kali, overhead refactoring akan mengecil dan karena jumlah token yang diharapkan per kueri berkurang, maka total jumlah token akhirnya akan lebih menguntungkan. Namun itu tampaknya hanya berlaku jika, dalam banyak kueri, penurunan biaya tersebut tetap terjaga seperti yang Anda bayangkan, dan menurut saya itu lebih seperti asumsi situasi yang sangat ideal. Tidak ada jaminan bahwa penurunan biaya akibat refactoring akan tetap bertahan terlepas dari jumlah kueri berikutnya, dan itu juga tidak bisa diasumsikan tanpa eksperimen. Jika Anda ingin menegaskan maksud tersebut, sepertinya Anda perlu menunjukkan lewat eksperimen adanya penurunan biaya untuk lebih dari satu kali kueri. Tetapi bukankah eksperimen yang dilakukan dan dibandingkan hanya satu kali?
Sebagai tambahan, ini hanya asumsi saya, tetapi jika untuk tujuan yang sama (hasil akhir ideal) kueri diulang tanpa batas, maka dalam situasi ideal, terlepas ada atau tidaknya refactoring, kodenya pada akhirnya tampaknya harus konvergen ke bentuk yang sama. (Hasil akhir ideal itu unik.) Jika asumsi ini masuk akal, maka seiring kueri diulang, perbedaan ada atau tidaknya refactoring akan semakin kecil, sehingga keuntungan penurunan biaya token juga tampaknya akan makin berkurang. Jadi jika dilihat secara makro, bila keuntungan dari penurunan biaya ini tidak cukup bertahan lama, bukankah mungkin perbedaan total jumlah token yang digunakan dalam kueri pada akhirnya tidak signifikan?
Dan, Anda juga menanyakan soal eksperimen terkait jumlah rangkaian prompt,
sebenarnya justru ini adalah elemen yang, dalam istilah kasarnya, bagus untuk dipakai penulis “mengakali” hasil.
Aktivitas development itu sendiri memiliki sangat banyak pilihan arah dalam prosesnya, dan jika prompt ditumpuk ke arah yang membuat penggunaan token semakin melebar, angka itu akan membengkak jauh lebih besar seperti bola salju.
Dalam penelitian, ada filosofi yang disebut
Cumulative Science.Setidaknya menurut standar saya, saya belum pernah sekalipun menemukan penelitian terkait penggunaan token untuk 1 kali perintah,
jadi alih-alih langsung melakukan penelitian N kali, saya memilih fokus pada pengujian dan kesimpulan untuk 1 kali yang benar-benar jelas,
dan penelitian N kali bisa dilanjutkan setelah eksperimen ini sebagai kelanjutan riset.
Selain itu, di tulisan lain, saya juga pernah membahas perbedaan perilaku AI berdasarkan perbedaan codebase.
(Ini juga pernah diperkenalkan di GeekNews ini: https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/)
Singkatnya, tulisan tersebut membahas pengujian dan hasil bahwa kualitas output berubah tergantung pada codebase yang diberikan sebagai input ke AI.
Bergantung pada kualitas dan arah codebase awal, kualitas kode berikutnya bisa tetap terjaga, atau justru terus memburuk.
Artinya, biaya refactoring pada tahap awal proyek dan biaya refactoring pada proyek yang sudah berjalan jauh bisa sangat berbeda.
Jika penanya adalah seorang developer, mungkin Anda pernah sekali mendengar ungkapan 'kapal induk di atas perahu layar',
Refactoring adalah topik yang mendalam: pada titik mana ia harus dilakukan, atau bagaimana biaya dapat berubah sangat besar tergantung pada filosofi dan desain yang diterapkan di awal proyek.
Daripada memasukkan hal ini sebagai variabel dan membuat kesimpulan menjadi tidak stabil,
saya melakukan pengujian yang setidaknya bisa menjelaskan dengan pasti bahwa 'kalau kualitas codebase bagus, penggunaan token akan berkurang'.
Izinkan saya menjelaskannya sekali lagi.
Pelaku vibe coding mencakup rentang yang luas, dari non-developer hingga developer berpengalaman. Bergantung pada tingkat pengetahuan yang mereka miliki, kualitas hasil keluaran bisa sangat beragam, terlepas sama sekali dari isi tulisan ini.
Seseorang mungkin secara alami, dengan asumsi menggunakan Cursor, memasukkan aturan dasar OOP dan aturan pemisahan kelas/metode ke dalam
.cursorrules, sehingga bisa beroperasi dalam bentuk yang hampir tidak memerlukan refactoring.Namun bagi orang lain, bisa saja terjadi produksi massal kode level rendah akibat tidak memahami poin-poin utama yang sangat mendasar.
Bahkan, tulisan dan pengalaman yang menganjurkan agar kualitas kode tetap baik melalui pengaturan aturan proyek pada dasarnya sudah banyak dibagikan sebelumnya.
Ini menunjukkan kemungkinan bahwa sebagian orang sudah memperoleh keuntungan dari sisi penggunaan token bahkan tanpa refactoring yang eksplisit.
Namun, kasus-kasus di atas tidak merangkum penurunan penggunaan token yang jelas per unit eksekusi melalui definisi aturan tersebut. Karena itu, tulisan ini menguji perbedaan penggunaan token berdasarkan kualitas codebase dan merangkum hasilnya.
Dengan kata lain, tergantung pada penggunanya, jumlah refactoring eksplisit itu sendiri kembali menjadi variabel dari 0 hingga n kali,
Dan tampaknya akan lebih tepat jika dipahami bahwa maksud esensial tulisan ini adalah menjelaskan, 'mengapa penting untuk memperhatikan codebase yang berkualitas baik?'
Saya penulisnya. Terima kasih atas masukannya. Akan saya jadikan referensi saat menulis artikel berikutnya.
Apakah maksudnya biaya berkurang setelah prompt ini ikut dimasukkan? Saya kurang yakin apakah saya memahami intinya dengan benar.
Sebagai tambahan, struktur kode perlu diperbaiki dengan model yang sesuai untuk proyek tersebut. Seperti isi jawaban di bawah, jika Anda meminta AI melakukan perbaikan struktur, AI akan memberi tahu metode perbaikan struktur yang tepat untuk proyek tersebut.
Secara pribadi, cara yang saya rekomendasikan adalah jangan langsung memberi perintah perbaikan struktur kepada AI. Sebaliknya, minta AI memberi usulan terlebih dahulu; AI akan memberikan respons, lalu melalui percakapan Anda bisa mencapai usulan yang cukup efisien, dan setelah itu barulah minta untuk menerapkannya.
Satu tips tambahan: sebisa mungkin selesaikan pekerjaan sebelum context summarization (inisialisasi ulang buffer konteks) terjadi. Jika inisialisasi ulang buffer konteks tidak bisa dihindari, sebaiknya sebelumnya minta untuk menambahkan aturan perbaikan ke
.cursorrules. Jika inisialisasi konteks terjadi di tengah pekerjaan, kemungkinan AI melakukan kesalahan akan lebih tinggi.Sebagai referensi, fakta bahwa semakin kecil ukuran source yang dimasukkan maka semakin sedikit token yang dikonsumsi adalah hal yang sudah jelas dan dikenal luas. Itulah sebabnya file
.cursorignoredibuat.Secara umum, ketika AI diminta memperbaiki struktur, dalam kebanyakan kasus jumlah source code memang cenderung berkurang, jadi klaim bahwa merapikan kode dengan alasan apa pun dapat menurunkan biaya tampaknya cukup masuk akal.
Tulisan ini menambahkan klaim bahwa melalui pengarahan struktur yang baik, pengurangan tambahan pada penggunaan token juga bisa dicapai.
Benar. Seperti yang juga disebutkan di artikel, memang ukuran kode proyek berkurang setelah perbaikan kode.
Namun, dalam contoh ini penurunannya hanya sekitar 10% berdasarkan jumlah karakter, dan itu saja tidak cukup untuk menjelaskan penurunan penggunaan token sebesar 37,91%.
Di artikel ada tautan ke repositori sumber, dan siapa pun bisa mereproduksinya lalu mengujinya sendiri.
Saya sendiri belum pernah mengujinya seperti ini,
namun saya rasa prompt seperti
'analisis kode saat ini, lalu perbaiki strukturnya menjadi bentuk yang mudah kamu kelola'
juga kemungkinan bisa bekerja.
Intinya, saya rasa maksud pastinya adalah bahwa bukan hanya menyampaikan kebutuhan fungsional kepada AI, tetapi juga mengarahkan struktur yang tepat dan benar dengan baik dapat membantu mengurangi biaya.
https://modgo.org/dib-rag-gaelreogtig-modeu-seuteurimeoreul-wihan-ciji…
Apakah mode DeepRAGGal ini Anda buat sendiri secara langsung?
Apakah ini juga dibuat dengan vibe coding?
Halo. Saya pemilik blog ini.
Benar, mode DeepRAGGal yang saya buat sendiri, dan saat ini sedang saya layankan melalui server pribadi. (Ini diperlukan karena autentikasi Chzzk OAuth)
Mode tersebut mencakup pengembangan menggunakan Unreal Engine, tetapi sayangnya di sisi Unreal Engine, vibe coding sulit dilakukan.
Sebagai gantinya, karena cara pengembangan mod itu sendiri tidak terlalu sulit, jika Anda tertarik, Anda bisa mempelajarinya dengan mudah melalui panduan pengembangan mod (https://modgo.org/dib-rag-gaelreogtig-modeu-gaebal-part-1/).
Saya melihat Anda mengunggah mode itu di komunitas lain, dan ternyata benar itu tulisan dari orang yang membuat mode tersebut.
Saya tidak menyangka Anda sampai menulis artikel tutorial mode Blueprint juga, terima kasih.
Ternyata dari awal Anda memang sudah sangat jago dalam pengembangan!
Ah, jadi Anda pernah melihat moderasi saya di komunitas lain.
Tulisan-tulisan yang saya buat memang masih banyak kekurangannya, tetapi saya akan senang jika bisa membantu.
Ah, menyebalkan.
Jika Anda memberi tahu bagian mana yang membuat Anda kesal, saya akan menjawab dengan ramah.
Silakan periksa bagian cara berkomentar di panduan penggunaan situs.
Mohon berbicara dengan ramah dan sopan.
Jika ada sanggahan, mohon tuliskan hanya isinya saja