yapay zeka ile kodlamada token optimizasyonu

yapay zekâ ile kodlama yaparken token optimizasyonu, aslında “modele her şeyi boca etmeden iş yaptırma sanatı”dır.

çünkü yapay zekâya kod yazdırırken çoğu kişinin yaptığı ilk hata şudur:

“al kardeşim tüm projeyi, bir bak.”

sonra model bir süre ekrana ciddi ciddi bakar, üç dosya okur, dördüncüde bağlamı kaybeder, beşincide kafasına göre mimari uydurur, altıncıda da sana çalışan kod yerine edebî niyet mektubu verir.

token dediğin şey kabaca modelin okuyup yazdığı metin bütçesidir. sen prompt’a ne kadar çok kod, log, açıklama, hata çıktısı, klasör yapısı, stack trace ve eski konuşma gömersen, modelin kafasındaki masa o kadar kalabalık olur.

ve masası kalabalık olan geliştirici nasıl saçmalıyorsa, model de öyle saçmalar.

token optimizasyonu, modele cimrilik yapmak değildir.
modele doğru bilgiyi, doğru sırayla, doğru miktarda vermektir.

mesela “bu projeyi düzelt” kötü prompt’tur.

çünkü proje ne?
hata ne?
beklenen davranış ne?
hangi dosya önemli?
hangi framework kullanılıyor?
hangi sürüm?
hangi endpoint bozuk?
hangi log gerçek?
hangi kod eski?
hangi dosyaya dokunulmayacak?

bunları söylemezsen model de doğal olarak “yaratıcı” olur. yazılımda yaratıcılık bazen güzeldir ama production bug’ında yaratıcı model, mutfakta el bombası bulan çocuk gibidir.

iyi yaklaşım şudur:

önce problemi daraltırsın.
sonra ilgili dosyaları verirsin.
sonra beklenen çıktıyı söylersin.
sonra sınırları çizersin.
sonra modelden tek seferde dünyayı kurtarmasını değil, küçük ve kontrol edilebilir değişiklik yapmasını istersin.

örnek:

“laravel projesinde ödeme callback’i 500 dönüyor. sadece `paymentcontroller.php` ve `nkolaypos.php` dosyalarını incele. hata şu: undefined index use_3d. beklenen davranış: eksik parametre geldiğinde notice üretmeden güvenli şekilde default değer kullansın. mevcut ödeme akışını değiştirme. bana sadece değişmesi gereken kod bloklarını ver.”

işte bu prompt, “abi site patladı düzelt” prompt’undan bin kat değerlidir.

token optimizasyonunun birinci kuralı: modeli dedektif gibi değil, cerrah gibi çalıştır.

dedektif olursa her yere bakar.
cerrah olursa nereye müdahale edeceğini bilir.

burada codex clı ve claude code clı gibi araçlar devreye girince mevzu daha da büyür. çünkü artık sadece modele soru sormuyorsun; model terminalde dosya okuyabiliyor, komut çalıştırabiliyor, diff görebiliyor, test koşturabiliyor. bu güzel bir şeydir ama kontrolsüz bırakılırsa token fırınına odun atmak gibidir.

bu yüzden cli ile çalışırken ilk yapılacak şey şudur:

modele tüm repoyu gezdirme, önce harita çıkar.

bunun için kullanılacak en temiz araçlardan biri `rg`, yani ripgrep’tir.

`grep` ile akrabadır ama daha moderndir, hızlıdır, `.gitignore` dosyasına saygı duyar. yani `vendor/`, `node_modules/`, `storage/`, `dist/`, `build/` gibi çöplüklere dalıp modeli token denizinde boğma ihtimalini azaltır.

mesela:

```bash
rg "use_3d|merchant_no|auth_code" catalog/controller
```

bu komut modele şunu demenin terminal halidir:

“kardeşim, bütün projeye değil, şu kelimelerin geçtiği yerlere bak.”

ikinci iyi dost `fd` olur.

dosya bulmak için kullanılır. klasik `find` gibi ama daha insani konuşur.

```bash
fd payment
fd "controller.php" app
fd "nkolay|iyzico|paytr" .
```

böylece modele “projede ödeme ile ilgili dosyalar bunlar” diye net malzeme verirsin. model de arkeolog gibi bütün klasörleri kazmaz.

üçüncü araç `tree` veya `eza --tree`.

ama burada da ayarı kaçırmamak lazım. tüm projeyi ağaç gibi basarsan modelin önüne orman yangını koymuş olursun.

doğru kullanım:

```bash
tree -l 2 app routes config
```

veya:

```bash
eza --tree --level=2 app routes config
```

bu, modele proje krokisi verir. ama tüm apartmanın elektrik tesisatını söküp masaya koymaz.

dördüncü araç `git diff`.

yapay zekâ ile kodlama yaparken en değerli bağlam genelde tüm proje değil, değişen kısımdır.

```bash
git diff
git diff --stat
git diff --name-only
git diff main...head
```

`git diff --name-only` özellikle altın değerindedir. çünkü modele önce “değişen dosyalar bunlar” dersin. sonra gerekirse sadece o dosyaları açtırırsın.

beşinci araç `delta`.

diff okumayı daha insani hale getirir. renkli, temiz, anlaşılır gösterir. model için şart değil ama insan için iyidir. çünkü yapay zekâya kontrolsüz yetki vermeyeceksen, sen de ne değiştiğini göreceksin.

altıncı araç `bat`.

`cat` yerine daha okunabilir çıktı verir. satır numarası, syntax highlight, bölüm bölüm okuma derken özellikle terminalden context hazırlarken işe yarar.

```bash
bat -n app/services/paymentservice.php
bat -n --line-range 80:130 catalog/controller/extension/payment/nkolaypos.php
```

işte bu ikinci örnek token optimizasyonunun özüdür.

tüm dosya değil, ilgili 50 satır.

yedinci araç `sed`, `awk`, `head`, `tail`.

bunlar eski usul ama hâlâ çok işe yarar. log kırpmak, dosya bölmek, sadece ilgili alanı almak için candır.

```bash
tail -200 storage/logs/laravel.log
sed -n '80,130p' catalog/controller/extension/payment/nkolaypos.php
```

modele 20.000 satır log yapıştırmak yerine son 200 satırı vermek bazen insanlığın hâlâ umut vadettiğini gösterir.

sekizinci araç `jq`.

api response, package lock, composer output, json log, config çıktısı gibi şeyleri düzene sokar.

```bash
cat response.json | jq '.error'
cat package.json | jq '.scripts'
```

json’u ham haliyle modele basarsan hem token yanar hem göz kanar. `jq` ile sadeleştirirsen model de insan gibi anlar.

dokuzuncu araç `yq`.

yaml için `jq` kafasıdır. kubernetes manifest, docker compose, github actions, gitlab ci gibi dosyalarda çok işe yarar.

```bash
yq '.services' docker-compose.yml
yq '.spec.template.spec.containers' deployment.yaml
```

kubernetes yaml’ını komple modele vermek, bazen tapu kadastro arşivini şiir diye okutmak gibidir. `yq` ile gereken yeri alırsın.

onuncu araç `wc`, `cloc` veya `tokei`.

projenin büyüklüğünü görmek için kullanılır.

```bash
tokei
cloc app
wc -l file.php
```

modele “bu küçük proje” dersin, proje 180 bin satır çıkar. sonra model de sen de birbirinize kırılırsınız. önce ölç, sonra konuş.

on birinci araç `ast-grep`.

regex ile kod aramak güzel ama bazen yetmez. `ast-grep` kodu metin gibi değil, syntax ağacı gibi arar. refactor, pattern bulma, framework bazlı arama gibi işlerde token tasarrufu sağlar.

“şu fonksiyon nerede çağrılıyor?”
“şu pattern hangi dosyalarda var?”
“şu import hangi componentlerde kullanılmış?”

bunu modele taratmak yerine önce araçla çıkar, sonra sonucu ver.

on ikinci araç `semgrep`.

güvenlik ve pattern bazlı kod taraması için kullanılır. modeli güvenlik uzmanı sanıp tüm projeyi okutmak yerine önce semgrep koşturursun. sonra çıkan bulguları modele yorumlatırsın.

doğru sıra şudur:

araç bulur.
model açıklar.
insan karar verir.

yanlış sıra şudur:

model tüm projeye bakar, “genel olarak güvenli görünüyor” der, herkes rahatlar, sonra prod’da yangın çıkar.

on üçüncü araç dilin kendi test ve lint araçlarıdır.

javascript tarafında:

```bash
npm test
npm run lint
npm run typecheck
```

php tarafında:

```bash
composer test
vendor/bin/phpunit
vendor/bin/phpstan analyse
vendor/bin/pint
```

python tarafında:

```bash
pytest
ruff check .
mypy .
```

go tarafında:

```bash
go test ./...
go vet ./...
```

rust tarafında:

```bash
cargo test
cargo clippy
cargo fmt
```

bunları modele “tahmin et” diye sormayacaksın. çalıştıracaksın, çıktısını vereceksin.

modelin “bence çalışır” demesiyle testin yeşil yanması aynı şey değildir. biri niyet, diğeri delildir.

on dördüncü araç `make` veya `just`.

projede tekrar eden komutları tek yerde toplamak için güzel çözümdür.

```makefile
test:
php artisan test

lint:
vendor/bin/pint --test

stan:
vendor/bin/phpstan analyse
```

veya:

```just
test:
npm test

lint:
npm run lint

check:
npm run typecheck
```

codex veya claude clı kullanırken modele şunu demek çok daha temiz olur:

“bu projede test için `just test`, lint için `just lint`, typecheck için `just check` kullanılır.”

bu cümle, her seferinde uzun uzun komut anlatmaktan iyidir. token da az gider, hata da azalır.

on beşinci araç `docker compose`.

local ortamı ayağa kaldırmak, database/redis gibi servisleri standart hale getirmek için iyidir.

ama modele docker compose dosyasını komple okutmak yerine önce servisleri özetlemek daha mantıklıdır:

```bash
docker compose ps
docker compose logs app --tail=100
docker compose logs db --tail=100
```

model bütün container geçmişini bilmek zorunda değil. o anki problemi çözecek kadarını bilsin yeter.

on altıncı araç `gh`, yani github clı.

pull request, issue, diff, review gibi işlerde context hazırlamayı kolaylaştırır.

```bash
gh pr view --json title,body,files
gh pr diff
gh issue view 123
```

bunu modele verirsen “şu pr ne yapıyor?” sorusuna daha temiz cevap verir. yoksa model pr’ı tahmin eder. yazılımda tahmin bazen kumardır.

on yedinci araç `grep` değil, doğru kullanılmış `rg`.

şunu ayrıca söylemek lazım. çünkü bazı insanlar hâlâ tüm projede `grep -r` ile `node_modules` mezarlığına dalıp sonra “model çok token yedi” diyor.

model yemedi kardeşim. sen önüne açık büfe attın.

on sekizinci araç `repomix` tarzı repo paketleyiciler olabilir.

bunlar projeyi tek dosya context haline getirir. ama dikkat: bu araçlar faydalıdır, aynı zamanda tehlikelidir. çünkü tüm repoyu tek dosya yapıp modele atmak token optimizasyonu değil, token katliamıdır.

doğru kullanım:

sadece ilgili klasörleri dahil et.
test, vendor, node_modules, build çıktısını hariç tut.
secret dosyalarını kesin dışarıda bırak.
çıktıyı önce kendin kontrol et.

yoksa `.env` dosyasını da pakete koyup sonra “ai güvenli mi?” diye entry girersin.

codex clı tarafında `agents.md`, claude code tarafında `claude.md` ayrı bir mevzudur.

bunlar modele proje kurallarını anlatan not defteri gibidir. her prompt’ta aynı şeyleri tekrar tekrar yazmamak için kullanılır.

iyi bir `agents.md` veya `claude.md` şöyle olur:

```markdown
# proje kuralları

- mevcut mimari bozulmayacak.
- büyük refactor yapılmadan önce plan yazılacak.
- test çalıştırmadan değişiklik tamamlandı denmeyecek.
- .env, secret, token, müşteri verisi okunmayacak.
- sadece ilgili dosyalarda değişiklik yapılacak.
- php tarafında psr-12 standardı korunacak.
- laravel için test komutu: php artisan test
- frontend için lint komutu: npm run lint
- veritabanı migration değişirse rollback notu yazılacak.
```

işte bu dosya token tasarrufu sağlar. çünkü modeli her seferinde sıfırdan eğitmezsin. evin kurallarını kapıya asarsın.

ama buraya da roman yazılmaz.

`agents.md` veya `claude.md` dosyası şirket anayasası değil, çalışma talimatıdır. kısa, net, uygulanabilir olmalıdır.

codex ve claude clı ile token optimizasyonu için güzel bir çalışma akışı şöyle olabilir:

```bash
git status
git diff --name-only
rg "hata|exception|payment|callback" app routes config
sed -n '80,140p' ilgili-dosya.php
tail -100 storage/logs/laravel.log
```

sonra modele dersin ki:

“yukarıdaki çıktılara göre sadece ödeme callback hatasını analiz et. kod yazmadan önce hangi dosyada ne değişmesi gerektiğini söyle. varsayım yapma. eksik bilgi varsa iste.”

bu prompt, “projeye bak düzelt” saçmalığından çok daha sağlıklıdır.

bir başka iyi akış:

```bash
git diff main...head --stat
git diff main...head -- app/services/paymentservice.php
vendor/bin/phpunit --filter paymenttest
```

sonra:

“bu değişiklik ödeme servisinde. diff ve test çıktısı yukarıda. sadece regression riski var mı kontrol et. yeni mimari önerme. gerekirse 3 test senaryosu öner.”

işte burada model gerçekten işe yarar.

çünkü bağlam dar.
hedef net.
çıktı sınırlı.
araçlar işini yapmış.
model yorum yapıyor.

yapay zekâ ile kodlama yaparken en iyi strateji şudur:

terminal aracı ham veriyi süzer.
model anlam çıkarır.
test gerçeği söyler.
insan son kararı verir.

hepsini modele yıkarsan model de yorulur, token da yanar, kod da saçmalar.

özellikle codex ve claude gibi cli araçlarında izin yönetimi de önemlidir.

modele her komutu koşturma hakkı vermek rahat görünebilir ama risklidir. `rm`, `git reset`, migration, production bağlantısı, secret okuma, dışarı veri gönderme gibi işlerde sınır şarttır. yapay zekâya terminal açmak, stajyere root vermek gibidir. bazen çok iş yapar, bazen şirketin kaderini değiştirir.

token optimizasyonunun güvenlik tarafı da vardır.

`.env` dosyasını okutma.
müşteri verisi verme.
production dump verme.
gerçek token verme.
kişisel veri içeren logları maskele.
database connection string’i sansürle.
api key’i prompt’a sokma.

fintech, sağlık, kvkk gerektiren işlerde bu artık tavsiye değil, refleks olmalı.

iyi bir prompt şöyle kokar:

“şu dosyalar, şu hata, şu beklenen davranış, şu sınırlar, şu test komutu.”

kötü prompt şöyle kokar:

“abi bi bakar mısın?”

`abi bi bakar mısın` prompt’u yazılım dünyasının en pahalı cümlelerinden biridir.

özetle yapay zekâ ile kodlama yaparken token optimizasyonu için araç seti şudur:

`rg` ile ara.
`fd` ile dosya bul.
`tree` veya `eza` ile proje haritası çıkar.
`git diff` ile değişeni göster.
`bat` ile ilgili satırı oku.
`sed`, `head`, `tail` ile log ve kod kırp.
`jq` ve `yq` ile json/yaml sadeleştir.
`phpunit`, `pytest`, `npm test`, `cargo test` ile gerçeği çalıştır.
`semgrep` ve `phpstan` gibi araçlarla statik analiz yap.
`docker compose logs --tail=100` ile sadece gerekli logu ver.
`gh pr diff` ile pr bağlamını temiz çıkar.
`agents.md` ve `claude.md` ile proje kurallarını sabitle.

yani modele çöp verme.
ayıklanmış bilgi ver.

çünkü yapay zekâ iyi bir yardımcıdır ama sen bütün depoyu, bütün logları, bütün eski konuşmayı ve bütün travmalarını aynı prompt’a doldurursan o da bir noktadan sonra sana yazılım değil, fal bakar.

token tasarrufu, para tasarrufundan önce akıl tasarrufudur.