Aynı yapay zekâ modeli, farklı çalışma yöntemi

Haziran 2026'da Revotas'taki ekibime, bir AI (yapay zekâ) asistanıyla bug (yazılım hatası) düzeltme üzerine bir oturum verdim. Sekiz slayt ve bir canlı demo.

Oturumun tamamı tek bir iddiaya dayanıyor: bug'ı asistan bulmaz. Sen yönlendirirsin, o analiz eder, sen doğrularsın.

Bu, o oturumun yazılı hali; demonun kurguladığım kısmı dahil.

Demo: tek uygulama, dört bug

Demo React, TypeScript ve Vite ile yazılmış bir yapılacaklar listesi uygulaması; tek bileşende yüz satır kadar. Üç kopyası var: aynı başlayan iki bozuk kopya ve çalışan bir referans.

Bozuk kopyalar dört bug'ı paylaşıyor. Hepsi, her React geliştiricisinin en az bir kez canlıya gönderdiği kalıplar olduğu için seçildi:

Bug	Nerede	Ne görürsün
Stale closure (bir fonksiyonun güncel değer yerine eski değeri kullanması)	bağımlılık dizisi boş bir effect	aktif sayacı hiç güncellenmez
State mutation (uygulama durumunu yeni kopya oluşturmadan doğrudan değiştirme)	toggle ve delete diziyi yerinde değiştirir	tıklamak hiçbir şey yapmaz
Key olarak index (liste öğesini tanıtan anahtar için sıra numarasını kullanmak)	liste `key={index}` kullanır	silince yanlış satır güncellenir
Ters filtre	"active" ve "completed" koşulları yer değiştirmiş	her filtre diğer listeyi gösterir

Öğretici olan mutation bug'ı. Kod veriyi doğru değiştiriyor, sonra React'e zaten elinde olan diziyi geri veriyor:

tsx

const toggleTodo = (id: number) => {
  const next = todos;
  const target = next.find((todo) => todo.id === id);
  if (target) {
    target.completed = !target.completed;
  }
  setTodos(next);
};

Referans aynı, yani yeniden render (veriyi ekranda gösterilecek görünüme dönüştürme) yok. Bellekte tutulan uygulama verisi değişiyor ama ekran güncellenmiyor. Belirsiz bir sorunun belirsiz bir cevap aldığı türden bir bug.

İki prompt

İlk kopya şunu alıyor:

text

fix the bugs

İkinci kopya beş parçalı bir prompt (yapay zekâya verilen talimat veya soru) alıyor ve her parçanın bir nedeni var:

Kapsam. Bozuk kod tek dosyada. Başka hiçbir şeye dokunma. Repoyu vermek yerine dosya yolunu veriyorum.
Düzenlemeden önce analiz. Bulduğun her bug'ı, hangi fonksiyonda olduğunu, neden bug olduğunu ve önerdiğin düzeltmeyi listele. Bir şey değişmeden önce gerekçeyi okumak istiyorum.
Nereye bakacağı. State mutation'lara, effect bağımlılıklarına, index key'lere ve ters dönmüş olabilecek filtre koşullarına bak. Bu kalıpları biliyorum, o yüzden tahmin ettirmek yerine işaret ediyorum.
Yalnızca hedefli düzeltme. Dosyayı baştan yazma. Baştan yazmak çalışan kısımları bozabilir.
İncelenecek bir özet. Neyin neden değiştiğini söyle ki güvenmeden önce kontrol edebileyim.

Ekranda ilk kopya tek satırlık bir "bug'ları düzelttim" ve hâlâ bozuk bir uygulamayla bitiyor: bir bug gitmiş, üçü duruyor. İkincisi dört açıklamalı düzeltme ve çalışan bir uygulamayla bitiyor.

Aynı asistan, aynı model. Tek fark iş akışı.

Kurguladığım kısım

Bu karşıtlık senaryolu. Demonun gösterdiğinden fazlasını ima etmesine izin vermektense bunu burada söylemeyi tercih ederim.

Her demo klasöründe sonucu sabitleyen bir talimat dosyası var. "Kötü" klasördeki dosya asistana yalnızca ters filtreyi düzeltmesini, gerisini atlamasını ve iki satırlık aşırı emin bir cevap vermesini söylüyor. "İyi" klasördeki, dördünü de hedefli düzenlemelerle düzeltip her birini açıklamasını söylüyor.

Böyle yaptım çünkü canlı bir model istendiği anda hata yapmaz. Bu kadar küçük bir uygulamada güncel bir model üç kelimeden dört bug'ı da bulabilir. Modelin kötü gününe denk gelmesine bağlı bir demo, demo değildir.

Yani todo uygulaması kanıt değil. Yaptığı şey, normalde gerçek bir kod tabanı ve gerçek bir öğleden sonra gerektiren bir hatayı birkaç dakikada görünür kılmak: büyük ve tanımadığı bir sisteme karşı belirsiz bir istek; asistan fark ettiği bug'ı düzeltir, başarı bildirir ve o kendinden emin özet merge (ayrı geliştirme dalındaki değişikliği ana kodla birleştirme) edilir.

Oturumdaki dört adım. Bir değişiklik ancak sonuncusundan sonra bitmiş sayılır.

Dört adım

Anlattığım süreç dört adım:

Yeniden üret. Bug'ı kendin gör ve ne zaman olduğunu bil. Tetikleyemiyorsan düzeltmenin işe yarayıp yaramadığını söyleyemezsin.
Context (modelin o anda görebildiği konuşma, talimat ve dosya bilgisi) ver. İlgili dosya ya da fonksiyon, bütün repo (projenin dosyalarını ve değişiklik geçmişini tutan kod deposu) değil.
Hedefle. Hangi tür hatalara bakacağını söyle. Tahmin ettirme.
Doğrula. Çalıştır, test et, diff'i (iki sürüm arasındaki değişiklikleri gösteren karşılaştırma) oku. Körü körüne kabul etme.

İnsanların atladığı dördüncüsü; ben de atladım. Bir kez doğrulamadan commit (kod deposuna kaydedilen değişiklik paketi) attım ve canlıya yanlış mantık gitti. "Doğrulamadan commit yok" oradan geliyor.

Context bir bütçedir

Ortadaki bir slayt şunu söylüyor: token (modelin metni işlerken saydığı küçük parça; her zaman bir kelime değildir); maliyet, hız ve kalitedir.

İlk ikisi açık. Daha fazla context daha pahalı ve daha yavaş. Davranışı değiştiren üçüncüsü: gereksiz context sonucu kötüleştirir. Asistan dikkatini, ilgili olsun olmasın verdiğin her şeye yayar.

Ekibe verdiğim kurallar:

Yalnızca ilgili dosyayı ver.
Bir seferde tek problem.
Uzun cevap değil, hedefli düzeltme iste.
Gerçekten istemiyorsan "dosyayı baştan yaz" deme.
Konuşma uzayınca yenisini başlat.

Yapamadıkları

Bir slayt sınırları listeliyor, çünkü yalnızca satış yapan bir oturum mühendislerin işine yaramaz:

Gerçek kök nedeni her zaman bulamaz.
İş mantığının doğrusunu bilemez.
Hangi düzeltmenin mimariye uyduğunu seçemez.
Hiçbir şey çalıştırmadan "çalışıyor" diyemez.

Uygulamak asistanın işi. Karar sende kalıyor.

Ekipten istediğim

Oturum bir araç listesiyle değil, bir alışkanlıkla bitti: günde bir bug'ı bu şekilde düzelt. Az context, adı konmuş kalıplar ve her seferinde bir doğrulama adımı.

Bir kas gibi çalışıyor. Dört adıma slaytta katılmak kolay, teslim tarihi altında uymak zor. Büyük bug'larda otomatik hale gelmesini sağlayan, küçük bug'lardaki tekrar.