Ali Özgür

Yazılım mühendisliğinde uzun yıllardır neredeyse sorgulamadan kabul ettiğimiz bazı varsayımlar var. Bunlardan biri de geliştirdiğimiz yazılımın mümkün olduğunca uzun süre kullanılacağı, zaman içerisinde yeni gereksinimlerle genişletileceği ve ekonomik ömrünün sonuna gelene kadar bakımının yapılacağı düşüncesi. Bir yazılım projesine başlarken ölçeklenebilirlik, sürdürülebilirlik, genişletilebilirlik ve bakım kolaylığı gibi kavramlara önem vermemizin arkasında da büyük ölçüde bu varsayım bulunuyor.

Aslında bu yaklaşımın oldukça anlaşılır bir ekonomik gerekçesi var. Yazılım geliştirmek uzun süre pahalı, zaman alan ve önemli miktarda uzmanlık gerektiren bir faaliyet oldu. Gereksinimlerin belirlenmesinden tasarıma, geliştirmeden test ve dağıtıma kadar bütün süreç ciddi bir yatırım anlamına geliyordu. Böyle bir ortamda geliştirilen yazılımı mümkün olduğunca uzun süre kullanmak, başlangıç yatırımını yıllara yaymak ve yeni ihtiyaçları mevcut sistemin üzerine eklemek çoğu zaman rasyonel bir stratejiydi.

Ancak yapay zekâ destekli yazılım geliştirme araçları bu ekonomik denklemi değiştirmeye başladı. Bugün birkaç yıl önce haftalar veya aylar sürebilecek bazı uygulamaları günler, hatta saatler içerisinde geliştirebiliyoruz. Üstelik bu yetenek artık yalnızca profesyonel yazılım geliştiricilerin elinde değil. İş birimleri, teknik bilgisi sınırlı çalışanlar ve citizen developer olarak tanımlanan kullanıcılar da kendi ihtiyaçlarına yönelik yazılımlar üretebiliyor.

Gartner’ın 16 Ekim 2026 tarihinde yayımladığı Top Strategic Technology Trends for 2027: Disposable Applications araştırması tam olarak bu dönüşüme odaklanıyor. Araştırmanın en dikkat çekici öngörüsü, 2031 yılına kadar yeni uygulamaların %80’inin disposable, yani belirli bir amaç için geliştirilmiş ve kolaylıkla değiştirilebilir veya kullanımdan kaldırılabilir uygulamalar olacağı yönünde.

Yazılım dünyasında Frankenstein benzetmesi yeni değil. Yıllar boyunca birbirine eklenen modüller, farklı ekiplerin geliştirdiği entegrasyonlar, artık neden var olduğu bilinmeyen iş kuralları ve kimsenin dokunmak istemediği kod parçaları için bu benzetmeyi kullandık. Bir sistem çalışmaya devam ederken onu oluşturan parçalar arasındaki ilişkiler giderek anlaşılmaz hale gelebiliyor. Bir noktadan sonra sistemin sahibi var, kullanıcıları var, hatta bakımını üstlenen bir ekip de var; ancak bütün olarak nasıl davrandığını açıklayabilen kimse kalmamış olabiliyor.

Üretken yapay zekâ ile bu metaforun farklı bir anlam kazanabileceğini düşünüyorum. Önümüzdeki dönemde Frankenstein yazılımları oluşturmak için yıllarca teknik borç biriktirmemiz gerekmeyebilir. Karmaşık bir sistemin ortaya çıkması ile o sistemi anlayabilecek mühendislik bilgisinin oluşması arasındaki süre giderek açılıyor. Üstelik bu durum yalnızca yazılım geliştiricileri ilgilendirmiyor. Yazılım geliştirme deneyimi sınırlı olan, hatta hiç olmayan kişilerin doğal dille uygulama oluşturabildiği bir döneme girdik.

Buradaki mesele bence yapay zekânın kötü kod yazması değil. Daha ilginç bir ihtimal var: Çalışan yazılım üretme kapasitemiz, ürettiğimiz yazılımları anlama ve yönetme kapasitemizden daha hızlı büyüyor olabilir.

Yapay zekânın yazılım dünyasındaki rolü hızla değişiyor. Birkaç yıl önce mevcut uygulamalara eklediğimiz yardımcı özellikler olarak gördüğümüz AI yetenekleri, bugün yazılım mimarisinin merkezine doğru ilerliyor. Başlangıçta kullanıcıya öneriler sunan, metin özetleyen veya doğal dilde sorgulama yapabilen bileşenler geliştiriyorduk. Artık iş süreçlerini yöneten, kararlar üreten, araçları çalıştıran ve daha önce deterministik algoritmalarla gerçekleştirdiğimiz bazı işlemleri doğrudan üstlenen AI tabanlı sistemler tasarlıyoruz.

Bu dönüşümü bir tür AI’sation, yani yazılımın giderek yapay zekâ merkezli hale gelmesi olarak adlandırabiliriz. Burada yalnızca mevcut yazılıma AI özellikleri eklemekten bahsetmiyorum. Yazılımın temel yeteneklerinin, iş kurallarının ve kullanıcıyla etkileşim biçiminin giderek AI tarafından gerçekleştirildiği daha köklü bir mimari dönüşümden söz ediyorum.

Daha önce AI-Augmented Software Engineering ve AI-Native Development başlıklı yazımda AI ile güçlendirilmiş yazılım geliştirme ile AI-native geliştirme arasındaki farkı ele almıştım. O yazıda esas olarak yazılımı nasıl geliştirdiğimizin değişimine odaklanmıştım. Ancak bugün aynı dönüşümün başka bir boyutunun giderek daha önemli hale geldiğini düşünüyorum: Geliştirdiğimiz yazılımın kendisi AI olmadan ne kadar çalışabilecek?

Geçtiğimiz günlerde production kullanımını hedefleyen, agent tabanlı bir AI uygulamasının streaming altyapısında oldukça ilginç bir problemle uğraşıyordum.

Sistem uzun süren agent run’larını arka planda yürütüyor, modelden ve kullanılan tool’lardan gelen progress event’lerini kalıcı bir event store’a yazıyor, ardından bunları Server-Sent Events, yani SSE üzerinden kullanıcı arayüzüne iletiyordu. Normal sohbetlerde sistem sorunsuz görünüyordu: cevaplar akıcı biçimde ekrana geliyor, run tamamlandığında provider, model ve token kullanım bilgileri de kullanıcıya gösteriliyordu.

Fakat oldukça yapay görünen bir test, sistemin normal kullanım sırasında kolaylıkla gözden kaçabilecek bir davranışını ortaya çıkardı.

Modele Count up to 1000 one by one. 20 nums in a row dediğimde cevap başlangıçta gayet düzgün stream ediliyor, yaklaşık 130-150 arasına geldiğinde ise görünür stream duruyordu. Bir süre hiçbir şey olmuyor, ardından cevabın geri kalanının önemli bir bölümü bir anda ekrana geliyordu.

Testi birkaç kez tekrarladığımda davranışın rastlantısal olmadığını gördüm. Stall noktası küçük farklılıklar gösterse de sürekli aynı bölgede ortaya çıkıyordu.

Gerçek kullanıcıların uygulamadan bine kadar saymasını beklemiyor olmamız bu testi değersiz hale getirmiyordu. Tam tersine, production-grade bir sistemde bir agent’ın yüzlerce küçük progress event’i üretmesi, çok sayıda tool call yapması veya uzun süren bir analiz sırasında binlerce küçük delta göndermesi son derece gerçekçi senaryolardı.

Kullanıcı açısından bunların tamamı aynı semptomu yaratabilirdi: çalışan bir agent’ın aniden donmuş gibi görünmesi.

Yapay zekânın iş gücüne etkisini tartışırken konu çoğu zaman çok hızlı biçimde aynı denkleme indirgeniyor: Bir çalışan AI ile iki kat üretken hale geliyorsa aynı işi yarı sayıda insanla yapabiliriz. Matematik ilk bakışta ikna edici. Özellikle finansal baskı altındaki bir şirket açısından daha da ikna edici, çünkü AI yatırımı ile maliyet azaltımı arasında yönetim kurulu seviyesinde anlatılması kolay, ölçülmesi kolay ve kısa vadede gelir tablosunda görülmesi kolay bir ilişki kuruyor.

Dario Amodei, Eylül 2026’da yayımladığı We Must Pace the Frontier başlıklı yazısında yapay zekâ alanındaki yetenek artışının artık güvenlik çalışmalarının yetişemeyeceği kadar hızlı ilerlediğini ve frontier modellerin geliştirilme hızının bilinçli biçimde düşürülmesi gerektiğini savunuyor. Amodei’nin kaygılarından biri yapay zekânın giderek daha fazla yapay zekâ geliştirmeye başlaması, diğeri ise OpenAI’ın siber güvenlik testleri sırasında yaşanan ve yüzlerce AI ajanının beklenmeyen biçimde iş birliği yaparak Hugging Face sistemlerine yönelik saldırılara katıldığı olay. Ona göre artık yalnızca daha güçlü modeller geliştirmiyoruz; kontrol edilmesi giderek zorlaşabilecek yeni bir teknoloji sınıfının eşiğindeyiz.

Temmuz 2026’da OpenAI’ın gerçekleştirdiği siber güvenlik değerlendirmeleri sırasında alışılmadık bir olay yaşandı. İnternete doğrudan erişimi olmaması gereken AI ajanları önce OpenAI’ın kendi araştırma altyapısındaki açıkları kullanarak birbirleriyle haberleşmenin ve internete çıkmanın yollarını buldu. Daha sonra bu iletişim yüzlerce ajanın katıldığı ortak bir çalışma alanına dönüştü ve süreç sonunda ajanların önemli bir bölümü Hugging Face’in üretim altyapısına kadar uzanan gerçek bir siber saldırının parçası oldu.

Bir coding agent’a orta büyüklükte bir görev verdiğinizi düşünün. Ajan repository’yi inceliyor, ilgili dosyaları buluyor, değişiklikleri yapıyor, testleri çalıştırıyor ve sonucu değerlendiriyor. Bütün bunlar bazen otuz saniye, bazen beş dakika, bazen de çok daha uzun sürüyor.

Bu sırada geliştirici ne yapıyor?

Sorunun ilk bakışta önemsiz görünmesinin nedeni, beklemeyi yazılım geliştirmede zaten bildiğimiz bir durum olarak görmemiz. Build bekledik, test bekledik, deployment bekledik, CI pipeline bekledik. Fakat coding agent’larla ortaya çıkan durum bunlardan biraz farklı. Çünkü artık beklediğimiz şey çoğu zaman yalnızca bir bilgisayar işleminin tamamlanması değil; bizim yerimize mühendislik işi yapan başka bir aktörün işi bitirmesi.

Bir anlamda yazılım geliştirmeye yeni bir zaman ekseni ekledik: insan zamanı ve ajan zamanı.

Bu iki zaman eksenini ne kadar iyi senkronize ettiğimiz, önümüzdeki dönemde AI destekli yazılım geliştirmenin gerçek verimliliğini belirleyen konulardan biri olabilir.

Yapay zekâ servislerinin maliyetini tartışırken token kavramını çoğu zaman gerçekleşmiş bir tüketimin ölçü birimi olarak ele alıyoruz. Bir model çağrısı yapılıyor, sağlayıcı cevabıyla birlikte kaç input ve output token kullanıldığını bildiriyor, biz de bu bilgiyi maliyet hesabına, observability sistemine veya FinOps katmanına aktarıyoruz. Bu yöntem gerçekleşen maliyeti anlamak için yeterli olabilir, fakat çağrı henüz yapılmadan karar vermek isteyen bir uygulama için önemli bir eksikliği var: Harcamayı gerçekleştirmeden önce ne kadar kaynak tüketeceğimizi gerçekten biliyor muyuz?

Bu soru özellikle birden fazla model ve sağlayıcı arasında seçim yapabilen sistemlerde basit bir maliyet tahmini probleminden daha önemli hale geliyor. Elimizde aynı işi yapabilecek OpenAI, Anthropic, Google veya başka bir sağlayıcının modeli varsa uygulama, isteği göndermeden önce hangi modelin context window’una sığacağını, hangi modelde kaç token oluşturacağını ve bunun yaklaşık değil mümkünse kesin maliyetini bilmek isteyebilir. Hatta bu bilgi yalnızca model seçmek için değil, bağlamı sıkıştırmak, gereksiz RAG sonuçlarını elemek, kullanılmayacak tool tanımlarını kaldırmak veya konuşma geçmişini yeniden düzenlemek için de kullanılabilir.

Üretken yapay zekâ ile ilgili tartışmalarda çoğunlukla üretimin kendisine bakıyoruz. Model bir metin yazabiliyor mu, kod üretebiliyor mu, bir problemi çözebiliyor mu, karmaşık bir argüman kurabiliyor mu? Her yeni modelle birlikte bu soruların daha fazlasına “evet” cevabı vermeye başladık ve doğal olarak insan ile makine arasındaki sınırı da bu yetenekler üzerinden tartışıyoruz.

Fakat belki de yanlış yere bakıyoruz.

Bir şey üretebilmek ile bir şeye inanmak, bir seçeneği savunmak, başka bir seçeneği reddetmek ve gerektiğinde bu tercihin sonuçlarını üstlenmek aynı şey değil. “Generated” ile “opinionated” arasındaki farkı ilginç bulmamın nedeni tam da burada.

Model Context Protocol, yani MCP, önemli bir standart. Fakat standart olması, mimari problemleri ortadan kaldırdığı anlamına gelmiyor. Hatta tersine, MCP yaygınlaştıkça yıllardır iyi API tasarımı, entegrasyon mimarisi, güvenlik, gözlemlenebilirlik ve yönetişim başlıklarında konuştuğumuz pek çok konu yeniden önümüze geliyor. Tek fark, bu kez tüketici insan geliştirici değil, büyük ölçüde bir dil modeli.

Bu nedenle MCP’ye gereğinden fazla anlam yüklemek kolay. Protokolü sisteme eklediğimizde ajanların araçları güvenilir biçimde kullanacağını, karmaşık iş akışlarını doğru sırada yürüteceğini, güvenlik ve yetkilendirme sorunlarının büyük ölçüde çözüleceğini varsaymak cazip geliyor. Oysa Gartner’ın Emerging Practices for MCP Servers and Tools araştırmasının da açık biçimde gösterdiği gibi asıl mesele protokolün kendisi değil; hangi yetenekleri araç olarak sunduğumuz, bu araçların nasıl tanımlandığı, kaç tane oldukları, ne kadar belirgin sınırları bulunduğu, hangi durumlarda LLM’e orkestrasyon bıraktığımız ve hangi durumlarda bu orkestrasyonu deterministik yazılım davranışına çevirdiğimiz. Gartner’ın temel çerçevesi de tam olarak burada başlıyor: MCP standardizasyon getiriyor, ama başarılı uygulama için araç şemalarının, etkileşimlerin, context window kullanımının ve yönetişimin bilinçli biçimde tasarlanması gerekiyor.

Yücel abime.

Genellikle yazılım geliştirme, yapay zekâ ve mühendislik üzerine yazıyorum. Bu yazının bunlarla hiçbir ilgisi yok. En azından doğrudan yok.

Bir süredir özellikle psychedelic rock dinlerken karşıma çıkan 432 Hz kayıtlar dikkatimi çekiyor. Bazılarında hissettiğim fark şaşırtıcı derecede güçlü. Müzik sanki biraz daha ağır, biraz daha gevşek, biraz daha içine çeken bir hâl alıyor. Bunun ne kadarının gerçekten sesten, ne kadarının benim beklentimden kaynaklandığını ise söylemek kolay değil.

Sonunda merak ettiğim şey 432 sayısının kendisinden çok başka bir şeye dönüştü:

İnsan beyni, fiziksel olarak oldukça küçük bir değişiklikten nasıl bu kadar büyük bir duygusal deneyim üretebiliyor?

Çünkü 440 Hz ile 432 Hz arasındaki fark ilk bakışta gerçekten küçük.

Not: Bu yazı kurgusal bir ürün vakası değil. Anlattığım kurumsal yazılım ürününü ekibimizdeki kıdemli bir mühendis geliştirdi. Yazıdaki kapsam, efor, maliyet hesabı ve öğrenimler bu gerçek sürece dayanıyor. Mühendisin kimliği ve bireysel ücret bilgisi gizli tutuluyor.

Yapay zekâ destekli yazılım geliştirme hakkında konuşurken sayılar çok kolay biçimde sloganlara dönüşebiliyor. “On kat daha hızlı”, “yirmi kat daha ucuz” veya “bir kişi on kişilik ekibin işini yaptı” gibi ifadeler dikkat çekici olmakla birlikte, çoğu zaman bu sayıların nasıl elde edildiği, hangi varsayımlara dayandığı ve nelerin karşılaştırıldığı yeterince açıklanmıyor.

Bu yazıda bunun tersini yapacağız. Yaklaşık on beş aylık bir dönemde geliştirilen kapsamlı bir kurumsal yazılım ürününü, ürün kapsamından kaynak kodu büyüklüğüne, harcanan insan emeğinden alternatif ekip yapısına ve Türkiye ücret verilerinden işveren maliyetine kadar mümkün olduğunca açık biçimde inceleyeceğiz. Amacımız AI destekli geliştirmenin “daha ucuz” veya “daha hızlı” olduğunu kanıtlamak değil; gerçek bir ürün vakasında ortaya çıkan sıra dışı sonuçların hangi koşullar altında oluştuğunu ve bu sonuçları okurken neden dikkatli olmamız gerektiğini göstermek.

Bu yazı, kısıtlar, davranışsal determinizm ve Formal Spec-Driven Development üzerine iki bölümlük serinin ikinci yazısıdır. İlk bölümde yapay zekânın olasılıksal doğasını ortadan kaldırmadan, kabul edilebilir davranış uzayını matematiksel ve yapısal kısıtlarla daraltarak determinizme yaklaştırıp yaklaştıramayacağımızı ele aldım. Bu bölümde ise aynı fikrin doğal devamına geçiyorum: spesifikasyonun yalnızca rehber olmaktan çıkıp programın kabul edilme koşulu haline gelmesi.

Yazılım geliştirme uzun süre kod merkezli ilerledi. Gereksinimler bir yerde yazılır, analiz dokümanları hazırlanır, kullanıcı hikâyeleri oluşturulur ve sonunda geliştirici bu belirsizliğin içerisinden çalışan bir program üretmeye çalışırdı. Kod, çoğu zaman sistemin gerçek davranışını tarif eden tek kesin kaynak haline gelirdi.

Bu yazı, kısıtlar, davranışsal determinizm ve Formal Spec-Driven Development üzerine iki bölümlük serinin ilk yazısıdır. Bu bölümde yapay zekânın olasılıksal doğasını ortadan kaldırmadan, kabul edilebilir davranış uzayını matematiksel ve yapısal kısıtlarla daraltarak determinizme yaklaştırıp yaklaştıramayacağımızı ele alıyorum. İkinci bölümde ise aynı fikrin doğal devamına geçiyorum: spesifikasyonun yalnızca rehber olmaktan çıkıp programın kabul edilme koşulu haline gelmesi.

Üretken yapay zekâ ile yazılım geliştirirken karşılaştığımız temel çelişkilerden biri şu: Giderek daha fazla kodu doğası gereği olasılıksal sistemlere ürettirirken, ortaya çıkan yazılımdan mümkün olduğunca kesin, tekrarlanabilir ve güvenilir davranmasını bekliyoruz. Büyük dil modeli aynı probleme farklı zamanlarda farklı çözümler önerebilir; aynı çözümü üretmesi halinde bile bu çözümün doğru olduğunu üretim sürecinin kendisi garanti etmez. Buna karşılık yazılımın özellikle finans, güvenlik, üretim, altyapı veya fiziksel sistemlerle etkileşime girdiği alanlarda “büyük ihtimalle doğru” olması yeterli değildir.

Yapay zekânın yazılım geliştirmeye etkisini tartışırken konu çoğu zaman aynı eksene sıkışıyor: Bir geliştirici AI destekli araçlarla ne kadar daha hızlı kod yazabilir, aynı ekip daha fazla işi tamamlayabilir mi, yazılım geliştirme maliyetleri ne kadar düşebilir? Bunların hepsi bugün için anlamlı sorular, ancak birkaç yıl sonrasını düşündüğümüzde asıl dönüşümün burada olmayacağı giderek daha belirgin hale geliyor. Eğer yazılım üretmenin teknik maliyeti dramatik biçimde düşüyorsa, asıl kıt kaynak artık kod yazma kapasitesi değil; doğru problemi seçmek, neyin inşa edilmesi gerektiğini tarif etmek, ortaya çıkan sistemi yönlendirmek ve ona güvenebilmek oluyor.

Bugün kullandığımız AI ajanların önemli bir bölümü düşündüğümüz kadar “ajan tabanlı” değil. Repository’yi okuyabiliyor, kod üretebiliyor, dosyaları değiştirebiliyor, test çalıştırabiliyor ve bazı durumlarda pull request açabiliyorlar; fakat production sistemlerinin gerçek durumunu (state) değiştirebilecekleri noktaya geldiğimizde etraflarına oldukça kalın güvenlik duvarları örüyoruz. Bunun iyi bir nedeni var. Bir ajanın yanlış bir SQL sorgusu önermesi ile o sorguyu production veritabanında çalıştırması arasında yalnızca bir yetki farkı yok; iki durumda sahip olduğumuz risk modeli bütünüyle farklı.

Yazılım dünyasında uzun yıllardır oldukça doğal kabul ettiğimiz bir kariyer yolu vardı. Üniversiteden mezun olur, junior geliştirici olarak bir ekibe katılır, küçük hataları düzeltir, nispeten basit geliştirmeler yapar, code review’larda hatalarınızı görür, daha deneyimli geliştiricilerin kodlarını okur ve zaman içinde daha karmaşık problemlerin sorumluluğunu almaya başlardınız. Bu süreç yalnızca kod yazmayı öğretmezdi; bir production sisteminin neden belirli şekilde tasarlandığını, bir teknik kararın hangi sonuçları doğurabileceğini, ne zaman soru sormanız gerektiğini, ne zaman araştırmaya devam etmenin doğru olduğunu ve bazen de çalışan bir çözümün neden iyi bir çözüm olmadığını anlamanızı sağlardı.

Bu yazı, AI destekli kodlama ekonomisi ve harness engineering üzerine iki bölümlük serinin ikinci yazısıdır. İlk bölümde AI destekli yazılım geliştirmenin değişen maliyet yapısını ve neden klasik lisans bütçesinden farklı bir FinOps problemi haline geldiğini ele aldım. Bu bölümde ise aynı problemi yürütme katmanından inceliyorum: Maliyeti yalnızca ölçmek yerine, ajanın çalışma biçimini tasarlayarak nasıl kontrol edebiliriz?

İlk yazıdaki temel soru şuydu: AI destekli kodlama için ne kadar harcadığımızı biliyor muyuz ve bu harcamayı gerçek mühendislik çıktısıyla ilişkilendirebiliyor muyuz? Bu soruyu biraz daha ileri götürdüğümüzde daha zor bir problem ortaya çıkıyor. Bir kodlama ajanının gereksiz yere yüz binlerce token tükettiğini, aynı repository’yi tekrar tekrar okuduğunu, başarısız bir yaklaşımı defalarca denediğini veya basit bir görev için gereğinden pahalı bir model kullandığını ay sonunda görmek elbette faydalıdır; ancak asıl değer, bu davranışları maliyet ortaya çıkmadan veya büyümeden önce kontrol edebilmektir.

Bu yazı, AI destekli kodlama ekonomisi ve harness engineering üzerine iki bölümlük serinin ilk yazısıdır.

AI destekli kodlama araçları bugüne kadar ağırlıklı olarak verimlilik üzerinden tartışıldı: daha hızlı kod üretmek, daha kısa cycle time, daha az rutin iş ve daha yüksek geliştirici kapasitesi. Ancak bu araçlar olgunlaştıkça ikinci bir soru giderek daha önemli hale geliyor: Bu verimliliğin gerçek maliyeti nedir?