2017 yılının bahar aylarında Google’da sekiz araştırmacı bir makale yayımladı. Büyük ses getiren bu makaleyi hepimiz biliyoruz. Ama pek bilinmeyen ilginç bir detay var. Araştırmacılar isimlerin hangi sırayla yazılacağında anlaşamayınca geleneği bozdular, her ismin yanına bir yıldız koyup dipnota herkesin eşit katkı verdiğini ve sıralamanın rastgele olduğunu yazdılar. Makalenin başlığı da hayli iddialıydı: “Attention Is All You Need.”
Aslında dikkat mekanizması yeni bir fikir sayılmazdı. 2014’te Dzmitry Bahdanau, Kyunghyun Cho ve Yoshua Bengio, çeviri modellerinin cümlenin hangi kısmına bakacağını kendisinin seçmesini sağlayan bu yöntemi ortaya koymuştu. Google’daki sekiz araştırmacının yaptığı şey ise daha radikaldi: dikkat dışındaki her şeyi attılar. Eski modeller metni aynı bizim gibi soldan sağa, kelime kelime okuyordu ve okuduklarını da aklında tutmaya çalışıyordu. Yeni model ise cümleyi bir bütün olarak görüyor. Her kelime, anlamını netleştirmek için diğer kelimelere aynı anda bakıyor ve hangilerinin kendisi için önemli olduğunu hesaplıyor. "Çayın kenarında oturup çay içtik" cümlesinde ilk "çay" en çok "kenarında" kelimesine, ikincisi "içtik" kelimesine ağırlık verir. Biri akarsu diğeri içecek olur. Dikkat dediğimiz şey tam olarak bu ağırlıklandırma. Bu mimariye “Transformer” adını verdiler. Bugün ChatGPT’den Claude’a, Gemini’dan Grok’a kadar kullandığımız büyük dil modellerinin neredeyse tamamının atası bu mimari.
Bu çözüm birçok derdi sona erdirdi. Ama bir bedeli vardı. Her kelimenin diğer bütün kelimelere bakması hesaplama maliyetini müthiş derecede büyütüyordu. Bu bedel daha çok para harcayarak ödendi. Herkes daha fazla GPU satınaldı ve modellerin aynı anda dikkat edebildiği metin, yani context window büyüdü.
Dokuz yıl sonra ise darboğaz değişti. Artık darboğaz biziz. Yapay zekâ, ona verdiğimiz her token’ı okuyup anlayabiliyor. Biz ise onun yazdığı kodu okumayı bıraktık.
Okumayı bırakmak
2025’in başında Andrej Karpathy bir fikir ortaya attı: vibe coding. Kısaca özetleyecek olursam kodu okumadan, yalnızca çalışıp çalışmadığına bakarak yazılım geliştirmek. Kısa sürede bu bir fikir olmaktan çıkıp bir yönteme dönüştü. Bugün bazı ekipler, adını ışıkları kapalı çalışan üretim tesislerinden alan “karanlık fabrika” düzenini savunuyor: spesifikasyon giriyor, test edilmiş yazılım çıkıyor. Arada kodu yazan, inceleyen ya da okuyan bir insan yok.
Sanırım artık hepimiz şu durumdayız: daha çok ürün çıkarabiliyoruz. Aklımıza ne gelirse onu çok hızlı geliştirebiliyoruz. Ama uygulamalar ve işimiz gelişirken biz de gelişebiliyor muyuz?
Peki bir hata fark ettiğimizde ya da bize bildirildiğinde ne oluyor? Kodu bilmiyoruz, hatanın nereden kaynaklandığını kafamızda canlandıramıyoruz. Tek çıkış yolumuz, hatayı yine yapay zekâya verip çözmesini beklemek. Bunu da mutlaka yaşadığınızı düşünüyorum. Bu durumda yapay zekâ agent’ları genellikle makul cevaplar üretir. Ama unutmayın: makul görünen cevap güvenli cevap değildir. Aradaki farkı anlamak için ise kodun nasıl çalıştığını bilmek gerekir.
Kullanmak ile hükmetmek
Buna yöneltilebilecek en güçlü itiraz şu: nasıl çalıştığını bilmediğimiz makineleri zaten her gün kullanıyoruz. Motorunu bilmeden otomobil kullanıyoruz. Leonard Read’in 1958 tarihli yazısında söylediği gibi, bir kurşun kalemin nasıl yapıldığını baştan sona bilen tek bir insan bile yok. Daha çarpıcısı, büyük dil modellerinin içeride nasıl çalıştığını onları geliştiren laboratuvarlar bile tam olarak bilmiyor. Modern teknoloji, kimsenin tamamını anlamadığı sistemlerin üzerine kurulu.
İtiraz haklı, ama şu ayrımı hatırlatmak isterim: kullanmak için anlamak gerekmez ama hükmetmek için gerekir. Sürücü otomobili kullanır. Bozulduğunda ne olduğunu bilen, sorumluluğu taşıyan ve karar veren ise mühendistir. Otopilot uçağı uçurur, ama bir şey ters gittiğinde uçağa hükmetmesi beklenen pilottur.
Burada anlamak her satırı bilmek anlamına gelmiyor. Gereken, makinenin ne zaman yanlış yaptığını fark edecek kadar mekanizmayı tanımak. Yazılım geliştiricinin işi kullanıcılık değil, hükmetmek. Sistem çöktüğünde “kodu agent yazdı” bir savunma sayılmıyor. Modelin kendisini anlayamıyorsak, en azından onun ürettiği kodu anlamak zorundayız. Kontrolün tutunabileceği son nokta orası.
Kasların erimesi
Sorun, bu anlayışın kendiliğinden korunmaması. 1983’te Lisanne Bainbridge, endüstriyel süreç kontrolündeki operatörler üzerine yazdığı “Ironies of Automation” makalesinde bir çelişkiye dikkat çekti: otomasyon rutin işi devraldıkça insana yalnızca en zor anı bırakır, yani sistemin çöktüğü anı. Ama rutini devraldığı için, o an geldiğinde gereken beceriyi de köreltmiş olur.
Kırk yılı aşkın bir süre sonra aynı durumu agent’larda yaşıyoruz. Bugünkü agent yapısı etkili denetimi zorlaştırıyor ve denetim için gereken bilişsel kapasiteler de yapay zekânın uzun süreli kullanımıyla aşınıyor. Kısacası, Bainbridge’in ironisinin güncel bir versiyonunu yaşıyoruz. Aşınmanın en sinsi yanı da fark edilmemesi. Hatırlamakta fayda var: hızlandığımızı hissetmek, hızlandığımızı göstermiyor.
Bu aşınma bireysel olmaktan çıkıp kurumsal bir soruna da dönüştü. Kıdemli bir geliştirici, yıllarca kod okuyup hata ayıklayarak biriktirdiği birikimle bugün yanlışı fark edebiliyor. Ama kodu okumadan onaylayarak büyüyen junior o muhakeme yeteneğini hiç kazanamıyor. Bugün okumayı atlayan ekip, beş yıl sonra sistemi denetleyebilecek kıdemli geliştiriciyi yetiştirmemiş olacak. Yazılım geliştirme ve kodlama gün geçtikçe kolaylaşıp daha da ileriye gidiyor; onu denetleyecek insanlar ise giderek zayıflıyor.
Ağırlığı nereye vermeli
Her satırı okumaya geri dönmek mümkün değil. Aslında gerekli de değil. Transformer mimarisinden çıkaracağımız ders de tam olarak bu: model her kelimeye bakar ama her kelimeye aynı ağırlığı vermez. Mesele, ağırlığı nereye vereceğini bilmek.
İlk adım, okunmadan geçmememiz gereken bölgeleri belirlemek. Mesela kimlik doğrulama, ödeme, veri silme, veritabanı işlemleri gibi hatanın geri alınamadığı alanlarda hiçbir değişiklik -ne kadar test edilmiş olursa olsun- bir insan okumadan merge edilmemeli. Bu liste ekibin dikkat haritasıdır ve sistem değiştikçe o da güncellenmelidir. Elbette liste projenin yapısına göre değişebilir. Burada anlatmaya çalıştığım nokta, hatanın bedeli.
İkinci adım, merge eden kişinin değişikliği kendi cümleleriyle anlatabilmesini şart koşmak. Ne yaptığını, neden bu şekilde yapıldığını ve neyi bozabileceğini açıklayamayan biri o kodun sorumluluğunu taşıyamaz. Bunun için sadece değişenleri değil mantığı anlamak gerekir. Kısaca değişikliğin dokunduğu akışı baştan sona izlemek. Agent’tan bu akışı anlatmasını istemek iyi bir başlangıç, ama o açıklamayı da bir model üretecek. Onu kodla karşılaştırmadan kabul etmek, okumamanın daha kibar bir biçimi.
Üçüncü adım, kasları bilinçli olarak çalıştırmak. Pilotların belirli aralıklarla otopilotu kapatıp elle uçması gibi, geliştiricilerin de, özellikle junior’ların, bazı hataları yapay zekâ yardımı olmadan ayıklaması, bazı modülleri baştan sona kendilerinin yazması gerekiyor. Bu kısa vadede verimsiz görünebilir. Ama makinenin yanlışını fark edebilecek insanı yetiştirmenin başka yolu yok.
2017’deki makalenin dipnotunda isimlerin sırasının rastgele olduğu yazıyordu. Bizim yaşadığımız durumda sıra rastgele değil: önce okumak, sonra anlamak, ancak ondan sonra hükmetmek. Dokuz yıl önce yapay zekâya dikkatin yettiğini kanıtlandı. Şimdi aynı şeyi kendimize kanıtlama sırası bizde.