Küçük Bir Ekipte AI Destekli Geliştirme Kültürü İnşa Etmek
Cursor'ı ilk tanıttığımızda ekip hızla benimsedi. Beklenenden çok daha hızlı.
Ama tepkiler tek tip değildi. Kimileri heyecanla farklı araçlar denemeye başladı. Kimileri temkinli yaklaştı. Bir kısmı ise açıkça dile getirdi: "Bu araç benim kişisel gelişimimi etkiler mi?" Tehdit olarak görenler de vardı, fırsata dönüştürenler de.
Bu çeşitlilik aslında sağlıklı bir ekibin işaretiydi. Ama aynı zamanda net bir şeyi gösteriyordu: araç ortaktı, kullanım dili değildi. Ve bu boşluğu doldurmak gerekiyordu.
İşte bu yazı, 5'ten fazla kişilik bir mühendislik ekibinde AI destekli geliştirme pratiklerini ve standartlarını sıfırdan nasıl inşa ettiğimizi anlatıyor.
Ekipte AI araçlarını tanıtmanın teknik boyutu aslında kolay kısmıydı. Asıl iş, farklı kaygıları olan insanları aynı yöne doğru yürütmekti.
"Bu araç beni gereksiz kılar mı?" sorusu hiç dile getirilmeden havada asılı kalabilir. Biz bu soruyu doğrudan masaya yatırdık. Cevabımız netti: AI, kodu yazan değil kodu hızlandıran bir araçtır. Sahiplik, yargı ve sorumluluk hâlâ insanda. Anlamadan onaylamak kabul görmez.
Bu kültürel zemin olmadan hiçbir standart tutar değil. Kurallar dayatıldığında değil, arkasındaki mantık anlaşıldığında içselleştirilir.
Ekibimiz hem .NET hem Python ile çalışıyor. İki farklı ekosistem, iki farklı sözdizimi, iki farklı toolchain. Ama standartlar ekip genelinde tek.
Bu bilinçli bir karardı. Her geliştirici en iyi bildiği dilde çalışmaya devam ediyor — uzmanlık köreltilmiyor. Ama deployment süreci, loglama formatı, kod gözden geçirme beklentisi ve prompt yaklaşımı dil bağımsız olarak tanımlı.
Sonuç şu: bir .NET geliştiricisi Python servisinin deployment'ını takip edebilir. Python tarafındaki bir log, .NET tarafında alışık olunan formatla okunabilir. Diller farklı, dil farklı değil.
AI araçları bu yapıyı daha da güçlendirdi. Cursor veya benzeri bir araçla üretilen kod, hangi dilde olursa olsun aynı standart üzerinden gözden geçiriliyor. "Bu .NET kodu nasıl çalışır bilmiyorum" artık bir kalkan olarak kullanılamıyor.
Standartları belgelemek bir adım. O belgelere herkesin doğru anda erişebilmesi başka bir adım.
Burada RAG (Retrieval-Augmented Generation) devreye giriyor. Ekip içi standartlar, geçmiş kararlar, mimari notlar ve prompt kütüphanesi — bunların hepsi indekslendi. Artık bir geliştirici "deployment için hangi prompt'u kullanıyoruz?" diye sormak yerine doğrudan yanıtı alabiliyor.
Bu yapının önemli bir katkısı var: kurumsal hafıza birikiyor. Yeni bir ekip üyesi onboarding sürecinde dağınık dokümanlara değil, soru sorabildiği yapılandırılmış bir bilgi tabanına erişiyor. "Bunu neden böyle yapıyoruz?" sorusunun yanıtı artık sadece o kararı alan kişinin kafasında değil.
Ekipteki heyecanlılar Cursor'la yetinmedi. Farklı araçlar denendi, karşılaştırıldı, tartışıldı. Kimileri başka alternatiflere yöneldi.
Bunu tek bir araçta zorla standardize etmek yerine farklı bir yaklaşım benimsedik: araç tercihi bireysel olabilir, ama çıktı standartları ekip genelinde geçerlidir.
Yani hangi araçla kod üretirsen üret — gözden geçirme süreci, kod kalitesi beklentisi ve dokümantasyon standardı aynıdır. Bu ayrım, heyecanı kısıtlamadan tutarlılığı korumanın anahtarı oldu.
Prompt yazmayı bireysel bir hüner olmaktan çıkarıp ekip pratiğine dönüştürmek, standartlaştırmanın ilk adımıydı.
Üç temel ilke benimsedik:
Bağlam önce gelir. "Şunu yaz" yerine "şu sistem içinde, şu kısıtla, şu amaca hizmet edecek şekilde şunu yaz" formatı yerleşti. AI'a ne istediğinizi değil, neden istediğinizi anlatmak çıktı kalitesini doğrudan etkiliyor.
Çıktı formatı tanımlanır. Fonksiyon mu, test mi, yorum mu — beklenen format promptun içine dahil edilir. Belirsiz promptlar belirsiz çıktılar üretir.
Prompt'lar belgelenir ve paylaşılır. Tekrar kullanılan, işe yarayan promptlar ekip içi kütüphaneye eklendi ve RAG üzerinden erişilebilir hale getirildi. Deneyim birikimlenir; her geliştirici sıfırdan keşif yapmak zorunda kalmaz.
AI hızı artırınca bir yan etki belirdi: canlıya geçme isteği de hızlandı. "Çalışıyor, deploy edelim" refleksi tehlikeli bir alışkanlığa dönüşebilir.
Buna karşı önce staging ortamını zorunlu hale getirdik. Canlıda geliştirme tamamen engellendi. Her değişiklik önce staging'e gider, orada doğrulanır, sonra production'a taşınır.
Deployment sürecinin kendisi de standartlaştırıldı. Sabit adımlar ve her adım için belirlenmiş prompt kalıpları tanımladık:
Bu adımlar hem .NET hem Python servisleri için aynı şekilde işliyor. Dil farklılığı süreci değiştirmiyor.
Farklı geliştiricilerin yazdığı arayüzlerin aynı dili konuşması için bir tasarım sistemi benimsedik. Renkler, bileşen davranışları, boşluklar merkezi olarak tanımlı. AI ile üretilen UI kodu da bu sistemi referans alıyor.
Görünmez tarafta ise loglama standardı var. Her servis, her kritik işlem, her hata aynı format ve detay seviyesinde loglanıyor .NET'te de Python'da da. Üretimde bir şey ters gittiğinde "ne oldu, nerede oldu?" sorusunun yanıtı artık tahmine değil, tutarlı bir log yapısına dayanıyor.
Bu iki standart birlikte şunu sağlıyor: sistem dışarıdan tutarlı görünüyor, içeriden de izlenebilir.
Araç benimsemesi kendiliğinden olur; kültür benimsemesi olmaz, inşa edilir. İki farklı dil ve ekosistemde çalışmak, standartlardan taviz vermek için bir gerekçe değil — aksine standartların ne kadar kritik olduğunun kanıtıdır. Ve ekip bilgisini RAG ile erişilebilir kılmak, bireysel uzmanlığı kurumsal zekâya dönüştürmenin en pratik yoludur.