Geçen ay İstanbul’da bir ürün ekibi toplantısında tam bu konuyu konuşuyorduk. Sistem çöktüğünde ilk refleksin ne olduğu. Bir kişi Slack’i açıyor, diğeri loglara dalıyor — ikisi de kıdemli, ikisi de iyi niyetli,. Biri sisteme yapışık, diğeri biraz havada kalıyor. Can sıkıcı olan şu: farkı yaratan unvan değil. Temas mesafesi.
Ben de bunu son yıllarda bayağı net gördüm, açık konuşayım. Artık sıfırdan kod yazmaktan kaçındığım anlar oluyor. Bu cümleyi söylemek ilk başta tuhaf geliyor — hatta hafif rahatsız edici. Yıllarca “gerçek mühendislik” dediğimiz şeyin tam merkezinde elini kirletmek vardı çünkü; şimdi ise yapay zekâ araçlarını optimize etmek, üretilen kodu denetlemek, hızla yayılan otomasyonun içinden sağlam bir iş çıkarmak çok daha baskın hale geldi. Nasıl desem… rol değişiyor ama bunu kabullenip kabullenememek ayrı bir mesele.
Durun, bir saniye.
Sistemin Çöküşü: Asıl Fark Nerede Başlıyor?
Şunu söyleyeyim, Sistem düştüğünde herkes aynı kelimeleri söylüyor. “Nerede takıldı?”, “Kim bakıyor?”, “Müşteri etkileniyor mu?” Ama pratikte bambaşka iki dünya oluşuyor — bir tarafta ekranı açıp durumu okuyabilen ekip lideri var, diğer tarafta gerçekten sistemin içine girip bozulmuş parçayı elle yoklayan kişi. İkisi de aynı odada, ama birbirinden çok uzakta aslında.
Bu ayrım bana 2024’ün sonlarında Ankara’daki bir SaaS projesinde yaşadığımız olayı hatırlattı. Aynı hataya iki farklı ekip baktı; birinci ekip toplantı üstüne toplantı yaptı, ikinci ekip doğrudan trace. Log üzerinden kök nedene indi. Sonuç? İkinci ekip üç saatte toparladı. Birincinin notları ise… valla, açıkçası biraz süs gibi kaldı (inanın bana)
Çok konuştum, örnekle göstereyim.
İşin aslı şu ki liderlik bazen çok görünmez bir kaymaya uğruyor. Günler toplantıyla doluyor, planlama yapılıyor, doküman okunuyor… ama sistemle gerçek bağ sessiz sedasız zayıflıyor. O anda kimse “artık uzaklaştın” demiyor (ciddiyim). Sadece bir gün geliyor ve eski reflekslerinizin yavaşladığını fark ediyorsunuz (inanın bana). Üstelik fark etmek de geç oluyor çoğu zaman.
Sisteme yakın olan kişi sadece hata bulmaz; sorunun nerede büyüyeceğini de hisseder. Bu his, dashboard’da yazmaz.
Yapay Zekâ ile Çalışırken El Becerisi Neden Köreliyor?
Bunu itiraf etmek kolay değil. Ama gerçek şu: yapay zekâ kod yazmayı hızlandırdıkça kas hafızamız da değişiyor. Eskiden kafamda tuttuğum pattern’leri şimdi modele tarif ediyorum, çıkan sonucu gözden geçiriyorum (şaşırtıcı ama gerçek). Güzel mi? Baya iş görüyor açıkçası. Ama bedeli de var — bazı şeyleri eskisi kadar hızlı çağıramıyorsunuz.
Ve işler burada ilginçleşiyor.
Geçen sene Kadıköy’de küçük bir ajans için yaptığım denemede bunu net gördüm. Basit bir API entegrasyonunu AI yardımıyla birkaç dakikada çıkardım; aynı işi araçsız yapmam istendiğinde ise akışım bariz yavaşladı. Sanki dili biliyorum ama aksanım değişmiş gibi bir şey. Bilgi orada duruyor, fluency gidiyor.
Bu kötü mu? Tam emin değilim. Bir yandan üretkenlik artıyor, öbür yandan teknik sezgi biraz körelebiliyor. Yani mesele artık “AI kullanalım mı kullanmayalım mı?” değil — mesele hangi kasların güçlenip hangilerinin zayıfladığı.
Kod yazmak yerine kodu yönetmek
Şimdi gelelim kritik noktaya. Ben artık çoğu projede sıfırdan yazmaktan çok yönlendiriyorum, kontrol ediyorum, iyileştiriyorum. Bu kötü bir şey gibi sunuluyor bazen — ama değil aslında. Rol değişiyor sadece. Eskiden marangoz gibi çalışıyorduk; şimdi şantiyeyi yöneten usta gibiyiz. Hmm, metafor biraz klişe oldu ama siz anladınız demek istediğimi. Bu konuyla ilgili DEV’in Haftanın Seçtikleri: Neden Herkes Bunları Konuşuyor? yazımıza da göz atmanızı tavsiye ederim.
Şahsen, Neyse uzatmayalım. Her görev için aynı yaklaşım uygun değil tabii ki.
| Durum | Sahaya yakın kişi ne yapar? | Uzak kalan kişi ne yapar? |
|---|---|---|
| Prod kesintisi | Log okur, geri alma planını dener | Status güncellemesi ister |
| Kod inceleme | Niyet ve yan etki arar | Sadece sözdizimine bakabilir |
| Mimari karar | Sistemin darboğazını bilir | Dökümanı yorumlar |
| Maliyet optimizasyonu | Nerede para yandığını görür | Tahmin yürütür |
Liderlik Meselesi: Yakınlık Yetmiyor mu?
Yetmiyor demek fazla sert olur… ama yakınlık olmadan da olmuyor işte. Lider olmak demek her şeyi kendin yapmak değil elbette; fakat sistemi hissetmeden yönetmeye çalışınca kararlar steril kalıyor. Bir şeyleri kaçırdığını da ancak sonradan anlıyorsun. Bu konuyla ilgili Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza da göz atmanızı tavsiye ederim.
Aslında, Bunu geçen mart ayında İzmir’deki orta ölçekli bir e-ticaret ekibinde gözlemledim. Takım lideri teknik olarak güçlüydü, ama sprintlerin çoğunu toplantılar içinde geçiriyordu — çünkü herkes ondan onay bekliyordu, klasik. Bir süre sonra o kadar çok koordinasyon yükü oluştu ki asıl sistem bilgisi birkaç geliştiricinin omzuna kaldı. Lider de farkında değil tam olarak. En tatsız kısmı bu zaten.
Bir de şu var: eğer sen her gün loglara bakmıyorsan ya da ara sıra debug etmiyorsan, ekip sana teknik gerçekliği filtrelenmiş halde anlatmaya başlıyor olabilir. Fark etmeden oluyor bu, çok insani aslında. Bu ne anlama geliyor? Ama sonuçta kararı veren sensen sorun büyüyebilir. yapay ile ilgili önceki yazımız yazımızda bu konuya da değinmiştik. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Küçük startup ile enterprise arasında fark ne?
Bi saniye — Küçük startup’ta lider hem ürünü hem sistemi hem müşteriyi aynı anda duyuyor zaten — mesafe kısa olduğu için çöküş anında refleks daha canlı oluyor. Peki enterprise’da ne oluyor? Orada katmanlar artıyor, roller bölünüyor ve bilgi dolaşımı ağırlaşıyor. Bu konuyla ilgili Agent’ler Ödeme Yaparken Kim Dur Diyecek?: Güvenlik Açığı yazımıza da göz atmanızı tavsiye ederim.
- Küçük takımda hata çıktığında çözüm daha hızlı gelir ama kişiye bağımlılık yüksek olur.
- Büyük kurumda süreçler oturmuştur ama sistemden kopma riski yükselir.
- Startup’ta “ben bakarım” kültürü vardır; kurumsalda “ticket açalım” refleksi baskındır.
- İyi taraf? Enterprise ölçekte kayıt ve iz bırakma daha güçlüdür. Kötü taraf? İnsan bazen olayın sıcaklığını kaçırır. (bu kritik)
Peki Bu Gidişat Normal mi?
Açık konuşayım — tamamen anormal değil. Teknoloji zaten böyle çalışıyor; beceriler yer değiştiriyor, işler yeniden tanımlanıyor. “Horse riding” metaforu burada kısmen doğru ama eksik kalıyor; çünkü uçak uçurmak yine de aerodinamik istiyor. Yani vibes yetmiyor!
Bence asıl soru şu olmalı: hangi becerileri bilinçli olarak koruyacağız? Her şeyi AI’a bırakırsanız kısa vadede rahat edersiniz. Uzun vadede teşhis yeteneğiniz düşebilir. Bu da özellikle güvenlikte veya prod ortamında hiç hoş olmayan sürprizler çıkarabiliyor (inanın bana). Ciddi fark var.
// Basit düşünce modeli
if (system_proximity == "yüksek") {
incident_response = "hızlı + sezgisel";
} else {
incident_response = "prosedürel + gecikmeli";
}Bende kalan küçük kırılma anları
Editör masasında otururken bazen eski alışkanlığımı yakalıyorum, hani… Hemen küçük bir script yazmak yerine önce modele soruyorum. Ne oluyor peki? Kimi zaman dakikalar kazanıyorum, kimi zaman da gereksiz soyutlama yüzünden kendi elim ayağıma dolaşıyor. Tam da öyle.
Ekim 2025’te Bursa’da tanıştığım bir backend mühendisi şöyle demişti: “AI bana hız verdi ama bazı bug’larda sezgimi köretti.” O cümleyi unutmadım — fazlasıyla dürüsttü (inanın bana). Hani ne farkı var diyorsunuz, değil mi? Bence sektörün genel hissi de bu yönde gidiyor zaten.
Neyi Kazanıyoruz, Neyi Kaybediyoruz?
Bilmem anlatabiliyor muyum, Kazanılan şey belli: hız, erişilebilirlik, tekrar eden işleri azaltma. Gel gelelim kaybedilen taraf pek konuşulmuyor — temel kas hafızası zayıflayınca karmaşık sorunlarda bağımsız düşünme zorlaşıyor (şaşırtıcı ama gerçek). Sessizce oluyor bu kayıp. Fark ettiğinde iş işten geçmiş oluyor bazen.
Bir başka risk de şu: genç mühendisler doğrudan AI destekli akışa girince temelin neden önemli olduğunu geç fark ediyorlar. Bu biraz matematik öğrenmeden hesap makinesine sarılmak gibi aslında (yanlış duymadınız). Kısa vadede işe yarıyor, uzun vadede… Hani ne farkı var diyorsunuz, değil mi? hmm, bakalım.
Peki Ne Yapmalı?
Araya gireyim: Bana kalırsa çözüm yasak koymak değil. Biraz disiplin gerekiyor işte. Kendime koyduğum basit kurallar var, büyük laflar değil ama işe yarıyor:
- Haftada en az bir işi araçsız çözmeye çalışıyorum.
- Kritik PR’larda sadece sonucu değil mantığı da okuyorum.
- Sistem tasarımından önce log/metric/tracing üçlüsüne bakıyorum.
- Ekip içinde ara sıra “neden böyle yaptık?” sorusunu bilerek uzatıyorum.
- Zor bug geldiğinde önce insan gibi düşünüyorum, sonra modele dönüyorum.
Daha önemlisi şu satırı unutmamak lazım: araç seni güçlendirmeli, yerine geçmemeli. İnce çizgi burada. Çok ince.
Sizin İçin Hangisi Daha Kritik?
Küçük bir startup’taysanız sistemle fiziksel temasınızı koruyun derim. Sabah stand-up’tan sonra iki dakika bile olsa production’a bakın. Metrikleri görün. “Logları koklayın” desem garip olacak ama tam olarak onu kastediyorum — gerçekten öyle bir şey bu.
Ekip içindeki görünmeyen başarıları belgelemek isteyenler için Brag Document Neden Lazım: Unutulan Başarıları Kurtaran Alışkanlık yazısı iyi gider; teknik katkının nasıl iz bırakacağını güzel anlatıyor çünkü.
Konuya yapay zekâ tarafından bakmak isterseniz Agent Hafızası: Vektörden Zaman Çizgisine Geçiş yazısına da göz atabilirsiniz; hafıza meselesi burada bayağı kritikleşiyor zaten.
Sıkça Sorulan Sorular
Sistem çökünce ilk yapılacak şey nedir?
Önce etki alanını netleştirin ve panik yerine veri toplayın.Loglar, metrikler ve son deploy bilgisi ilk bakılacak yerlerdir.Sonra ilgili kişileri tek kanalda toplayıp iletişim karmaşasını azaltın.
Ana problem AI kullanmak mı yoksa ona fazla güvenmek mi?
Ana problem kör güven.Eğer çıktıların doğruluğunu düzenli test etmiyorsanız AI sizi hızlandırırken yanlış yöne de götürebilir.Kontrol mekanizması şarttır.
Liderlerin teknik işten uzaklaşması normal mi?
İşin garibi, Kısmen evet.Normal. Yönetim yükü artar.Ama tamamen kopmak iyi fikir değil; ara sıra sisteme dokunan lider daha sağlıklı karar verir.
Kaynaklar ve İleri Okuma
Size bir şey söyleyeyim, Orijinal İlham Yazısı — The System Went Down
a href=“https://docs.github.com/en/actions” target=“_blank” rel=“noopener”GitHub Actions Resmi Dokümantasyonu/a>
a href=“https://platform.openai.com/docs” target=“_blank” rel=“noopener”OpenAI Platform Dokümantasyonu/a>
a href=“https://learn.microsoft.com/en-us/azure/architecture/guide/” target=“_blank” rel=“noopener”Azure Architecture Center/a>
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
