Ali Özgür

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.

“Loop Engineering: Kendi Kendini İyileştiren Yapay Zekâ Döngüleri” yazımda loop engineering kavramını, yani LLM tabanlı sistemleri tek seferlik cevap üreten araçlar olmaktan çıkarıp kontrollü, doğrulanabilir ve gerektiğinde kendini düzelten süreç bileşenleri haline getirme fikrini ele almıştım.

Orada temel soru şuydu:

Bir LLM’i hedefe doğru adım adım ilerleyen, hata yaptığında geri dönebilen, sonucu test edebilen ve gerektiğinde kendini iyileştirebilen bir yapıya nasıl dönüştürürüz?

Yapay zekâ, yazılım geliştirme süreçlerini kökten değiştirdi. Artık dakikalar içinde kod üretebiliyor, test senaryoları hazırlayabiliyor, SQL yazabiliyor, dokümantasyon oluşturabiliyor ve mimari alternatifleri tartışabiliyoruz.

Bu değişimin en görünür sonucu üretkenlik artışı oldu. Ancak, bence gözden kaçan başka bir değişim daha yaşanıyor. Yapay zeka yalnızca üretkenliğimizi artırmıyor, yazılım geliştirirken nasıl davrandığımızı da değiştiriyor.

Yapay zekâ ile yazılım geliştirme, veri analizi, dokümantasyon ve iş süreçleri otomasyonu artık tek seferlik “soru-cevap” etkileşimlerinin ötesine geçiyor. Birkaç yıl önce gündemimizde daha çok prompt engineering vardı: Modele doğru soruyu nasıl sorarız? Bağlamı nasıl veririz? Beklediğimiz çıktıyı nasıl tarif ederiz?

Bugün ise daha farklı bir noktaya doğru ilerliyoruz. Artık mesele yalnızca iyi prompt yazmak değil; yapay zekâ sistemlerinin bir işi alıp, adım adım ilerleyebileceği, hata yaptığında geri dönebileceği, sonucu test edebileceği, öğrendiğini kaydedebileceği ve bir sonraki denemede daha iyi davranabileceği kontrollü döngüler tasarlamak.

Bu yaklaşımı genel olarak loop engineering olarak adlandırabiliriz.

Loop engineering, yapay zekâ destekli sistemlerde şu soruya cevap arar:

Bir LLM’i tek seferlik cevap üreten bir araç olmaktan çıkarıp, hedefe doğru kontrollü şekilde ilerleyen, doğrulanan ve gerektiğinde kendini düzelten bir süreç bileşeni haline nasıl getiririz?

Bu yazıda loop engineering kavramını, self-improving loop yani kendi kendini iyileştiren döngü fikrini, erken benchmark sonuçlarının bu konuda bize ne söylediğini ve bu yaklaşımın yazılım geliştirme ile kurumsal yapay zekâ sistemleri açısından ne anlama geldiğini ele alacağım.

Teknoloji tarihinde bazı dönemler vardır. Herkes büyük bir değişimin geldiğini hisseder, şirketler yatırım yapar, yöneticiler sunumlarında bu yeni teknolojiden bahseder, danışmanlar yeni kavramlar üretir, tedarikçiler hızlıca yeni ürünler çıkarır. Fakat bütün bu hareketliliğe rağmen verimlilik göstergeleri beklenen hızda değişmez. İnsanlar doğal olarak şu soruyu sormaya başlar: “Bu kadar büyük teknoloji yatırımı yapıyoruz ama gerçek verimlilik nerede?”