Yazardan yöneticiliğe: ajanlarla birlikte geliştiricinin işi nasıl değişiyor?

Ajanlar kod yazmayı çok daha ucuz hâle getirdi. Ama neyin yapılacağını anlamayı ve ortaya çıkan sonucu kontrol etmeyi ucuzlatmadı. Bu yüzden ajanlarla çalışmanın en ilginç kısmı kod yazılmadan önce ve sonra yaşanıyor: görevi kim tanımlıyor, sonucun iyi olduğuna kim karar veriyor ve işin ne kadarının ajana verileceği nasıl seçiliyor?

Aşağıda, son iki yılın araştırma ve raporlarının bu konuyu nasıl anlattığına bakacağız: ajanla çalışmanın dört yolu, göreve uygun yolun seçimi ve "niyet ile kalite çıtası" denen şey. İkinci yarıda geliştiricinin rolünün neden kod yazmaktan daha geniş hâle geldiğini konuşacağız. Veriler Eylül 2026 itibarıyla. Rakamlar kaynak bağlantısıyla ayrı bloklarda yer alıyor. Yazarların görüşlerini aktarırken kimden söz ettiğimi belirtiyor, kendi çıkarımlarımı da ayrıca işaretliyorum.

Ajanla çalışmanın dört yolu

En açık şemayı Microsoft'tan Jared Spataro Mayıs 2026'da önerdi. İnsanla yapay zekânın işi nasıl paylaştığına dair dört yol anlatıyor. Şema anlaşılır; geliştirici araçlarla kat ettiği kendi yolunu burada tanıyacaktır.

Basamak yükseldikçe elle yazdığınız iş azalır; önceden karar verme ve sonradan kontrol etme payınız artar. Yazar, yazarken kaliteyi aklında tutar. Direktör kodun nasıl ortaya çıktığını görmez; bu yüzden onun için önemli olan her şey işe başlamadan söylenmeli, sonrasında da kontrol edilmelidir. Orkestratörlük burada yalnızca adı geçen bir rol: araçlarıyla birlikte başlı başına büyük bir konu. İlk üç yol sağlam biçimde oturduktan sonra ele almak daha doğru.

Merdiven değil, göreve uygun yol

Bu şemayı merdiven gibi okumak kolay: önce yazar olursunuz, sonra orkestratörlüğe kadar yükselirsiniz; ne kadar yukarı, o kadar iyi. Spataro tam tersini söylüyor. Amaç her görevi dördüncü yola taşımak değil, her iş akışına uygun yolu seçmek.

Uygulamada seçim dört soruya dayanıyor:

• Hedef ne kadar net? Nasıl bir sonuç istediğinizi henüz kendiniz de bilmiyorsanız görevin tamamını vermek için erken;
• Sonuç otomatik olarak kontrol edilebilir mi? İyi testler ajana daha fazla alan açar; hatayı dikkatiniz değil, kontrol yakalar;
• Bir hatanın bedeli ne? Bir ipucundaki yazım hatasını düzeltmek kolay, yanlış para hesabıysa pahalıya patlar;
• Görev tekrarlanıyor mu? Tek seferlik bir görev için ayrı süreç kurmaya değmez; her hafta tekrarlanıyorsa değer.

Somut görevlerde seçim şöyle görünüyor:

Bence bu rakamları akılda tutmakta fayda var. Çoğunluğun temkinli olması geride kaldıkları anlamına gelmiyor: insanlar yöntemi hatanın bedeline göre seçiyor ve bu doğru. Hata maliyetinin yüksek olduğu bir görevde editör gibi çalışıyorsanız bu, ajanı "yeterince kullanmadığınız" anlamına gelmez.

Claude Code'da bu seçimi doğrudan ayarlayabilirsiniz. Plan mode ve izin kuralları sizin belirlediğiniz bir ayar düğmesi gibi çalışır. Hata maliyeti yüksekse düzenlemelerden önce planı ve riskli eylemler için onayı açarsınız; rutin işlerde ajana daha fazla alan tanırsınız.

Niyet ve kalite çıtası

Ne kadar çok işi devrederseniz, işe başlamadan söyledikleriniz o kadar önemli hâle gelir. Microsoft araştırması bunu şöyle ifade ediyor: yapay zekâyı en etkili kullananlar daha fazlasını daha hızlı yapanlar değil, değerlerini yalnızca insanın yapabildiği şeyler üzerine kuranlar olacak. Bu da açık bir niyet belirlemek, yani istenen sonucu ve kalite çıtasını tarif etmek, bir de işin insanlar ve yapay zekâ arasında nasıl paylaşılacağını düşünmek demek.

Yazılım geliştirmede bu fikrin yerleşik adları zaten var. Niyet, neyin neden yapılacağını anlatan spesifikasyondur. Kalite çıtası ise kabul kriterleri ve Scrum'da Definition of Done denen şeydir: işin tamamlanmış sayılması için gereken koşulların listesi. Bundan sonra buna kısaca tamamlanma çıtası diyeceğiz.

Microsoft'tan, Agile yaklaşımıyla ajanlar geliştiren Daniel Epstein bunu Agentic-Agile serisinin ilk yazısında (19 Mayıs 2026) çok kısa ifade etti: "Every capability is an issue. Every issue has acceptance criteria." Her yetenek bir görevdir. Her görevin kabul kriterleri vardır.

Bir görevi baştan iki farklı üslupla yazmak kullanışlıdır. İnsanlara görevin neden ve kimin için gerekli olduğunu açıklarsınız. Ajana ne yapacağını, nasıl kontrol edileceğini ve nereye dokunmaması gerektiğini söylersiniz. Aşağıdaki eğitim amaçlı örnekte aynı isteğin önceki ve sonraki hâlini görebilirsiniz. İkinci örneğin ilk paragrafı insanlara, geri kalanı ajana yöneliktir.

Önce:

Harcamaları CSV olarak dışa aktar, düzgün olsun.

Sonra:

Neden: muhasebeci her ay ekip harcamalarını kendi tablosuna
elle aktarıyor. Bir saat sürüyor ve tutarlarda hatalar oluyor.

Görev: aylık harcamalar sayfasına "CSV olarak dışa aktar" düğmesi ekle.

Şu koşullarda tamamlanmış sayılır:
- dosya tablo düzenleyicisinde çift tıklamayla açılır, Türkçe
  adlar kodlamayı elle ayarlamadan okunur;
- her satır bir harcamadır, ilk satırda sütun adları yer alır;
- hücreleri düzenlemeden formülle tutarlar toplanabilir.

Dokunma: harcamaların saklanma biçimine ve mevcut liste ekranına.
Önce planı ve her maddeyi nasıl kontrol edeceğini göster.

İkinci örnekte ajanın tahmin etmesi gereken neredeyse hiçbir şey kalmıyor. Daha önemlisi, sonucu karşılaştırabileceğiniz ölçütler var: üç maddeyi birkaç dakikada elle kontrol edebilirsiniz. İlk örnekteki "düzgün" sözcüğünü doğrulamanın yolu yok. Ona ancak güvenebilirsiniz.

Ajan neyin iyi olduğunu bilmez

Buradan sonrası verilerin kendisinden çok benim çıkardığım sonuçlar. Görüşümü araştırma sonucu gibi sunmamak için bunu baştan belirteyim.

Ajan pek çok şeyi yapabilir: bilmediği bir projeyi okuyabilir, hatanın nedenini bulabilir, uygulamayı yazabilir, testleri çalıştırabilir ve ne yaptığını açıklayabilir. Yapamayacağı bir şey var: bu kullanıcılar ve bu iş için "iyi yapmak" ne demek, buna kendi başına karar vermek. Ölçütler yoksa kulağa makul gelen ortalama bir seçeneği seçer ve hazırmış gibi kendinden emin biçimde raporlar. Kod düzenli olabilir ama çözüm yine de yanlış olabilir.

"İyi" kavramı kodda bulunmaz. Sonucu kimin kullanacağına, bu kişi için neyin önemli olduğuna ve hangi hataların kabul edilemeyeceğine bağlıdır. Dışa aktarma örneğinde ajan teknik açıdan doğru bir CSV hazırlayabilir, ama muhasebeci dosyayı açtığında karakterler bozuk görünebilir. Kod açısından her şey doğru, görevin amacı açısından değil.

Çıkarım basit. Ölçüt belirlemek ve sonucu ona göre kontrol etmek, devredemeyeceğiniz işlerden biri. Ajan ölçütleri ifade etmenize yardım edebilir, netleştirici sorular sorabilir ve kontroller önerebilir. Ölçütlerin doğru olup olmadığına karar vermek yine size kalır.

Önce süreci anlamak

Ölçütler nereden gelir? Neredeyse hiçbir zaman koddan değil. İş sürecinden gelir: dosyayı kim açacak, sonra ne yapacak, bir satır kaybolursa ya da tutar yanlış yuvarlanırsa ne olur?

"Türkçe adlar elle ayar yapmadan okunmalı" koşulu, CSV'yi böyle yazmak doğru olduğu için ortaya çıkmadı. Birisi muhasebeciye dosyaları nasıl açtığını sordu ve onun içe aktarma sihirbazı kullanmadan çift tıkladığını gördü. Süreci bilen geliştirici bu ölçütü baştan yazar. Bilmeyen ise bir ay sonra gelen şikâyetle öğrenir.

Şirketler de bunu fark edip rolleri yeniden düzenliyor.

Bu konunun ters yöndeki görüşünü de bilmekte fayda var. Örneğin danışmanlık şirketi Converteo blogunda ürün yöneticisi, tasarımcı ve AI product builder rollerini birbiriyle rekabet eden değil, birbirini tamamlayan roller olarak anlatıyor: ilki "neden" sorusunu, ikincisi kullanıcıyı ele alıyor, üçüncüsü fikri hızla çalışan bir prototipe dönüştürüyor. Converteo da bu alanda hizmet satıyor. Ben bu görüşlerden birine bahis oynamazdım. Sizin için pratik sonuç aynı: müşterinin sürecini anlayan bir geliştirici, kusursuz yazılmış bir ticket bekleyenden daha değerlidir.

İletişim bir iş aracı

Eskiden soft skills çoğu zaman teknik becerilere hoş bir ek gibi sunulurdu. Ajanlarla bu değişiyor. Kalite ölçütleri repoda değil, insanların aklında; bunları ortaya çıkarmanın tek yolu konuşmak.

İşin parçası hâline gelenler şunlar:

• sorun. "Ne yapalım?" değil, "Sonuçla ne yapacaksınız?" diye sorun; insanlar bu soruya daha net yanıt veriyor;
• netleştirin. Uç durum hataya dönüşmeden sorun: kategorisi olmayan harcamayla ne yapacağız?
• kaydedin. Yalnızca konuşmada kalan anlaşmayı ajan okuyamaz, iş arkadaşınız da unutur;
• sınırları belirleyin. Göreve nelerin dahil olduğunu ve olmadığını netleştirin; "hazır başlamışken şunu da düzelt" dediklerinde "bu ayrı bir görev" deyin;
• ödünleşimi açıklayın. "Dönem seçimi olmadan bir günde ya da seçim ekleyerek üç günde yaparız." Karar müşterinin, seçenekleri sunmak sizin işiniz.

Bu becerilerin hiçbiri kodla ilgili değil ama her biri ajanın yapacağı işi doğrudan etkiliyor. Yani insanlarla konuşmanızın kalitesi, ajana verilen görevin kalitesine dönüşüyor.

Herkes biraz CEO

Hepsini bir araya getirince tanıdık bir tablo çıkıyor. Hedef koymak, ölçüt belirlemek, işi dağıtmak, sonucu kontrol etmek ve sorumluluğunu almak yöneticinin işidir. Ajanlarla çalışan geliştirici de her gün, küçük ölçekte olsa da, bunları yapıyor.

CEO benzetmesinin işe yarar yanı, sorumluluğun kimde olduğunu doğru göstermesi. CEO, sonuçtan sorumluluğu dışında neredeyse her şeyi devredebilir. Ajanlarda da aynı durum geçerli. Ajan muhasebecinin tablosunu bozan bir dışa aktarma hazırlarsa, bunun sorumlusu ajan olmaz.

Benzetmenin ne anlama gelmediğini de söylemek gerek. Bu bir terfi değil; üç ajan çalıştırmak kimseyi yönetici yapmaz. Daha çok, yöneticilik becerileri eskisinden daha erken, ilk işinizde bile gerekebilir. Bir de şu risk var: geliştiriciler uzun süre kodu elle yazarak ilerledi, şimdi bu yol değişiyor. Ajandan kabul ettiğiniz kodu anlamak hâlâ şart. Yoksa kontrol "galiba çalışıyor" demekten ibaret kalır.

Bu veriler nasıl okunmalı?

Yukarıdaki rakamların tümü yapay zekâ ya da onunla bağlantılı ürünler satan şirketlerden geliyor. Bu, verilerin yanlış olduğu anlamına gelmez ama akılda tutmak gerekir. Kısa bir özet:

Buradaki tüm yüzdeler, insanların belirli bir andaki öz değerlendirmeleridir. Gerçekte ne olduğunu değil, insanların ne düşündüğünü ve beklediğini gösterirler. Work Trend Index 2026'nın yazarları, analizlerindeki ilişkilerin neden-sonuç değil, istatistiksel bağlantılar olduğunu açıkça belirtiyor.

Yapay zekâ ve işle ilgili her rakama bakarken üç soru sorun. Araştırmayı kim finanse etti? Tam olarak ne ölçüldü: görüş mü, beklenti mi, gerçek sonuç mu? Kimlere soruldu ve bu kişiler size benziyor mu? Yanıtlar içinize siniyorsa rakamı kullanabilirsiniz. Sinmiyorsa yine de ilginç olabilir, yalnızca ağırlığı daha azdır.

Bütün bunlar ne işe yarıyor?

Yukarıda rapor diliyle anlatılanlar, Claude Code kullanırken somut alışkanlıklara dönüşüyor:

• düzenlemeden önce plan - niyetin kendisi. Ajandan önce neyi, nasıl değiştireceğini göstermesini isteyin; sonra bunu sizin isteğinizle karşılaştırın;
• istekte kabul kriterleri - tamamlanma çıtanız. "Düzgün olsun" yerine kontrol edilebilir iki üç madde;
• çalışma modu ve izin kuralları - yöntem seçimi. Hatanın bedeli yükseldikçe ajan daha sık durup sorar;
• diff'i inceleyip sonucu gerçekten kontrol etmek - ajanın raporuna değil, kendi ölçütlerinize göre değerlendirmek;
• kısa özet: ne yapıldı, nasıl kontrol edildi, ne kontrol edilmedi - ajana devredilemeyecek sonuç sorumluluğu.

Veriler Eylül 2026 itibarıyla. Bu alandaki araştırmalar sık yayımlanıyor; rakamlar, çıkarımlardan daha hızlı geçerliliğini yitiriyor.