Ali Özgür

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?”

Brett Hemenway Falk ve Gerry Tsoukalas’ın Mart 2026 tarihli “The AI Layoff Trap” başlıklı çalışması, yapay zekâ ve istihdam tartışmasına alıştığımız eksenden bakmıyor. Makalenin odağı, “çalışanlar işlerini kaybederse ne olur?” sorusuyla sınırlı değil. Daha sert ve teknoloji liderleri açısından daha rahatsız edici bir soru soruyor:

Şirketler yapay zekâ ile maliyetlerini düşürürken, bir taraftan da kendi ürün ve hizmetlerine olan toplam talebi de düşürüyor olabilir mi?

Bir cuma akşamı production ortamında kritik bir hata çıktığını düşünün. Sistem çalışıyor ama bazı müşteriler sipariş oluşturamıyor. Loglar temiz. Monitoring sistemleri olağan dışı bir şey göstermiyor. Kodun ilgili kısmına bakan ekip üyeleri mantıksal bir problem göremiyor.

Sonra ekipte biri şöyle diyor:

“Ah… bu davranış aslında bilerek böyle yapılmıştı.”

Herkes dönüp soruyor: “Bunu kim yaptı?”

Cevap: “Üç yıl önce ayrılan bir geliştirici.”

O noktada organizasyon bir gerçekle yüzleşiyor. Kod orada olabilir. Ama sistemi gerçekten anlayan kişi artık organizasyonda değildir.

Bu sahne yazılım sektöründe sanıldığından çok daha yaygındır. Tam olarak bu nedenle Baldur Bjarnason’ın “Theory-building and why employee churn is lethal to software companies” yazısı bence yazılım organizasyonları üzerine yazılmış en önemli metinlerden biri.

Çünkü yazının merkezindeki fikir oldukça net:

Yazılım yalnızca kod değildir. Yazılım, ekiplerin zihnindeki kolektif anlayışın çalışan bir dışavurumudur.

Bu yaklaşımın kökeni ise Peter Naur’un yıllar önce ortaya koyduğu “Programming as Theory Building” düşüncesine dayanıyor.

Son birkaç yıldır teknoloji dünyasında sürekli aynı cümleyi duyuyoruz:

“Yapay zeka her şeyi değiştirecek.”

Bu cümle artık o kadar sık tekrarlandı ki, neredeyse anlamını kaybetti. Ama bazen bazı metinler çıkıyor ve size teknolojinin sadece ne yapabildiğini değil, insanlık için ne anlama geldiğini düşündürüyor.

Kyle Kingsbury’nin “The Future of Everything is Lies, I Guess” başlıklı uzun denemesi tam olarak böyle bir metin. Teknik bir makale değil. Bir yatırım sunumu değil. Bir ürün lansmanı hiç değil. Daha çok, yapay zekanın insan hayatına sızarken beraberinde getirdiği kültürel, psikolojik ve toplumsal kırılmaları anlatan karanlık ama dürüst bir düşünce yazısı.

Kök neden analizi, yani RCA (Root Cause Analysis), endüstride uzun yıllardır kullanılan en önemli iyileştirme araçlarından bir tanesi. Üretimden havacılığa, finanstan enerji sektörüne kadar birçok alanda, yaşanan bir problemin gerçek nedenini bulmak ve aynı problemin tekrar yaşanmasını engellemek için RCA süreçleri uygulanıyor.

Temel mantık oldukça basit. Bir sorun yaşandıysa sadece görünen sonucu değil, o sonucu ortaya çıkaran gerçek nedeni bulmak gerekir. Çünkü semptomları düzeltmek ile problemi çözmek aynı şey değildir.

Jevons Paradoksu, bir kaynağın kullanım verimliliği arttığında o kaynağın toplam tüketiminin azalmak yerine artabileceğini ifade eder. İlk bakışta bu durum sezgisel olarak yanlış gibi görünür. Çünkü yaygın beklenti, verimlilik artışının daha az kaynak tüketimine yol açmasıdır. Ancak ekonomik sistemler çoğu zaman sezgisel beklentilerle değil, teşvikler ve davranışlar üzerinden çalışır.

Paradoksun temelinde oldukça basit ama güçlü bir mekanizma vardır. Bir kaynağın daha verimli kullanılması, o kaynağın efektif maliyetini düşürür. Maliyet düştüğünde ise talep artar.

Agent sistemleriyle ilgili konuşurken çoğu ekip hala aynı varsayımla ilerliyor: eğer kod doğruysa sistem güvenlidir. MCP ile birlikte bu varsayım artık geçerli değil. Çünkü bu sistemlerde kararları kod değil, model veriyor. Model ise dünyayı API contract’ları üzerinden değil, doğal dil üzerinden anlıyor.

Bu fark küçük gibi görünür ama etkisi büyük. Çünkü model bir şeyi yanlış anladığında, bu artık sadece yanlış bir cevap değildir; yanlış bir aksiyondur. MCP’nin sunduğu şey tam olarak bu: modelin dış dünyada işlem yapabilmesi. Ama aynı zamanda yeni bir risk katmanı da ekler: semantic yanlış anlama.

Yapay zeka son birkaç yılda “hızlı dene – hızlı üret” paradigmasıyla ilerledi. Model seç, prompt yaz, deploy et. Özellikle LLM tabanlı ürünlerde bu yaklaşım neredeyse varsayılan hale geldi. Ancak Avrupa Birliği’nin AI Act düzenlemesi ile birlikte bu dönem kapanıyor. Artık yapay zeka sadece bir yazılım bileşeni değil; regüle edilen bir ürün.

Bu yazıda AI Act’in ne olduğunu anlatmanın ötesine geçip, geliştiriciler ve teknoloji şirketleri için gerçek dünyada neyi değiştirdiğini konuşalım.