“Bilgisayar biliminde iki zor şey vardır: cache invalidation ve isimlendirme.” Phil Karlton’un bu lafı onlarca yıl öncesinden geliyor ama hâlâ tokat gibi çarpıyor yüze. Açık konuşayım — yapay zekâ kod yazmayı gerçekten hızlandırdı, bazı işlerde insanı bayağı rahatlatıyor, bunu inkâr etmek saçma olur. Ama konu isim vermeye gelince, yani bir kavramı doğru etiketlemeye gelince, işler bir anda bulanıklaşıyor. Çünkü kodu üretmek başka bir şey; neyi ürettiğini doğru anlatmak bambaşka bir şey.
Şunu söyleyeyim, Ben bunu ilk kez 2024 sonbaharında, İstanbul’da küçük bir SaaS projesinin refactor işinde çok net gördüm (kendi tecrübem). Ekip “AI ile yarım günde toparlarız” diye düşünüyordu. Güzel fikir. Hoş plan. Ta ki aynı kavramın üç farklı isimle ortalıkta dolaştığını fark edene kadar — mesela kullanıcıya gösterilen tek bir dosya tipi vardı. Backend’de “file”, frontend’de “asset”, entegrasyon katmanında ise “document” deniyordu (ilk duyduğumda inanamadım). AI da doğal olarak şaşırdı. Haklıydı yani.
Doğrusu, İşin aslı şu: yapay zekâ çoğu zaman kusurlu değil. Bizim verdiğimiz tarif bulanık oluyor. Hani mutfakta biri size “biraz tuz koy” der ya… hangi biraz? İşte tam o kafa karışıklığı kod tarafında da yaşanıyor, kelimesi kelimesine. AI’ya yeterince net konuşmazsanız çıkan şey dışarıdan düzgün görünür ama içeride çatırdayabilir, üstelik fark etmesi de zaman alır.
AI hızlıdır, ama sadece siz yol açarsanız
SRE/DevOps tarafında AI ile çalışmak genelde daha rahat (evet, doğru duydunuz). Geçen mart ayında Ankara’da bir müşteri ortamında Terraform modülü düzenlerken bunu birebir yaşadım — ne istediğim belliydi: birkaç değişkeni standardize et, tekrar eden blokları çıkar, çıktı formatını bozmadan ilerle. AI burada fena değil, hatta baya iş görüyor, çünkü hedef belli. Ben ne aradığımı biliyorum; model de bana hamallığı yapıyor. Ortada bir anlaşmazlık yok.
Bu senaryoda ondan yaratıcılık beklemiyorum. İnisiyatif almasını da istemiyorum zaten. Benim için mesele hız; güvenli hız. Yani AI burada bir stajyer gibi değil de iyi ayarlanmış elektrikli tornavida gibi çalışıyor: doğru başlığı takarsanız vida sökülüyor, yanlış takarsanız iz bırakıyor. Basit.
Bir şey dikkatimi çekti: Gel gelelim yazılım geliştirmeye geçince tablo değişiyor (yanlış duymadınız). Orada sadece komut vermiyorsunuz; davranış tanımlıyorsunuz, sınır çiziyorsunuz, kavramlar kuruyorsunuz. Ve en kritik nokta şu: eğer adlandırma kötüyse gerisi domino taşı gibi gidiyor, biri devrilince hepsi.
Neden isimlendirme bu kadar kritik?
Çünkü isimler sadece etiket değil; bağlamın kendisi oluyor bazen. Bir sınıfa verdiğiniz ad, fonksiyonun ne yaptığını anlatmıyorsa AI orada boşluk doldurmaya başlıyor. İnsan da bunu yapar aslında — ama insan en azından kaş kaldırır, “bu ne oluyor?” diye sorar. Model direkt uydurur. Sessizce.
Kötü isimlendirilmiş bir proje, yapay zekâ için teknik borçtan öte bir sis perdesi gibidir.
Karmaşa nerede başlıyor? Eski projelerde her yerde
Garip gelecek ama, Editör masasında bu haberi görünce hemen test etmek istedim (en azından benim deneyimim böyle). Çünkü yıllardır şunu görüyorum: bakımı yapılmamış projelerde isim karmaşası neredeyse kaçınılmaz oluyor, özellikle farklı dönemlerde farklı freelancer’larla büyümüş eski kod tabanlarında bu daha da belirginleşiyor — herkes kendi dilini, kendi alışkanlığını bırakmış geriye. Kimse kasıtlı yapmıyor, sadece öyle birikip gidiyor.
Bende buna benzer bir durum 2023’te İzmir’deki bir e-ticaret panelinde oldu (evet, tarih veriyorum çünkü hafızamda net yeri var). Aynı ürün kavramı üç ayrı mikroserviste farklı adla geçiyordu ve API sözleşmeleri de buna göre yamalı bohça olmuştu. Sonuç? AI’ye “şunu güncelle” (belki yanılıyorum ama) dediğinizde model önce hangi “şu”yu kastettiğinizi anlamaya çalışıyor, sonra da el yordamıyla ilerliyor. Hız? Sıfır. Nvidia Blackwell Kiraları Neden Uçtu? AI Faturası Büyüyor yazımızda bu konuya da değinmiştik.
| Kavram | Kötü durum | Daha iyi yaklaşım |
|---|---|---|
| Aynı nesne | track / item / product | tek terim: mediaAsset |
| Aynı işlem | save / submit / create all together | net ayrım: draftSave / publishSubmit |
| Aynı rol | User / Member / Customer rastgele kullanımı | domain’e göre sabit terminoloji |
| Aynı durum | active / enabled / available karışması | sözlükle tanımlanmış state set’i |
Böyle ortamlarda AI’ın hatası aslında semptomdur; hastalık bizdedir. Önce gerçek domain modelini çıkarmak gerekiyor, sonra terimleri standartlaştırmak, en son da kodu elden geçirmek lazım. Tersinden giderseniz makine size hız verir ama yön vermez. İkisi çok farklı şeyler.
İşte tam da bu noktada devreye giriyor. Daha fazla bilgi için Wilmer’e Tool Calling Geldi: Yerel AI Akışı Değişiyor yazımıza bakabilirsiniz.
Küçük startup ile kurumsal yapı arasında fark ne?
Küçük startup tarafında sorun genelde hız baskısı oluyor. Herkes “bir an önce canlıya alalım” dediği için terminoloji ikinci plana düşüyor, sonra da üçüncüye, sonra da hiç ele alınmıyor. Kurumsal tarafta ise tam tersi — süreç çok var ama ortak dil bazen yine yok! Yani ölçek büyüdükçe problem kaybolmuyor. Tahmin eder misiniz? Sadece şekil değiştiriyor.
Şöyle söyleyeyim, Tabi enterprise seviyede dokümantasyon daha iyi olabilir ama bu neredeyse her zaman kurtarmıyor. Eğer ekipler aynı şeyi farklı kelimelerle anlatıyorsa AI’nın işi iyice zorlaşıyor. Küçük ekipte çözüm bazen beş dakikalık karar olurken büyük organizasyonda veri sözlüğü şart haline geliyor. Hangisi daha iyi? Bence her ikisi de işe yarıyor, önemli olan yapılıyor olması. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek 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.
Diliniz daraldıkça doğruluk artabiliyor mu?
Bence ilginç taraflardan biri de bu. Ana dili İngilizce olmayan biri olarak bazen daha sade cümlelerle ifade kuruyorum — ilk bakışta dezavantaj gibi görünüyor, kelime haznesi geniş olmayınca esneklik azalıyor sanıyorsunuz, ama pratikte başka bir fayda çıkıyor ortaya: gereksiz süs azalıyor. Süs azalınca netlik artıyor. Netlik artınca AI daha az yorum yapıyor. Daha fazla bilgi için SDLC Modelleri: Hangi Yapı Ne Zaman İşe Yarıyor? yazımıza bakabilirsiniz.
Bilmem anlatabiliyor muyum, Bunu geçen yıl Berlin’de uzaktan yürüttüğüm bir projede fark ettim. Kafamda dolanan uzun açıklamalar yerine — itiraz edebilirsiniz tabi — kısa ve net cümleler kurunca prompt kalitesi yükseldi. Mesela “kullanıcı giriş yaptıktan sonra dashboard’a gider” demek varken neden roman yazasınız ki? AI sade talebi daha iyi yakalıyor… tabii domain gerçekten temizse. Temiz değilse sadelik de kurtarmıyor, o ayrı mesele.
- Daha kısa cümle: Daha az yorum alanı bırakır.
- Daha net terim: Modelin tahmin ihtimalini azaltır.
- Daha az metafor: Hele bir de iş mantığında belirsizliği düşürür.
- Daha fazla örnek: Yapay zekânın sizi yanlış anlamasını ciddi biçimde azaltır.
Koddan önce sözlük gelir mi? Çoğu zaman evet!
Lafı gevelemeden söyleyeyim: güçlü AI kullanımı çoğu zaman prompt mühendisliği değil terminoloji mühendisliği gerektiriyor. Önce takımın kullandığı sözcükleri sabitlemeniz lazım. Sonra o sözcüklerin sınırlarını çizmeniz lazım. En sonunda otomasyon geliyor zaten. Sıra bu.
Kısa bir not düşeyim buraya.
// Kötü örnek
const data = getItem();
if (data.status === "active") {
//...
}
// Daha iyi yaklaşım
const mediaAsset = fetchMediaAsset();
if (mediaAsset.lifecycleState === "published") {
//...
}Kod bloğunda bile fark hissediliyor değil mi? İlk sürümde her şey muğlak; ikinci sürümde niyet biraz daha açık. Dur bir saniye — — itiraz edebilirsiniz tabi — aslında burada esas mesele syntax bile değil, kelimenin taşıdığı ağırlık. AI’a hangi kapıyı açtığınızı siz söylüyorsunuz, başka kimse söylemiyor.
Nereden başlanmalı?
Önce küçük başlayın. Tüm sistemi yeniden adlandırmaya kalkmayın hemen; bu insanı da ekibi de yoruyor, üstelik yarım kalma ihtimali yüksek. Bir çember seçin: örneğin ödeme akışı, medya yönetimi ya da kullanıcı profili. O bölümün terimlerini toplayın, tek listeye dökün ve mümkünse ekipçe onaylayın.
Neyse uzatmayalım, benim gözlemim şu: isimlendirme işi düzgün kurulursa AI gerçekten ivme kazandırıyor. Kurulmazsa araç pahalılaşmış bir tahmin makinesine dönüyor. Beklediğim kadar pürüzsüz olmayan kısım — ki bu tartışılır — burası işte — modelden ziyade bizim disiplinimiz eksik kalabiliyor. Dürüstçe söylemek gerekirse bu biraz can sıkıcı, çünkü çözüm teknik değil kültürel.
Peki pratikte ne işe yarıyor?
Bana sorarsanız üç şey hemen sonuç veriyor. Birincisi domain glossary oluşturmak. İkincisi enum ve state adlarını sert şekilde standardize etmek. Üçüncüsü de prompt içinde belirsiz zamirleri azaltmak — “bunu düzelt” yerine doğrudan nesneyi söylemek. Bu kadar. Gerçekten bu kadar.
- Tek kavram için tek ad kullanın. — bunu es geçmeyin
- Aynı dosyada bile tutarlı olun; küçük tutarsızlıklar büyür.
- Migrasyon öncesi kısa bir terimler listesi çıkarın.
- Ekip içi review sırasında isimleri teknik borç sayın, estetik detay değil.
- AI’den gelen çıktıyı körlemesine kabul etmeyin; özellikle yeni eklenen alanlarda.
Sıkça Sorulan Sorular
Yapay zekâ ile kod yazarken neden isimlendirme bu kadar önemli?
p>Çünkü model kodun niyetini büyük ölçüde isimlerden çıkarır. Kavramlar karışıksa sonuç da karışık olur. Net terimler,daha doğru çıktı demek.Kötü isimlendirme her zaman probleme yol açar mı?
p>Her zaman değil ama risk ciddi biçimde artar.
p>Karmaşık süreçlere gerek yok. Basit bir ortak sözlük,iki saatlik toplantıda bile çıkabilir. Önemli olan herkesin aynı şeyi aynı kelimeyle anlatmasıdır.Anadili İngilizce olmayan geliştiriciler avantajlı mı?
p>Bazı durumlarda evet. Daha sade ifade kurdukları için belirsizlik azalabiliyor. Ama bunun işe yaraması için disiplin şart;yoksa sade dil bile muğlak kalabilir.AI’yi Projene 2 Saatte Eklemenin Gerçek Hali;
Python’la Günlük İşleri Otomatikleştirin: Evde, İşte, Hayatta;
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.
