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.
Perlu membandingkan kode sumber sebelum dan sesudah prapemrosesan.
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.
Vibe coding tidak menyelesaikan output akhir hanya dengan 1 prompt.
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.
Untuk membantu pemahaman semaksimal mungkin, saya memberikan contoh perbaikan kode dari kode buatan AI yang memiliki masalah struktural saat tidak ada instruksi khusus.
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,
ketika ada aturan instruksi pengarah struktur sebagai base context, ada kemungkinan total penggunaan token justru berkurang,
dan karena ada variabel berupa perolehan output akhir melalui n kali perintah prompt,
maka klaim bahwa penggunaan token dari 1 kali perintah prompt perbaikan struktur harus ditambahkan ke dalam perhitungan mengandung kekeliruan.
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,
Menyiapkan dua source code: source code yang akan ditanyakan ke AI, dan source code yang telah dipraproses(?) dengan prompt
Menjalankan kedua source code tersebut masing-masing 5 kali pada GPT5 dan Sonnet, lalu membandingkan jumlah token yang terpakai
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.
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.
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.
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.
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?
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
Kesimpulan
Menggunakan AI memang membantu menekan biaya
dengan meningkatkan produktivitas,
namun AI itu sendiri bukan sesuatu yang langsung menghasilkan uang.
API Web Codecs sendiri punya performa yang bagus, jadi library media web semuanya punya performa yang sangat baik. Agak meragukan kalau ini disebut pure TS.
Wah, sekarang bahkan Delphi dan C++Builder juga mulai punya komponen pengembangan AI.
Delphi terasa seperti kampung halaman di hati, jadi setiap kali ada kabar baru saya selalu membacanya.
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 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 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.
Memberi hadiah yang tidak berguna memang sedang populer.. sepertinya ini bagus untuk menemukan hadiah tidak berguna baru.
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.
Jika Anda perlu memanfaatkan informasi spasial, ini adalah pilihan yang bagus.
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…
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.
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?
lapisan berlapis
Saya penulisnya. Terima kasih atas masukannya. Akan saya jadikan referensi saat menulis artikel berikutnya.
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
Tiba-tiba semua titik hilang.
Kesimpulan
Menggunakan AI memang membantu menekan biaya
dengan meningkatkan produktivitas,
namun AI itu sendiri bukan sesuatu yang langsung menghasilkan uang.
Hal seperti nodejs cukup merepotkan kalau ingin di-binding ke aplikasi lain, jadi semoga bisa dibuat lebih mudah.
API Web Codecs sendiri punya performa yang bagus, jadi library media web semuanya punya performa yang sangat baik. Agak meragukan kalau ini disebut pure TS.
Melihat benchmark-nya, ternyata performanya cukup bagus juga.
Wah, sekarang bahkan Delphi dan C++Builder juga mulai punya komponen pengembangan AI.
Delphi terasa seperti kampung halaman di hati, jadi setiap kali ada kabar baru saya selalu membacanya.