AI Coding Assistant'lar Gerçekte Ne Kadar Yardım Ediyor? Araç Türleri, Kanıtlar ve Doğru Beklenti

Sürüm notu: Bu yazıdaki kodlar .NET 10 ile derlenip denenmiştir; model çıktıları yerel Ollama 0.34.4 üzerinde qwen3:4b ve gemma3:12b ile alınmıştır. Araç ve araştırma bilgileri 2026-11 itibarıyladır.

Önce Tahmin Et

2025'in başında METR (AI modellerinin yeteneklerini ve risklerini ölçen bağımsız bir araştırma kuruluşu) 16 deneyimli open-source geliştiriciyle bir deney yaptı. Geliştiriciler, yıllardır katkı verdikleri büyük repo'lardan (ortalama 22 binin üzerinde yıldız ve bir milyonun üzerinde satır kod) 246 gerçek issue seçti. Her issue rastgele iki gruptan birine düştü: AI kullanmak serbest ya da yasak. Serbest olanlarda çoğunlukla Cursor Pro ile Claude 3.5/3.7 Sonnet kullanıldı.

İşe başlamadan önce geliştiricilere sordular: AI işinizi ne kadar hızlandıracak? Ortalama cevap %24'tü. Deney bitince tekrar sordular: AI sizi ne kadar hızlandırdı? Bu sefer cevap %20 oldu. Peki ekran kayıtları ve süre ölçümleri ne dedi? Hızlanma %20'nin altında mıydı, üstünde mi, yoksa başka bir şey mi oldu? Bir sayı tahmin et; cevap yazının ortasında.

Bu seri, AI coding assistant ve coding agent'ları her gün kullanan ama çıkan kodun kalitesinden ve gerçekten kazandırıp kazandırmadığından emin olmayan .NET ve Angular geliştiricisi için. Araçların düğmelerini anlatmayacağız; her araç kendi serisinde (Claude Code, OpenAI Codex, Claude ile Çalışmak, ChatGPT ile Çalışmak) ayrıca ele alınıyor. Burada araçtan bağımsız olanı konuşacağız: hangi işe hangi tür araç, agent'a ne anlatmak gerekir, yazdığı kodu nasıl doğrularsın, güvenliği ve ekibi nasıl korursun. Örnekler sitedeki serilerin ortak örnek uygulaması Bookstore (bir online kitapçı) üzerinde.

Araç Yelpazesi: Completion'dan Cloud Agent'a

"AI ile kod yazıyorum" cümlesi çok farklı beş çalışma biçimini kapsıyor. Aralarındaki fark modelin zekâsında değil, bir adımda ne kadar iş yaptığında ve o işi kimin, ne zaman kontrol ettiğinde:

Son satıra bir örnek: GitHub'ın dokümanları 2026-11 itibarıyla bu türü "Copilot cloud agent" diye anıyor. Bir issue'yu Copilot'a atadığında GitHub Actions üzerinde geçici bir ortamda çalışıyor, copilot/ ile başlayan bir branch'e push ediyor ve draft pull request açıyor. Oturum en fazla 59 dakika sürüyor, tek repo ile sınırlı ve açtığı pull request'i bir insanın review edip merge etmesi gerekiyor.

Tabloyu yukarıdan aşağı okuyunca bir şey dikkat çekiyor: aşağı indikçe AI'ın bir seferde ürettiği iş büyüyor, ama kontrol noktası da seyrekleşiyor. Completion'da her satırı görürsün. Cloud agent'ta ilk gördüğün şey 14 dosyalık bir diff olabilir. Yani kazandığın yazma süresinin bir kısmını okuma ve doğrulama süresine geri ödüyorsun. Bu takas serinin her yazısında karşımıza çıkacak. IDE içindeki özelliklerin turu IDE'ler serisinin 9. yazısında; burada türlerin ortak davranışına bakıyoruz.

Küçük Bir Deney: İzole Görev ve Repo'ya Bağlı Görev

Önce iki görevi yerel bir modele verdim. Bulut sağlayıcıların modelleri bu küçük modellerden çok daha güçlü; deneyin amacı bir modeli puanlamak değil, görev türünün sonucu nasıl etkilediğini görmek. İlk görev tamamen izole: kitapların uluslararası standart numarası ISBN'i (13 haneli sürümü ISBN-13) doğrulayan bir method. Prompt şuydu:

Write a C# 14 static class `Isbn13` with a method `public static bool IsValid(string? isbn)` that checks an ISBN-13.
Hyphens and spaces may appear between digits and must be ignored. Return false for null, wrong length or a wrong check digit.
Reply with the code only, in one ```csharp block.

qwen3:4b, 85 token'lık bu prompt'a cevap vermeden önce 6.668 token boyunca kendi kendine düşündü (184 saniye). Bu sırada yanlış bir örnek ISBN üzerinde hesap yapıp kafası karıştı, sonra toparladı. Son cevap şu oldu:

public static class Isbn13
{
    public static bool IsValid(string? isbn)
    {
        if (isbn == null)
            return false;

        var cleaned = new string(isbn.Where(c => char.IsDigit(c)).ToArray());

        if (cleaned.Length != 13)
            return false;

        int total = 0;
        for (int i = 0; i < 12; i++)
        {
            int digit = cleaned[i] - '0';
            int weight = (i % 2 == 0) ? 1 : 3;
            total += digit * weight;
        }

        int checkDigit = (10 - (total % 10)) % 10;

        return cleaned[12] - '0' == checkDigit;
    }
}

Okunaklı, ağırlıklar doğru, check digit formülü doğru. Bir demo'da The Hobbit'in ISBN'ini verip true görsen ikna olursun. Ben bunun yerine kodu değiştirmeden bir .NET 10 file-based app'in (tek .cs dosyasıyla dotnet run ile çalışan uygulama) sonuna ekledim ve vakaları kendim yazdım:

#:property PublishAot=false
// Kod qwen3:4b'nin yazdığı gibi duruyor; vakaları biz yazdık
(string? Input, bool Expected)[] cases =
[
    ("9780261102217", true),        // The Hobbit, Bookstore seed'inden
    ("978-0-261-10221-7", true),    // aynı ISBN, tireli
    ("978 0 261 10221 7", true),    // aynı ISBN, boşluklu
    ("9780261102218", false),       // yanlış check digit
    ("978026110221", false),        // 12 hane
    (null, false),
    ("ISBN 9780261102217", false),  // spec'e göre harf kabul edilmez
    ("9780261102217-X", false),     // sonda fazladan karakter
];

int failed = 0;
foreach ((string? input, bool expected) in cases)
{
    bool actual = Isbn13.IsValid(input);
    string mark = actual == expected ? "ok  " : "FAIL";
    if (actual != expected) failed++;
    Console.WriteLine($"{mark} {input ?? "null",-22} expected={expected,-5} actual={actual}");
}
Console.WriteLine($"{cases.Length - failed}/{cases.Length} passed");

> dotnet run isbn-check.cs
ok   9780261102217          expected=True  actual=True
ok   978-0-261-10221-7      expected=True  actual=True
ok   978 0 261 10221 7      expected=True  actual=True
ok   9780261102218          expected=False actual=False
ok   978026110221           expected=False actual=False
ok   null                   expected=False actual=False
FAIL ISBN 9780261102217     expected=False actual=True
FAIL 9780261102217-X        expected=False actual=True
6/8 passed

Prompt yalnız tire ve boşluğun yok sayılmasını istiyordu; model rakam olmayan her karakteri silmeyi seçti. Sonuç, "ISBN" önekli ya da sonunda çöp olan girdileri sessizce geçerli sayan bir method. Bir API'de bu, veritabanına beklemediğin biçimde değer yazılması demek. Hata zor değil, ama happy path'i deneyen bir demo'da asla görünmez. Bir not daha: ilk denemede file-based app derlenmedi, çünkü repo'daki TreatWarningsAsErrors ayarı, file-based app'in varsayılan AOT (uygulamayı önceden makine koduna derleme) bağımlılığındaki bilinen bir güvenlik açığı uyarısını hataya çevirdi. #:property PublishAot=false satırı bu yüzden var; bu tür uyarıları beşinci yazıda tekrar göreceğiz.

İkinci görev Bookstore'a bağlı. Bu sefer gemma3:12b'ye, repo'dan tek dosya göstermeden şunu sordum:

Our Bookstore web API runs on .NET 10. Add an endpoint that returns the books of one category,
for example GET /api/categories/classics/books. Show the code you would add or change, with file names.

Model 143 saniyede uzun ve kendinden emin bir cevap yazdı. Önerdiği dosya yapısı ve kayıt kodu şöyleydi (cevaptan kısaltılmış, kod aynen):

Bookstore.Api/
├── Models/
│   ├── Book.cs
│   └── Category.cs
├── Services/
│   └── IBookService.cs
│   └── BookService.cs  (Implementation - optional)
├── Controllers/
│   └── BooksController.cs
├── Startup.cs
└── Program.cs

[HttpGet("categories/{categoryId}/books")]
public ActionResult<IEnumerable<Book>> GetBooksByCategory(int categoryId)

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        // ... other services ...

        services.AddScoped<IBookService, BookService>(); // Register the service
    }

Cevapta bir derleme hatası bile yok; sorun, cevabın bizim projemize ait olmaması. Bookstore Minimal API ve module klasörleriyle yazılmış, model MVC (Model-View-Controller; controller class'larıyla çalışan klasik yapı) controller'ları ve .NET 6 öncesi proje şablonlarından kalma bir Startup.cs önerdi. Bookstore'da zaten bir Book entity'si ve Entity Framework Core context'i var, model Bookstore.Models altında ikinci bir Book ile içinde dört kitaplık sabit bir liste tutan bir service yazdı. İstenen yol /api/categories/classics/books iken controller'ın route'u /api/books/categories/1/books oldu ve kategori slug yerine int id ile arandı. Kategoride kitap yoksa 404 dönüyor, test yok. Model bunların hepsini "reasonable assumptions" diye açıkça yazmış; varsayım yapmaktan başka şansı yoktu, çünkü repo'yu görmedi.

İki deneyin farkı, araştırmaların neden birbirinden bu kadar farklı sonuç verdiğini de açıklıyor. İzole, doğrulaması kolay bir görevde model hızlı ve çoğunlukla doğru. Repo'ya bağlı bir görevde kalite, modele ne kadar context verdiğine ve çıktıyı ne kadar dikkatli kontrol ettiğine bağlı.

METR 2025: Hızlandığını Sanıp Yavaşlamak

Girişteki soruya dönelim. METR'in 10 Temmuz 2025'te yayımladığı ölçümde, AI serbest olan issue'lar ortalama %19 daha uzun sürdü. Geliştiriciler %24 hızlanma bekledi, %20 hızlandıklarını düşündü, ölçüm ise yavaşlama gösterdi. Algı ile ölçüm arasındaki bu fark, çalışmanın en çok alıntılanan kısmı oldu.

Sonucu doğru okumak için çalışmanın sınırlarını da METR'in kendi sayfasından okumak gerekiyor. Çalışma; geliştiricilerin büyük kısmının ya da başka alanlardaki geliştiricilerin AI ile yavaşladığını göstermiyor. Daha iyi bir kullanım biçiminin ya da sonraki modellerin aynı ortamda hızlandırmayacağını da göstermiyor. Örneklem 16 kişi; AI'ın çok işe yaradığına inanan geliştiricilerin katılmamış olabileceğini, yaklaşık 50 saatten fazla Cursor kullanımıyla gelen öğrenme etkisini dışlayamadıklarını da yazıyorlar. METR, yavaşlamayı açıklayabilecek 20 etkeni incelemiş ve bunlardan beşinin büyük ihtimalle katkı yaptığına dair kanıt bulmuş.

Benim için çalışmanın asıl dersi rakam değil, ortam: codebase'i çok iyi bilen, kalite çıtası yüksek, büyük ve olgun bir projede çalışan uzman. Bu kişinin kafasındaki bağlam, modele verilebilen context'ten çok daha zengin. Modelin önerisini anlamak, düzeltmek ve beklemek, işi kendi yapmaktan uzun sürebiliyor. Senin günlük işin bu ortama ne kadar benziyorsa, bu sonucu o kadar ciddiye almalısın.

METR 2026 Güncellemesi: Sonuç Neden Hâlâ Belirsiz

METR Ağustos 2025'te aynı tasarımla daha büyük bir çalışma başlattı ve 24 Şubat 2026'da sonuçlarını yayımladı: 57 geliştirici (10'u ilk çalışmadan), 143 repo, 800'ün üzerinde görev. METR'in işaret düzeninde negatif değer daha hızlı bitirmek demek. İlk çalışmadan dönen geliştiriciler için tahmin -%18, güven aralığı -%38 ile +%9 arası. Yeni katılanlar için tahmin -%4, güven aralığı -%15 ile +%9 arası.

Bu rakamlar bazı ikincil kaynaklarda "AI artık %18 hızlandırıyor" diye aktarıldı. METR'in kendi yorumu çok daha temkinli: ham sonuçların bir miktar hızlanmaya işaret ettiğini, geliştiricilerin 2025 başına göre muhtemelen daha çok hızlandığını, ama bu artışın büyüklüğü için verinin çok zayıf bir kanıt olduğunu söylüyor. Güven aralığının üst ucu hâlâ yavaşlamayı içeriyor.

Belirsizliğin nedenleri de öğretici. Geliştiricilerin bir kısmı artık AI olmadan çalışmayı kabul etmedi; %30 ile %50 arası, AI olmadan yapmak istemedikleri bazı görevleri çalışmaya hiç getirmediğini söyledi. Yani AI'ın en çok kazandırdığı görevler ve AI'a en çok inanan geliştiriciler örneklemden düşmüş olabilir. Ücretin saatlik 150 dolardan 50 dolara inmesi de katılımı etkilemiş. Birden çok agent'ı aynı anda çalıştıran geliştiricilerin süresini ölçmek de güvenilir olmamış. METR bu yüzden tasarımını değiştirdiğini yazıyor. Senin için çıkarım şu: AI'ın verimliliğe etkisini ölçmek, en dikkatli araştırmacılar için bile zor. "Bizim ekip %40 hızlandı" diyen bir slayt gördüğünde ilk sorun, bunun nasıl ölçüldüğü olmalı.

DORA 2025: AI Bir Amplifier

İkinci önemli kaynak DORA (DevOps Research and Assessment; Google bünyesinde yazılım teslim performansını yıllardır araştıran program). 2025 raporu, 13 Haziran ile 21 Temmuz 2025 arasında yapılan anket ve yaklaşık 5.000 teknoloji çalışanının cevabına dayanıyor. Bulgular METR ile çelişmiyor, başka bir soruya cevap veriyor: AI kurum içinde hangi koşullarda işe yarıyor?

Katılımcıların %90'ı işinde AI kullanıyor ve %80'den fazlası verimliliğinin arttığına inanıyor. Aynı kişilerin %30'u AI'ın ürettiği koda az (%23) ya da hiç (%7) güvenmiyor; %46'sı biraz, %20'si çok, %4'ü ise tamamen güveniyor. Rapor bunu olgun bir kullanımın işareti sayıyor: geliştiriciler AI çıktısına, Stack Overflow'dan aldıkları bir cevaba yaklaştıkları gibi temkinle yaklaşıyor. Kullanmak ile güvenmek arasındaki bu fark, serinin dördüncü yazısında konuşacağımız review alışkanlığının gerekçesi.

Raporun teslimatla ilgili bulgusu daha dikkat çekici: AI kullanımı artık throughput'u (ekibin değişiklikleri production'a taşıma hızı) artırıyor, bu önceki yıla göre bir değişiklik. Ama instability'yi (değişikliklerin ne sıklıkla geri alma ya da acil düzeltme gerektirdiği) hâlâ artırıyor. Ekipler hızlanmaya uyum sağlamış, hızlanan kodu güvenle teslim edecek sistemleri henüz kuramamış. Raporun ana mesajı da buradan geliyor: AI bir amplifier; kurumun güçlü yanlarını da zayıf yanlarını da büyütüyor. Testi zayıf, review'u yüzeysel, deploy'u zor bir ekipte AI daha çok ve daha hızlı sorun üretiyor. DORA'nın bunun için önerdiği yedi temel yeteneği (net bir AI politikası, küçük adımlarla çalışmak, sağlam version control pratikleri gibi) altıncı yazıda ekip politikası konuşurken ele alacağız.

Vibe Coding ve Augmented Coding

Deneydeki ISBN örneğinde ben ne yaptım? Modelin kodunu kabul etmeden önce ne yapması gerektiğini vakalarla yazdım ve sonucu ölçtüm. Kent Beck (Extreme Programming'in ve TDD'nin (önce testi sonra kodu yazma yaklaşımı) öncüsü) Haziran 2025'te bu farkı iki isimle anlattı. Vibe coding'de koda bakmazsın, yalnız sistemin davranışına bakarsın; hata çıkınca hatayı AI'a geri verir, yeterince iyi bir düzeltme gelmesini umarsın. Augmented coding'de kodun kendisi önemlidir: karmaşıklığı, testleri, test coverage'ı. Çıta, elle yazdığın kodla aynıdır; fark, çok daha az klavyeye dokunmandır.

Beck bu yazıda bir B+ tree library'sini AI ile geliştirirken modelin yoldan çıktığını gösteren üç işaret sayıyor: aynı yerde dönüp durmak, istenmemiş bir işlevi (makul bir sonraki adım bile olsa) eklemek ve testleri devre dışı bırakmak ya da silmek gibi hile sayılabilecek hamleler. Üçü de bu serinin dördüncü yazısındaki review checklist'inde karşımıza çıkacak. Beck'in çözümü de tanıdık: agent'a bir plan dosyası, TDD döngüsü ve "yapısal değişiklikle davranış değişikliğini aynı commit'e koyma" gibi kurallar vermek. Bunun Bookstore'daki karşılığını ikinci ve üçüncü yazıda kuracağız.

Vibe coding her zaman yanlış değil. Bir kez çalıştırıp atacağın bir script, bir prototip, kimsenin bakım yapmayacağı bir deneme için koda bakmamak makul bir takas. Sorun, prototip için kabul edilebilir olan alışkanlığın Bookstore'un sipariş akışına taşınması.

Doğru Beklenti: Hangi İşte Ne Kadar Yardım

Kanıtları ve deneyi birleştirince ortaya kaba ama işe yarar bir harita çıkıyor. AI'ın en çok kazandırdığı işler, doğruluğu hızlı kontrol edilebilen ve az context isteyen işler: tekrar eden kod, DTO (katmanlar arasında veri taşıyan basit class) ve mapping, test iskeleti ve test verisi, bilmediğin bir kod parçasını açıklatmak, bir regex'i ya da SQL sorgusunu taslak olarak yazdırmak, tek seferlik script'ler. Orta seviye kazanç, iyi yapılandırılmış ve testleri olan bir repo'daki sınırları belli özelliklerde geliyor; orada agent'ın verdiğin context'i ne kadar iyi kullandığı belirleyici. Kazancın küçük, hatta negatif olabildiği yerler ise METR'in ortamına benzeyenler: çok iyi bildiğin büyük ve olgun bir codebase, belirsiz gereksinim, güvenlik açısından kritik kod ve öğrenmek için yaptığın işler.

Kendi durumunu ölçmek istiyorsan satır sayısıyla değil görevle ölç. Birkaç hafta boyunca görevlerini başlamadan önce tahmin et, AI ile ya da AI olmadan yaptığını not et, gerçek süreyi ve sonradan gelen düzeltmeleri yaz. METR'in tasarımının küçük bir kopyası bu; mükemmel değil, ama "bence hızlandım" hissinden iyidir. Ekip düzeyinde ölçümü altıncı yazıda konuşacağız.

Üretimde Dikkat

AI'ın yazdığı kod, insanın yazdığı kodla aynı kapılardan geçmeli: build, test, review, statik analiz, güvenlik taraması. "AI yazdı, hızlıca bakıp geçelim" diye ayrı ve gevşek bir yol açtığın anda DORA'nın gördüğü instability artışı senin ekibinde de görünür. Cloud agent kullanıyorsan, açtığı pull request'lerin CI'ı otomatik çalıştırmadan önce onay gerektirip gerektirmediğine ve branch protection kurallarının agent için de geçerli olduğuna bak.

Ölçüm tarafında yanıltıcı metrikleri baştan ele. Kabul edilen öneri oranı ve üretilen satır sayısı, kod ne kadar çok yazılırsa o kadar iyi görünür; oysa review süresi, geri alınan değişiklikler ve production hataları gerçek maliyeti gösterir. Maliyetin bir de doğrudan tarafı var: token ve kredi. Örneğin GitHub'ın dokümanı, Copilot code review'un pull request başına ortalama maliyetini effort seviyesine göre yaklaşık 0,25 ile 10 dolar arasında veriyor. Bu tür fiyatlar sık değişiyor; karar vermeden önce sağlayıcının güncel sayfasına bak.

Son olarak, araç bilgisi çabuk eskiyor. Bu yazıdaki ürün adları ve limitler 2026-11 itibarıyla doğru; bir yıl sonra bazılarının adı değişmiş olacak. Ekip dokümanına araç özelliği yazarken tarih düş.

Sık Düşülen Tuzaklar

• Tek bir etkileyici demo'dan genelleme yapmak: demo happy path'i gösterir, ISBN örneğindeki gibi hata edge case'tedir.
• Verimliliği üretilen satır ya da kabul edilen öneri sayısıyla ölçmek: daha çok kod daha çok review ve bakım demek.
• Algıya güvenmek: METR'in geliştiricileri yavaşladıkları hâlde %20 hızlandıklarını düşündü.
• Araç türünü işe göre seçmemek: bir satırlık düzeltmeye cloud agent, belirsiz bir mimari karara completion kullanmak.
• Bağlam vermeden repo'ya bağlı iş istemek ve çıkan kodu projenin kurallarıyla karşılaştırmamak.
• AI'ın yazdığı kod için review ve test çıtasını düşürmek: yeşil build, kodun doğru olduğunun kanıtı değil.

Küçük Bir Deneme

★☆☆ isbn-check.cs dosyasındaki Isbn13.IsValid method'unu, yalnız rakam, tire ve boşluğa izin verecek şekilde düzelt. İki FAIL satırı ok olmalı, diğer altı vaka bozulmamalı. Sonra char.IsDigit'in Arapça-Hint rakamları gibi ASCII (temel Latin karakter seti) dışındaki rakamları da kabul ettiğini dene; bunun için de bir vaka ekle.

★★☆ Bu hafta yaptığın beş görevi seç. Her birine başlamadan önce süre tahmini yaz, AI kullanıp kullanmadığını ve gerçek süreyi not et. Hafta sonunda, sonradan düzeltmek zorunda kaldığın değişiklikleri de ekleyip tabloya bak: hissin ile ölçüm aynı yönü mü gösteriyor?

★★★ Aynı repo'ya bağlı görevi (bir kategorinin kitaplarını döndüren endpoint) kullandığın agent'a hiçbir dosya göstermeden ver. Çıkan diff'te projenin kurallarına uymayan her şeyi işaretle: dosya yeri, endpoint stili, test, isimlendirme. Bu listeyi sakla.

O liste, bir sonraki yazının girdisi. Agent'ın repo'yu bilmemesi çözülemez bir sorun değil; build komutlarını, katman kurallarını ve yasakları kısa bir dosyada anlatabilirsin. İkinci yazıda Bookstore için bir AGENTS.md (agent'lara repo'yu anlatan talimat dosyası) yazıp aynı görevi tekrar vereceğiz ve farkı ölçeceğiz.