Sadece böyle zamanlarda aynı fikirde oluyorlar.
Adında “Open” kelimesini taşımasına rağmen utanmazca davranan OpenAI da,
OpenAI değişti diyerek ayrılıp giden Anthropic de...
Bunu para yüzünden mi yapıyorlar, yoksa yapay zekayı bir hegemonya mücadelesi olarak görüp hükümetin devreye girerek yöneticileri istediği gibi oynatması mı söz konusu?
madde (ajanlar arasında sorumlulukların ayrılması) bence en zor kısım. Herkese açık benchmark trace’lerine biraz bakmıştım; orada gördüğüm bir deseni paylaşayım.
En sık görülen şey “yanlış karar”dan ziyade aynı işin iki kez çalıştırılmasıydı. Aynı argümanlarla e-posta gönderiminin tekrarlanması ya da aynı dosyanın yeniden yazılması gibi. Özellikle timeout sonrası retry aralıklarında sık çıkıyordu; ilk çağrı sadece yavaştı ama başarısız sayılıp yeniden çağrılıyordu.
Bunu izlemenin zor olmasının nedeni, hata oluşmaması. İki çağrı da 200 dönüyor, loglar da temiz; bu yüzden sonradan sadece loglara bakınca görünmüyor.
Bizim kullandığımız yöntem, (araç, normalize edilmiş argümanlar, çıktı hash’i) şeklinde gruplayıp aynı kombinasyonun tekrarlanıp tekrarlanmadığını mekanik olarak saymak. LLM değerlendirmesi olmadan, sadece hesaplamayla yapılabildiği için yeniden üretilebilir. Ancak sınırı net: yalnızca “iki kez çağrıldı” bilgisini verir; “gerçekten iki kez çalıştı mı” trace’ten tek başına doğrulanamaz. Yanıtta entity ID veren araçlarda (doküman oluşturma API’si gibi) ID’leri karşılaştırarak doğrulamak mümkün; ama e-posta gibi yalnızca “gönderim başarılı” döndüren araçlarda bir yol yok.
maddede bahsettiğiniz “hız için öylece geçirivermek” kısmına da katılıyorum. Biz de gerçek zamanlı engellemeyi değerlendirdik, ancak çalıştırmadan önce sonucu göremediğiniz için yalnızca argümanlara bakarak karar vermek gerekiyor ve bunun doğruluğu düşüktü. Normal retry’ları bile engellediği durumlar olduğu için vazgeçtik.
Hata düzeltmeleri de artık çok ucuzladı ve yazılım güncelleme maliyeti de neredeyse sıfıra yaklaşıyor; ayrıca finans sektörü düzeyinde değilse çoğu durumda hatalar sonradan düzeltilip geçiliyor...
Ama bu tür bir algı biriktikçe, sonuçta büyük bir kazanın yaşanması kaçınılmaz olur herhalde
Kullanırken geri atlamanın boşa düştüğü konuşmalar ya da “bu biraz rahatsız edici” dediğiniz kısımlar olursa lütfen rahatça yorum bırakın. Her sitenin konuşma yapısı farklı olduğu için gerçek kullanım örnekleri en çok yardımcı oluyor. Sırada Perplexity desteği ve Notion/Obsidian’a dışa aktarmaya bakıyorum; daha acil bir şey varsa önce onu yapmayı düşünüyorum haha
Teşekkürler. Deneyip jumpback’in yakalamadığı bir konuşma olursa lütfen rahatça haber verin~
Ben de kullanıp deniyorum ama gerçek kullanıcıların yaşadığı rahatsızlıkları da birlikte duyabilirsem iyi olur gibi, haha
Ajanın her düzeltme yaptığında diff günlüklerini izleyip, shotgun surgery ya da büyük çaplı değişikliklere yol açıyorsa bunu yazılım mühendisliği açısından bir code smell olarak görerek pekiştirmeli öğrenme yapılabilir gibi de geliyor...
[Okuması zor olabilir diye README’nin Türkçe çevirisini ekledim!]
Clew
Ajan izlerinde boşa harcanan işleri bulan deterministik bir dedektör.
Clew, tamamlanmış yapay zeka ajanı çalıştırma izlerini okuyarak, zaten yapılmış işleri tekrarlayan adımları — aynı aracı aynı argümanlarla yeniden çağırma, başarısız bir çağrıyı aynı argümanlarla yeniden deneme, zaten bağlamda bulunan bilgiyi tekrar sorgulama — bulur. LLM kararı olmadan çalıştığı için, aynı izi verdiğinizde her zaman aynı sonucu üretir.
estimated cost impact: $0.026340 ~ $0.263400 (cache-hit to cache-miss)
Bu neden önemli?
Yapay zeka kodlama ajanı oturumlarında israf yalnızca faturada ortaya çıkar. Tüm araç çağrıları 200 döndürdüğü ve hiçbir şey hata vermediği için israf gözle görülmez. Ancak izlerin içinde ajan aynı dosyayı iki kez okur, başarısız bir çağrıyı aynı argümanlarla yeniden dener, aynı aracı aynı payload ile tekrar çağırır.
Kodlama ajanı oturumlarında okuma (read) işlemleri token’ların %65~90’ını oluşturduğu için bu tür israf fark edilmeden birikir. Gözlemlenebilirlik araçları izleri gösterir, ancak hangi adımın tekrar olduğunu söylemez.
Neyi tespit eder?
Clew üç tür tekrar kalıbını bulur:
repeat — aynı araç/düğüm tekrar tekrar çağrılır
requery — aynı araç aynı girdiyle yeniden çağrılır (çıktı aynı)
pingpong — iki ajan özünde aynı içeriği birbirine gönderip alır (çoklu ajan)
Her bulgu dört sınıfa ayrılır:
error_repeat — çıktı hata olduğu halde aynı çağrının tekrarlanması
side_effect — durumu değiştiren bir aracın (gönderme/yazma/oluşturma vb.) yeniden çalıştırılması
idempotent — salt okunur/deklaratif bir aracın tekrarlanması (yan etki yok, token tüketir)
unclassified — eşlemede bulunmayan araç. Etki payload’a bağlı olduğu için yalnızca araç adından çıkarım yapılmaz (Bash/PowerShell vb.)
[Nasıl çalışır]
2 aşamalı bir kaskattır:
Yapısal kapı — aynı aracı aynı (normalleştirilmiş) argümanlarla çağıranları gruplar
Özdeşlik kapısı — çıktının sha256 değerinin tamamen aynı olup olmadığını kontrol eder. Farklıysa durum değişmiş demektir, bu yüzden işaretlenmez
Ucuz yapısal kontrol önce adayları eler; pahalı anlamsal kontrol (embedding+cosine) yalnızca gerektiğinde çalışır. LLM kararı olmadığı için sonuç deterministiktir — CI’a koymak istiyorsanız bu önemlidir.
[Girdi biçimi]
Claude Code — oturum JSONL dosyasını doğrudan analiz eder
LangGraph — izlerde zincir tekrarlarını tespit eder
LangChain·CrewAI·AutoGen·LlamaIndex vb. — OpenTelemetry/OpenInference standart biçiminde enstrümante edilmiş izleri ayrıştırır (biçim desteği var; framework bazında gerçek ölçüm doğrulaması sürüyor)
Herkese açık benchmark izleri (Toolathlon, RedundancyBench)
Cursor ve Codex oturumları henüz desteklenmiyor — yerel formatları inceleniyor.
[Doğrulama sonuçları]
Herkese açık benchmark (Toolathlon, 6.780 iz, 176.270 araç span’i):
8.042 tekrar çağrısı tespit edildi. Bunların %47’si gri alan (idempotent işlemler, tamamlandı beyanları); bunlar çıkarıldığında 4.251 vaka kalıyor (araç span’lerine göre %2,41). Claude Code oturumlarına (%0,80) kıyasla yaklaşık 3 kat.
Durum değiştiren araçların 1.343 tekrar çalıştırılması; buna aynı argümanlarla tekrarlanan 459 e-posta gönderimi dahil. Ancak bu, aynı aracın aynı argümanlarla tekrar çağrıldığının tespitidir; gerçekte yan etkinin gerçekleşip gerçekleşmediği doğrulanmamıştır.
Etiketleme benchmark’ı (RedundancyBench):
precision 0.826 (dosya içi tekrarlar için alt sınır tahmini). RB etiketlerinin önemli bir kısmı dosyalar arası (cross-file) tekrarlardır ve oturum bazlı analiz tasarımının kapsamı dışındadır. recall 0.157 ile düşüktür.
[Dürüstlük sınırları]
Ölçülmüş tasarruf örneği henüz yok. Tespit edip tahmin edebilir, ancak gerçek bir kullanıcının bir şeyi düzeltip faturanın gerçekten azaldığını gösteren before/after verisi 0 vakadır.
Benchmark’ta işaretlenenlerin %47’si gri alandır (idempotent yeniden çalıştırma). Filtrelemiyoruz, yalnızca sınıflandırıyoruz — salt okunur yeniden çalıştırmanın israf olup olmadığı görünmeyen bağlama bağlıdır.
sha256 tam eşleşmesi gerektiğinden çıktı azıcık bile farklıysa işaretlenmez. Recall’ın düşük olmasının nedeni budur; tasarım hassasiyet tarafında durur.
Claude Code olağanüstü iyi optimize edilmiştir. Gerçek CC oturumlarında altı aday israf kalıbı ölçtük; beşi orada yoktu. İlginç israf CC’nin kendisinde değil, çok araçlı MCP ortamında ortaya çıktı.
Maliyet tahmini (amplification) ölçüm değil tahmindir ve yalnızca Claude Code formatında mümkündür.
Doğrulanmayanı atarız
Dosya yeniden okuma dedektörü yaptık, ancak 30 vakalık örnekte insan notlandırmasında precision ön kayıt eşiğinin (%70) çok altında kaldığı için (iyimser bakışla %3,3, sıkı bakışla %0) iptal ettik. Tahminler ve sonuçlar ön kayıt belgesinde birlikte bırakıldı.
Yazar güncellemesi. Metinde tek satırla değindiğim MCP sunucusu kısmını ayrıca derlediğim bir yazı yayımladım — ajanın migration yazarken kolon adlarını kafasına göre koyması sorununu, fiziksel adı "girdi" ile vermek yerine sözlük tabanlı "hesaplama"ya çevirerek çözen bir yapı: https://sqemo.com/blog/erd-mcp-server
(Şimdilik yalnızca stdio yerel kullanımını destekliyor, bu yüzden uzak MCP desteklenmiyor; uygulamanın ana gövdesi kapalı kaynak, yalnızca MCP sunucusu açık).
Kayıt olmadan hemen deneyebilirsiniz (app.sqemo.com); takıldığınız bir nokta olursa yorum bırakın — daha başlangıç aşamasında olduğu için geri bildirimler hemen yansıtılıyor.
İlk yazıdan sonra Repolis'i basit bir 3D repo tarayıcısından, yeniden ziyaret etmek için bir neden sunan küçük bir kasaba yönünde genişletmeyi sürdürdüm.
GitHub traffic ve herkese açık repo bilgileri her gün binalara ve gece ışıklandırmasına yansıtılıyor.
8 sakini ve her birine ait evi olan Starlight Row'u, gündüz/gece yaşam rutinlerini ve sakinlerin kısa yürüyüşleriyle etkileşimlerini ekledim.
Explorer Passport, Village Chronicle ve Town Gazette ile ziyaret kayıtlarını ve yeni repo, release, push ve metrik değişimlerini art arda görebilirsiniz.
threejs-sculpt-dna Copilot plugin ile oluşturulan procedural World Tree'yi gerçek Repolis şehrine yerleştirdim.
Temel yapı hâlâ backend ve anahtar gerektirmeyen zero-build static app; yalnızca grounded AI taxi/scholar özellikleri isteğe bağlı.
Yeni bir yazı oluşturmak yerine, sonraki değişiklikleri de bu orijinal yazının yorumlarında kaydetmeye devam edeceğim.
Bugünlerde teknik borçtan değil, bilişsel borçtan söz ediliyor.
Bazen iş arkadaşlarımla konuşurken, kendi yaptıkları şeyin bile nasıl çalıştığını tam olarak anlamadıklarını gördüğümde biraz ürperiyorum.
Zaman geçtikçe kimsenin nasıl çalıştığını anlamadığı bir hale gelecek gibi; ama yapay zekaya analiz ettirip sorabileceğimiz için belki de sorun değildir diye de düşünüyorum.
Sadece böyle zamanlarda aynı fikirde oluyorlar.
Adında “Open” kelimesini taşımasına rağmen utanmazca davranan OpenAI da,
OpenAI değişti diyerek ayrılıp giden Anthropic de...
Bunu para yüzünden mi yapıyorlar, yoksa yapay zekayı bir hegemonya mücadelesi olarak görüp hükümetin devreye girerek yöneticileri istediği gibi oynatması mı söz konusu?
Iyy...
Eğitim satmak en yüksek maliyet-etkinliğe sahip olanı. Sorumluluk yok, sadece ücret tahsilatı var. Yapay zeka da bu ticaretin büyük payını alacak.
Birkaç yıl önce görmüş gibiyim
Öncelikle orijinal siteye gidince, görsellerle açıklandığı için sezgisel olarak anlaması kolay.
Yürüyüş yapmak ya da kitap okumak gibi çevrimdışı etkinlikleri artırırsanız iyi gelir. Haha
En sık görülen şey “yanlış karar”dan ziyade aynı işin iki kez çalıştırılmasıydı. Aynı argümanlarla e-posta gönderiminin tekrarlanması ya da aynı dosyanın yeniden yazılması gibi. Özellikle timeout sonrası retry aralıklarında sık çıkıyordu; ilk çağrı sadece yavaştı ama başarısız sayılıp yeniden çağrılıyordu.
Bunu izlemenin zor olmasının nedeni, hata oluşmaması. İki çağrı da 200 dönüyor, loglar da temiz; bu yüzden sonradan sadece loglara bakınca görünmüyor.
Bizim kullandığımız yöntem, (araç, normalize edilmiş argümanlar, çıktı hash’i) şeklinde gruplayıp aynı kombinasyonun tekrarlanıp tekrarlanmadığını mekanik olarak saymak. LLM değerlendirmesi olmadan, sadece hesaplamayla yapılabildiği için yeniden üretilebilir. Ancak sınırı net: yalnızca “iki kez çağrıldı” bilgisini verir; “gerçekten iki kez çalıştı mı” trace’ten tek başına doğrulanamaz. Yanıtta entity ID veren araçlarda (doküman oluşturma API’si gibi) ID’leri karşılaştırarak doğrulamak mümkün; ama e-posta gibi yalnızca “gönderim başarılı” döndüren araçlarda bir yol yok.
Hata düzeltmeleri de artık çok ucuzladı ve yazılım güncelleme maliyeti de neredeyse sıfıra yaklaşıyor; ayrıca finans sektörü düzeyinde değilse çoğu durumda hatalar sonradan düzeltilip geçiliyor...
Ama bu tür bir algı biriktikçe, sonuçta büyük bir kazanın yaşanması kaçınılmaz olur herhalde
Kullanırken geri atlamanın boşa düştüğü konuşmalar ya da “bu biraz rahatsız edici” dediğiniz kısımlar olursa lütfen rahatça yorum bırakın. Her sitenin konuşma yapısı farklı olduğu için gerçek kullanım örnekleri en çok yardımcı oluyor. Sırada Perplexity desteği ve Notion/Obsidian’a dışa aktarmaya bakıyorum; daha acil bir şey varsa önce onu yapmayı düşünüyorum haha
Teşekkürler. Deneyip jumpback’in yakalamadığı bir konuşma olursa lütfen rahatça haber verin~
Ben de kullanıp deniyorum ama gerçek kullanıcıların yaşadığı rahatsızlıkları da birlikte duyabilirsem iyi olur gibi, haha
Ajanın her düzeltme yaptığında diff günlüklerini izleyip, shotgun surgery ya da büyük çaplı değişikliklere yol açıyorsa bunu yazılım mühendisliği açısından bir code smell olarak görerek pekiştirmeli öğrenme yapılabilir gibi de geliyor...
[Okuması zor olabilir diye README’nin Türkçe çevirisini ekledim!]
Clew
Ajan izlerinde boşa harcanan işleri bulan deterministik bir dedektör.
Clew, tamamlanmış yapay zeka ajanı çalıştırma izlerini okuyarak, zaten yapılmış işleri tekrarlayan adımları — aynı aracı aynı argümanlarla yeniden çağırma, başarısız bir çağrıyı aynı argümanlarla yeniden deneme, zaten bağlamda bulunan bilgiyi tekrar sorgulama — bulur. LLM kararı olmadan çalıştığı için, aynı izi verdiğinizde her zaman aynı sonucu üretir.
pip install "clew-custos[detect]"
python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md
Herkese açık bir Claude Code oturumunda çalıştırılmış gerçek çıktı örneği:
Result: WASTE DETECTED
1. requery — Read on
.../boot.tsBu neden önemli?
Yapay zeka kodlama ajanı oturumlarında israf yalnızca faturada ortaya çıkar. Tüm araç çağrıları 200 döndürdüğü ve hiçbir şey hata vermediği için israf gözle görülmez. Ancak izlerin içinde ajan aynı dosyayı iki kez okur, başarısız bir çağrıyı aynı argümanlarla yeniden dener, aynı aracı aynı payload ile tekrar çağırır.
Kodlama ajanı oturumlarında okuma (read) işlemleri token’ların %65~90’ını oluşturduğu için bu tür israf fark edilmeden birikir. Gözlemlenebilirlik araçları izleri gösterir, ancak hangi adımın tekrar olduğunu söylemez.
Neyi tespit eder?
Clew üç tür tekrar kalıbını bulur:
repeat — aynı araç/düğüm tekrar tekrar çağrılır
requery — aynı araç aynı girdiyle yeniden çağrılır (çıktı aynı)
pingpong — iki ajan özünde aynı içeriği birbirine gönderip alır (çoklu ajan)
Her bulgu dört sınıfa ayrılır:
error_repeat — çıktı hata olduğu halde aynı çağrının tekrarlanması
side_effect — durumu değiştiren bir aracın (gönderme/yazma/oluşturma vb.) yeniden çalıştırılması
idempotent — salt okunur/deklaratif bir aracın tekrarlanması (yan etki yok, token tüketir)
unclassified — eşlemede bulunmayan araç. Etki payload’a bağlı olduğu için yalnızca araç adından çıkarım yapılmaz (Bash/PowerShell vb.)
[Nasıl çalışır]
2 aşamalı bir kaskattır:
Yapısal kapı — aynı aracı aynı (normalleştirilmiş) argümanlarla çağıranları gruplar
Özdeşlik kapısı — çıktının sha256 değerinin tamamen aynı olup olmadığını kontrol eder. Farklıysa durum değişmiş demektir, bu yüzden işaretlenmez
Ucuz yapısal kontrol önce adayları eler; pahalı anlamsal kontrol (embedding+cosine) yalnızca gerektiğinde çalışır. LLM kararı olmadığı için sonuç deterministiktir — CI’a koymak istiyorsanız bu önemlidir.
[Girdi biçimi]
Claude Code — oturum JSONL dosyasını doğrudan analiz eder
LangGraph — izlerde zincir tekrarlarını tespit eder
LangChain·CrewAI·AutoGen·LlamaIndex vb. — OpenTelemetry/OpenInference standart biçiminde enstrümante edilmiş izleri ayrıştırır (biçim desteği var; framework bazında gerçek ölçüm doğrulaması sürüyor)
Herkese açık benchmark izleri (Toolathlon, RedundancyBench)
Cursor ve Codex oturumları henüz desteklenmiyor — yerel formatları inceleniyor.
[Doğrulama sonuçları]
Herkese açık benchmark (Toolathlon, 6.780 iz, 176.270 araç span’i):
8.042 tekrar çağrısı tespit edildi. Bunların %47’si gri alan (idempotent işlemler, tamamlandı beyanları); bunlar çıkarıldığında 4.251 vaka kalıyor (araç span’lerine göre %2,41). Claude Code oturumlarına (%0,80) kıyasla yaklaşık 3 kat.
Durum değiştiren araçların 1.343 tekrar çalıştırılması; buna aynı argümanlarla tekrarlanan 459 e-posta gönderimi dahil. Ancak bu, aynı aracın aynı argümanlarla tekrar çağrıldığının tespitidir; gerçekte yan etkinin gerçekleşip gerçekleşmediği doğrulanmamıştır.
Etiketleme benchmark’ı (RedundancyBench):
precision 0.826 (dosya içi tekrarlar için alt sınır tahmini). RB etiketlerinin önemli bir kısmı dosyalar arası (cross-file) tekrarlardır ve oturum bazlı analiz tasarımının kapsamı dışındadır. recall 0.157 ile düşüktür.
[Dürüstlük sınırları]
Ölçülmüş tasarruf örneği henüz yok. Tespit edip tahmin edebilir, ancak gerçek bir kullanıcının bir şeyi düzeltip faturanın gerçekten azaldığını gösteren before/after verisi 0 vakadır.
Benchmark’ta işaretlenenlerin %47’si gri alandır (idempotent yeniden çalıştırma). Filtrelemiyoruz, yalnızca sınıflandırıyoruz — salt okunur yeniden çalıştırmanın israf olup olmadığı görünmeyen bağlama bağlıdır.
sha256 tam eşleşmesi gerektiğinden çıktı azıcık bile farklıysa işaretlenmez. Recall’ın düşük olmasının nedeni budur; tasarım hassasiyet tarafında durur.
Claude Code olağanüstü iyi optimize edilmiştir. Gerçek CC oturumlarında altı aday israf kalıbı ölçtük; beşi orada yoktu. İlginç israf CC’nin kendisinde değil, çok araçlı MCP ortamında ortaya çıktı.
Maliyet tahmini (amplification) ölçüm değil tahmindir ve yalnızca Claude Code formatında mümkündür.
Doğrulanmayanı atarız
Dosya yeniden okuma dedektörü yaptık, ancak 30 vakalık örnekte insan notlandırmasında precision ön kayıt eşiğinin (%70) çok altında kaldığı için (iyimser bakışla %3,3, sıkı bakışla %0) iptal ettik. Tahminler ve sonuçlar ön kayıt belgesinde birlikte bırakıldı.
Yazar güncellemesi. Metinde tek satırla değindiğim MCP sunucusu kısmını ayrıca derlediğim bir yazı yayımladım — ajanın migration yazarken kolon adlarını kafasına göre koyması sorununu, fiziksel adı "girdi" ile vermek yerine sözlük tabanlı "hesaplama"ya çevirerek çözen bir yapı:
https://sqemo.com/blog/erd-mcp-server
(Şimdilik yalnızca stdio yerel kullanımını destekliyor, bu yüzden uzak MCP desteklenmiyor; uygulamanın ana gövdesi kapalı kaynak, yalnızca MCP sunucusu açık).
Kayıt olmadan hemen deneyebilirsiniz (app.sqemo.com); takıldığınız bir nokta olursa yorum bırakın — daha başlangıç aşamasında olduğu için geri bildirimler hemen yansıtılıyor.
Güncelleme kaydı (2026-07-25)
İlk yazıdan sonra Repolis'i basit bir 3D repo tarayıcısından, yeniden ziyaret etmek için bir neden sunan küçük bir kasaba yönünde genişletmeyi sürdürdüm.
Yeni bir yazı oluşturmak yerine, sonraki değişiklikleri de bu orijinal yazının yorumlarında kaydetmeye devam edeceğim.
Live: https://hyeonsangjeon.github.io/Repolis/
Source: https://github.com/hyeonsangjeon/Repolis
Mac’in Korece klavyesinde girilemiyor 😢 Claude ise yanıt verirken bu işareti daha çok kullanıyor gibi; Korece kullanıcılarına pek tanıdık gelmiyor...
Bana da gelmişti, ben de denedim... ama Korece hâlâ yok T_T
Yazarıyım. Metne sığdıramadığım birkaç şeyi ekleyeyim —
· Demo videoları (telefondan onay akışı, masaüstünde 3 bölmeli komuta merkezi) landing sayfasında gerçek ekran kaydı olarak var: adhf.dev
· Self-host için tek satır yeterli: npm i -g adhdev; dashboard localhost:3847’de açılıyor (hesap gerekmiyor)
· ff-only merge tasarımı ya da MAGI çapraz doğrulamasının pratikte neyi yakaladığı gibi tasarım sorularına açığım
Geri bildirim verirseniz hemen yansıtacağım.
Ben GPT-6 bekliyordum... Opus 5 çıktığına göre yeni bir modelin gelmesi gerekmiyor mu?
Bugünlerde teknik borçtan değil, bilişsel borçtan söz ediliyor.
Bazen iş arkadaşlarımla konuşurken, kendi yaptıkları şeyin bile nasıl çalıştığını tam olarak anlamadıklarını gördüğümde biraz ürperiyorum.
Zaman geçtikçe kimsenin nasıl çalıştığını anlamadığı bir hale gelecek gibi; ama yapay zekaya analiz ettirip sorabileceğimiz için belki de sorun değildir diye de düşünüyorum.
Böyle yazıları çok seviyorum.