AI coding agent’ları kullanırken öğrendiğim dersler

AI coding araçlarıyla ilk kez ciddi biçimde çalışmaya başladığınızda yaşadığınız duygu çok güçlü. Bir şey söylüyorsunuz; dosyalar oluşuyor, component’ler yazılıyor, migration hazırlanıyor, testler ekleniyor. Dakikalar içinde birkaç yıl önce saatler sürecek bir iş ortaya çıkıyor.

Sonra bir süre geçiyor. Bir agent yanlış repository’de çalışıyor. Başka biri mevcut mimariyi fark etmeden ikinci bir sistem kuruyor. Bir fix production’da başka bir modülü kırıyor. Bir agent “tamamlandı” diyor ama gerçek cihazda özellik çalışmıyor. Bir başkası problemi çözmek yerine üzerine yeni abstraction’lar ekliyor.

AI kod yazmayı ucuzlattı. Doğru karar vermeyi değil.

Claude, Cursor, Codex ve Lovable gibi araçları gerçek ürün geliştirme süreçlerinde yoğun biçimde kullanıyorum. Bu süreçte AI hakkında düşündüğüm en önemli şey değişti. Başta soru “hangi model daha iyi kod yazıyor?” idi. Bugün ise daha çok “hangi çalışma sistemi AI’ın hata üretme alanını küçültüyor?” diye soruyorum.

1. En iyi model kötü bağlamı kurtaramıyor

Bir agent’a “Planning ekranını düzelt” dediğinizi düşünün. İnsan olarak ne demek istediğinizi biliyorsunuz. Agent bilmiyor. Hangi repository? Hangi branch? Planning dediğiniz /planning mi /plan mı? Mevcut sistem korunacak mı? Hangi tasarım referansı doğru? Desktop ve mobil aynı davranmalı mı? Backend değiştirmek serbest mi? Yeni dependency kurulabilir mi?

Bunların hiçbiri belirtilmemişse agent’ın yaptığı şey büyük ölçüde tahmindir. Ben bu yüzden bugün görevleri bir çeşit contract gibi düşünüyorum.

1interface AgentTask {2  repo: string;3  branch: string;4  scope: string[];5
6  preserve: string[];7  forbidden: string[];8
9  acceptanceCriteria: string[];10}

AI’ın zekâsına güvenmek yerine çalışma alanını sınırlandırmak daha güvenilir. İyi bağlam, modele daha fazla bilgi yığmak değil; doğru bilgiyle gereksiz ihtimalleri ortadan kaldırmaktır.

2. Preflight opsiyon değil

Bir dönem AI agent’ların yanlış repository veya yanlış worktree üzerinde işlem yaptığı durumlarla karşılaştım. Agent’a göre her şey yolundaydı. Kod yazılmıştı. Test geçmişti. Commit bile alınmıştı. Sadece yanlış yerdeydi.

Bu yüzden bugün geliştirme görevlerinde ilk iş kod yazmak değil, çalışma alanını doğrulamak.

1pwd2git remote -v3git branch --show-current4git status5git log -1 --oneline

Basit görünüyor. Ama bu beş kontrol birkaç saatlik yanlış çalışmayı engelleyebilir. Benim için GitHub kaynak doğrusu; agent göreve başlamadan önce içinde bulunduğu gerçekliği doğrulamak zorunda.

1if (!repoVerified || !branchVerified) {2  throw new Error("Do not modify code.");3}

3. AI çok hızlı olduğu için kötü mimari daha tehlikeli

Eskiden gereksiz bir abstraction yazmak maliyetliydi. Dosyayı açacak, kodlayacak, test edecektiniz. Bu doğal sürtünme bazen sizi durduruyordu. AI ile aynı abstraction birkaç dakika içinde oluşabiliyor. Dolayısıyla kötü fikirlerin üretim maliyeti dramatik biçimde düştü.

Örneğin problem “modal mobil klavyenin altında kalıyor” olabilir. Agent bu tek probleme beş yeni abstraction, üç provider ve yeni bir hook ailesiyle cevap verebilir. Kod miktarı artar ama problem hâlâ çözülmemiş olabilir.

Fix the bug, not the universe.

Bir hata için önce mümkün olan en küçük düzeltmeyi arıyorum. Yeni sistem ancak mevcut sistem gerçekten yetersizse kurulmalı. AI’ın hızını daha fazla mimari üretmek için değil, daha kısa doğrulama döngüleri için kullanmak gerekiyor.

4. “Tamamlandı” teknik bir durum değildir

AI agent’ların sevdiği ifadelerden biri “implementation completed successfully”. Ama başarı neye göre? TypeScript compile oldu mu? Unit test geçti mi? Browser açıldı mı? Production build geçti mi? Authenticated kullanıcıyla test edildi mi? Android cihazda denendi mi? Production verisiyle çalıştı mı?

Bunların her biri farklı doğrulama seviyeleri. Bu yüzden completion’ı katmanlı düşünüyorum.

1type VerificationLevel =2  | "code_written"3  | "typecheck_passed"4  | "tests_passed"5  | "build_passed"6  | "browser_verified"7  | "production_verified"8  | "real_device_verified";

Agent yalnızca ulaşabildiği seviyeyi söylemeli. “Build passed. Authenticated browser acceptance could not be verified.” cümlesi, “Done.” demesinden çok daha değerlidir. Çünkü doğrulanmamış kısmı saklamaz.

5. Agent’a sonucu değil, sınırları da anlatmak gerekiyor

Kötü prompt “dashboard’u özelleştirilebilir yap” der. Bu ifade agent’a büyük bir tasarım alanı bırakır. Taşıma, resize, serbest grid, preset’ler, kullanıcı ayarları ve daha fazlasını ekleyebilir.

Daha iyi görev ne yapılacağını kadar ne yapılmayacağını da söyler.

1Users may choose which approved cards are visible.2
3They may NOT:4- freely reposition cards5- resize cards6- create arbitrary dashboard layouts7
8Preserve the fixed daily hierarchy.

Bu çok önemli. Çünkü AI modelleri boşlukları doldurmaya eğilimli. Sınır belirtmezseniz çoğu zaman daha fazla özellik üretirler. Oysa ürün geliştirmede daha fazla özellik çoğu zaman daha iyi ürün değildir.

6. Büyük görevleri agent’a tek nefeste vermek kötü fikir

Bir modele “planning’i yeniden tasarla, performansı düzelt, mobile iyileştir, month view ekle, agenda ekle, cloud sync’i düzelt ve testleri yaz” dediğinizde teknik olarak bir şeyler üretebilir. Ama acceptance yüzeyi o kadar büyür ki hangisinin neden bozulduğunu anlamak zorlaşır.

Ben daha çok küçük ve test edilebilir adımlarla ilerlemeyi tercih ediyorum.

1const plan = [2  "STEP 1 — establish canonical data projection",3  "STEP 2 — build desktop week shell",4  "STEP 3 — implement geometry",5  "STEP 4 — mobile behavior",6  "STEP 5 — acceptance",7];

Her adım küçük, test edilebilir, geri alınabilir ve anlaşılır olmalı. AI’ın hızı burada kullanılmalı: kapsamı büyütmek için değil, döngü süresini küçültmek için.

7. Bir agent’ın çıktısını başka bir agent’a körlemesine vermemek gerekiyor

Claude bir şey yaptıktan sonra Cursor’a yalnızca “bunu kontrol et” demek ikinci agent’ın da ilk agent’ın varsayımlarını kabul etmesine yol açabilir. İkinci model reviewer değil, başka bir autocomplete katmanı haline gelir.

Daha iyi yaklaşım bağımsız denetimdir.

1Do not assume the previous implementation is correct.2
3Inspect:4- current code5- requirements6- changed files7- runtime implications8
9Report mismatches first.10Do not modify code yet.

Bu prompt ikinci agent’a önceki çözümü savunmak yerine problemi yeniden değerlendirme görevi verir. Özellikle büyük refactor ve kritik bug fix’lerde çok daha kullanışlıdır.

8. AI agent’ların rolleri aynı olmak zorunda değil

Bütün araçları tek bir “AI coder” kategorisine koymayı faydalı bulmuyorum. Pratikte farklı roller kullanmak daha mantıklı. Araçların yetenekleri sürekli değişiyor; bu yüzden aşağıdaki sınıflandırma sabit gerçek değil, çalışma modeli.

1const agents = {2  lovable: "rapid product/UI exploration",3  cursor: "repo-aware implementation",4  claude: "deep reasoning / alternative implementation",5  codex: "engineering tasks / audits / implementation",6};

Bir UI fikrini hızla görmek istediğim araçla production repository üzerinde kapsamlı denetim yaptırdığım aracın aynı olması gerekmiyor. Önemli olan tek favori seçmek değil, görevin karakterine uygun çalışma biçimini seçmek.

9. Kod üretiminin ucuzlaması review’ı daha değerli yaptı

AI ile daha hızlı kod yazıyoruz. Bu yüzden daha fazla kod üretiyoruz. Daha fazla kod ürettiğimiz için review’ın önemi artıyor. Darboğaz zamanla kod yazmaktan karar, review, integration ve validation tarafına kayıyor.

110x coding speed2≠310x product speed4
5real bottleneck:6decision → review → integration → validation

Bir agent beş dakikada 20 dosya değiştirebilir. Benim o 20 dosyanın gerçekten gerekli olup olmadığını anlamam gerekir. Bu yüzden bazen en değerli agent görevi kod yazmak değil, diff’i denetleyip gereksiz karmaşıklığı bulmaktır.

10. Git geçmişi AI çağında daha önemli

Agent’ların hızlı çalışması geri dönüşü de kolaylaştırmalı. Küçük ve anlamlı commit’ler bunun için kritik. “feat: improvements” gelecekte hiçbir şey anlatmaz. “fix(planning): prevent duplicate day-header rendering” ise kararın sınırını kaydeder.

AI çağında commit mesajları yalnızca insanlara değil, gelecekteki agent’lara da bağlam sağlıyor. Bir sonraki agent geçmişi okuyabilir, neden karar verildiğini görebilir ve regression’ın hangi değişiklikte başladığını daha hızlı anlayabilir. Git history giderek projenin uzun vadeli hafızasına dönüşüyor.

11. Kaynak doğrusu belirlemek zorundasınız

Bir proje birkaç AI aracıyla yönetildiğinde çok kolay biçimde birden fazla gerçeklik oluşuyor: local branch başka, remote başka, production başka, agent’ın worktree’si başka, preview başka. Bunların hepsi aynı anda doğru olamaz.

1const sourceOfTruth = "GitHub";

Benim çalışma biçimimde GitHub merkezde. Bu yüzden bir agent “local’de çalışıyor” dediğinde iş bitmiş sayılmıyor. Kodun kaynak doğrusuna ulaşması ve doğru deployment sürecinden geçmesi gerekiyor.

12. Production ile development aynı şey değil

AI agent local ortamda mükemmel görünen bir değişiklik yapabilir. Sonra production’da dynamic import, eski asset hash, service worker veya CDN cache nedeniyle sayfa açılmayabilir. Bu tür problemler kod seviyesinde görünmeyebilir.

1const done =2  localBuildPassed &&3  productionDeployed &&4  productionRouteLoaded;

Mobil uygulamalarda bunun üzerine gerçek cihaz doğrulaması da eklenebilir. Production acceptance ayrı bir adım olarak düşünülmediğinde “kod doğru” ile “ürün çalışıyor” birbirine karışıyor.

13. AI size ürün kararını vermemeli

Agent’a “hangisini yapalım?” dediğinizde gayet ikna edici bir cevap verebilir. Sorun şu ki diğer seçeneği seçseydi onu da ikna edici biçimde savunabilirdi. Model seçenekleri açmalı, sonuçları göstermeli, riskleri analiz etmeli ve implementation üretmeli; ama ürünün kaynak doğrusu hâlâ insan kararı olmalı.

1type DecisionAuthority = {2  productVision: "human";3  architectureConstraints: "human";4  implementationDetails: "human+agent";5  repetitiveExecution: "agent";6};

Bu denge kaybolduğunda ürün çok hızlı biçimde agent’ın gördüğü en yakın pattern’e dönüşüyor. AI’ın güçlü olması ürün vizyonunu devretmek için sebep değil; uygulama yüzeyini küçültmek için kaldıraçtır.

14. Prompt aslında geçici bir specification

Prompt engineering ifadesi meseleyi bazen sihirli kelimeler bulmakmış gibi gösteriyor. Benim için iyi bir coding prompt daha çok kısa bir specification. Problem, bağlam, mevcut davranış, istenen davranış, korunacak şeyler, yasaklar ve acceptance kriterleri açık olmalı.

1const task = {2  problem: "...",3  context: "...",4  currentBehavior: "...",5  desiredBehavior: "...",6
7  preserve: ["..."],8  doNot: ["..."],9  acceptance: ["..."],10};

Bu yapının avantajı kullanılan modelden bağımsız olması. Yarın farklı bir agent kullanabilirim ama görev tanımı yine anlamlı kalır. Asıl varlık prompt değil, açıkça tarif edilmiş çalışma sözleşmesidir.

Benim bugün kullandığım basit agent protokolü

Bir coding agent görevinin ideal akışı benim için kabaca şöyle görünüyor:

1async function runAgentTask() {2  await verifyRepository();3  await inspectExistingArchitecture();4  await restateScope();5
6  const implementation = await makeMinimalChange();7
8  await typecheck();9  await test();10  await build();11
12  if (browserAvailable) {13    await verifyInBrowser();14  }15
16  return {17    changedFiles,18    verification,19    unresolvedIssues,20  };21}

Buradaki en önemli satır makeMinimalChange(). Çünkü AI’ın doğal eğilimi çoğu zaman genişletmek. Benim işim çoğu zaman daraltmak.

AI ile geliştirme beni daha az teknik yapmadı

Başta AI coding’in teknik bilgiyi daha az gerekli hale getireceğini düşünmek kolaydı. Benim deneyimim tersine döndü. Kodun her satırını elle yazmak daha az gerekli olabilir; ama mimariyi, state’i, network davranışını, veri modelini, cache’i, güvenliği, deployment’ı ve platform farklarını anlamak daha değerli hale geldi.

1AI removes typing.2It does not remove understanding.

Çünkü agent’ın yanlış yaptığı şeyi anlayabilmek için sistemin nasıl çalışması gerektiğini bilmek zorundasınız. AI kodlama bilgisinin yerini almıyor; düşük değerli yazma işini azaltıp yüksek değerli karar verme işini öne çıkarıyor.

En büyük ders

AI coding araçlarının gerçek gücünün daha fazla kod yazmak olduğunu düşünmüyorum. Bence gerçek güç, fikir ile doğrulanabilir implementation arasındaki döngüyü küçültmek.

Bir günde üç kat fazla feature çıkarabiliyorsanız ama yanlış ürün yapıyorsanız hız kazanmamışsınızdır. Yalnızca yanlış yöne daha hızlı gidiyorsunuz.

Bu araç benim karar kalitemi mi artırıyor, yoksa sadece üretim hızımı mı?

İdeal durumda ikisini de artırmalı. Ama seçim yapmak gerekirse hâlâ doğru yönde yavaş gitmeyi, yanlış yönde çok hızlı gitmeye tercih ederim. Model değişebilir. Araç değişebilir. Çalışma sistemi ise bütün bu değişimlerin üzerinde kalıcı olan katmandır.