Yapay Zeka Odaklı (AI-Native) Bir Mühendislik Organizasyonu Kurmak

Geçtiğimiz hafta Will Larson'ın mühendislik yöneticilerini yapay zeka becerileri açısından nasıl değerlendirdiğimize dair sorusu, sektörde önemli bir tartışma başlattı. FurtherAI'da son dokuz aydır yapay zeka odaklı (AI-native) bir mühendislik organizasyonu inşa ederken edindiğimiz dersler, modern yazılım geliştirme süreçlerinin nasıl kökten değiştiğini gösteriyor.

Bölüm 1: Yazılım Teslimat Sürecimizde Neler Değişti?#

Mühendis Başına Teslimat Miktarı#

Ocak ayından bu yana mühendis başına günlük birleştirilen (merge edilen) kod değişikliği sayısı yaklaşık 5 kat arttı ve geri alma (revert) oranımız %0,5'in altında kaldı. Ancak mühendislere sadece kodlama ajanları vermek tek başına bu sonucu sağlamadı. Sürecin bir adımını hızlandırdığımızda, işler bir sonraki adımda birikti (darboğaz oluştu). Bu yüzden yazılım teslimat sürecini uçtan uca, adım adım yeniden ele alarak optimize ettik.

Teslimat Sürecini Yeniden İnşa Etmek#

• Kod (Mart): Ajanlar kodu yazar, mühendisler ise onları yönlendirir. Başlangıçta araçlar nadiren iz bırakıyordu ancak bugün kod değişikliklerinin neredeyse %100'ü ajanlar üzerinden gerçekleşiyor. Çıkarım: Geliştiricinin rolü kod yazmaktan mimari yönlendirmeye evriliyor.
• Testler (Nisan): Ajanlar kodla birlikte testleri de yazar. Test içeren değişikliklerin oranı %15'ten %91'e yükseldi. Çıkarım: AI test stratejileri, kod kalitesini ölçeklendirmenin temelidir.
• İnceleme / Review (Mayıs): Yapay zeka, değişikliklerin %99'unu bir insandan önce inceliyor (önceden %60'tı). Böylece insan incelemeciler yalnızca muhakeme gerektiren kritik kısımlara odaklanabiliyor.
• CI (Haziran): Testleri paralelleştirdik ve yalnızca değişiklikten etkilenen testleri çalıştırmaya başladık. CI artık aynı 17 dakikalık sürede 20 kat daha fazla test çalıştırıyor. Çıkarım: Hızlı üretim için CI/CD boru hattı ajan hızına ayak uydurmalıdır.
• Hata Raporları (Temmuz): Hata kabul sürecini otomatikleştirmek için ClaudeTag kullanmaya başladık. Herkes Slack üzerinden hata bildirebiliyor; ajan kopyaları tespit ediyor, kayıt açıyor ve doğru kişiye atıyor. Artık hata kayıtlarının %60'ını otomatik açıyor.
• Kurallar (Ağustos): Bir hata veya inceleme yorumu yalnızca kıdemli mühendislerin bildiği yazılı olmayan bir bilgiyi (tribal knowledge) ortaya çıkardığında, bunu her commit ve PR'da çalışan, derlemeyi durdurup çözümü ekrana yazdıran küçük bir Python kontrolüne dönüştürdük. Sıfırdan 21 kurala çıktık. Ajanlar bu kontrollere takıldığında kendi kodlarını düzeltip devam ediyor.
• Birleştirme / Merging (Ağustos): Testleri, otomatik kontrolleri ve AI incelemesini geçen düşük riskli değişiklikler kendi kendine birleştiriliyor. Değişikliklerimizin üçte birine kadarı artık insan müdahalesi olmadan yayına alınıyor.
• Kod Kanalları (Eylül): Herkes bir Slack kanalı açıp ajana değişikliği tarif ederek PR açtırabiliyor. Birden fazla kişinin aynı kanalda tek bir ajanla çalışıp bağlam eklemesi ve Devin bulut oturumları ekip içi işbirliğini güçlendiriyor.

Ayrıca üretim ve test ortamlarındaki sorunları incelemek ve çözmek için loglara, metriklere, izlere (trace) ve salt okunur veritabanı erişimine sahip şirket içi Poirot ve Sherlock ajanlarımızı kullanıyoruz. En verimli anlar ajanların birlikte çalıştığı anlardır: ClaudeTag talebi sınıflandırır, Devin işi yapar ve Poirot gerekli iç veriyi çeker.

Bu dönüşümün en ilginç yan etkisi, mühendis olmayanların da kod göndermeye başlaması oldu. Tasarımcımız Ağustos'tan beri tasarım sistemimiz dahil yaklaşık 50 değişiklik birleştirdi; saha ve müşteri ekipleri de sürece doğrudan katılıyor.