Kuzeyli
Köşe Yazarı
Kuzeyli
 

Yeni kuralın adı ...

        2026'da Yapay Zekâ Ajanlarını "Sahiplenmek" Bugünün en iyi yapay zekâ araçları, ChatGPT'ye hiç benzemiyor. Hatta tam tersi bir mantıkla çalışıyorlar. ChatGPT deneyimi taslak üzerine kurulu: bir şey yazarsın, bir cevap alırsın, üzerinde oynarsın, sonra çıkarıp başka bir yere taşırsın ve orada bitirirsin. Ama son altmış günde piyasaya çıkan, büyük model üreticilerinden (Google, Anthropic, OpenAI) gelmeyen yeni girişimlerin yaklaşık yüzünü inceleyince ortaya net bir tablo çıkıyor: bu yeni oyuncular işin son halini, kullanıcının zaten bulunduğu yerde tamamlamayı hedefliyor. Yani seni başka bir yere taşımak değil, olduğun yerde son ürünü üretmek istiyorlar. "Ajan" Kelimesi Neden Bu Kadar Kafa Karıştırıcı? Bir yapay zekâ ajanını gerçekten tehlikeli kılan en hızlı yol şu: herkesin kullanmasına izin verip kimsenin sahiplenmemesi. "Ajan" kelimesini duyduğumuzda hemen "tam otonom, arka planda çalışan bir şey mi, dijital bir çalışan mı, bir model mi, Codex mi, Claude mi, yoksa trençkotlu bir ChatGPT mi" diye sorularla kafamız karışıyor. Ama asıl önemli soru bu değil. Asıl soru: bu şeyin yaptığı işten kim sorumlu? Basit bir ayrım yapalım: ChatGPT'ye bir soru sorup cevap alıp günüme devam edersem, bu bir asistan etkileşimidir — sorarım, cevap gelir, ne yapacağıma ben karar veririm. Ama notlarımı her hafta okuyup Pazartesi önceliklerimi hazırlayan, kurallarıma uyan ve gerçekten kullandığım bir iş çıktısı üreten özel bir GPT'm varsa, bu artık ajan sayılır. Bir Claude projesi dosyalar, talimatlar ve örneklerle tekrar eden bir işi yapıyorsa, veya Claude Code dosyaları inceleyip değişiklik yapıp komut çalıştırıp sonuç döndürüyorsa, artık ajan bölgesindesin. Codex'e bir repo verip "bu kodu incele, hatayı düzelt, testi çalıştır, bana diff'i göster" dersen, bu da adımlar ve araçlar üzerinden gerçek sonuçları olan bir iş yapıyor demektir. Marka adı önemli değil — ChatGPT, Claude, Codex, Cursor, bir iş akışı aracı, hepsi ajan olabilir. Etiket değil, iş önemli. Ve bir işi devrettiğin anda, o işi sahiplenme sorumluluğun başlar. Sahiplenmeden Bırakılan Ajanların Riski Yapay zekâ tartışması hâlâ "inşa etme" saplantısıyla dolu: ajan kur, ajan yap, ajanı başlat, araçları bağla, iş akışını otomatikleştir. Bunların hepsi önemli, ben de inşa etmeyi seviyorum. Ama gerçek sorumluluk, demo bittikten sonra başlıyor. İşe yarayan ajanlar demo aşamasında kalmıyor; ekibin günlük işleyişinin parçası haline geliyorlar. Bir araştırma ajanının her gün güvendiğin kaynaklardan beslenmesi gerekiyor. Bir yazma ajanının senin değişen sesini takip etmesi gerekiyor. Bir kodlama ajanının dosyalara dokunması güven gerektiriyor. Bir destek ajanı müşterilerin şirketten ne duyacağını şekillendiriyor. Bir ürün ajanı, mühendisliğin önüne gelecek iş listesini şekillendiriyor. Eğer kimse bu ajanı sahiplenmiyorsa, tehlike sıradan görünür — ta ki öyle olmaktan çıkana kadar. Ajan eski bir politikayı kullanabilir, bayat belgelerden veri çekebilir, kötü bir kalıbı tekrarlayabilir, mantıklı görünen ama yanlış bir taslak üretebilir ve sen "yine halüsinasyon görüyor" diyebilirsin. Ya da bir varsayımı öneriye çevirebilir. Çıktı çok temiz göründüğü için, insanlar onun nereden geldiğini sorgulamayı bırakır — işte asıl risk burada. Kötü niyetli bir yapay zekâ değil; sahiplenilmeyen işin, kontrol edilmediği için zamanla gerçek sonuçlar doğurması. Ajanını Nasıl "Beslersin" — Dört Adım 1. İş tanımı: Ajanın yapması gereken net bir görev olmalı. "Ürüne yardım et" gibi belirsiz bir şey değil; "bu bilet türü için iade yanıtları taslakla", "bu pull request'i riskli değişiklikler için incele" gibi tek cümleyle ifade edilebilen, gerçek bir iş. 2. "Diyet": Ajanın okuduğu her şey — belgeler, biletler, transkriptler, repo talimatları, örnekler. Bu beslenme bayatsa ajan da bayatlaşır; dağınıksa ajan da dağınıklaşır; yanlış örnekler içeriyorsa ajan kötü alışkanlıklar öğrenir. 3. Sınırlar: Ajan neye dokunabilir? Sadece okuyabilir mi, taslak hazırlayabilir mi, sisteme yazabilir mi, gönderebilir/silebilir mi? Bunlar aynı risk seviyesinde değil. Sadece taslak hazırlayan bir ajanla, sisteme doğrudan yazan veya müşteriye mesaj gönderen bir ajan tamamen farklı kategorilerde. Kural basit: belirsizsen salt-okunur veya sadece-taslak ile başla, izni kazandıkça genişlet. 4. Geri bildirim döngüsü: Ajan çalışır, bir insan (bazen başka bir ajan) inceler, neyin iyi neyin kötü olduğu not edilir, talimatlar/kaynaklar/izinler güncellenir, ajan tekrar çalışır. Karmaşık bir yönetişim süreci değil — çalıştır, incele, geliştir, tekrar çalıştır. Somut Bir Örnek: Ürün Ekibi Senaryosu Bir Scrum ekibinde, her hafta backlog hazırlığından önce birisi aynı dağınık ön hazırlığı yapıyor: müşteri biletlerini okumak, PRD'yi kontrol etmek, tasarım değişikliklerine bakmak, backlog'u taramak ve bunları kabul kriterlerine, bağımlılıklara, biletlere dönüştürmek. Ürün yöneticisi (PM) bunun için bir "hikâye hazırlama ajanı" kurar: PRD'yi, tasarım özetini, destek biletlerini, backlog'u ve birkaç iyi örnek hikâyeyi okuyup bir "rafine paket" hazırlar — final biletler değil, sadece aday hikâyeler, müşteri kanıtları, kabul kriterleri, bağımlılıklar, yapılan varsayımlar ve insanın karar vermesi gereken açık noktalar. Ekip bu pakete her hafta güvenmeye başlayınca, ajan artık bir takım ajanı haline gelir ve sprint'i şekillendirmeye başlar. PRD eskiyse, eski varsayımlar gerçek işe sızar. Destek biletleri gürültülüyse, bu da sorun yaratır. Tasarım dün değiştiyse ve ajan bunu fark etmediyse, bu da bir mesele olur. Patlama ya da robot isyanı değil — ama ekip için gerçek bir sorun. Bu noktada sahiplenme şöyle dağılır: PM, backlog kalitesinden sorumlu olduğu için ajanı sahiplenir. Mühendislik lideri teknik varsayımlara yardım eder. QA test edilebilirlik konusunda destek olur. Bakım döngüsü basit: rafine öncesi PM paketi inceler, rafine sırasında ekip neyin yardımcı neyin kafa karıştırıcı olduğunu not eder, sprint sonrasında PM birkaç hikâyeyi kontrol eder — mühendisler yeniden yazmak zorunda kaldı mı, QA anladı mı, bağımlılıklar geç mi ortaya çıktı? Girdileri düzeltebiliyorsan (bayat PRD'yi çıkar, daha iyi örnek ekle, neyi okuyabileceğini değiştir), sistemi düzeltmiş olursun. Komut Vermek ile İş Vermek Arasındaki Fark "Bu özellik için kabul kriterleri yaz lütfen" demek bir istektir. Oysa "PRD'yi, son yirmi destek biletini, tasarım özetini ve en iyi üç backlog örneğimizi oku; rafine için hikâyeleri taslakla, müşteri kanıtını ekle, varsayımları işaretle ve Jira bileti oluşturma — her şeyi önce benim gözden geçirmem için incelemeye koy" demek bir iştir — kaynakları, sınırları, çıktısı ve geri bildirim döngüsü olan bir iş. 2026'da yapılması gereken asıl geçiş bu: istekten işe geçiş. Takım Liderleri İçin: Ajan Envanteri Sahiplenilmeyen ajanlar her yerde tehlike yaratabilir: kalibrasyon öncesi performans notlarını özetleyen ama kimsenin sahiplenmediği bir İK ajanı bayat yönetici geri bildirimlerinden besleniyor olabilir; aday değerlendirme kartları hazırlayan ama sahipsiz bir işe alım ajanı sapabilir; sahipsiz bir destek triyaj ajanı eski bir iade politikasını uygulayabilir. Takım liderleri için çözüm büyük bir veritabanı değil, basit bir ajan listesi: hangi ajanlar kullanılıyor, kim sahibi, hangi kaynakları okuyor, izinleri ne, gözden geçirme sıklığı ne, bilinen hata modları ne. Her ajan için bir "sahiplenme kartı" — isim, sahip, iş tanımı, kaynaklar, yapabildikleri, yapamadıkları ve izlenmesi gereken hata modu. Bu, bireyler için de aynı şekilde işliyor; bir Slack kanalında herkesin kendi ajan kartını paylaştığı bir sistem bile kurulabilir — Google'ın A2A protokolünün ajanlar arası "tanıtım kartları" mantığına benzer, ama bu sefer insanlar için.   2026 Ötesi ... 2023'te öğrendiğimiz beceri istem yazma (prompting) idi. 2025'te öğrendiğimiz beceri devretme (delegation) idi. 2026'nın becerisi ise bakım (maintenance) — çünkü işe yarayan ajanlar artık bizim sorumluluğumuz haline geliyor. Karar kuralı basit: bir sistem önemli bağlamı okuyabiliyorsa, üzerine hareket ettiğin bir iş üretiyorsa, başkalarının bağımlı olduğu bir iş akışına dokunuyorsa, şimdi bir sahibi olması gerekir. Senin işinse sen sahiplenirsin; takımın işiyse takım birini sahip olarak atamalı. Kimse sahiplenmek istemiyorsa, o ajan muhtemelen önemli bir iş yapmamalı — kapatılmayı düşünmek gerekir. En çok ajana sahip olmak veya her aracı bilmek önemli değil; sahiplendiğin ve gerçek değer ürettiğin az sayıda ajana sahip olmak önemli. Neyi yediklerini, neye dokunabildiklerini, nasıl gözden geçirdiğini ve ne zaman güvenip ne zaman güvenmeyeceğini bilmek — işte yapay zekâ ajanlarını "yetişkin" bir şekilde benimsemenin gerçek hali bu.

Yeni kuralın adı ...

 

 

 

 

2026'da Yapay Zekâ Ajanlarını "Sahiplenmek"

Bugünün en iyi yapay zekâ araçları, ChatGPT'ye hiç benzemiyor. Hatta tam tersi bir mantıkla çalışıyorlar. ChatGPT deneyimi taslak üzerine kurulu: bir şey yazarsın, bir cevap alırsın, üzerinde oynarsın, sonra çıkarıp başka bir yere taşırsın ve orada bitirirsin. Ama son altmış günde piyasaya çıkan, büyük model üreticilerinden (Google, Anthropic, OpenAI) gelmeyen yeni girişimlerin yaklaşık yüzünü inceleyince ortaya net bir tablo çıkıyor: bu yeni oyuncular işin son halini, kullanıcının zaten bulunduğu yerde tamamlamayı hedefliyor. Yani seni başka bir yere taşımak değil, olduğun yerde son ürünü üretmek istiyorlar.

"Ajan" Kelimesi Neden Bu Kadar Kafa Karıştırıcı?

Bir yapay zekâ ajanını gerçekten tehlikeli kılan en hızlı yol şu: herkesin kullanmasına izin verip kimsenin sahiplenmemesi. "Ajan" kelimesini duyduğumuzda hemen "tam otonom, arka planda çalışan bir şey mi, dijital bir çalışan mı, bir model mi, Codex mi, Claude mi, yoksa trençkotlu bir ChatGPT mi" diye sorularla kafamız karışıyor. Ama asıl önemli soru bu değil. Asıl soru: bu şeyin yaptığı işten kim sorumlu?

Basit bir ayrım yapalım:

  • ChatGPT'ye bir soru sorup cevap alıp günüme devam edersem, bu bir asistan etkileşimidir — sorarım, cevap gelir, ne yapacağıma ben karar veririm.
  • Ama notlarımı her hafta okuyup Pazartesi önceliklerimi hazırlayan, kurallarıma uyan ve gerçekten kullandığım bir iş çıktısı üreten özel bir GPT'm varsa, bu artık ajan sayılır.
  • Bir Claude projesi dosyalar, talimatlar ve örneklerle tekrar eden bir işi yapıyorsa, veya Claude Code dosyaları inceleyip değişiklik yapıp komut çalıştırıp sonuç döndürüyorsa, artık ajan bölgesindesin.
  • Codex'e bir repo verip "bu kodu incele, hatayı düzelt, testi çalıştır, bana diff'i göster" dersen, bu da adımlar ve araçlar üzerinden gerçek sonuçları olan bir iş yapıyor demektir.

Marka adı önemli değil — ChatGPT, Claude, Codex, Cursor, bir iş akışı aracı, hepsi ajan olabilir. Etiket değil, önemli. Ve bir işi devrettiğin anda, o işi sahiplenme sorumluluğun başlar.

Sahiplenmeden Bırakılan Ajanların Riski

Yapay zekâ tartışması hâlâ "inşa etme" saplantısıyla dolu: ajan kur, ajan yap, ajanı başlat, araçları bağla, iş akışını otomatikleştir. Bunların hepsi önemli, ben de inşa etmeyi seviyorum. Ama gerçek sorumluluk, demo bittikten sonra başlıyor. İşe yarayan ajanlar demo aşamasında kalmıyor; ekibin günlük işleyişinin parçası haline geliyorlar.

  • Bir araştırma ajanının her gün güvendiğin kaynaklardan beslenmesi gerekiyor.
  • Bir yazma ajanının senin değişen sesini takip etmesi gerekiyor.
  • Bir kodlama ajanının dosyalara dokunması güven gerektiriyor.
  • Bir destek ajanı müşterilerin şirketten ne duyacağını şekillendiriyor.
  • Bir ürün ajanı, mühendisliğin önüne gelecek iş listesini şekillendiriyor.

Eğer kimse bu ajanı sahiplenmiyorsa, tehlike sıradan görünür — ta ki öyle olmaktan çıkana kadar. Ajan eski bir politikayı kullanabilir, bayat belgelerden veri çekebilir, kötü bir kalıbı tekrarlayabilir, mantıklı görünen ama yanlış bir taslak üretebilir ve sen "yine halüsinasyon görüyor" diyebilirsin. Ya da bir varsayımı öneriye çevirebilir. Çıktı çok temiz göründüğü için, insanlar onun nereden geldiğini sorgulamayı bırakır — işte asıl risk burada. Kötü niyetli bir yapay zekâ değil; sahiplenilmeyen işin, kontrol edilmediği için zamanla gerçek sonuçlar doğurması.

Ajanını Nasıl "Beslersin" — Dört Adım

1. İş tanımı: Ajanın yapması gereken net bir görev olmalı. "Ürüne yardım et" gibi belirsiz bir şey değil; "bu bilet türü için iade yanıtları taslakla", "bu pull request'i riskli değişiklikler için incele" gibi tek cümleyle ifade edilebilen, gerçek bir iş.

2. "Diyet": Ajanın okuduğu her şey — belgeler, biletler, transkriptler, repo talimatları, örnekler. Bu beslenme bayatsa ajan da bayatlaşır; dağınıksa ajan da dağınıklaşır; yanlış örnekler içeriyorsa ajan kötü alışkanlıklar öğrenir.

3. Sınırlar: Ajan neye dokunabilir? Sadece okuyabilir mi, taslak hazırlayabilir mi, sisteme yazabilir mi, gönderebilir/silebilir mi? Bunlar aynı risk seviyesinde değil. Sadece taslak hazırlayan bir ajanla, sisteme doğrudan yazan veya müşteriye mesaj gönderen bir ajan tamamen farklı kategorilerde. Kural basit: belirsizsen salt-okunur veya sadece-taslak ile başla, izni kazandıkça genişlet.

4. Geri bildirim döngüsü: Ajan çalışır, bir insan (bazen başka bir ajan) inceler, neyin iyi neyin kötü olduğu not edilir, talimatlar/kaynaklar/izinler güncellenir, ajan tekrar çalışır. Karmaşık bir yönetişim süreci değil — çalıştır, incele, geliştir, tekrar çalıştır.

Somut Bir Örnek: Ürün Ekibi Senaryosu

Bir Scrum ekibinde, her hafta backlog hazırlığından önce birisi aynı dağınık ön hazırlığı yapıyor: müşteri biletlerini okumak, PRD'yi kontrol etmek, tasarım değişikliklerine bakmak, backlog'u taramak ve bunları kabul kriterlerine, bağımlılıklara, biletlere dönüştürmek. Ürün yöneticisi (PM) bunun için bir "hikâye hazırlama ajanı" kurar: PRD'yi, tasarım özetini, destek biletlerini, backlog'u ve birkaç iyi örnek hikâyeyi okuyup bir "rafine paket" hazırlar — final biletler değil, sadece aday hikâyeler, müşteri kanıtları, kabul kriterleri, bağımlılıklar, yapılan varsayımlar ve insanın karar vermesi gereken açık noktalar.

Ekip bu pakete her hafta güvenmeye başlayınca, ajan artık bir takım ajanı haline gelir ve sprint'i şekillendirmeye başlar. PRD eskiyse, eski varsayımlar gerçek işe sızar. Destek biletleri gürültülüyse, bu da sorun yaratır. Tasarım dün değiştiyse ve ajan bunu fark etmediyse, bu da bir mesele olur. Patlama ya da robot isyanı değil — ama ekip için gerçek bir sorun.

Bu noktada sahiplenme şöyle dağılır:

  • PM, backlog kalitesinden sorumlu olduğu için ajanı sahiplenir.
  • Mühendislik lideri teknik varsayımlara yardım eder.
  • QA test edilebilirlik konusunda destek olur.

Bakım döngüsü basit: rafine öncesi PM paketi inceler, rafine sırasında ekip neyin yardımcı neyin kafa karıştırıcı olduğunu not eder, sprint sonrasında PM birkaç hikâyeyi kontrol eder — mühendisler yeniden yazmak zorunda kaldı mı, QA anladı mı, bağımlılıklar geç mi ortaya çıktı? Girdileri düzeltebiliyorsan (bayat PRD'yi çıkar, daha iyi örnek ekle, neyi okuyabileceğini değiştir), sistemi düzeltmiş olursun.

Komut Vermek ile İş Vermek Arasındaki Fark

"Bu özellik için kabul kriterleri yaz lütfen" demek bir istektir. Oysa "PRD'yi, son yirmi destek biletini, tasarım özetini ve en iyi üç backlog örneğimizi oku; rafine için hikâyeleri taslakla, müşteri kanıtını ekle, varsayımları işaretle ve Jira bileti oluşturma — her şeyi önce benim gözden geçirmem için incelemeye koy" demek bir iştir — kaynakları, sınırları, çıktısı ve geri bildirim döngüsü olan bir iş. 2026'da yapılması gereken asıl geçiş bu: istekten işe geçiş.

Takım Liderleri İçin: Ajan Envanteri

Sahiplenilmeyen ajanlar her yerde tehlike yaratabilir: kalibrasyon öncesi performans notlarını özetleyen ama kimsenin sahiplenmediği bir İK ajanı bayat yönetici geri bildirimlerinden besleniyor olabilir; aday değerlendirme kartları hazırlayan ama sahipsiz bir işe alım ajanı sapabilir; sahipsiz bir destek triyaj ajanı eski bir iade politikasını uygulayabilir.

Takım liderleri için çözüm büyük bir veritabanı değil, basit bir ajan listesi: hangi ajanlar kullanılıyor, kim sahibi, hangi kaynakları okuyor, izinleri ne, gözden geçirme sıklığı ne, bilinen hata modları ne. Her ajan için bir "sahiplenme kartı" — isim, sahip, iş tanımı, kaynaklar, yapabildikleri, yapamadıkları ve izlenmesi gereken hata modu. Bu, bireyler için de aynı şekilde işliyor; bir Slack kanalında herkesin kendi ajan kartını paylaştığı bir sistem bile kurulabilir — Google'ın A2A protokolünün ajanlar arası "tanıtım kartları" mantığına benzer, ama bu sefer insanlar için.

 

2026 Ötesi ...

2023'te öğrendiğimiz beceri istem yazma (prompting) idi. 2025'te öğrendiğimiz beceri devretme (delegation) idi. 2026'nın becerisi ise bakım (maintenance) — çünkü işe yarayan ajanlar artık bizim sorumluluğumuz haline geliyor.

Karar kuralı basit: bir sistem önemli bağlamı okuyabiliyorsa, üzerine hareket ettiğin bir iş üretiyorsa, başkalarının bağımlı olduğu bir iş akışına dokunuyorsa, şimdi bir sahibi olması gerekir. Senin işinse sen sahiplenirsin; takımın işiyse takım birini sahip olarak atamalı. Kimse sahiplenmek istemiyorsa, o ajan muhtemelen önemli bir iş yapmamalı — kapatılmayı düşünmek gerekir.

En çok ajana sahip olmak veya her aracı bilmek önemli değil; sahiplendiğin ve gerçek değer ürettiğin az sayıda ajana sahip olmak önemli. Neyi yediklerini, neye dokunabildiklerini, nasıl gözden geçirdiğini ve ne zaman güvenip ne zaman güvenmeyeceğini bilmek — işte yapay zekâ ajanlarını "yetişkin" bir şekilde benimsemenin gerçek hali bu.

Yazıya ifade bırak !
Sitemizden en iyi şekilde faydalanabilmeniz için çerezler kullanılmaktadır, sitemizi kullanarak çerezleri kabul etmiş saylırsınız.