Teknoloji ve AI Kararlarını Projeye Bağlamak

Yeni bir teknolojiyi denemek heyecan verici bir karar gibi görünüyor. Pratikte bir maliyet kararı: seçtiğin araç, o projeyi bundan sonra kimin nasıl sürdüreceğini de belirliyor. Yapay zekâ için de aynı şey geçerli — asıl soru "kullanayım mı" değil, hangi adımda kullanayım.

Bu yazı, bu iki soruyu ayrı ayrı değil, aynı karar hattının parçaları olarak ele alıyor.

Önce problem, sonra araç

Bir teknoloji tartışması genellikle araçtan başlıyor: "şunu mu kullansak, bunu mu?" Bu soru neredeyse her zaman erken. Cevaplanabilmesi için önce şunların netleşmesi gerekiyor:

• Bu sistem hangi işi yapacak ve kim kullanacak?
• Veri nereden geliyor, nereye gidiyor?
• Hangi kısım gerçekten değişken, hangi kısım yıllarca aynı kalacak?
• Yanlış giderse ne olur — bir rapor mu bozulur, bir ödeme mi kaybolur?

Son madde belirleyici. Bir dashboard'un yanlış sayı göstermesiyle bir ödemenin iki kez işlenmesi aynı ağırlıkta değil. Aracın ne kadar "yeni" olabileceğini de büyük ölçüde bu belirliyor.

Yeni bir aracın gerçek maliyeti öğrenmek değil

Yeni bir framework ya da kütüphane seçerken en çok konuşulan şey öğrenme eğrisi oluyor. Halbuki öğrenmek bir kerelik bir maliyet. Asıl maliyet sonrasında geliyor:

• Bakım: Bu aracın kırıcı sürüm geçişlerini kim takip edecek?
• Devralınabilirlik: Yarın başka biri bu projeye baktığında ne kadar sürede anlar?
• Kaynak derinliği: Sıra dışı bir hatayla karşılaştığında arayıp bulabileceğin bir cevap var mı, yoksa kaynak koda mı bakacaksın?
• Sağlayıcı bağımlılığı: Aracın arkasındaki servis sözleşmesini değiştirirse elinde ne kalıyor?

Bu sorular "yeni olan kötüdür" demiyor. Sadece yeniliğin bedava olmadığını söylüyor. Bedeli ödemeye değecek bir karşılık varsa yeni araç doğru seçim.

Karar tablosu

Pratikte kendime sorduğum ayrım kabaca şu:

Tablo bir kural değil, bir başlangıç noktası. Ama "bu aracı neden seçtim" sorusuna sonradan verilecek cevabı hazırlıyor — ve bir kararı savunabilmek, çoğu zaman doğru olmasının ön koşulu.

Yapay zekâ bu hattın neresinde

Çalışma biçimimi dört adımda düşünüyorum: problemi anla → mimariyi kur → hızlandır → kontrol et ve yayınla. Yapay zekâ bu hattın üçüncü adımında duruyor. Birinci ve ikinciyi devralmıyor.

Bunun sebebi AI'ın mimari öneremeyeceği değil. Önerebiliyor, üstelik makul öneriler de çıkıyor. Sebep şu: mimari kararın doğruluğu, çoğunlukla kodda görünmeyen bilgilere bağlı. Hangi ekip bakacak, hangi kısım gelecek çeyrekte değişecek, hangi kural mevzuattan geliyor, geçen sene hangi yaklaşım denenip bırakıldı. Bu bilgiler istemde yoksa, cevap teknik olarak doğru ama bağlam olarak yanlış oluyor.

Bir örnek: analiz ekranları olan bir sistemde "iki ekran aynı metrik için farklı sayı gösteriyor" problemine hızlıca bir düzeltme yazdırmak mümkün. Ama sorun genellikle hesaplamada değil, kapsamın tanımında oluyor — iki ekran farklı kümeyi değerlendiriyordur. Bunu görebilmek için ekranların ortak bir filtre sözleşmesine bağlanması gerektiğini bilmek gerekiyor. O karar verildikten sonra AI'ın hızlandıracağı çok iş var; ama kararın kendisi verilmeden yazılan kod, yanlış yerde iyileştirme yapıyor.

AI'ı hangi işlerde kullanıyorum

Somut olarak üretkenlik kazandığı yerler:

• Araştırma ve alternatif çıkarma. Bir problemin kaç farklı yaklaşımı olduğunu hızlıca görmek, her birinin takasını konuşmak.
• Bilinen bir kalıbı yazmak. Şekli belli olan doğrulama, dönüştürme, tekrar eden CRUD katmanları.
• Kendi koduma ikinci bir göz. "Bu fonksiyonda gözden kaçırdığım sınır durumu var mı?" sorusu, tek başına çalışırken en çok işe yarayan kullanım.
• Test ve dokümantasyon taslağı. Taslak; son hâli değil.
• Yabancı bir kod tabanını okumak. Devraldığın bir projede hangi dosyanın ne yaptığını çıkarmak.

AI'a bırakmadığım şeyler

• Mimari kararlar. Yukarıdaki sebeple.
• Güvenlik sınırları. Gizli değerlerin nerede duracağı, kimin neye erişeceği, bir endpoint'in neyi kabul edeceği. Bunlar gözden geçirilecek değil, baştan tasarlanacak konular.
• Doğrulanmamış teknik iddialar. Bir kütüphanenin belirli bir sürümde nasıl davrandığı, bir sağlayıcının API sözleşmesi, bir platformun varsayılanı. Bunları kendi sürümünle ve kendi hesabınla sınamadan yazıya da koda da geçirmiyorum.
• Üretim verisine dokunan son adım. Migrasyon, toplu güncelleme, gerçek para veya gerçek kişisel veriyle çalışan akışlar.

Kararı projeye bağlamak

Teknoloji seçimiyle AI kullanımı aslında aynı soruyu soruyor: bu kararın sahibi kim?

Bir aracı "popüler olduğu için" seçmekle, bir kodu "AI öyle yazdığı için" bırakmak arasında yapısal bir fark yok. İkisinde de karar dışarıya devredilmiş oluyor. Sorun çıktığında ise açıklama sende aranıyor.

Pratikte bunu şöyle işletiyorum:

1. Problemi ve sınırlarını yazıyorum. Ne yapacak, ne yapmayacak, yanlış giderse ne olur.
2. Mimariyi kendim kuruyorum. Veri modeli, sınırlar, hangi kısım nereye ait.
3. Hızlandırma adımında AI'dan yararlanıyorum. Alternatifler, taslaklar, ikinci göz.
4. Çıktıyı kendi ölçütlerimle denetliyorum. Testler geçiyor mu, sınır durumları karşılanıyor mu, altı ay sonra ben bunu okuyabilir miyim.

Dördüncü adım geçilmeden hiçbir şey yayına çıkmıyor.

Yayına almadan önce sorduklarım

Yeni bir araç ya da hızlandırılmış bir çıktı üretime girmeden önce:

• Bu kararı bir başkasına gerekçesiyle anlatabiliyor muyum?
• Araç yarın bakımsız kalırsa elimde çalışan bir plan var mı?
• Kodun yaptığı işi satır satır takip edebiliyor muyum?
• Hata durumunda ne olacağı tanımlı mı — sessizce mi geçiyor, yoksa görünür bir yerde mi duruyor?
• Gizli bir değer yanlış tarafa mı düştü?

Bu soruların hiçbiri araç karşıtı değil. Hepsi aynı şeyi soruyor: karar bende mi kaldı?

Kapanış

Güncel teknolojiyi takip etmek, her yeniyi kullanmak demek değil; hangi problemin artık daha iyi bir çözümü olduğunu bilmek demek. Yapay zekâyı kullanmak da her şeyi ona yazdırmak değil; hangi adımda gerçekten hızlandırdığını bilmek demek.

İkisinde de belirleyici olan araç değil, aracı seçerken sorulan soru. Daha iyi çözümler, doğru soruları sormakla başlıyor.