Özet
- Kod yapısını (strateji·fabrika deseni, dosya ayrımı,
.cursorrulesdüzenlemesi) tek satırlık bir prompt ile refaktör ettikten sonra, aynı özellik ekleme promptu çalıştırıldığında yapay zeka token kullanımının büyük ölçüde azaldığını gösteren deney raporu (Zero-context, N=5). Deneyde kullanılan promptlar ve kaynaklar açıklandığı için yeniden üretilebilir.
Temel veriler
-
Claude-4 Sonnet: ortalama 390,159 → 242,265 token (−37.91%)
-
GPT-5: ortalama 315,839 → 233,634 token (−26.03%)
-
Ölçüt: Cursor’un gösterdiği Total Tokens. Modeller arası mutlak değer karşılaştırması anlamlı değil (modele göre sayım farkı var).
Kurulum (özet)
-
IDE Cursor 1.6.6, modeller GPT-5 / Claude-4 Sonnet
-
Tüm promptlar Zero-context, her turda editör tamamen yeniden başlatıldı
-
Başarı ölçütü: gereksinim tek bir prompt ile uygulanırsa başarılı sayıldı
Neden önemli
-
“İyi kod yapısı” yalnızca insanlar için daha okunaklı olmakla kalmıyor, yapay zekanın token, maliyet ve süre kullanımını da etkiliyor; buna dair nicel bir kanıt sunuyor
-
Promptların ve depo içeriğinin açık olması yeniden üretilebilirlik sağlıyor (iş ortamında uygulama ve takip deneylerinde doğrudan kullanılabilir)
Kişisel değerlendirme
- Bir Cursor kullanıcısı olarak, maliyet tasarrufu için temel bir metodoloji sunan harika bir yaklaşım önerdiğini düşünüyorum.
- Metinde de belirtildiği gibi, örneklem sayısının yetersiz olması biraz üzücü.
34 yorum
Başlık atma kursuna mı gittiniz..
Deneyi keyifle izledim.
Teşekkür ederim.
İçerikten bağımsız olarak, başlıktaki
tek satırlık promptifadesi nedeniyle bakmak istediği şeyle yazının içeriği farklı olduğu için daha da öyle geliyor sanırımEvet, ben de aynı düşünüyorum. hıçkırık
Üzgünüm;;
Bu yazıya gösterdiğiniz yoğun ilgi için teşekkür ederim. Görünüşe göre asıl amaç yurt dışına dağıtım olduğu için metin İngilizce yazılmıştı ve bu nedenle çeşitli sorunlar ortaya çıkıyor gibi duruyor.
Bu nedenle, Korece olarak düzenlenmiş gönderiyi paylaşıyorum.
https://modgo.org/tokeun-sayongryang-37-91-reul-gamsosikin-dan-hanjuly…
Ek olarak, kullanılan prompt ile ilgili içeriği özetleyeyim.
Her hâlükârda geliştiriciler, yapı iyileştirmeye yönelik prompt yazma konusunda daha avantajlıdır. Her programın doğası farklı olduğundan, yüksek verimli bir iyileştirme için belli ölçüde geliştirme bilgisi gerekir.
Bu, geliştirici olmayan vibe coder'ların bu yöntemi kullanamayacağı anlamına gelmez. Verimlilikte fark olsa da, "Proje kodunu biraz düzenle. Kullanılmayan kodları kaldır." gibi basit komutlarla bile yapay zeka dosyaları ve class'ları ayırıp düzenleme davranışı gösterir.
Ancak, yapı iyileştirmesindeki detay farklarının verimlilik farkı yaratabilen bir alan olduğu için, kaynakları referans alırken dikkatli olmak gerekir.
Prompta yalnızca temel noktaları mantıklı bir şekilde eklemek gerekir. Yani prompta şunu bunu ne kadar çok eklerseniz gürültü o kadar artar, ortaya çıkan kod da daha karmaşık ve daha gürültülü olur; söylenmek istenen bu mu?
Asıl nokta, yapay zekaya kod yapısını refactor etmesini söyledikten sonra tüketilen token miktarının azalmasıdır.
Tersinden bakarsak, kodda yapısal kusurlar varken komut vermeye devam edilirse token kullanımının arttığı şeklinde de açıklanabilir.
Özetle, kaynak kodun yapısının iyileştirilmesi gerektiği anlatılıyor; bunun anlamı, prompt’un yalnızca özünü mantıksal biçimde yazmak gerektiği değildir.
Bana da bu tanıtım yazısı ve orijinal metin fazlasıyla uzun ve sanki yazmayı pek beceremeyen biri yazmış gibi geldiği için okuması zordu,
ama özünde
"token’ları azaltmaya yönelik yapısal kısıtlar içeren tek satırlık bir talimat ekleyin"
demek mümkün.
Bu yazı, niteliği gereği daha çok bir 'deney' araştırmasına yakındır.
Bu nedenle, bu yazıda yer alan tüm sayılar, bu yazıyı okuyan herkesin 'yeniden üretim' yapabilmesine odaklanmıştır.
Buna göre, kullanılan özgün kaynak kodu ve testte kullanılan tüm prosedürlerin tamamı kaydedilerek,
her deneycinin aynı sonuçları elde edebilmesi için bilgi sunmaya içerik odaklanmıştır.
Yorumların genel havasına bakınca ve hissedince,
bundan sonra 3 satırlık özet eğiliminde bir yazı ile,
detayı öğrenmek isteyenler için olan yazıyı ayırıp iki ayrı metin olarak yazmam gerekip gerekmediğini de düşünüyorum.
Bu yazının hangi kısmının gereğinden fazla karmaşık hissettirdiğini ve hangi noktaların fazla uzun bulunduğunu paylaşırsanız,
bundan sonraki yazılarımı hazırlarken bana çok yardımcı olacaktır.
Ben de benzer şekilde hissettim.
Yazıyı yazan kişinin niyetini anlıyorum ancak yapılan şeye kıyasla metin gereğinden fazla karmaşık görünüyor.
Muhtemelen deneyde kullanılan detayları olabildiğince yazıya yedirmek istediği için bu şekilde yazmış,
ama sadece özü kısa biçimde ayıklasanız bile bu konuyla ilgilenenler büyük ihtimalle anlayacaktır.
Detayları cesurca budayıp sadece özü özetlerseniz daha iyi olmaz mı diye düşünüyorum.
Ben ise yazarın niyetini ve sonucun kendisini ilginç buldum.
Asıl argüman, daha iyi kaynak kodun daha az token tüketimine yol açtığı gibi görünüyor,
ve bununla ilgili bir deney tasarlayıp yürütmüş gibi duruyor.
Deney hakkında benim anladığım kısımları sıralarsam
gibi görünüyor.
Ve eğer doğru anladıysam, prompt ile ön işlenen kaynak kodun genel olarak daha az token tükettiği sonucuna varılmış gibi.
İlginç bir sonuç olsa da, deney hakkında benim görüşüm şöyle.
Adil bir karşılaştırma değil
Rakamlar düşmüş gibi görünse de, kaynak kodu işlemek için kullanılan toplam token sayısı üzerinden karşılaştırmak daha doğru olur gibi geliyor.
Yani ön işleme için kullanılan token sayısının da hesaba katılması gerekir.
Ön işleme için kullanılan token sayısı aşırı yüksekse aslında daha fazla token harcanmış olacağından anlamsız hale gelir; az olsa bile gerçek token tüketimi farkı yazıda göründüğünden belirgin şekilde daha düşük olabilir.
Ön işleme öncesi ve sonrası kaynak kodu karşılaştırmak gerekir.
Ön işleme için kullanılan tokenlar hariç tutulursa, sorgu sırasında token tüketiminin anlamlı biçimde azaldığı görülüyor.
Ancak kaynak koddaki tam olarak hangi farkın bu sonuca yol açtığını analiz edersek yazının değeri daha da artabilir.
Çünkü bu farkı en üst düzeye çıkarmak için ön işleme prompt'unu optimize etmek mümkün olabilir.
Yazar, bu sonucun kod yapısı refaktörizasyonundan kaynaklandığını söylüyor ama ben buna katılmıyorum; henüz bunu bilemeyiz diye düşünüyorum.
Çünkü AI'ye refaktörizasyon dışında başka şeyler iyileştirildiğinde de token tüketiminde azalma olabilir.
Daha çeşitli deneyler gerekli
Sadece mevcut kodla değil, başka kod tabanlarında da aynı deneyin yapılması gerektiğini düşünüyorum.
Bunun tutarlı biçimde iyi sonuç verip vermediğine karar vermek gerekir.
Ama bunun pratikte test etmesi zor bir şey olabileceğini anlıyorum; bu yüzden sadece bir not olarak değerlendirmeniz daha iyi olabilir.
Tamamen katılıyorum. Bu tür eleştirileri fazlasıyla memnuniyetle karşılıyorum.
Dünya tek başına yaşanmıyor ve her bireyin yetenekleri ya da koşulları farklıdır.
Ben de nihayetinde sıradan bir geliştiriciden ibaretim ve kişisel maliyet üstlenerek tüm testleri gerçekleştiremem.
Umarım bu yazı bir tohum olur; pek çok kişiye olumlu etki eder ve devamındaki pek çok araştırma için bir başlangıç noktası haline gelir.
Ara başlık içerikle tam uyuşmuyor. Yeniden düzenlenecek olursa, ara başlık olarak “token azalmasına yol açan daha net unsurların analiz edilmesi gerekiyor” daha uygun görünüyor.
Bu içeriğin birçok kısmına katılıyorum. Ancak bu yazının doğasında, “bu yazıyı okuyanlara gerçekçi uygulama yöntemleri önermek” gibi bir unsur da bulunuyor.
Zaten bu yazıya eklenen yorumlara bakınca bile genel havayı anlamak mümkün; ben de yakın zamanda fark ettim ama, yapay zeka kullanıcıları arasında geliştirici olmayan vibe coder'ların da oldukça fazla olduğu tahmin ediliyor.
Yapay zeka aracılığıyla değil de yazarın doğrudan düzenlediği kodla olağanüstü bir sonuç ortaya çıkarsa,
bu durum, yazarın geliştirme becerisini sergileyip yapay zeka yeteneğini küçümsüyormuş gibi algılanmaya oldukça açık olur.
Bu nedenle, diğer vibe coder'ların da kullanabileceği bir unsur olan “prompt” üzerinden, sonucu herkesin hissedebileceği bir örneği ele aldım.
Bu araştırmanın devamında, yapay zeka token kullanım miktarını etkileyen unsurların daha ayrıntılı biçimde sınıflandırılabildiği çalışmaların gelmesi iyi olur diye düşünüyorum.
Tek bir yapısal düzenleme sayesinde n kez kullanılacak promptların token tüketim oranını düşüren bir etki ortaya çıkarsa, token azalma miktarı aynı şekilde yürütülecek n kez boyunca yansıtılır.
n, projenin amacı, özellik sayısı ve bunun için gereken kod miktarı ile karmaşıklığı tarafından belirlenen bir değerdir ve,
ayrıca son dönemde cursor / claude code agent’larında sonsuz tekrar yürütme ya da yapay zekanın kontrolsüz token kullanımı sorununu çözmek için yürütme birimini küçük tutan güncellemeler geldiğinden,
proje karmaşıklığıyla ilgili n değeri araştırmasının ayrıca yapılmasının doğru olduğunu düşünüyorum.
Burada gözden kaçırılmaması gereken nokta, yapının iyileştirilmesinin kod geliştirmeden mutlak biçimde bağımsız gerçekleşen bir eylem olmadığıdır.
İlk prompt ya da AI ruleset(.cursorrules) gibi kısıtlar üzerinden base context olarak etkide bulunabilecek bir kısımdır ve,
proje geliştirme döngüsü sırasında tek bir yapısal iyileştirmenin her şeyi yoluna koyması mümkün değildir.
Yani belirli periyotlarla kod iyileştirmesi planlamaktansa, base context olarak doğru yapısal yönlendirme daha iyi bir yaklaşımdır.
Ayrıca, base context olarak yapısal yönlendirme talimat kurallarının olduğu durum ile olmadığı duruma ilişkin araştırmanın da ayrıca yapılması doğru görünüyor.
tek seferlik yapısal iyileştirme prompt komutunun token kullanımını ekleyerek hesaplamak gerektiği yönündeki iddia isabetsizdir.
Yorumda ne demek istediğinizi tam anlayamadım. Benim yorumum, iki yöntemi adil biçimde karşılaştırmak için harcanan toplam token sayısını karşılaştırmak gerekmez mi, şeklindeydi. Refactoring de token tüketmiyor mu?
Ayrıca verdiğiniz ek yanıtın yazıda yer almadığını ve deneylerde de ele alınmamış bir içerik olduğunu düşünüyorum. Sanırım söylemek istediğiniz şey, sorgu başına token karşılaştırması değil; birden çok sorguda refactoring overhead'inin azalacağı ve sorgu başına beklenen token sayısı düştüğü için toplam token sayısında avantaj oluşacağı. Ama bu, ancak çoklu sorgularda yazarın düşündüğü gibi maliyet düşüşü korunursa söylenebilecek bir şey gibi görünüyor; yani oldukça ideal bir durumu varsayıyor. Refactoring kaynaklı maliyet düşüşünün sonraki sorgu sayısından bağımsız olarak korunacağını garanti edemeyiz; deney olmadan da bunu varsayamayız. Eğer kastedilen argüman buysa, tek seferden fazla sorgu için maliyet düşüşünü deneyle göstermeniz gerekir gibi geliyor. Ama deney yalnızca bir kez yapılıp karşılaştırma da onunla mı yapıldı?
Ek olarak, bu sadece benim varsayımım ama aynı hedefe (ideal nihai çıktı) ulaşmak için sorgular sonsuza kadar tekrar edilirse, ideal durumda refactoring olsun ya da olmasın kodun aynı biçime yakınsaması gerekir gibi duruyor. (İdeal nihai çıktı tektir.)
Eğer bu makul bir varsayımsa, sorgular tekrarlandıkça refactoring olup olmamasının farkı azalacağı için token maliyet düşüşünden elde edilen kazanç da giderek azalacaktır. Bu yüzden makro ölçekte bakınca, bu maliyet düşüşünün faydası yeterince kalıcı değilse, sorgularda kullanılan toplam token sayısı farkı anlamlı olmayabilir, değil mi?
Ayrıca, prompt zincirleme sayısıyla ilgili deneyi de sormuştunuz.
Aslında bu, tersine, yazarın kaba tabirle kolayca hile yapmasına elverişli bir unsurdur.
Geliştirme denen eylemin kendisinde, izlenecek yönde son derece çok seçenek vardır; token kullanımını daha fazla açacak yönde promptları biriktirirseniz, o sayı kartopu gibi daha da büyür.
Araştırmada
Cumulative Sciencediye bir felsefe vardır.En azından benim ölçütlerime göre, tek seferlik komutta token kullanımıyla ilgili bir araştırmaya şimdiye kadar hiç rastlamadığım için,
hemen N kezlik bir araştırma yapmak yerine, net bir tek seferlik teste ve onun sonucuna odaklandım,
N kezlik araştırma ise bu deneyin ardından çalışmalar sürerse devam edebilir.
Ayrıca, başka bir yazıda kod tabanındaki farklılıklara göre yapay zekanın davranış farklarını ele almıştım.
(Bu da daha önce GeekNews'te tanıtılmıştı: https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/)
Kısaca açıklamak gerekirse, yapay zekaya verilen kod tabanına göre çıktının kalitesinin değiştiğini gösteren testler ve sonuçlar ele alınıyor.
Başlangıçtaki kod tabanının kalitesi ve yönüne bağlı olarak, sonrasında gelen kod kalitesi korunabilir de sürekli kötüleşebilir de.
Yani projenin ilk aşamasındaki refactoring maliyeti ile epey ilerlemiş bir projenin refactoring maliyeti büyük ölçüde farklı olabilir.
Eğer soruyu soran kişi bir geliştiriciyse, muhtemelen 'yelkenli üstündeki uçak gemisi' ifadesini en az bir kez duymuştur,
refactoring'in hangi noktada yapılması gerektiği ya da projenin başında yerleşen yaklaşım ve tasarıma göre maliyetin inanılmaz derecede değişebildiği oldukça derin bir konudur.
Bunu da bir değişken olarak dahil edip sonucu belirsiz hale getirmek yerine,
'en azından kod tabanı kalitesi iyiyse token kullanımının azaldığını' net biçimde açıklayabilen bir test yapılmış oldu.
Tekrar açıklamayı deneyeyim.
Vibe coding yapanların yelpazesi geliştirici olmayanlardan deneyimli geliştiricilere kadar oldukça geniştir. Sahip oldukları bilgi düzeyine göre, bu yazının içeriğinden tamamen bağımsız olarak ortaya çıkan çıktının kalitesi büyük farklılık gösterebilir.
Birileri doğal olarak cursor kullanımını temel alıp
.cursorrulesiçine temel OOP kurallarıyla sınıf/metot ayırma kurallarını koyarak neredeyse hiç refactoring gerektirmeyen bir yapıda çalışıyor olabilir,birilerinde ise en temel ana noktaları kavrayamama nedeniyle düşük seviyeli kodun sürekli üretiliyor olması söz konusu olabilir.
Hatta temelde proje kuralları ayarlayarak kod kalitesini iyi tutmanız gerektiğini anlatan yazı ve deneyim örnekleri daha önce de çokça vardı.
Bu, bazı kişilerin açık bir refactoring yapmadan da token kullanımı açısından kazanç sağlıyor olabileceğine işaret eder.
Ancak yukarıdaki örneklerde, ilgili kural tanımları üzerinden yürütme başına token kullanımında ne kadar net bir azalma olduğu düzenli biçimde ortaya konmuyor. Bu nedenle bu yazıda, kod tabanı kalitesine göre token kullanımı farkını test edip sonuçları derledim.
Yani kullanıcıya bağlı olarak, açık refactoring sayısı başlı başına yeniden 0~n kez arasında değişen bir değişken hâline gelir,
Bu yazının özündeki niyetin, "Neden iyi kalitede bir codebase'e dikkat etmek faydalıdır?" sorusunu açıklamak olduğunu düşünmek daha doğru olur.
Yazarıyım. Geri bildiriminiz için teşekkür ederim. Bir sonraki yazıyı hazırlarken bunu dikkate alacağım.
Bu prompt'u birlikte ekleyince maliyetin düştüğü mü söyleniyor? Özeti doğru anladığımdan pek emin değilim.
Ek olarak belirtmek gerekirse, kodun yapısı ilgili projeye uygun bir modele göre yeniden düzenlenmelidir. Aşağıdaki yanıtta olduğu gibi, yapısal iyileştirme konusunda yapay zekaya soru sorarsanız, o proje için uygun yapısal iyileştirme yöntemlerini size söyler.
Benim kişisel olarak önerdiğim yöntem, yapay zekaya doğrudan yapı iyileştirme komutu vermek yerine önce ondan öneri istemektir; bu şekilde bir yanıt verir ve sohbet ederek yeterince verimli bir öneriye ulaştıktan sonra bunu uygulamasını istemeniz iyi olur.
Ek bir ipucu olarak, mümkünse context summarization (bağlam arabelleğinin sıfırlanması) gerçekleşmeden önce işi tamamlamak daha iyidir; bağlam arabelleğinin sıfırlanması kaçınılmazsa, önceden
.cursorrulesiçine iyileştirme kuralları eklemesini istemek faydalı olur. Çalışma sırasında bağlam sıfırlanırsa yapay zekanın hata yapma olasılığı yükselir.Ben bunu bizzat bu şekilde test etmedim ama,
'Önce mevcut kodu analiz et, ardından senin yönetmesi kolay olacak bir yapıya göre yeniden düzenle'
şeklindeki prompt da işe yarayabilir diye düşünüyorum.
Tam olarak verilmek istenen nokta şu gibi görünüyor: Yapay zekaya yalnızca işlevsel gereksinimleri aktarmak değil, aynı zamanda uygun ve doğru bir yapıyı iyi yönlendirmek de maliyeti azaltmaya yardımcı olabilir.
Referans olarak, girilen kaynak boyutu küçüldükçe tüketilen token miktarının azaldığı iyi bilinen, açık bir gerçektir. Zaten
.cursorignoredosyası da bunun için oluşturuldu.Genel olarak yapay zekaya yapısal iyileştirme yaptırdığınızda, çoğu durumda kaynak kod miktarı azalma eğilimi gösterir; bu yüzden hangi nedenle olursa olsun düzenleme yaptırmanın maliyeti düşürdüğünü söylemek inandırıcı bir iddia gibi görünüyor.
Bu yazıya eklenen iddia ise, iyi bir yapı yönlendirmesiyle ek token kullanımında da azalma sağlanabileceği yönünde.
Doğru. Metinde de belirtildiği gibi, kod iyileştirmesinden sonra proje kodunun boyutunun küçüldüğü bir gerçek.
Ancak bu örnekte karakter sayısı bazında yaklaşık %10’luk bir azalma oldu; yalnızca bununla token kullanımındaki %37,91’lik düşüşü açıklamak mümkün değil.
Metinde kaynak depo bağlantısı yer alıyor ve isteyen herkes bunu yeniden üretip test edebilir.
https://modgo.org/dib-rag-gaelreogtig-modeu-seuteurimeoreul-wihan-ciji…
Bu DeepRAG gaelle modu doğrudan siz mi yaptınız?
Bunu da vibe coding ile mi yaptınız?
Merhaba. Blogun sahibiyim.
DeepRAGGal modu gerçekten doğrudan benim tarafımdan yapıldı ve şu anda kişisel bir sunucu üzerinden hizmet veriyor. (Chzzk OAuth kimlik doğrulaması nedeniyle bu gerekli.)
Bu mod, Unreal Engine üzerinden geliştirmeyi de içeriyor ancak ne yazık ki Unreal Engine tarafında vibe coding yapmak zor.
Bunun yerine, mod geliştirme yöntemi başlı başına zor olmadığı için ilgileniyorsanız mod geliştirme rehberi (https://modgo.org/dib-rag-gaelreogtig-modeu-gaebal-part-1/) üzerinden kolayca öğrenebilirsiniz.
Başka bir toplulukta modu paylaştığınızı görmüştüm; gerçekten de o modu yapan kişinin yazdığı bir yazıymış.
Blueprint modu hakkında bir rehber yazısı da yazmış olduğunuzu bilmiyordum, teşekkürler.
Zaten baştan beri geliştirme konusunda çok iyiymişsiniz!
Ah, demek başka bir toplulukta benim modumu görmüştünüz.
Yazdığım gönderilerde eksik kalan çok yer var ama yine de yardımcı olabiliyorsam ne mutlu bana.
Ah, ne sinir bozucu
Hangi kısmın canınızı sıktığını söylerseniz memnuniyetle yanıt veririm.
Site kullanım kuralları içindeki yorum yazma bölümünü lütfen kontrol edin.
Lütfen nazik ve ölçülü bir şekilde konuşun.
Bir itirazınız varsa yalnızca o içeriği yazın