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 hale 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 ise aynı özellik için dört farklı takımın 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.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Buna ben “senkronizasyon vergisi” demeyi seviyorum. Güzel isim 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 ise 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 ise süreçleri yeniden tasarlamak gerekir.
- Düzenlenmemiş ortamda kaos üretir — yani sihir yoktur!
// Basit model
PM = "What" + "Why"
FullSpectrumEngineer = "How" + "Execution"
if (team.hasStrongAI && team.hasStandardizedPavedRoads) {
deliverySpeed++;
handoffCost--;
}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 |
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.
