AI kullanan kıdemli (senior) bir mühendis artık ne kadar büyük bir sistemi yönetebilir?

Son üç ayda yürüttüğümüz bir çalışma, AI-native yazılım geliştirmenin doğru ellerde nereye varabileceğine dair bizim için çok güçlü bir örnek oldu.

Bu yazıda senior / seniority, İngilizce mesleki dilde kıdemli demektir: işi parçalayan, yanlış çıktıyı ayırt eden, başından sonuna taşıyacak deneyimde mühendis. Junior (yeni yetişen) değil.

Tek bir kıdemli (senior) yazılım mühendisi, Claude ile birlikte çalışarak; mimari kararlar, geliştirme politikaları, test stratejileri, veri güvenliği, tenant izolasyonu (müşteri verisinin birbirine karışmaması), CI/CD akışları (sürekli derleme ve yayın), dokümantasyon, entegrasyonlar ve üretim süreçlerini kapsayan oldukça geniş bir mühendislik sistemi oluşturdu.

Ardından bu yapı ChatGPT ile bağımsız olarak değerlendirildi.

Ortaya çıkan assessment (bağımsız değerlendirme) bize şunu gösterdi:

Doğru kıdem (seniority) seviyesinde kullanıldığında AI, yalnızca geliştirme hızını artırmıyor; bir mühendisin etki alanını olağanüstü ölçüde büyütüyor.

Normal şartlarda onlarca kişilik bir ekibin uzun süre boyunca biriktireceği mühendislik çıktılarının önemli bir bölümü, çok daha küçük bir yapı ve çok daha kısa bir zaman diliminde üretilebiliyor.

Burada kritik nokta AI’ın kendisi değil.

Asıl farkı yaratan;

problemi doğru parçalayabilen,

mimari kararları verebilen,

yanlış çıktıyı ayırt edebilen,

test ve güvenlik sınırlarını koyabilen,

üretim tecrübesine sahip

kıdemli (senior) mühendislik bilgisi.

AI bu seviyede bir mühendisin yerini almıyor.

Onun düşünme, üretme, doğrulama ve öğrenme kapasitesini katlıyor.

Bu yüzden bizim gördüğümüz gelecek, “AI yazılımcıların yerini alacak mı?” tartışmasından biraz farklı.

Asıl soru şu:

AI kullanan kıdemli (senior) bir mühendis, artık ne kadar büyük bir sistemi tek başına yönetebilir?

Biz bu çalışmada bunun oldukça çarpıcı bir cevabını gördük.

Ek olarak, sistemin mimari ve yazılım geliştirme yönetişimi açısından bağımsız değerlendirmesini içeren assessment raporunu da paylaşıyoruz.

GETRAC yönetici değerlendirmesi — mühendislik yönetişimi ve yazılım geliştirme politikası

Raporun künyesi: GETRAC Executive Engineering Governance & Software Development Policy, Executive Assessment. Tarih: 21 Eylül 2026. Dayanak: mioe-tr/getrac, test dalı. Damga: CONFIDENTIAL — INTERNAL ENGINEERING REVIEW (gizli — iç mühendislik incelemesi). Bu, C seviyesinde bir bakıştır: yazılım değişikliği nasıl yönetiliyor, müşteri (tenant) verisi nasıl korunuyor, kalite nasıl doğrulanıyor, kod fikirden üretime nasıl gidiyor.

Kapaktaki dört yargı: Engineering discipline — güçlü. Policy-as-code (kuralın koda yazılması) — güçlü. Merge governance (birleştirme yönetişimi) — boşluk. Review independence (bağımsız inceleme) — boşluk.

Yönetici özeti

getrac, depo (repository) içinde olgun bir mühendislik kültürü gösteriyor. Proje, sahadaki arızaları ve iş kurallarını sistemli biçimde çalıştırılabilir testlere, göç (migration) kontrollerine, müşteri ayrımı (tenant isolation) sınırlarına ve yayın doğrulamasına çeviriyor. Asıl zayıf yer yazılım işçiliği değil; GitHub’da birleştirme (merge) sınırındaki yönetişim.

Kurul sonucu: Yazılım yaşam döngüsü (SDLC), onu koruyan depo yönetişiminden daha güçlüdür. Sonraki olgunluk adımı, zaten duran mühendislik kontrollerinin etrafına onay, zorunlu kontrol, sahiplik ve yayın kapısı koymaktır.

01 — Politika çalıştırılabilir. Birçok yazılı kural, geliştiricinin ezberine değil, CI (sürekli kontrol) testlerine bağlıdır.

02 — Müşteri güvenliği katmanlıdır. Uygulama tarafındaki kuruluş süzgeci, PostgreSQL satır düzeyi güvenlik (RLS) ve kısıtlı rolle yapılan bütünleştirme testleriyle pekişir.

03 — GitHub kontrolleri yaşam döngüsünün gerisindedir. Ana dal (main) silinmeye ve geri sarılamayan (non-fast-forward) değişikliğe karşı korunur; ama zorunlu PR onayı ve durum kontrolleri mevcut kural setinde dayatılmaz.

04 — Bağımsız inceleme sınırlıdır. Yakın çekme istekleri (PR) derin belgelenmiş ve ağır test edilmiş olsa da istenmiş bir insan inceleyici olmayabilir.

Yönetimin karar vermesi gerekenler: test ve main, başarılı kontrolleri zorunlu kılan korumalı yükselme sınırları olmalı mı? Hangi değişiklik sınıfları bağımsız onay ister: güvenlik, müşteri ayrımı, finans, altyapı, gizlilik ve yıkıcı veri işlemleri? Depodaki yapay zekâ işletme kuralları, insanın da okuyacağı resmi bir mühendislik politikasına çıkarılmalı mı?

1. Bugünkü yazılım teslim modeli

Depo, işe yarar bir bütünleştirme-dalı modeli kullanır. Özellik ve onarım dalları test’e akar; test sahne (staging) ortamına yayınlanır; main üretimdir. Süreç CI, önizleme ortamları ve duman (smoke) testleriyle pekişir. Akış: özellik / onarım → test → sahne → main / üretim.

Kontrol katmanları. Depo politikası: küresel mühendislik kuralları, alan notları, işe özel beceriler — güç yüksek; kurum bilgisi kodun yanında durur. Otomatik testler: birim, bütünleştirme, RLS, göç, uçtan uca ve politika gerileme kapıları — güç yüksek; kritik kurallar tekrarlanabilir. CI/CD: derleme, kontroller, yalıtılmış önizleme, sahne yayını, duman doğrulaması — güç yüksek; teslim kalitesi derlemenin ötesinde otomatik. GitHub yönetişimi: dal kuralları, zorunlu inceleme, zorunlu kontroller — güç düşük–orta; belgelenmiş süreç, yetkisi yeterli biri tarafından hâlâ aşılabilir.

Görülen politika sırası: CLAUDE.md küresel el kitabı ve işletme sınırıdır. .claude/skills/* veri tabanı, arayüz ve yapay zekâ işleri için kontrol listesidir. docs/alan-notlari/* alan gerekçesi, kenar durum ve eski derslerdir. Testler ve CI, politikayı çalıştırır. GitHub kuralları dış yönetişim sınırıdır; bugün iç yaşam döngüsünden dardır.

2. Politikanın güçlü olduğu yerler

Gerileme bilgisi kalıcı olur. Üretim ve kullanım arızaları tekrar tekrar adlı otomatik kapılara döner: müşteri birleşim kontrolleri, işlem bağlamı kontrolleri, gönderim onayı testleri, modal katman testleri, gömülü müşteri verisi testleri ve yayın duman doğrulaması.

Müşteri ayrımı bir sistem özelliği sayılır. Süzgeç uygulama katmanında durur; PostgreSQL RLS ikinci sınırdır. Testler NOSUPERUSER / NOBYPASSRLS rol kullanır; RLS’i atlayarak tesadüfen geçemezler.

Veri tabanı değişiklikleri açık disipline bağlıdır. Ham, parametreli SQL bilinçlidir. Göçler, işlem bağlamı, RLS açılış sırası ve şema belgesi tesadüfi uygulama değil, kontrollü mühendislik işidir.

Yayın, niyeti değil gerçeği doğrular. Yayın sonrası ortam, sunucuda duman testinden geçer. İş akışının yeşil dönüp hizmetin ayağa kalkmadığı ya da göçün patladığı klasik arızayı hedefler.

Dışa dönük ve yıkıcı işlerin güvenlik anlamı vardır. Müşteriye giden gönderiler önizleme ve açık onay ister; yıkıcı silmeler etki görünürlüğü ve açık rıza ister. Bunlar gerileme kapılarıyla tutulur.

3. Yönetişim boşlukları ve kurumsal risk

Baskın riskler süreç-yönetişim riskidir; zayıf uygulama kalitesinin kanıtı değildir. Önemlidir, çünkü bir kurum, platformun dayatabileceği bir sürece her katılanın gönüllü uymasına bağlanmamalıdır.

Zorunlu kalite kapısı olmadan birleştirme: olasılık orta, etki yüksek. CI vardır ama mevcut main kural seti başarılı kontrol veya PR onayı istemez. Yanıt: yükselme dallarında kontrol ve PR incelemesini zorunlu kıl.

Birbiriyle ilişkili yapay zekâ hatası: olasılık orta, etki yüksek. AI aynı değişiklik içinde kod, test, belge ve gerekçe üretebilir. Yanıt: yüksek etkili alanlarda bağımsız inceleme iste.

Politikanın dağılması: olasılık orta, etki orta. Kritik yönlendirme CLAUDE.md, beceriler ve alan notlarına yayılmıştır. Yanıt: tek kanonik Geliştirme Politikası ve açık hiyerarşi.

Belge kayması: olasılık yüksek, etki orta. Eski mimari belgeler bugünkü RLS uygulamasıyla çelişebilir. Yanıt: belgeleri yetkili / üretilmiş / kılavuz / tarihî diye ayır; tazeliği kapıla.

Büyük yükseltme yığınları: olasılık orta, etki yüksek. test, üretime çıkmadan main’den epey sapabilir. Yanıt: yayın yığınını küçült; yayın listesi / etiket ve açık yükseltme ölçütü kullan.

Kritik gözlem: GitHub bugün main’i silmeye ve geri sarılamayan güncellemeye karşı korur; incelenen etkin kural seti inceleme veya geçen durum kontrolü istemez. İncelenen dalda CODEOWNERS (kod sahibi listesi) veya çekme isteği şablonu yoktu.

4. Yönetici olgunluk görünümü

Aşağıdaki değerlendirme niteldir. Yazılım tesliminin etrafındaki işletme sisteminin olgunluğunu anlatır; geliştirici performansı veya ürün kalitesi notu değildir.

Mühendislik standartları: ileri. Ayrıntılı küresel / alan kuralları ve tekrarlayan gerileme kapıları. Sonraki eşik: politikayı kanonik ve araçtan bağımsız kıl.

Kalite güvencesi: ileri. Geniş birim / bütünleştirme takımları, RLS kontrolleri, uçtan uca ve duman testleri. Sonraki eşik: riske göre test sahipliği ve ölçülebilir kapsama hedefleri.

Veri / müşteri güvenliği: ileri. RLS + uygulama süzgeci + kısıtlı rol testi. Sonraki eşik: atlama yolları ve ayrıcalıklı işlemler için resmi güvenlik incelemesi.

CI/CD: ileri. Önizleme / sahne otomasyonu ve sunucu düzeyinde duman doğrulaması. Sonraki eşik: resmi yayın yükseltmesi ve geri alma kontrolü.

Değişiklik yönetişimi: gelişiyor. PR merkezli işleyiş var; zorunlu inceleme / kontrol kuralı görülmedi. Sonraki eşik: zorunlu kontroller, onaylar, CODEOWNERS ve korumalı test / main.

Belge yönetişimi: gelişiyor–yerleşiyor. Üretilmiş belgeler var; bazı eski anlatı belgeleri duruyor. Sonraki eşik: yetkili hiyerarşi ve tazelik sahipliği.

Bağımsız güvence: gelişiyor. Derin öz-doğrulama; sınırlı inceleyici ataması. Sonraki eşik: kritik değişiklik sınıflarında ikinci kişi veya bağımsız ajan incelemesi.

Yorum: getrac, güçlü mühendislik kontrolleri olan bir kurum gibi davranır. Eksik katman, birleştirme yetkisi, onay bağımsızlığı ve yayın yükseltmesi etrafındaki resmi kurumsal yönetişimdir.

5. Önerilen 90 günlük yönetişim yol haritası

0–30 gün: test ve main’i zorunlu PR, başarılı durum kontrolü ve çözülmüş konuşmalarla koru. Belgelenmiş yaşam döngüsü varsayılan olarak aşılamaz olur. Sahip sınıfı: CTO / depo yöneticisi.

0–30 gün: PR şablonu getir: kapsam, risk, göç, müşteri etkisi, testler, geri alma, belge. Değişiklik kanıtı tutarlı, inceleme hızlanır. Sahip: mühendislik lideri.

0–30 gün: güvenlik, veri tabanı / göç, altyapı, fatura / muhasebe ve gizlilik yolları için CODEOWNERS yaz. Kritik değişiklik doğru inceleyiciye otomatik gider. Sahip: CTO / alan sahipleri.

31–60 gün: docs/development-policy.md’yi kanonik yaşam döngüsü politikası yap; CLAUDE.md yürütme yoldaşı kalsın. Politika insana ve yapay zekâya yansız olur. Sahip: mühendislik lideri.

31–60 gün: belgeleri yetkili, üretilmiş, kılavuz veya tarihî diye ayır; mümkünse tazelik kontrolü ekle. Çelişen mimari yönlendirme görünür olur. Sahip: mimari sahibi.

31–60 gün: bağımsız onay isteyen yüksek riskli değişiklikleri tanımla. Özellikle yapay zekâ destekli geliştirmede ilişkili hata riski düşer. Sahip: CTO / güvenlik.

61–90 gün: test→main yükseltmesini resmileştir: yayın listesi / etiket, geri alma planı, yayın kanıtı ve onay. Üretim yayını denetlenebilir ve tekrarlanır olur. Sahip: yayın sahibi.

61–90 gün: yönetişim ölçülerini izle: aşmalar, başarısız yükseltmeler, kaçan hatalar, inceleme gecikmesi, geri alma sıklığı. Yönetim, yönetişimin sürtünmeyi şişirmeden güvenlik ekleyip eklemediğini ölçer. Sahip: CTO / mühendislik işletmesi.

Önerilen politika cümlesi: “Üretimi etkileyen hiçbir değişiklik, zorunlu testleri, müşteri / veri güvenliği kontrolleri, belge yükümlülükleri, bağımsız onayları ve yayın doğrulaması, dayatılabilir kontrollerle karşılanmadan tamamlanmış sayılmaz.”

6. Hedef işletme modeli

Hedef daha çok bürokrasi değildir. Depodaki bugünkü hızı koruyup en önemli korumaları otomatik, riske göre ve denetlenebilir kılmaktır.

1 PLAN — iş kalemi / kabul ölçütü / risk sınıfı. 2 BUILD — test’ten dal + ilgili alan becerisi / politikası. 3 VERIFY — birim + bütünleştirme + RLS + göç + gerektiğinde uçtan uca. 4 REVIEW — tanımlı yüksek risk sınıflarında bağımsız inceleme. 5 PREVIEW — yalıtılmış PR ortamı + kanıt. 6 PROMOTE — korumalı birleştirme test’e, sonra kontrollü test→main yayını. 7 OBSERVE — duman testi + izleme + hatadan gerileme kapısına dönüş.

Yönetişim ilkeleri. Değişmezi otomatikleştir: bir kural tekrar tekrar önemliyse ezbere değil CI’ya yaz. Katılığı riske uydur: kopya değişikliği ile müşteri verisi göçüne aynı onay yükünü yükleme. Yazarı güvenceden ayır: yüksek etkili değişikliklerde son onay, yalnızca o işi yazan kişiden veya ajandan gelmesin. Törenden çok kanıt: test, önizleme, göç provası ve duman sonucu, yalnızca kutucuk işaretlemekten güçlüdür. Kaynağı açık tut: üretilmiş ve yetkili belgeler, eski anlatı kopyalarını yensin.

Ek A — İncelenen kanıt

Bu değerlendirme, getrac test dalında ve bağlı hesaba açık GitHub yapılandırmasında görülen depo kanıtına dayanır. Mühendislik-yönetişim değerlendirmesidir; sızma testi, hukuk denetimi veya resmi uygunluk belgesi değildir.

Küresel politika: CLAUDE.md ve işe özel .claude/skills kuralları. Mimari ve veri politikası: docs/mimari.md, docs/veri-erisim-katmani.md ve bugünkü RLS uygulaması. Kalite kontrolleri: ön yüz testleri, arka yüz birim / bütünleştirme, müşteri ayrımı kontrolleri, uçtan uca ve göç provası. CI/CD: CI, önizleme, sahne ve üretim yayını için GitHub Actions iş akışları. Depo yönetişimi: etkin kural seti ve dal yapılandırması. Yakın PR kanıtı: test’e giden çekme istekleri, uygulama / test kanıtı ve inceleyici atama durumu.

Önemli sınırlar. GitHub yönetim izni isteyen dal-koruma REST uçları bağlı bütünleşmeden okunamadı; etkin kural seti okundu ve GitHub dayatması gözlemi buna dayanır. Değerlendirme, belgelenmiş ve görülebilir geliştirme politikasına odaklanır; her testi, sır yönetimini, bulut iznini veya üretim işletme usulünü bağımsız doğrulamaz. Olgunluk etiketleri nitel yönetim tanımlarıdır, dış belgelendirme notu değildir.

Son yönetici cümlesi: GETRAC’ın yeni bir mühendislik kültürüne ihtiyacı yoktur. İhtiyacı, mevcut mühendislik kültürünü bugünkü katılanların ötesinde kalıcı, denetlenebilir ve ölçeklenebilir kılan yönetişim katmanıdır.

Raporun asıl sayfaları

Kaynak: MIOE Elektronik ve Yazılım Mühendislik, LinkedIn paylaşımı, 4 Ekim 2026; GETRAC Engineering Governance Assessment, 21 Eylül 2026 (1791124242947.pdf). Şirket metni ve rapor, yüklenen haliyle aktarılmıştır. İngilizce terimlerin yanına Türkçesi, bilmeyene ulaşmak için konmuştur.