Ali Özgür

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?

Digital Thread serisi — Bölüm 2

Serinin ilk bölümünde Digital Thread’i ürün yaşam döngüsü boyunca oluşan bilgilerin bağlamını kaybetmeden birbirine bağlanmasını sağlayan dijital süreklilik olarak ele aldık. PLM’deki tasarım verisinden ERP’deki malzeme ve siparişlere, MES/MOM sistemindeki üretim kayıtlarından IIoT verilerine, kalite sonuçlarından servis geçmişine ve Digital Product Passport’a kadar uzanan bu yapı, tek bir sistemin doğal sınırlarını aşıyor. Bu noktada teknik olarak kaçınılmaz bir soru ortaya çıkıyor: Böyle bir Digital Thread oluşturmak istiyorsak hangi standardı kullanacağız?

Türkiye Yapay Zekâ Eylem Planı 2026–2030, yapay zekâyı yalnızca belirli sektörlerin kullanacağı yeni bir teknoloji olarak değil, ekonomik dönüşümün temel unsurlarından biri olarak ele alıyor. Planın “Fark Et, İstifade Et, Üret, Yönet” şeklinde tanımlanan dört temel ekseni; insan kaynağından hesaplama altyapısına, veriden uygulamalara, finansmandan düzenleyici çerçeveye kadar oldukça geniş bir alanı kapsıyor. Enerji, hesaplama donanımı, altyapı, modeller ve veri ile uygulamalar planın temel katmanlarını oluştururken; yetenek, finansman ve düzenleme-güven bu yapının tamamını besleyen kesişen bileşenler olarak tanımlanıyor.

Digital Thread serisi — Bölüm 1

Üretim teknolojileri dünyasında bazı kavramlar, neyi ifade ettiklerinden çok hangi ürün ailesiyle birlikte kullanıldıkları üzerinden tanınmaya başlıyor. “Digital Thread” da bunlardan biri. Kavramı çoğu zaman PLM, CAD, Digital Twin veya Model-Based Enterprise gibi başlıkların yanında görüyoruz; bu nedenle ilk bakışta bunun esas olarak ürün tasarımı ve PLM dünyasına ait bir yaklaşım olduğu izlenimi oluşabiliyor. Oysa Digital Thread’in anlamı bundan daha geniş ve özellikle üretim şirketlerinin sahip olduğu PLM, ERP, MES/MOM, QMS, IIoT, bakım, lojistik ve servis sistemleri birlikte düşünüldüğünde çok daha değerli bir çerçeve ortaya çıkıyor.

Yapay zekâ tarafından üretilen içeriğin nasıl ayırt edileceği uzun süredir teknik bir tartışma konusuydu. Bir metnin diline, kelime seçimlerine veya cümle yapılarına bakarak “bunu bir yapay zekâ yazmış olabilir” diyen sınıflandırıcılar geliştirildi; görseller için metadata ve görünür filigranlar kullanıldı; kriptografik imzalar ve içerik kökenini izleyen standartlar üzerinde çalışıldı. Ancak Ağustos 2026 itibarıyla konu yalnızca araştırma laboratuvarlarının veya güvenlik ekiplerinin meselesi olmaktan çıktı. Avrupa Birliği’nin Yapay Zekâ Tüzüğü’nün (AI Act) şeffaflığa ilişkin hükümlerinin uygulanmaya başlaması, üretken yapay zekâ sağlayıcılarını doğrudan teknik önlem almaya zorluyor.

Yapay zekâ hayatımıza yeni girmedi. On yılı aşkın süredir arama motorlarının sonuçları sıralamasından öneri sistemlerine, kredi kartı işlemlerindeki sahtekârlık tespitinden görüntü işlemeye, talep tahmininden kestirimci bakıma kadar pek çok sistemin arkasında makine öğrenmesi ve yapay zekâ modelleri bulunuyor. Hatta bugün geriye dönüp baktığımızda, günlük hayatımızda kullandığımız birçok ürünün uzun süredir AI destekli olduğunu ancak çoğu zaman bunun farkında bile olmadığımızı söyleyebiliriz.

Yuval Noah Harari’nin yapay zekâ üzerine yaptığı konuşmalarda kullandığı cin hikâyeleri benzetmesini oldukça düşündürücü buluyorum. Harari, dünyanın farklı kültürlerinde farklı biçimlerde karşımıza çıkan cin ve dilek hikâyelerindeki ortak bir noktaya dikkat çekiyor. Bu hikâyelerde temel problem çoğu zaman cinin yeterince güçlü olmaması veya insanın dileğini gerçekleştirememesi değildir. Asıl problem, insanların ne istemeleri gerektiğini bilmemeleri ve yanlış şeyleri dilemeleridir. Cin kendisinden isteneni yapar; hatta bazen dileği kelimesi kelimesine ve kusursuz biçimde gerçekleştirir. İnsan ise istediği şeyi elde ettikten sonra bunun aslında arzuladığı sonuç olmadığını veya dileğinin öngöremediği sonuçlar doğurduğunu fark eder.

Yapay zekânın yazılım geliştirme süreçlerine girişi artık “gelecekte yaşanabilecek” bir dönüşüm değil.

Bugün bir yazılım geliştirici gereksinimi analiz ederken ChatGPT kullanabiliyor, mimari alternatifleri Claude ile tartışabiliyor, Cursor veya GitHub Copilot ile kod yazabiliyor, Codex benzeri bir ajanı bir issue üzerinde çalıştırabiliyor, oluşturulan kodu başka bir LLM’e (Large Language Model — Büyük Dil Modeli) inceletebiliyor ve son olarak ortaya çıkan değişikliği Git üzerinden pull request olarak gönderebiliyor.