Uygulama Mühendisinin Sonu: Gelecek 10 Yıl Neden AI Agent Geliştirenlerin Olacak?

Tarihin kafiyeli tekerrür etmek gibi garip bir huyu vardır, genellikle de tam biz rahatımıza bakarken.

90'ların sonunu hayal edin. Eğer HTML ile boğuşup, yanına biraz Perl veya PHP katarak çalışan bir web sitesi ortaya çıkarabiliyorsanız, siz bir büyücüydünüz. Siz bir Web Mühendisiydiniz ve dünya ayaklarınızın altındaydı. İnternetin vitrinlerini siz inşa ediyordunuz.

2009'a hızlı saralım. iPhone dünyayı yeni çatlatıp açmıştı. Aniden, kimse statik web sitenizi o kadar da umursamamaya başladı. Enerji Objective-C ve Java'ya kaydı. Eğer bir Mobil Uygulama Mühendisiyseniz, geleceği yazıyordunuz. İnsanların ceplerinde taşıdığı araçları siz inşa ediyordunuz.

Şimdi 2024'e bakın. Hava yine ince ve durgun hissettiriyor. Uygulama mağazaları doygunluğa ulaştı; web tıklım tıklım. Ancak yüzeyin altında tektonik bir kayma yaşanıyor. Arayüz (Interface) çağından çıkıp, Agent (Ajan) çağına giriyoruz.

Önümüzdeki on yılda en değerli unvan "Full Stack Geliştirici" veya "iOS Mühendisi" olmayacak. Bu unvan AI Agent Mühendisi olacak.

Yeni Tektonik Kayma

Bu sadece başka bir framework savaşı ya da öğrenilecek yeni bir programlama dili değil. Bu, işi kimin yaptığına dair temel bir değişiklik.

Son yirmi yıldır yazılım mühendisliği, insanların tıklaması için net, deterministik (belirlenmiş) yollar inşa etmekten ibaretti. Siz bir buton yapardınız; insan ona tıklardı; kod bir fonksiyonu çalıştırırdı. İnsan beyindi; yazılım ise kastı.

Bu dinamik tersine dönüyor.

Agent Çağında, beyni yazılım sağlıyor. İşiniz artık insanın tıklaması için buton yapmak değil. İşiniz, butona ne zaman tıklayacağına karar veren, hatta daha da iyisi, butona hiç ihtiyaç olmadığını fark eden dijital çalışanı inşa etmek.

10 yılı aşkın süredir ürün geliştiriyorum ve zeminin hareket ettiğini hissedebiliyorum. Bugün size hizmet eden, iş akışınızı otomatize eden veya müşterilerinize hizmet veren bir agent yazabiliyorsanız, 1999'da bir işi internete taşımayı yeni öğrenmiş o çocukla aynı kaldıraca sahipsiniz demektir.

Ama işte acı gerçek: Eğer bunu öğrenmeyi reddederseniz, eğer sadece deterministik kodlamaya bağlı kalırsanız, masaüstü yayıncılık çağında bir dizgici (typesetter) olmanın dijital karşılığına dönüşme riskiyle karşı karşıyasınız.

Büyünün Gizemini Çözmek: Araçlar ve Bağlam

İnsanlar "AI Agent" terimini duyduklarında Skynet'i veya imkansız derecede karmaşık bir sinir ağı mimarisini hayal ediyorlar. Gelin şu gürültüyü bir keselim.

Bir agent inşa etmek büyü değildir. Mühendisliktir. Ve temelde iki şeye dayanır: Araçlar (Tools) ve Bağlam (Context).

Çoğu geliştiricinin bu konuyu gereğinden fazla karmaşıklaştırdığını görüyorum. Kendi modellerini eğitmeleri gerektiğini sanıyorlar. Gerek yok. Modeller—Claude, GPT-4, Llama—zaten yeterince zeki. Sizin işiniz onlara el ve hafıza vermek.

1. Araçlar (Modele El Vermek)

Büyük Dil Modeli (LLM), sadece kavanozdaki bir beyindir. Düşünebilir ama dünyaya dokunamaz. Bir "Agent", basitçe API uç noktalarına veya CLI komutlarına erişim verilmiş bir LLM'dir.

Modele şöyle dersiniz: "Burada list_files (dosyaları listele) adında bir araç var. Burada read_file (dosya oku) adında bir araç var. Burada send_email (e-posta gönder) adında bir araç var."

2. Bağlam (Modele Yön Vermek)

Sonra rolü tanımlarsınız. "Sen kıdemli bir QA mühendisisin. Amacın bu depodaki (repository) tip hatalarını düzeltmek."

İşte bu kadar. Temel döngü budur.

Eğer Cursor veya Claude Code kullandıysanız, bunu iş başında görmüşsünüzdür. Düzenlemeleri mikro düzeyde yönetmezsiniz. " utils.ts içindeki tip hatalarını düzelt" dersiniz.

Agent düşünür: Tamam, önce dosyayı görmem lazım. ls aracını kullanmaya karar verir. Sonra grep veya read kullanmaya karar verir. Hatayı tespit eder. Düzeltmeyi yazmaya karar verir. İşini kontrol etmek için derleyiciyi çalıştırır.

Büyük atılım budur. Bu artık sadece "sohbet etmek" değil. Bu bir karar döngüsü. Model, verdiğiniz problemi çözmek için hangi araçları eline alacağını seçiyor.

Chatbotlardan Karar Motorlarına

Son iki yıldır "Sohbet" (Chat) evresinde sıkışıp kaldık. Yapay zekaya akıllı bir kütüphaneci muamelesi yapıyoruz; bir soru soruyoruz, o da cevap veriyor.

O evre sona eriyor.

Agent evresi icraat (execution) ile ilgilidir. Bu, CLI'a (Komut Satırı Arayüzü) sizin yazı yazacağınız bir yer olarak değil, modelin oyun alanı olarak bakmak demektir.

Bunun startup'lar için ne anlama geldiğini düşünün. Eskiden, müşteri iadelerini yönetecek bir hizmet kurmak istesem, bir arayüz (UI), bir backend, bir veritabanı inşa etmem ve butonlara tıklaması için bir destek ekibi kurmam gerekirdi.

Bugün, bir agent yazabilirim. Ona Stripe API'sine (Araç) ve e-posta geçmişimize (Bağlam) erişim veririm. Ona bir politika veririm: "Kullanıcı 7 gün içinde memnun kalmazsa iade yap." Agent gelen e-postayı okur, kriterlere uyup uymadığına karar verir, Stripe iade aracını tetikler ve bir yanıt taslağı hazırlar.

Arayüze gerek yok. Destek talebi kuyruğuna gerek yok. Sadece bir hedef ve bir dizi araç.

Agent İnşa Etmenin "Karmaşık Ara Dönemi"

Burada bir ütopya tablosu çizmek istemiyorum. Son altı ayımı agent inşasının siperlerinde geçirdim ve size şunu söyleyeyim: ortalık karışık.

Geleneksel kodlama mantıksaldır. Eğer X ise Y. Ya çalışır ya da bozulur.

Agent mühendisliği olasılıksaldır. Agent'ı inşa edersiniz, araçları verirsiniz ve bazen pencereyi açmak için çekiç kullanmaya karar verir. Bazen var olmayan bir parametre uydurur (halüsinasyon görür).

Yeni yetenek seti tam da burada yatıyor.

Bir AI Agent Mühendisi olmak sadece Python scriptleri yazmak değildir. Şunları içerir:

• Mimari Olarak Prompt Mühendisliği: Modelin davranışını kısıtlamak için sistem prompt'larını tasarlamak.
• Eval (Değerlendirme) Odaklı Geliştirme: Yaratıcılık için birim testleri (unit tests) yazamazsınız, bu yüzden agent'ın bir görevde ne sıklıkla başarılı olduğunu ölçmek için değerlendirme hatları (pipelines) kurarsınız.
• Araç Tasarımı: Modelin kafası karışmadan anlayabileceği kadar "temiz" API arayüzleri oluşturmak.

Agent'ların kendi yarattıkları bir hatayı düzeltmeye çalışırken sonsuz döngülere girdiğini gördüm. Yanlış dosyayı kendinden emin bir şekilde sildiklerini gördüm. Gerçek bu. Ancak bu sürtünme noktalarını çözmek, tam olarak değerin yaratıldığı yerdir.

Pratik Çıkarımlar: Bugün Nasıl Başlanır

Eğer bugün sıfırdan başlıyor olsaydım veya kariyerimde bir yön değişikliği (pivot) yapmak isteseydim, tam olarak şunları yapardım:

1. GUI (Arayüz) Yapmayı Bırakın: En azından yan projeleriniz için. Bir problemi frontend olmadan çözmeye çalışın. Bunu bir CLI ve bir LLM ile çözebilir misiniz?
2. Arayüz Protokolünü Öğrenin: OpenAI'ın fonksiyon çağırma (function calling) veya Anthropic'in araç kullanımının (tool use) nasıl çalıştığını anlayın. Bu, agent çağının TCP/IP'sidir.
3. "Konuşan" değil "Yapan" Bir Şey İnşa Edin: Takviminizle ilgili soruları yanıtlayan bir bot yapmayın. Takviminizi yöneten bir bot yapın. Ona etkinlikleri silme yeteneği verin. Bir yapay zekaya yazma erişimi vermenin korkusunu hissedin. İşte o zaman gerçekten öğrenmeye başlarsınız.
4. Bağlam Yönetiminde Ustalaşın: Doğru bilgiyi, bağlam penceresini (context window) taşırmadan içeriye nasıl sığdıracağınızı öğrenin. RAG (Retrieval-Augmented Generation), sadece başlangıç.

Önümüzdeki Fırsat

Tek bir geliştiricinin, uzmanlaşmış agent'lardan oluşan bir filoyla donanmış olarak, 20 kişilik bir startup'ın işini yapabileceği bir geleceğe bakıyoruz.

Yaratım için giriş bariyerleri sıfıra iniyor. Ancak orkestrasyon için—yani bu beyinleri birbirine nasıl bağlayacağını anlamak için—giriş bariyerleri yeni hendek (moat) haline geliyor.

On yıl önce, kodu yazmak için işe alınıyordunuz. Bugün, kodu yazan sistemi mimari olarak tasarlamak için işe alınıyorsunuz.

Tren istasyondan kalkıyor. Ya peronda durup eski framework'lerinize sıkı sıkı sarılabilirsiniz ya da atlayıp rayların döşenmesine yardım edebilirsiniz.

Hadi inşa edelim.