1.3 Milyon Satır, Haftada 630 PR: Vibe-Coded Kod Tabanını Nasıl Sürdürülebilir Tutuyoruz

Temmuz 2026'da Robert C. Martin şunu yazdı: artık kodlama ajanlarının ürettiği kodu okumuyor.

Bu açıklama oldukça ilgi çekti. Ancak gönderisinin geri kalanı, nasıl çalıştığını anlamak için daha önemli. Martin, ajanları birim testleri, Gherkin kabul testleri, QA prosedürleri, mutasyon testleri, kapsam kontrolleri ve kalite metrikleriyle çevreliyor. Kod, bu sistemden geçerek güvenini kazanıyor.

Birkaç ay önce de benzer bir noktaya değinmişti. Uygulamayı incelemek yerine test kapsamına, bağımlılık yapısına, çevrimsel karmaşıklığa, modül boyutuna ve mutasyon testi sonuçlarına bakıyor. İnsanlar bunu tamamen incelemeden vazgeçmek olarak yorumlayınca, açıklık getirdi: "Çokça inceleme yapıyorum — sadece kodu değil."

Yorumları, yapay zekâ ağırlıklı yazılım geliştirmede pratik bir sorunu tanımlıyor. Kodlama ajanları, insanların okuyabileceğinden daha hızlı değişiklik üretebiliyor. Yapay zekâ tarafından üretilen kodun hacmi ekibin inceleme kapasitesini aştığında, satır satır inceleme artık tek güven kaynağı olamaz.

Biz de son sekiz aydır vm0'da aynı sorunla uğraşıyoruz. Depomuzdaki uygulamanın çoğu ajanlar tarafından yazılıyor — popüler kısaltmayla vibe coding — ve altı mühendis, bu kodun üretimde ne yaptığı konusunda sorumluluğu sürdürüyor.

Kısa özet

vm0 bir vibe-coded kod tabanıdır: ajanlar uygulamanın çoğunu yazar, altı mühendis ise üretimdeki davranışından sorumludur. Sekiz ay sonunda depo 1,329,170 satır ve tek bir haftada 630 birleştirilmiş pull request içeriyor. Satır satır incelemenin tek başına taşıyamayacağı kalite yükünü beş mekanizma üstleniyor.

• Yakınsayan ortamlar. Mühendisler ve ajanlar aynı geliştirme konteynerinde çalışır, her pull request kendi veritabanı dalını alabilir. Bir ajan için çalışan komut, bir kişi için de çalışır.
• Çalıştırılabilir kısıtlar. Sıkı TypeScript, yaklaşık 135 tipli API kontrat modülü, Oxlint, ESLint ve mimari kurallar; CI hiçbir uyarıyı kabul etmez. Mekanik olarak kontrol edilebilen bir kural, incelemeye bırakılmaz.
• Sınır odaklı testler. Test piramidi yerine test kupası: entegrasyon testleri, gerçek PostgreSQL ve gerçek göçler, sadece dış sistemlerde mock. Test kodu, deponun yaklaşık %36'sını oluşturur.
• Tam geri bildirim döngüleri. Ajanlar uygulamayı ve veritabanını başlatır, göçleri çalıştırır, gerçek bir tarayıcıyı yönetir, ardından çalıştırdıkları komutları, test ettikleri yolu ve ekran görüntülerini raporlar. Medyan pull request yaklaşık 53 dakikada birleştirilir.
• Sürekli temizlik. Knip, ölü kodu deterministik olarak kaldırır, günlük iş akışları AI kalıntılarını temizler, sık tekrarlanan bir desen ise lint kuralına veya tip sistemine terfi ettirilir.

Vibe coding ve agentic coding gerçekte ne demek

Vibe coding, bir LLM'den kod istemek, üretileni çalıştırmak, değişiklik istemek ve üretilen koda hiç dikkat etmemektir. Martin Fowler'ın tanımı özellikle dardır ve "kodun varlığını bile unutmak" ifadesini vurgular. Prototipler, atılabilir yazılımlar ve sınırlı sonuçları olan küçük araçlar için uygundur.

Agentic coding, Fowler'ın agentic programming dediği, ekibin sonucu sürdürmeyi beklediği durumdur. Bir ajan depoyu okur, dosyaları düzenler, testleri çalıştırır ve uzun süre bağımsız çalışır; insanlar ise yapı ve davranışın sahipliğini sürdürür ve bir çalıştırmanın ürettiği kanıtı inceler: test sonuçları, kalite sinyalleri, önizlemeler ve üretim davranışı.

Fark, bir modelin ne kadar kod yazdığı değil, insan dikkatinin nereye gittiğidir.

	Vibe coding	Agentic coding
Ajan özerkliği	Prompt, çalıştır, tekrar prompt	Depoyu okur, düzenler, test eder, iterasyon yapar
Kodu kim okur	Kimse	Risk taşıyanı insanlar okur
Ne doğrulanır	Çıktı doğru görünüyor mu	Tipler, kontratlar, testler, önizlemeler, üretim sinyalleri
En uygun kullanım	Prototipler ve atıl araçlar	Bakım ufku olan yazılım
Tipik hata	Kimsenin anlamadığı kod	Hacme göre zayıf doğrulama

Depoyu düzenleyen ajanlar, daha geniş bir değişimin bir dalıdır; geliştirici olmayan tarafını ayrıca inceledik.

vm0'ı sıkça vibe-coded proje olarak adlandırıyoruz çünkü bu ifade, esas olarak yapay zekâ tarafından yazılan yazılımlar için yaygın bir kısaltma haline geldi. Fowler'ın terimleriyle ise agentic coding'e daha yakındır. Mühendislerimiz, eskisine göre daha az uygulama kodu yazıyor, ancak mimari, bakım maliyeti ve üretim davranışının sahipliğini sürdürüyor.

Kod üretimi hızlandıkça, bu sorumluluğun daha fazlası geliştirme ortamına, tip sistemine, test paketine ve otomatik bakım iş akışlarına taşındı.

Vibe-coded kod tabanında sekiz ayda büyüme

vm0 deposu Kasım 2025'da oluşturuldu. Son haftalık mühendislik ölçek raporumuzun zamanında, yaklaşık sekiz buçuk aylıktı.

Depoda şunlar vardı:

Metrik	Sayı
Boş olmayan mantıksal satır	1,329,170
Üretim satırı	850,913
Test satırı	478,257
Kaynak dosya	5,549
Test dosyası	1,327
Paket	44
Ana dalda commit	14,005

Bu sayılar, Temmuz 20–26, 2026 haftası için haftalık mühendislik ölçek raporumuzdan, doğrudan monorepo'dan ölçülmüştür. Test kodu, ölçülen kod tabanının yaklaşık %36'sını oluşturuyordu. Bu, test kapsamı değil, kod hacmi oranıdır; ancak doğrulama etrafında ne kadar uygulama biriktiğine dair bir fikir verir.

Son üç tam haftada altı mühendis sırasıyla 541, 640 ve 631 commit yaptı. Temmuz 20–26 haftasında GitHub, 630 birleştirilmiş pull request kaydetti. Altı mühendis bunların 556'sini yazdı, kalan 74 ise sürüm otomasyonu tarafından oluşturuldu.

Bir pull request'in açılmasından birleştirilmesine kadar geçen medyan süre yaklaşık 53 dakikaydı. %90'lık dilimde ise yaklaşık 7.4 saatti.

Bu değişim hızında, insan incelemesi hâlâ faydalı ancak tüm kalite sistemini taşıyamaz. Değişiklik yaşam döngüsünün birkaç noktasında bağımsız sinyallere ihtiyacımız var.

Mevcut yaklaşımımızda beş tekrar eden tema var: yakınsayan ortamlar, çalıştırılabilir kısıtlar, sınır odaklı testler, tam geri bildirim döngüleri ve sürekli temizlik.

Geliştirme ortamını dev container ile yakınsama

Yeniden üretilemeyen birçok hata, bir pull request'te hiç görünmeyen durumdan kaynaklanır.

Bir geliştiricinin belgelenmemiş bir ortam değişkeni, küresel olarak kurulu bir aracı, eski bir yapılandırma dosyası veya aylardır çalışan bir veritabanı olabilir. İnsanlar bu ayrıntılara alışır. Ajanlar genellikle bunları göremez.

Zamanla ana makineyi standart geliştirme ortamı olarak kullanmayı bıraktık. Mühendisler ve ajanlar bir dev container içinde çalışıyor. Geliştirme imajı, proje araç zincirini, PostgreSQL, pgvector, Chromium ve tarayıcı otomasyon araçlarını içerir.

CI, aynı çok aşamalı Dockerfile ailesinden oluşturulan sürümlü araç zinciri imajlarını çalıştırır. Geliştirme ve CI imajları farklı amaçlara hizmet eder, üretimin ise kendi dağıtım şekli vardır. Faydalı özellik yakınsamadır: araç sürümleri, bağımlılıklar ve çalışma zamanı varsayımları açık ve sürümlüdür.

Bu bize basit bir beklenti sunar. Bir ajanın çalıştırdığı komutlar, aynı geliştirme konteynerinde bir mühendis tarafından da tekrarlanabilmelidir. Geliştirme sırasında geçen kontroller, CI'da yakından ilişkili bir araç zinciriyle çalıştırılmalıdır.

Benzer bir fikri veriye de uyguluyoruz. Her pull request önizlemesi kendi veritabanı dalına sahip olabilir ve gerçek göçler ve tohum adımlarını çalıştırabilir. Bir ajan veri oluşturabilir, değiştirebilir ve yıkıcı testleri tekrar tekrar yapabilir; bunun için bir geliştiricinin mevcut veritabanını ödünç almasına veya başka bir pull request'ten durum devralmasına gerek yoktur.

Ortam değişiklikleri depo üzerinden taşınır. Araç yükseltmeleri, tarayıcı sürümleri ve veritabanı uzantıları, uygulama koduyla aynı şekilde gözden geçirilir ve yayılır.

Mühendislik standartlarını tiplerde ve lint kurallarında çalıştırılabilir yapmak

Yazılı standartlar, insanların tasarım kararlarını anlamasına yardımcı olur. Ancak özellikle uzun ajan oturumlarında, her değişikliğin bu kararlara uyduğunu garanti etmez.

Kararlı kuralları, kural güvenilir şekilde ifade edilebiliyorsa tip sistemine, linterlara ve CI'a koyuyoruz.

vm0, strict ve noUncheckedIndexedAccess dahil olmak üzere sıkı TypeScript ayarları kullanır. Bazı paketler, kullanılmayan değerler ve örtük dönüşler için ek kontroller etkinleştirir.

API, tRPC'nin tip mekanizması ve Zod şemalarıyla oluşturulmuş şema-öncelikli tipli bir REST kontrat katmanı kullanır. Drizzle, veritabanı erişimini TypeScript tiplerine bağlar. Bu inceleme sırasında depoda yaklaşık 135 kontrat modülü vardı.

Bu tercihler yanlış ürün kararlarını yakalamaz. Ancak arayüz kaymasını erken ortaya çıkarır. Bir alan veya yanıt değiştiğinde, ilgili çağrılar genellikle statik analiz sırasında başarısız olur. Ortaya çıkan hata, genellikle bir ajanın bir sonraki iterasyonda kullanabileceği kadar özeldir.

Linting ikinci bir kural grubunu kapsar. Platform Oxlint, tip farkındalıklı kontroller ve ESLint ile proje özelinde mimari kurallar çalıştırır. CI hiçbir uyarıyı kabul etmez. Süresiz kalabilen uyarılar arka plan gürültüsüne dönüşür ve hem insanlar hem de ajanlar için kolayca göz ardı edilir.

Bir sorun tekrarlandığında, kontrolün nereye ait olduğunu değerlendiriyoruz:

1. Tip sistemi bunu ifade edebilir mi?
2. Bir linter veya yapısal araç bunu doğru tespit edebilir mi?
3. Depo genelinde anlamsal yargı gerektiriyor mu?

İlk ikisi her değişiklikte hızlı, deterministik geri bildirim sağlar. Üçüncü grubu ise bu makalede daha sonra açıklanan tekrar eden iş akışlarıyla ele alıyoruz.

Yapay zekâ tarafından üretilen kodda hata eğilimli desenleri daraltmak

Bazı dil özelliklerinin meşru kullanımları vardır ve aynı zamanda kırılgan ajan kodunda sıkça görülür.

try/catch bir hata sınırını bulanıklaştırabilir. Bir ajan bir hatayla karşılaştığında, bir catch bloğu ve yedek eklemek, mevcut yolu çalışır tutmanın kolay bir yoludur; ancak orijinal hatayı kaybettirir. Promise .then() ve .catch() ile async/await'yi karıştırmak, kontrol akışını birkaç stile yayabilir.

React'ın useEffect özelliği, durum yönetiminde benzer bir sorun yaratır. Genellikle durumu kopyalamak, iki doğruluk kaynağını senkronize etmek veya veri modelinden görülmesi zor bir sıralama bağımlılığını kodlamak için kullanılır.

Çekirdek web platformu bu desenleri varsayılan olarak sınırlar. Gerekçeli bir istisna, yanında açık bir açıklama ile kalabilir.

Çekirdek web platformundaki üretim kodunda şu anda hiç useEffect yok. Bağımlılıkları ve yan etkileri daha açık modellemek için ccstate ve diğer etkisiz desenleri kullanıyoruz. Monorepo'nun başka yerlerinde, çoğunlukla paylaşılan UI ve masaüstü kodunda az sayıda üretim useEffect çağrısı hâlâ mevcut, bu yüzden iddianın kapsamı önemlidir.

Bu kurallar, bu depoda tekrar eden hatalardan doğdu. Bir desen sürekli aynı bakım sorununu yaratıyorsa, onu inceleme rehberliğinden çalıştırılabilir bir kısıta taşırız.

Modül sınırlarında test: test kupası, piramit değil

vm0 geleneksel bir test piramidi izlemez. Test rehberimiz bir test kupasını tanımlar: tabanda statik analiz, baskın katmanda entegrasyon testleri ve kritik kullanıcı yolculukları için az sayıda uçtan uca test.

Birim testler nispeten nadirdir. Güvenlik hassasiyeti olan mantık, algoritmalar ve durum makineleri için seçici olarak kullanılır. Çoğu iş davranışı, bir modülün genel sınırı üzerinden test edilir.

API testleri, gerçek uygulamayı kontratları üzerinden çağırır. Test verisi, mümkün olduğunda üretim uç noktalarından hazırlanır ve doğrulamalar genel davranış üzerinden yapılır. Testler, doğrudan bir iç servise ulaşmaktan veya veritabanı tablolarını değiştirmekten kaçınır; çünkü bu, onları mevcut uygulamaya bağlar.

İç altyapı, maliyeti makul olduğu sürece gerçek kalır:

• PostgreSQL ve pgvector
• veritabanı göçleri
• dosya sistemi
• iç servisler
• dış sistem sınırlarında mock

Bu entegrasyon testleri, yüksek derecede izole birim testlerinden daha yavaş çalışır ve daha eksiksiz bir ortam gerektirir. Ayrıca "test geçti" ile "uygulama gerçek bir veritabanıyla bu işlemi yapabiliyor" arasındaki farkı azaltır.

Sınır testleri, büyük iç yeniden düzenlemelere alan bırakır. Bir ajan modülleri yeniden düzenleyebilir, bir servisi bölebilir veya veri erişim katmanını değiştirebilir; genel davranış ise korunur.

Uncle Bob farklı bir karışımı tercih eder: yoğun birim testleri, Gherkin ve mutasyon testi. Ortak ilke bağımsız doğrulamadır. Kodu üreten süreç, kodun çalıştığını iddia eden tek kaynak olmamalıdır.

Kodlama ajanlarına tam bir geri bildirim döngüsü sağlamak

İlk kodlama ajanı çalıştırmalarımız genellikle tanıdık bir raporla biterdi: kod değiştirildi ve TypeScript geçti; lütfen uygulamayı başlatıp sayfayı kontrol edin.

Bu, geliştirme döngüsünün yarısını mühendise bırakır. Birinin yine de bir veritabanı hazırlaması, servisleri çalıştırması, tarayıcı açması, veri oluşturması, hatayı gözlemlemesi ve bunu ajana geri bildirmesi gerekir.

Ajanlar artık geliştirme ortamının yeterli kısmına sahip, böylece bu işin daha fazlasını yapabiliyorlar. Uygulamayı ve veritabanını başlatabiliyor, göçleri çalıştırabiliyor, test verisi oluşturabiliyor, pull request önizlemesini ziyaret edebiliyor ve gerçek tarayıcı etkileşimleri gerçekleştirebiliyorlar.

Tarayıcı doğrulaması, tip kontrolleri ve API testlerinin iyi kapsayamadığı bir problem sınıfını yakalar: bozuk gezinme, hiç tamamlanmayan yükleme durumları, yalnızca tam akışta ortaya çıkan izin hataları ve görsel bozulmalar.

Bir çalıştırmanın sonunda ajan, yürüttüğü komutları, test ettiği yolu ve gözlemlediklerini raporlar. Kullanıcı arayüzü değişikliklerinde ekran görüntüleri de ekleyebilir. Bir mühendis, önizlemeyi şahsen açmaya karar vermeden önce bu kanıtı inceleyebilir.

Bir ekran görüntüsü test değildir ve başka hataların yokluğunu kanıtlamaz. Ajanın bağlamını yeniden oluşturma maliyetini düşürür. Küçük bir arayüz değişikliğinde, tekrarlanabilir adımlar ve son ekran görüntüsü, "değişiklik düzeltilmiş olmalı" mesajından çok daha faydalıdır.

Bir ajanın işinin kalitesi, bir kişiyi beklemeden elde edebileceği geri bildirime büyük ölçüde bağlıdır.

Dalları kısa tutmak için trunk-based development

Hızlı kod üretimi, çok sayıda dal birikimine yol açabilir.

Uzun ömürlü özellik dalları, birleştirme çatışmaları, yinelenen işler ve bayat bağlam biriktirir. Pull request'ler büyüdükçe inceleme zorlaşır ve yavaşlar. Dalları kısa tutmak ve main etrafında sürekli entegre olmak için trunk-based development kullanıyoruz.

Ana dal kurallarımız şunları gerektirir:

• değişiklikler için pull request
• doğrusal geçmiş ve squash birleştirmeler
• birleştirme kuyruğu
• Turbo, Rust ve güvenlik kontrolleri
• gerekli kontroller için rutin atlama yok

Otomasyon da aynı yolu izler. Bir ajan pull request oluşturabilir ve bazı düşük riskli bakım görevleri otomatik birleştirmeye izin verebilir; ancak değişiklik yine de CI ve birleştirme kuyruğundan geçer.

Pull request'lerin boyutu ve ömrü, bir haftada nasıl 630 tanesinin birleştirilebildiğini açıklar. Küçük bir değişiklik daha az bağlam taşır, doğrulaması daha kolaydır ve ürün çalışması veya başka bir otomatik onarımla çakışma olasılığı daha düşüktür.

Knip ile depo çöp toplama: ölü kodun kaldırılması

Kod üretimi doğal olarak dosya ve soyutlama ekler. Silme genellikle ayrı bir prompt gerektirir.

Bir refaktörden sonra eski dosyalar depoda kalabilir. Bir özelliğin kaldırılması, dışa aktarımlar, bağımlılıklar ve giriş noktaları bırakabilir. Bu artifaktlar nadiren testleri bozar, ancak zamanla kod tabanını gezinmeyi zorlaştırır.

Knip'i kullanılmayan dosyaları, dışa aktarımları, bağımlılıkları ve giriş noktalarını bulmak için kullanıyoruz. TypeScript kodun geçerli olduğunu doğrulayabilir; Knip ise hâlâ sistemde yer alıp almadığını sorar.

Bu kalıntının kodlama ajanları için ek bir maliyeti vardır. Depo, onların en önemli bağlam kaynaklarından biridir. Eski bir yardımcı veya terk edilmiş bir uygulama, sonraki ajana onaylanmış bir desen gibi görünebilir. Bu bağlamı temiz tutmak, bağlam mühendisliğinin göz ardı edilen yarısıdır: bir ajanın depodan okuduğu, verilen prompt kadar girdidir.

Ölü kodun kaldırılması, gelecekteki çalıştırmalar için mevcut girdileri de iyileştirir. Knip, bu işin deterministik kısmını yeterince hızlı halleder ve düzenli bir kalite kontrolüne dönüşür.

Tekrarlayan AI kalıntısı temizleme iş akışları

Knip ve ESLint'in net sınırları vardır. Birçok bozulma türü, proje bağlamı ve anlamsal yargı gerektirir.

Bu kalıntıya pratikte "AI slop" diyoruz: gereksiz yedekler, yinelenen soyutlamalar, genel sınırı atlayan testler veya imkânsız durumlar için savunmacı dallar. Her örnek zararsız görünebilir. Toplamda, depoyu anlamayı zorlaştırır ve sonraki ajanlara kötü örnekler sunar.

Birkaç tekrarlayan vm0 iş akışı bu desenleri programlı olarak tarar.

Günlük AI kalıntısı temizliği, yeni kalıntıları arar ve yüksek güvenli, düşük riskli küçük bir düzeltme seti seçer. Diğer iş akışları, iç servislere ulaşan API testlerini, React ve ccstate antipattern'lerini ve güvenli şekilde ele alınabilecek teknik borcu inceler.

Her iş akışı değişikliklerini dar tutar. Bir pull request açar, ardından normal tip kontrolleri, lint kuralları, testler ve birleştirme kuyruğuna güvenir. Otomatik birleştirme için yapılandırılmış bir pull request bile aynı kapılardan geçmek zorundadır.

Ajanları programlı olarak çalıştırmak ücretsiz değildir ve bu maliyetleri düşük tutmak hakkında ayrıca yazdık. İş akışları, teknik borcun tamamını tek seferde temizlemeye çalışmaz. Küçük günlük partiler, birkaç ayda bir yapılan büyük temizlikten daha kolay doğrulanır ve daha az bozucudur.

Bir tekrarlayan iş akışı aynı deseni yeterince sık bulursa, kontrolü ESLint, Knip veya tip sistemine taşımayı düşünürüz. Anlamsal iş akışı, kuralı daha ucuz deterministik bir kontrole dönüştürmeden önce gözlemleme ve iyileştirme alanı sunar.

Flaky test hatalarını otomatik onarımlara dönüştürmek

Başka bir iş akışı grubu, GitHub Actions hatalarından başlar.

Bir test ana dalda veya birleştirme kuyruğunda başarısız olduğunda, bir iş akışı günlükleri okur, kararsızlık kanıtı arar, tekrar denemeleri, zamanlamayı ve ortam faktörlerini inceler. Kanıt belirli bir onarımı destekliyorsa, testi veya uygulamayı günceller, bir pull request açar ve tam CI yolunu tekrar çalıştırır.

Tekrar denemede geçmek, orijinal hatayı zararsız yapmaz. Yeniden deneme butonuna güvenen ekipler, zamanla kırmızı derlemelere olan güvenini kaybeder. Bu olduğunda, başarısız kontroller başka bir arka plan gürültüsü biçimine dönüşür.

Otomatik onarım iş akışı, aralıklı bir hatayı izlenebilir bir kod değişikliğine dönüştürür. Tanı, yamalama ve doğrulama pull request'te görünür kalır. Mühendisler daha riskli değişiklikleri inceleyebilir, güçlü kanıtlı dar düzeltmeler ise birleştirme kuyruğundan geçebilir.

Kalite sistemimizde şu anda üç geniş katman var:

Aşama	Mekanizmalar	Tipik endişeler
Yazarken	TypeScript, kontratlar, Drizzle, ESLint	tip hataları, arayüz kayması, bilinen kod desenleri
Birleştirmeden önce	Knip, entegrasyon testleri, gerçek veritabanları, önizlemeler, birleştirme kuyruğu	ölü kod, modül davranışı, tam çalışma zamanı sonuçları
Birleştirdikten sonra	programlı ve olay tetiklemeli vm0 iş akışları	AI kalıntısı, anlamsal antipattern'ler, kararsız testler, mimari kayma

Katmanlar birbirini besler. İş akışlarında bulunan sorunlar statik kurallara dönüşebilir. CI veya üretimde bulunan hatalar test ve yeni mühendislik rehberine dönüşebilir.

Yapay zekâ tarafından üretilen kodun incelemesinde insan dikkati nereye gider

vm0 mühendisleri hâlâ kod okur, özellikle mimari değişiklikler, güvenlik hassasiyeti olan işler, ödemeler ve veri göçleri için. "Kodu asla okuma"yı ekip kuralı yapmadık.

Değişen, kod incelemesinde dikkatin dağılımı oldu. Kod okuma, kontratlar, test sınırları, önizleme davranışı, ekran görüntüleri, kalite metrikleri ve iş akışı teşhisleri arasında bir sinyaldir.

Bazı kararlar hâlâ deneyimli yargı gerektirir:

• gereksinimin tamam olup olmadığı
• modül sınırlarının nerede olması gerektiği
• hangi hataların kurtarılabilir olduğu
• bir hatanın ne kadar iş etkisi yaratabileceği
• güvenlik modelinin uygun olup olmadığı
• mevcut kuralların hangi yeni hata desenini kapsayamadığı

Benzer bir değişim tasarım tarafında da oldu; design-as-code görsel kararları aynı depoya ve aynı inceleme yoluna taşıdı. Mühendisler ayrıca ajanların çevresindeki ortamı da sürdürür. Bir sorun tekrarlandığında, tip kısıtı, lint kuralı, test veya tekrarlayan iş akışı ekleyip eklemeyeceğimize karar veririz. Geliştirme sistemi, başlı başına önemli bir mühendislik çıktısı haline geldi.

Okunabilir kod hâlâ önemlidir. Sonraki okuyucu bir mühendis veya başka bir ajan olabilir. Dolaşık kod daha fazla bağlam tüketir, gelecekteki değişikliklerin kapsamını genişletir ve doğrulamayı daha az güvenilir kılar.

Güvenlik ve hızlanmayan değişiklikler

Hız eşit dağılmaz. vm0, kendi hızında ilerleyen kısa bir değişiklik listesi tutar: güvenlik hassasiyeti olan işler, ödemeler, veri göçleri ve mimari kararlar. Bunları kim veya ne yazarsa yazsın, bir mühendis satır satır okur.

Yapay zekâ tarafından üretilen kodun güvenlik riski, deneyimimize göre, egzotik açıklar değil, kimsenin sahiplenmediği makul görünen koddur. Önemli olan kontroller sıradandır ve tutarlı uygulanır:

• Normalde az kullandığımız birim testleri, güvenlik hassasiyeti olan mantık, algoritmalar ve durum makineleri için özellikle kullanılır.
• Testler yalnızca dış sistem sınırlarında mock kullanır. İç altyapı gerçek kalır, böylece bir iç kontratı bozan değişiklik CI'da, üretimde değil, başarısız olur.
• Ajanlar, geliştiricinin makinesinde veya paylaşılan bir veritabanında değil, pull request başına bir veritabanı dalında dev container içinde çalışır.
• Birleştirme kuyruğu ve gerekli kontroller için rutin atlama yoktur; bir ajan tarafından açılıp otomatik birleştirme için işaretlenen pull request dahil.
• try/catch varsayılan olarak kısıtlıdır, böylece bir ajanın bir yolu çalışır tutmak için eklediği bir yedek tarafından bir hata yutulma olasılığı azalır.

Kimlik bilgisi yönetimi, kendi yanıtı olan ayrı bir tasarım problemidir: broker deseni ile token'ları bir ajanın eline geçirmemeyi ayrı bir makalede anlattık.

Bunların hiçbiri, üretilen kodu kendi başına güvenli yapmaz. İnsan kararının tek kontrol olduğu değişiklik kümesini daraltır ve bu kümeyi açık hale getirir.

Bu rakamların göstermediği şeyler

Haftalık rapor, depo ölçeğini ve teslimat hızını gösterir. Kendi başına, üretim güvenilirliğini göstermez.

Çalışma zamanı kalitesine etkisini değerlendirmek için erişilebilirlik, üretim hata oranları, olay sayısı, değişiklik-hata oranı, geri alma sıklığı ve ortalama kurtarma süresi gerekir. Yeşil bir CI çalışması, teslimat sürecinin yalnızca bir bölümünü tanımlar.

Bu sonuç ölçümlerini toplamaya devam ediyoruz. Mühendislik uygulamaları, bir sistemin riski nasıl yönettiğini açıklar; üretim verisi ise bu yönetimin ne kadar iyi çalıştığını gösterir.

SSS

Vibe coding nedir? Vibe coding, bir LLM'den kod istemek, döneni çalıştırmak, değişiklik istemek ve üretilen kodu okumamaktır. Martin Fowler'ın tanımı kasıtlı olarak dardır: geliştiricinin "kodun varlığını bile unutması" amaçlanır. Prototipler, atılabilir yazılımlar ve sınırlı sonuçları olan araçlar için uygundur.

Agentic coding nedir? Agentic coding, bir ajanın bir depoyu okuduğu, dosyaları düzenlediği, testleri çalıştırdığı ve kendi başına uzun süre iterasyon yaptığı, daha uzun süreli bir yapay zekâ destekli geliştirme biçimidir. İnsanlar hâlâ mimari ve davranışın sahibi olur ve ajanın yazdığı her satırı değil, bir çalıştırmanın ürettiği kanıtı inceler.

Vibe coding ile agentic coding arasındaki fark nedir? Dikkat, sahiplik değil. Vibe coding'de kod asla incelenmez. Agentic coding'de ajan bağımsız çalışırken mühendisler çevresindeki kanıtı kontrol eder: test sonuçları, kalite sinyalleri, önizlemeler ve üretim davranışı. vm0 genellikle vibe-coded olarak tanımlanır; Fowler'ın terimleriyle agentic coding'dir.

AI slop nedir? AI slop, yapay zekâ tarafından üretilen kodun geride bıraktığı kalıntıdır: gereksiz yedekler, yinelenen soyutlamalar, genel sınırı atlayan testler, imkânsız durumlar için savunmacı dallar. Her örnek zararsız görünür. Toplamda, depoyu anlamayı zorlaştırır ve sonraki ajanlara kötü örnekler sunar.

630 pull request haftada nasıl AI kodu incelenir? Satır satır değil. vm0'da insan incelemesi, yargı gerektiren yere gider: mimari, güvenlik hassasiyeti olan işler, ödemeler, veri göçleri. Diğer her şey mekanizmalarla taşınır: sıkı tipler ve kontratlar, modül sınırlarında entegrasyon testleri, pull request başına gerçek veritabanları, tarayıcı doğrulaması, Knip ve hiçbir değişikliğin rutin olarak atlayamadığı bir birleştirme kuyruğu.

Ölçekli vibe coding için en iyi uygulamalar nelerdir? vm0'da sekiz ay boyunca beşi öne çıktı: geliştirme ortamını yakınsamak, böylece ajanlar ve insanlar aynı komutları çalıştırır; standartları belgeler yerine tiplerde, linterlarda ve CI'da çalıştırılabilir yapmak; gerçek altyapıya karşı modül sınırlarında test etmek; ajanlara tarayıcı dahil tam bir geri bildirim döngüsü vermek; ve büyük aralıklı temizlikler yerine sürekli temizlik yapmak.

Yapay zekâ tarafından üretilen kodun güvenlik riskleri nelerdir? Yaygın risk, egzotik bir açık değil, kimsenin sahiplenmediği makul görünen koddur. vm0, güvenlik hassasiyeti olan işleri, ödemeleri ve veri göçlerini insan incelemesinde tutar, bu mantık için özellikle birim testleri kullanır, testlerde iç altyapıyı gerçek tutar, hataları yutan try/catch gibi desenleri sınırlar ve gerekli kontrollerin rutin atlamasına izin vermez.

Yapay zekâ tarafından üretilen kod teknik borç yaratır mı? Belirli bir tür yaratır: hâlâ derlenen ve testleri geçen, ancak artık sisteme katılmayan kod ile hiçbir linter'ın adlandıramayacağı anlamsal kalıntı. Knip deterministik kısmı kaldırır. Tekrarlayan iş akışları geri kalanını küçük günlük partilerde ele alır ve yeterince sık tekrarlanan bir desen lint kuralı veya tip kısıtı olur.

vm0 kod tabanının ne kadarı yapay zekâ tarafından yazıldı? Uygulamanın çoğu. Altı mühendis, Temmuz 20–26, 2026 haftasında birleştirilen 630 pull request'in 556'ünü yazdı, kalanını sürüm otomasyonu oluşturdu ve ajanlar bu pull request'lerin içindeki kodun büyük kısmını yazdı. Mühendislerin sahip olduğu ise mimari, kısıtlar ve üretim davranışıdır.

Test kupası nedir, neden test piramidi değil? Test kupası, tabanda statik analiz, baskın katmanda entegrasyon testleri ve üstte az sayıda uçtan uca test içerir. vm0 bunu kullanır çünkü bir modülün genel sınırı üzerinden yazılan testler, bir ajan alttaki uygulamayı yeniden düzenlerken davranışı korumaya devam eder; büyük bir birim test katmanı bunu yapamaz.

Yapay zekâ tarafından yazılmış bir depoda ölü kod nasıl bulunur? Kod üretimi dosya ve soyutlama ekler; silme genellikle ayrı bir prompt gerektirir. vm0, kullanılmayan dosya, dışa aktarma, bağımlılık ve giriş noktalarını bulmak için Knip'i düzenli olarak çalıştırır. TypeScript kodun geçerli olduğunu doğrular; Knip ise hâlâ sisteme katılıp katılmadığını sorar, ki ölü kod için önemli olan budur.

Vibe-coded kodu üretimde çalıştırmak güvenli mi? Bunu doğrulayan şeylere bağlıdır, yazan kişiye değil. Gereken sinyaller değişmedi: tipler ve kontratlar, genel sınırlar üzerinden testler, gerçek altyapı ve yeşil olması gereken bir boru hattı. Bu makaledeki rakamlar depo ölçeği ve teslimat hızını tanımlar. Üretim sorusunun yanıtı erişilebilirlik, hata oranları ve değişiklik-hata oranlarıdır ve bunları hâlâ topluyoruz.

Sekiz ay sonra

Sekiz ay, nihai bir yöntem ilan etmek için erken. Modeller, ajan araçları ve depo değişmeye devam ediyor; kurallarımız ve iş akışlarımız da onlarla birlikte değişiyor.

Bir değişim şimdiden netleşti. Kod üretimi hızlandıkça, ortam, kısıtlar, testler ve geri bildirim sistemi kalite yükünün daha fazlasını üstlendi. Mühendisler uygulama yazmaya daha az, davranış tanımlamaya, sınır tasarlamaya ve doğrulamayı iyileştirmeye daha çok zaman harcıyor.

vm0 kod tabanı büyümeye devam edecek. Knip deterministik kalıntıyı kaldırır. Statik kurallar, zaten anladığımız hata desenlerini engeller. Entegrasyon testleri modül davranışını korur. Tekrarlayan iş akışları, henüz mekanik olarak ifade edemediğimiz bozulmayı ele alır.

Kod hâlâ önemlidir. Bu makaledeki en iyi uygulamalar, daha az kod yazmakla ilgili değil, bir değişikliğin ana dala ait olması için neyin doğru olması gerektiğine karar vermekle ilgilidir. Artık bir değişikliğin ana dala ait olup olmadığına ve uygulamasının depoda kalıp kalmaması gerektiğine karar vermek için daha fazla makineyle çalıştırılabilir kanıt kullanıyoruz.