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?
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.
Ön işleme öncesi ve sonrası kaynak kodunu karşılaştırmak gerekiyor.
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.
Vibe coding’de çıktı tek bir prompt ile tamamlanmaz.
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.
Anlaşılmayı mümkün olduğunca kolaylaştırmak için, ayrıca bir talimat yoksa AI’ın yazdığı yapısal sorunlar içeren koddan hareketle bir kod iyileştirme örneği verdim.
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.
maddeyi özetlersek,
base context olarak yapısal yönlendirme talimat kuralları olduğunda toplam token kullanımının azalması ihtimali de vardır ve,
n kez verilen prompt komutları üzerinden nihai çıktının elde edilmesi gibi bir değişken bulunduğundan,
tek seferlik yapısal iyileştirme prompt komutunun token kullanımını ekleyerek hesaplamak gerektiği yönündeki iddia isabetsizdir.
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
AI'ye sorulacak kaynak kod ile, bu kaynak kodun prompt ile ön işlenmiş(?) hali olmak üzere iki kaynak kod hazırlanmış
GPT5 ve Sonnet'te bu iki kaynak kod ayrı ayrı 5'er kez çalıştırılarak token tüketimleri karşılaştırılmış
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.
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.
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.
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.
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?
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.
Web Codecs API'nin kendisi zaten yüksek performans sunduğu için, web medya kütüphanelerinin neredeyse hepsi performans açısından çok güçlü. Buna tamamen saf TS demek ise biraz tartışmalı.
Vay be, artık Delphi ve C++Builder'a da yapay zeka geliştirme bileşenleri giriyor demek.
Delphi sanki insanın manevi memleketi gibi; her yeni haber çıktığında dönüp bakıyorum.
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?
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.
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.
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.
İşe yaramaz hediye vermek popülermiş gibi görünüyor.. yeni işe yaramaz hediyeler keşfetmek için güzel olabilir
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.
Mekânsal bilgileri kullanmanız gereken bir işiniz varsa, bu iyi bir seçimdir.
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…
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.
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?
Gereksizin de gereksizi
Yazarıyım. Geri bildiriminiz için teşekkür ederim. Bir sonraki yazıyı hazırlarken bunu dikkate alacağım.
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.
Bir anda bütün noktalar kayboldu
nodejs gibi şeyleri başka uygulamalara bağlamak isteyince iş oldukça can sıkıcı hale geliyor; keşke biraz daha kolay olsa.
Web Codecs API'nin kendisi zaten yüksek performans sunduğu için, web medya kütüphanelerinin neredeyse hepsi performans açısından çok güçlü. Buna tamamen saf TS demek ise biraz tartışmalı.
Benchmarklara bakınca ilginç şekilde performansının kötü olmadığı görülüyor.
Vay be, artık Delphi ve C++Builder'a da yapay zeka geliştirme bileşenleri giriyor demek.
Delphi sanki insanın manevi memleketi gibi; her yeni haber çıktığında dönüp bakıyorum.