Geçen cumartesi sabahı, kahvemi alıp laptopun başına oturdum ve klasik o “sadece bir saat bakayım” diyerek başladığım şey yine kontrolden çıktı. Bir LLM açık, kafamda yarım yamalak bir fikir var, önümde de sanki tek kişilik bir ekip kurulmuş gibi her rol elimde: ürün yöneticisi benim, tasarımcı benim, frontend de backend de yine ben. Garip olan şu ki… bu düzen bayağı çalışıyor.
Bir özelliği sabah düşünüyorsun. Öğlene doğru çalışan bir prototip çıkıyor ortaya, akşam olmadan da küçük bir demo gösterecek seviyeye geliyorsun — ya da en azından öyle oluyor çoğu zaman. Açık konuşayım, bu hız insanın kafasını hafif bulandırıyor. “Demek mesele sadece daha çok kod yazmakmış” diye düşünduruyor. Siz hiç denediniz mi? Ama işin aslı öyle değil; pazartesi ofise dönünce tablo biraz sertleşiyor, hani gerçekten sertleşiyor.
Hafta Sonu Sihri: Tek Kişilik Takım Neden Uçuyor?
Bu tür vibe coding seanslarında en büyük fark şu: bağlam senin elinde. Kimseyi beklemiyor, kimseyle toplantı ayarlamıyorsun, “bu endpoint kimin sorumluluğundaydı?” diye ortada kalmıyorsun. Ben bunu ilk kez 2024’te Kadıköy’de küçük bir yan proje üstünde yaşadım; akşamüstü aklıma gelen fikri gece yarısına kadar kaba saba ama çalışan hâle getirdim. O an şunu net gördüm: hızın kaynağı yapay zekâdan çok, sürtünmenin azalması.
LLM burada bir çeşit çarpan etkisi yaratıyor, yani gerçekten ciddi bir çarpan. Normalde üç saat sürecek UI düzenini on dakikada toparlıyor, API sözleşmesini hızlıca çıkarıyor, hatta bazen hata ayıklarken sana ikinci göz oluyor. Kusursuz değil tabii; bazen özgüveni fazla yüksek cevaplar veriyor ve insanı yanlış yola sokabiliyor — bunu birkaç kez bizzat yaşadım. Yani hız var, ama dikkat de lazım.
İnanın, Bir de psikolojik tarafı var bunun. Hafta sonu projelerinde karar alma yükü daha hafif geliyor. Ürün kapsamı küçük tutuluyor ya da en azından öyle sanılıyor (sonra tabii ufak ufak büyüyor, her zaman büyüyor). Kurumsal işlerde işe aynı özellik için dört farklı takimin onayı gerekiyor olabilir; işte tam burada eğlence bitiyor.
“Yapay zekâ kod yazmayı hızlandırıyor ama kurum içi koordinasyon yavaşsa kazanç masada eriyip gidiyor.”
Kurum İçinde Asıl Darboğaz Kod Değil
İnanın, Pazartesi ofiste açtığım roadmap’e baktığımda hep aynı hissi yaşıyorum. Teknik olarak yapılabilir görünen işler organizasyonel olarak ağırlaşıyor (yanlış duymadınız). Frontend ekibi başka yerde yoğun, backend ekibi ayrı öncelikte, mobil ekip bambaşka takvimle ilerliyor… üstüne bir de ürün tarafında herkesin fikri var tabi, herkesin.
Buna ben “senkronizasyon vergisi” demeyi seviyorum. Güzel işim gibi duruyor ama pek hoş değil; çünkü aslında ödediğin şey zaman değil sadece, enerji de gidiyor. Bir JSON alanının adını belirlemek için üç toplantı yapmak zorunda kalıyorsan orada sorun kodda değildir artık. Bu kadar basit. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
2023’te İstanbul’da çalıştığım orta ölçekli bir projede buna çok benzerini görmüştüm. Küçük görünen bir kampanya modülü için beş ekip devreye girmişti. Iş iki haftalık geliştirmeden çok daha uzun sürdü; nedeni teknik zorluk değildi, herkes kendi parçasını tamamlayıp diğerini bekliyordu. Tam anlamıyla klasik “duvarın üstünden ticket atma” haliydi, hani o meşhur handoff dansı.
Bunu biraz açayım.
Nerede Tıkanıyoruz?
Bilmem anlatabiliyor muyum, Bence tıkanma noktaları üç şey etrafında dönüyor: Apple’ın SQUIRE hamlesi: Arayüz prototipinde yeni oyun yazımızda bu konuya da değinmiştik. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
- Takımlar arasında parçalanmış sahiplik
- Aşırı onay zinciri ve toplantılar
- Tasarım-kod-veri katmanlarının ayrı adacıklar gibi yönetilmesi
Bunların hepsi tek tek makul görünüyor olabilir, gerçekten. Ama hepsi üst üste binince ortaya garip bir tablo çıkıyor; AI sana dakika kazandırırken organizasyon gün kaybettiriyor. Hatta bazen hafta. Daha fazla bilgi için Yapay Zekâyla Kod Yazarken Kontrolü Nasıl Kaybetmiyorum yazımıza bakabilirsiniz. Bu konuyla ilgili neden konusundaki yazımız yazımıza da göz atmanızı tavsiye ederim.
| Süreç | Hafta Sonu Projesi | Kurum İçi Epic |
|---|---|---|
| Kapsam belirleme | Anlık karar | Çoklu paydaş onayı |
| Kodlama hızı | LGS gibi seri deneme çözmek kadar hızlı değil ama yakın 🙂 | AI ile ciddi hız artışı var |
| Teslimat gecikmesi | Düşük | Ekipler arası bekleme yüzünden yüksek olabilir |
| Risk yönetimi | Daha basit senaryo | Üretim güvenliği ve SLA baskısı yüksek |
Neden Çözüm Sadece Daha Çok Otomasyon Değil?
Dışarıdan bakınca kolay cevap şu gibi duruyor: “O zaman otomasyonu artır.” Güzel fikir. Ama eksik kalıyor, çünkü sorun sadece testlerin koşması ya da deployment’ın otomatik olması değil; kararların nasıl alındığıyla ilgili bir şey bu.
Editör masasında geçen ay bu konuya tekrar döndüğümüzde — Ankara’daki ofiste öğleden sonra kahve soğurken, klasik bir anlık durdu toplantı havasında — ekip arkadaşlarımdan biri çok net söyledi: “Bizde kod yazmak kısa sürüyor zaten, asıl bekleme karar aşamasında.” Haklıydı. İnsanlar bazen AI araçlarını görünce üretkenlik problemi çözüldü sanıyor ama mesele organizasyon tasarımı olunca durum değişiyor.
Küçük startup tarafında işe resim daha farklı çiziliyor. Üç kişilik ekiple AI destekli geliştirme yaparken gerçekten ciddi ivme alınabiliyor; çünkü iletişim yolu kısa ve roller birbirine yakınlaşıyor. Kurumsal ölçekteyse uzmanlaşma faydalı olsa bile hareket alanını daraltabiliyor. Yani kazanılan hız hemen başka yere çarpıp sönebiliyor. İşte paradoks tam burada başlıyor.
Senkronizasyon Vergisini Azaltmanın Daha Gerçekçi Yolu Ne Olabilir Peki?
Bence çözüm büyük çoğunluk rolleri yok etmek değil; roller arasındaki mesafeyi kısaltmak. Bunun pratik karşılığı da şu: ürünü taşıyan kişi ile sistemi uçtan uca kurabilen mühendis arasındaki bağı güçlendirmek. Kulağa teorik gelebilir ama sahada baya işe yarayan yerleri var, gördüm.
İki Kişilik Epik Modeli Mantıklı mı?
// Basit model
PM = "What" + "Why"
FullSpectrumEngineer = "How" + "Execution"
if (team.hasStrongAI && team.hasStandardizedPavedRoads) {
deliverySpeed++;
handoffCost--;
}Peki bu model herkese uyar mı?
- Küçük startup’ta evet, çoğu zaman iyi çalışır.
- Büyük şirkette işe süreçleri yeniden tasarlamak gerekir.
- Düzenlenmemiş ortamda kaos üretir — yani sihir yoktur!
Kendimce şöyle görüyorum: tek PM artı geniş yetenek setine sahip tek mühendis yaklaşımı, özellikle keşif fazında baya güçlü. Ama kritik sistemlerde güvenlik, uyumluluk, gözlemlenebilirlik gibi konular boş bırakılırsa işler ters döner — ve döndüğünde de sert döner. Kağıt üstünde güzel duran şey pratikte duvara toslayabilir, bu ihtimali göz ardı etmemek lazım.
Peki Ekipler Ne Yapmalı?
Aslında, Açık konuşayım, bir anda tüm organizasyonu ters yüz etmeye gerek yok. Zaten böyle dönüşümler genelde büyük vaatlerle başlar, sonra pilotlarda sıkışır kalır. Benim önerim daha temkinli ilerlemek: önce çapraz fonksiyonlu küçük gruplar kur, ardından onları standardize edilmiş araç zinciriyle besle.
- Sorumluluğu uçtan uca tanımla;
- Tasarımdan deploy’a kadar geçen yolu kısalt; — bunu es geçmeyin
- LLM’i sadece kod üreten yardımcı değil, karar destekçisi gibi kullan; (bu kritik)
- Ekipler arası el değiştirmeleri azalt;
“Asıl mesele geliştiricinin kaç satır yazdığı değil; kaç kez beklemek zorunda kaldığı.”
Küçük startup ile enterprise neden farklı?
| Kriter | Küçük Startup | Enterprise |
|---|---|---|
| Süreç esnekliği | Evet, rahatlıkla | Zorlanır |
| Tescilli risk yönetimi | Genelde informal | Zorunlu ve katmanlı |
| AI entegrasyon hızı | Hızlı, deneysel | Yavaş, onay süreçli |
| Ekip iletişim maliyeti | Düşük | Yüksek, yapısal |
Sıkça Sorulan Sorular
Vibe coding tam olarak nedir ve neden hafta sonu daha hızlı çalışıyor?
Vibe coding, daha çok “bağlamı akışta tutarak” hızlı deneme-yanilma ile kod üretmeye dayanir. Hafta sonu daha hızlı olmasının ana nedeni, toplantı/bağımlılık bekleme gibi sürtünmelerin azalması. Benim gördüğüm fark, işin kod kısmından çok karar ve koordinasyon maliyetinin düşmesi.
LLM’ler gerçekten projeyi hızlandırıyor mu, yoksa sadece yanilsama mı?
LLM’ler çoğu zaman somut bir çarpan etkisi yaratıyor: iskelet çıkarma, API sözleşmesi taslağı, basit UI düzenleme gibi işleri hızlandırıyor. Ama “kusursuz doğruluk” beklemek riskli; bazen özgüveni yüksek cevaplar yanlış yönlendirebiliyor. Ben de birkaç kez “çalışıyor gibi görünen” ama sonradan düzeltilmesi gereken kısımlar yaşadım.
Kurumlar neden hafta sonu hızını yakalayamıyor?
Kod yazmak tek başına zor değil; asıl dar boğaz senkronizasyon. Frontend-backend-ürün-mobil gibi farklı ekipler aynı anda aynı şeye odaklanmayınca, küçük kararlar bile toplantı ve onay sürecine takılıyor. Bu yüzden AI hızlandırsa bile kazanç, koordinasyon gecikmeleriyle eriyebiliyor.
“Senkronizasyon vergisi” tam olarak ne demek?
Bir özelliğin ilerlemesi için gereken ortak anlayışı kurma maliyetini kastediyorum. Örneğin bir alan adını netleştirmek bile ekipler arası senkron gerektiriyorsa, harcanan zaman sadece toplantı değil; zihinsel enerji kaybı da oluyor. Kod kalitesi değil, akışın kesintiye uğraması problemi büyütüyor.
Haftasonu prototipleme ile kurumsal geliştirme arasındaki farkı nasıl yönetmek lazım?
Önce “hafta sonu demo” ile “üretim kalitesi” arasındaki farkı net tanımlamak gerekiyor; aksi halde kapsam ufak ufak büyüyüp kurumsal sürece takılıyor. Kurum içinde de küçük, iyi tanımlı teslimatlar ve net API/UX sözleşmeleri kurmak sürtünmeyi azaltıyor. Benim en iyi sonuç aldığım yaklaşım, önce dar bir kapsamla uçtan uca çalışan bir akış oluşturup sonra genişletmek.
Kaynaklar ve İleri Okuma
Azure Architecture Center: Microservices (mimari ve bağımlılık yönetimi)
Azure AI Foundry / OpenAI: Kavramlar ve temel konseptler
Azure DevOps Pipelines: CI/CD ile hızlı ve güvenilir teslimat
GitHub Copilot: Yapay zekâ ile geliştirici üretkenliği (genel bilgi)
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.
