Yapay zeka ile performans optimizasyonu: önce ölç

Yapay zeka ile performans optimizasyonu yaparken istem yazmadan önce ölç: yavaş yolun profilini çıkar, profili ajana ver, sıcak noktayı ortadan kaldıran en küçük değişikliği iste ve ancak bir benchmark farkı gösterdiğinde kabul et. Claude Code, Codex ve Gemini CLI gibi kodlama ajanları bir flame graph’ı okumakta, sıcak bir fonksiyonu çağıranlarına kadar izlemekte ve bir sorguyu yeniden yazmakta hızlıdır. Veri verilmezse herkesin yaptığını yaparlar: tahmin. Tahmine dayalı optimizasyonlar da pahalı türdendir, çünkü kodu hızlandırmadan okunmasını zorlaştırırlar.

Bu rehber pratikte ayakta kalan bir akışı anlatıyor: hedefi tanımla, profil çıkar, kanıtı teslim et, tek bir şeyi değiştir, benchmark ile doğrula ve kazancı bir regresyon korumasıyla kilitle. Yol boyunca gerçek uygulamalardaki yavaşlıkların çoğuna sebep olan sorunlara da bakıyor: N+1 sorguları, bundle boyutu ve eksik önbellekler.

Bir hisle değil, bir sayıyla başla

“Dashboard yavaş” bir görev değildir. Onu ajanın kontrol edebileceği bir şeye çevir:

• Ne yavaş: bir endpoint, bir sayfa yüklemesi, bir CLI komutu, bir toplu iş.
• Ne kadar yavaş, ölçülmüş haliyle: bir endpoint’in p95 gecikmesi, bir sayfanın etkileşime hazır olma süresi, bir betiğin çalışma süresi.
• “Yeterince hızlı” ne demek: “p95’te 300 ms altı” ya da “içe aktarma 100 bin satır için bir dakikadan kısa sürede bitiyor” gibi bir hedef.
• Hangi koşullarda: veri boyutu, soğuk ya da sıcak önbellek, production build ya da dev sunucusu.

Son madde çok fazla boşa giden emeği yakalar. Dev sunucusundaki bir React uygulaması, NODE_ENV=production olmadan çalışan bir Node servisi ya da on satırlık test verisiyle çalışan bir Python işi, production’da olmayan sıcak noktalar gösterir. Yayına çıkardığın şeyi ölç.

Adım 1: yavaş yolun profilini çıkar

Zamanın nereye gittiğine uyan profiler’ı seç.

Tarayıcıda

Chrome DevTools’taki Performance paneli bir trace kaydeder: uzun görevler, script çalışması, layout, ağ şelaleleri. Lighthouse somut fırsatlarla birlikte bir laboratuvar puanı verir. Lighthouse CLI kullanışlıdır, çünkü ajana verebileceğin bir dosya yazar:

npm install -g lighthouse
lighthouse https://localhost:3000/dashboard \
  --only-categories=performance \
  --output=json --output-path=./lighthouse.json

Ajanın MCP destekliyorsa Chrome DevTools MCP sunucusu, onun bir performans trace’i başlatıp içgörüleri kendisinin okumasını sağlar:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

Node.js’te

Node’un yerleşik bir örnekleme profiler’ı var. --cpu-prof, süreç kapanırken DevTools Performance panelinde açabileceğin ya da ajana verebileceğin bir .cpuprofile dosyası yazar:

node --cpu-prof --cpu-prof-dir=./profiles server.js
# run the slow request a few times, then stop the server

Daha eski --prof bayrağı, node --prof-process komutunun metin rapora çevirdiği bir V8 logu yazar; bu raporu bir ajan çok kolay okur:

NODE_ENV=production node --prof server.js
node --prof-process isolate-0x*-v8.log > processed.txt

Bellek sorunları için --heap-prof aynı şekilde bir .heapprofile yazar.

Python’da

py-spy çalışan bir süreci kodunu değiştirmeden örnekler; bu da onu canlı bir servis için güvenli seçenek yapar:

py-spy top --pid 12345                    # live view, like top
py-spy record -o profile.svg --pid 12345  # flame graph
py-spy record -o profile.svg -- python import_job.py

Kendin başlatabildiğin bir betik için standart kütüphanedeki cProfile kesin çağrı sayıları verir:

python -m cProfile -s cumtime import_job.py | head -40

Ekim 2026 itibarıyla Python 3.15 ayrıca istatistiksel bir profiler (python -m profiling.sampling) içeren bir profiling paketiyle geliyor ve cProfile’ı izleme (tracing) profiler’ının takma adı olarak koruyor; daha eski sürümlerde kullanılacak araçlar cProfile ve py-spy.

Veritabanında

Sorgu süresinde cevabı veritabanı zaten biliyor: yavaş sorgu logu, PostgreSQL’de pg_stat_statements ve tek bir sorgu için EXPLAIN ANALYZE. Yapay zeka ile SQL yazmak yazısı sorgu planlarını okumayı ve ajanla indeks seçmeyi anlatıyor, burada tekrarlamayacağım.

Adım 2: kanıtı ajana ver

Artık ajanın üzerinde çalışabileceği gerçek bir şey var. Profili ve bağlamı teslim et, koddan önce analiz iste:

/api/orders endpoint'i production'da p95'te yaklaşık 1,8 sn sürüyor; hedef
300 ms. Ekte: 50 istek için node --prof-process çıktısı processed.txt ve aynı
dönemin yavaş sorgu logu.
Henüz kodu değiştirme. İlk üç sıcak noktayı listele; her biri için profildeki
kanıtı (fonksiyon, self time ya da total time, çağrı sayısı), kodumuzdaki
olası nedeni (dosya ve satır) ve önerdiğin düzeltmeyi yaz. Beklenen etkiye
göre sırala.

Bu adımı işe yarar kılan birkaç alışkanlık:

• Özetini değil, ham çıktıyı ver. Senin özetin zaten senin tahminini içerir.
• Her iddia için kanıt iste. “Bu fonksiyon yavaş” cümlesi profilden bir sayıyla gelmeli.
• Ajanı sıcak yolda tut. Zamanın %2’sini alan kod, ne kadar çirkin olursa olsun yeniden yazılmaya değmez.

Ajan “profil darboğazı net göstermiyor” gibi bir şey söylerse ona inan ve daha fazla yükle ya da production build ile daha iyi bir profil çıkar. Bu, kendinden emin bir tahminden çok daha iyi bir sonuçtur.

Adım 3: benchmark’ı düzeltmeden önce yaz

Benchmark senin doğrulama adımın. Onu yaz, mevcut kodda çalıştır ve bir şey değişmeden önce taban çizgisini kaydet.

Bir komut ya da betik için hyperfine onu defalarca çalıştırır ve ortalamayı ve dağılımı raporlar:

hyperfine --warmup 3 'node scripts/build-report.js'

Bir fonksiyon için yığınının benchmark desteğini kullan: Go’da go test -bench=. -benchmem, Python’da pytest-benchmark, JavaScript’te test çalıştırıcının bench desteği. Bir endpoint için production build’e karşı sabit sayıda istekle kısa bir yük testi.

Sonra ajana kuralı söyle:

İşte benchmark ve taban çizgisi sonucu. Her seferinde tek bir değişiklik
yap. Her değişiklikten sonra testleri ve benchmark'ı üç kez çalıştır ve
öncesi/sonrasını raporla. Bir değişiklik sonucu gürültünün ötesinde
iyileştirmiyorsa, yardımcı olması gerektiğini düşünsen bile geri al ve
bana söyle.

İki ayrıntı önemli. Aynı makinede aynı veriyle karşılaştır, çünkü dizüstü bilgisayarlar ısınınca yavaşlar ve önbellekler ısınır. Ve testleri benchmark’ın yanında çalıştırmaya devam et: yanlış cevap döndüren daha hızlı bir fonksiyon bir hatadır. Optimize ettiğin kodun testi yoksa önce test ekle; yapay zeka ile test yazmak bir ajandan işe yarar testleri nasıl alacağını anlatıyor.

Zaman genelde nereye gider?

Gerçek uygulamalarda yavaşlıkların çoğunu küçük bir sorun kümesi açıklar. Önce bunlara bak.

N+1 sorguları

Klasik olanı: bir liste yükle, sonra bir döngüde ya da şablonda her öğe için bir sorgu daha çalıştır. Geliştirmede on satırla iyi görünür, production’da iki bin satırla çöker. Çözüm, ilişkili veriyi ORM’inin sunduğu araçla bir ya da iki sorguda yüklemektir:

Nerede olduğunu bildiklerinde ajanlar bu düzeltmede iyidir. Sorgu loglamayı aç, yavaş sayfayı bir kez aç ve logu ajana ver: farklı ID’lerle tekrar eden bir sorgu kalıbı parmak izidir. Sonra düzeltmeyi ve o sayfadaki sorgu sayısını doğrulayan bir testi iste ki sorun fark edilmeden geri dönemesin.

Bundle boyutu

Ön yüz performansında gönderdiğin JavaScript çoğu zaman en büyük kaldıraçtır. Önce bundle’da ne olduğunu source-map-explorer ya da webpack-bundle-analyzer (veya bundler’ının analiz aracı) ile ölç, sonra olağan sebeplere bak:

• tek bir fonksiyon için içe aktarılmış büyük bir kütüphane,
• tek bir import yüzünden çekilen koca bir ikon seti ya da dil paketi,
• ilk boyamada yüklenen ama lazy load edilebilecek ağır bileşenler,
• aynı bağımlılığın farklı sürümlerle iki kez paketlenmesi.

Analiz çıktısını ajana ver ve kazanılan byte’a göre sıralanmış değişiklikler iste. Sonra build çıktısını, bir benchmark’ı karşılaştırdığın gibi öncesi ve sonrasıyla karşılaştır.

Tekrar eden iş ve önbellek

Önbellek, aynı pahalı sonuç aynı girdilerle tekrar tekrar hesaplandığında doğru cevaptır. Hesaplamanın kendisi ucuzlatılabiliyorsa ya da veri değiştiğinde ne olacağına kimse karar vermediyse yanlış cevaptır. Bir ajandan gelen önbelleği kabul etmeden önce ona sor:

Bu önbellek için: anahtar ne, onu ne geçersiz kılıyor, kabul ettiğimiz
en fazla bayatlık ne, ne kadar bellek kullanabilir ve soğuk başlangıçta ne
oluyor? Onu haklı çıkaran ölçülmüş isabet oranını ya da profili göster.

Cevaplar belirsizse önbellek sonra bir hata raporuna dönüşür. Çoğu zaman daha iyi düzeltme zincirin daha başındadır: eksik bir indeks, her sütunu çeken bir sorgu, her turda aynı değeri yeniden hesaplayan bir döngü.

Algoritmik sorunlar

Bazen profil devasa çağrı sayısına sahip tek bir fonksiyon gösterir: iki liste üzerinde iç içe döngü, .map() içinde .find(), döngü içinde sıralama. Doğrusal bir aramayı Map ya da Set ile değiştirmek klasik bir ajan düzeltmesidir ve benchmark bunun önemli olup olmadığını hemen söyler.

Erken ve spekülatif optimizasyondan kaçın

Ajanlar optimize etmeye bayılır. Birinden bir dosyada “performansı iyileştir” istersen bileşenleri memoize eder, döngüleri yeniden yazar ve her yere önbellek ekler. Bu değişikliklerin çoğu ölçülebilir hiçbir şeyi değiştirmez ve kodu değiştirmeyi zorlaştırır. Proje talimatlarında açıkça yazmaya değer kurallar:

## Performans çalışması
- Sorunu gösteren bir profil ya da benchmark olmadan optimizasyon yok.
- Commit başına tek değişiklik; mesajda öncesi/sonrası sayılar.
- Ölçülmüş sıcak yolların dışında okunabilirlik mikro optimizasyonlardan önce gelir.
- Sormadan önbellek, worker ya da yeni bağımlılık ekleme.

Aynısı, ajanın ilgisiz bir iş sırasındaki önerileri için de geçerli. “Hazır buradayken şunu da optimize ettim” derse sayıları iste ya da geri almasını iste. Bir optimizasyondan sonra bir şey bozulursa yapay zeka ile hata ayıklamak tahmin etmeden nasıl daraltacağını anlatıyor.

Adım 4: kazancı koru

Performans sessizce, her seferinde makul bir değişiklikle kötüleşir. Her düzeltmeyi yüksek sesle kırılan bir kontrole çevir:

• Sorgu sayısı testleri. Siparişler sayfasının en fazla sabit sayıda sorgu çalıştırdığını doğrula. Çoğu framework’ün bunun için bir yardımcısı var; Django’daki assertNumQueries gibi.
• Bundle bütçeleri. size-limit gibi araçlar bir bundle belirlenen boyutun ötesine büyüdüğünde build’i kırar.
• CI’da Lighthouse. Lighthouse CLI’ı bir önizleme build’ine karşı çalıştır ve önemli sayfalarda bir puan eşiğinin altında kır.
• Taban çizgisine karşı benchmark. Taban çizgisini sakla ve karşılaştır; Go’da benchstat iki benchmark çalıştırmasını karşılaştırır ve farkın anlamlı olup olmadığını söyler.

Ajanlar bu korumaları yazmakta iyidir ve düzeltmeyle aynı görevde birini istemeye değer: “N+1’i düzelt ve onu yakalayacak bir test ekle”.

AgentVera’da nasıl yapılır?

AgentVera; Claude Code, Codex ve Gemini CLI gibi kodlama ajanı CLI’larını yan yana çalıştıran bir masaüstü uygulaması. Birkaç özelliği bu döngüye uyuyor:

• Ajanın kullanabildiği bir tarayıcı. Ajan tarayıcısı, ajanların Playwright MCP üzerinden kullandığı, DevTools ve konsolu içinde olan ayrı bir Chrome profili; ajan yavaş sayfayı kendisi açabilir, sen de izleyebilirsin.
• Kanıtı tek kısayolla gönder. Ajana gönder (⌘⇧L) terminal çıktısını, editör seçimini, bir diff’i ya da tarayıcı konsolunu bir ajana gönderir. Terminaldeki profiler çıktısı kopyala-yapıştır olmadan ajana gider; çok uzun çıktı 12.000 karakterde kesilir, bu yüzden raporun başını gönder ya da bir dosyaya kaydet.
• Sorgu planları kodun yanında. Veritabanı yöneticisi (Pro) PostgreSQL, MySQL ve SQLite’ı EXPLAIN planlarını gösteren bir SQL editörüyle açar; ajanlar da veritabanını yerleşik aracıyla sorgulayabilir.
• Kabul kriteri olarak benchmark. Mesajına “testler geçiyor ve benchmark taban çizgisinden en az %30 daha hızlı” yaz; Verify bunu tur sonunda komut çalıştırabilen ama dosya düzenleyemeyen bir doğrulayıcıyla kontrol eder.
• Karşılığını vermeyen optimizasyonu geri al. Turlar ve oturum tekrarı her turun anlık görüntüsünü alır, böylece bir deneyi geri almak tek tıktır.
• İki yaklaşımı aynı anda dene. Çalışma alanı ızgarasında iki ajanı ayrı worktree’lerde çalıştır, biri önbellek üzerinde, diğeri sorgu üzerinde; sayıları daha iyi olanı tut.

Sonuç

Yapay zeka ile performans optimizasyonu, onsuz yapılan optimizasyonla aynı disiplindir, sadece daha hızlıdır: net bir hedef, bir profil, teslim edilmiş kanıt, her seferinde tek değişiklik, kanıt olarak bir benchmark ve kazancı tutacak bir koruma. Okumayı ve yeniden yazmayı ajan yapar; kararı sayılar verir. Yavaşlık bir bağımlılık güncellemesiyle geldiyse yapay zeka ile bağımlılık güncelleme yazısındaki akış hangi paketin sebep olduğunu ayırmana yardım eder.

Bu akışı kendi projende denemek için AgentVera’yı indir.