AI Kodlama Araçlarında “Bedava Yemek Bitti”

Son birkaç yıldır yazılım dünyasında yapay zeka destekli geliştirme araçlarını çoğunlukla verimlilik başlığı altında konuştuk. Daha hızlı kod yazmak, daha hızlı refactor yapmak, testleri daha hızlı üretmek, dokümantasyonu toparlamak, pull request açıklamalarını yazdırmak… Bunların hepsi gerçek kazanımlar. Ben de bu araçların doğru kullanıldığında ciddi zaman kazandırdığına inanıyorum.

Ama bence artık başka bir döneme giriyoruz. Bu dönemin sorusu “AI ile kod yazabilir miyiz?” değil. Bunu zaten görüyoruz. Asıl soru şu: AI destekli yazılım geliştirmeyi sürdürülebilir, ölçülebilir, güvenli ve maliyeti yönetilebilir bir mühendislik pratiği haline getirebiliyor muyuz?

GitHub Copilot’un 1 Haziran 2026 itibarıyla kullanım bazlı ücretlendirme modeline geçmesi bu yüzden önemli. İlk bakışta konu sadece fiyatlandırma gibi görünüyor. Ancak biraz daha yakından bakınca bunun aslında yazılım ekipleri için daha büyük bir kırılmanın işareti olduğunu düşünüyorum. AI coding artık “aboneliği aldık, herkes kullansın” seviyesinde kalamayacak. Kullanım, çıktı, maliyet, güvenlik, kod kalitesi ve ekip standardı birlikte yönetilmek zorunda kalacak.

Mesele sadece Copilot faturası değil

GitHub’ın dokümantasyonunda yeni modelin GitHub AI Credits üzerinden çalışacağı, Copilot kullanımının belirli planlarda dahil edilen kredi miktarlarıyla ölçüleceği ve ek kullanımın ayrıca faturalandırılacağı anlatılıyor. Özellikle daha uzun, daha karmaşık, daha ajan tabanlı görevlerin daha fazla hesaplama maliyeti doğurması sürpriz değil. Çünkü bir autocomplete önerisiyle, repository üzerinde çok adımlı analiz yapan ve dosya değiştiren bir coding agent aynı şey değil.

Bu noktada bana göre önemli olan şu: AI aracının maliyeti görünür hale geldikçe ekiplerin alışkanlıkları da görünür hale gelecek. Kim hangi aracı, hangi iş için, ne kadar kullanıyor? Bu kullanım gerçekten değer üretiyor mu? Yoksa sadece “kolay olduğu için” her küçük karar modele mi soruluyor? Birim iş başına maliyet nedir? Üretilen kodun test, review ve bakım maliyeti ne oluyor?

Bir aracın ucuz görünmesi, onun toplam maliyetinin düşük olduğu anlamına gelmez. Yazılımda bunu yıllardır biliyoruz. Kötü tasarlanmış bir mikroservis mimarisi de başlangıçta havalı görünür, ama operasyon maliyetiyle sonradan kendini gösterir. Gereksiz karmaşık bir framework tercihi de ilk sprintte hız kazandırabilir, ama ekip değiştiğinde bakım yükü olarak geri döner. AI coding araçlarında da benzer bir tablo oluşuyor.

Agent dönemi, mühendislik disiplinini azaltmıyor; artırıyor

Microsoft Build 2026 tarafındaki gündeme baktığımızda da benzer bir yön görüyoruz. Agent Framework, Foundry, Copilot ekosistemi, MCP entegrasyonları ve çok adımlı agent akışları artık konferans sunumlarının merkezinde. Bu da bize şunu söylüyor: sektör basit sohbet arayüzlerinden, daha kalıcı ve iş süreçlerine gömülü agent sistemlerine doğru ilerliyor.

Bu güzel bir gelişme. Ama aynı zamanda daha ciddi bir mühendislik problemi. Çünkü agent dediğimiz şey, klasik anlamda sadece cevap veren bir yardımcı değil. Tool çağırıyor, dosya okuyor, kod değiştiriyor, terminal komutu çalıştırıyor, PR açıyor, bazen test koşturuyor, bazen de yanlış özgüvenle gayet ikna edici ama hatalı bir çözüm üretebiliyor.

Ben burada senior mühendisliğin değerinin azalmadığını, tam tersine arttığını düşünüyorum. Çünkü artık sadece kod yazan kişi değil, kod üretim sürecini tasarlayan kişi önemli hale geliyor. Hangi işi modele vereceğiz? Hangi işi vermeyeceğiz? Hangi veri modele gidebilir? Hangi repository erişimi sınırlandırılmalı? Hangi komutlar otomatik çalışabilir? Hangi çıktılar insan review’undan geçmeden merge edilemez?

Bu sorulara cevap verilmeden AI coding araçlarını kurumsal ölçekte yaygınlaştırmak bana göre riskli. Çünkü hız tek başına başarı metriği değil. Hatalı şeyi daha hızlı üretmek de bir hızdır, ama iyi bir mühendislik sonucu değildir.

Prompt sayısı değil, mühendislik çıktısı ölçülmeli

Kullanım bazlı fiyatlandırma doğal olarak ekipleri ölçüm yapmaya itecek. Fakat burada yanlış metriklere kapılmak çok kolay. “Bu ay kaç kredi harcadık?” sorusu tek başına çok zayıf bir soru. Daha doğru soru bence şu: “Harcanan AI maliyeti hangi mühendislik sonucunu iyileştirdi?”

Örneğin bir ekip AI aracıyla daha fazla test üretiyor olabilir. Ama bu testler gerçekten davranışı yakalıyor mu, yoksa sadece coverage yüzdesini mi şişiriyor? Bir başka ekip agent ile refactor yaptırıyor olabilir. Ama refactor sonrası domain modeli sadeleşiyor mu, yoksa sadece dosya yapısı değişip karmaşıklık başka yere mi taşınıyor? Bir ekip PR açıklamalarını otomatikleştiriyor olabilir. Ama review süresi kısalıyor mu, yoksa reviewer hâlâ aynı belirsizliklerle mi uğraşıyor?

Ben AI coding araçlarının değerini üç seviyede ölçmenin daha doğru olduğunu düşünüyorum:

• Üretim etkisi: Tekrarlı işleri azaltıyor mu, geliştiricinin odağını daha değerli kararlara taşıyor mu?
• Kalite etkisi: Test kalitesi, hata oranı, review kalitesi, mimari sadelik ve bakım kolaylığı iyileşiyor mu?
• Risk etkisi: Güvenlik, gizlilik, lisans, KVKK, veri sızıntısı ve yetkisiz erişim riskleri kontrol altında mı?

Bu üç seviye birlikte ele alınmadığında AI maliyet yönetimi eksik kalır. Sadece faturaya bakarsak kaliteyi kaçırırız. Sadece hıza bakarsak güvenliği kaçırırız. Sadece güvenliğe bakıp üretkenliği yok sayarsak da ekip aracı doğal olarak etrafından dolanır. Dengeyi kurmak gerekiyor.

Kurumsal ekipler için yeni bir “AI kullanım politikası” ihtiyacı var

Bugün birçok ekipte kod review standardı var, branch stratejisi var, deployment prosedürü var, erişim yetkileri var, veri tabanı migration kuralları var. Ama AI kullanım standardı hâlâ çoğu yerde belirsiz. “Copilot açık mı kapalı mı?” seviyesinde bir karar yeterli değil.

Bence kurumsal ekiplerde en azından şu başlıkların netleşmesi gerekiyor:

• Hangi projelerde AI coding aracı kullanılabilir?
• Hangi veri, kod veya müşteri bilgisi modele gönderilemez?
• Agent hangi repository yetkilerine sahip olabilir?
• Terminal komutu çalıştırma, dosya silme, migration üretme gibi aksiyonlarda sınır nedir?
• AI tarafından üretilen kod için review ve test zorunluluğu nasıl tanımlanır?
• AI kullanım maliyeti hangi ekip veya proje bütçesine yazılır?
• Üretilen çıktının lisans, güvenlik ve KVKK açısından sorumlusu kimdir?

Bu sorular bürokrasi olsun diye sorulmuyor. Tam tersine, iyi tanımlanmış sınırlar ekibe hız kazandırır. Çünkü geliştirici neyi yapabileceğini, neyi yapamayacağını, hangi durumda insan onayı gerektiğini bilir. Belirsizlik azaldıkça kullanım kalitesi artar.

AI maliyeti, bulut maliyetine benziyor

Bu konuda bulut maliyetlerinden çıkarabileceğimiz dersler var. Buluta geçişin ilk yıllarında da benzer bir heyecan vardı. Sunucu almak yok, kapasite beklemek yok, birkaç dakika içinde ortam ayağa kalkıyor. Bu hâlâ büyük bir avantaj. Ama zamanla ekipler şunu öğrendi: ölçülmeyen kaynak tüketimi büyür. Etiketlenmeyen kaynak unutulur. Sahibi belli olmayan ortam kapanmaz. Küçük görünen maliyetler ay sonunda büyük bir faturaya dönüşür.

AI coding araçlarında da benzer bir FinOps yaklaşımına ihtiyaç olacak. Belki buna “AI Engineering Ops” ya da “AI Usage Governance” diyebiliriz. İsmi çok önemli değil. Önemli olan şu: AI kullanımı artık bireysel geliştirici alışkanlığı olmaktan çıkıp ekip ve organizasyon ölçeğinde yönetilmesi gereken bir kaynak tüketimine dönüşüyor.

Nasıl ki production ortamında sınırsız CPU, sınırsız log retention, sınırsız storage verip sonra “neden maliyet arttı?” diye şaşırmıyorsak, AI araçlarında da sınırsız agent oturumu, sınırsız premium model kullanımı, sınırsız context gönderimi verip maliyet ve risk oluşmamasını bekleyemeyiz.

Benim pratik önerim: küçük ama bilinçli başlayın

Bu yazıdan “AI coding araçlarını kullanmayalım” sonucu çıkmasın. Tam tersine, ben bu araçların doğru kullanıldığında çok değerli olduğunu düşünüyorum. Ama rastgele kullanım yerine bilinçli kullanım daha doğru.

Ben olsam bir ekipte şu sırayla ilerlerdim:

• Önce düşük riskli kullanım alanlarını belirlerdim: test taslağı, dokümantasyon, basit refactor, örnek veri üretimi, kod okuma ve açıklama gibi.
• Sonra AI kullanımını birkaç metrikle izlerdim: PR başına review süresi, test hata yakalama oranı, tekrar açılan bug sayısı, model maliyeti, geliştirici memnuniyeti.
• Daha sonra agent kullanımına geçerdim ama repository yetkilerini, komut çalıştırma sınırlarını ve merge kurallarını netleştirirdim.
• En son aşamada ise ekip standardı oluştururdum: prompt şablonları, güvenlik kuralları, veri paylaşım sınırları, review checklist’i ve maliyet alarmı.

Bu yaklaşım biraz daha yavaş görünebilir ama uzun vadede daha sağlıklı. Çünkü AI aracı bir süre sonra ekip kültürünün parçası oluyor. İlk alışkanlıklar yanlış kurulursa düzeltmek zorlaşıyor.

Sonuç: AI artık sadece hız meselesi değil

Copilot’un kullanım bazlı ücretlendirme hamlesi bana göre sektörün geldiği noktayı iyi özetliyor. AI coding araçları artık deneysel yardımcılar değil; maliyeti olan, davranışı izlenmesi gereken, güvenlik ve kalite etkisi olan mühendislik bileşenleri.

Bu yüzden önümüzdeki dönemde iyi ekipleri ayıracak şey sadece “AI kullanıyor musunuz?” sorusunun cevabı olmayacak. Asıl fark şurada oluşacak: AI’ı hangi işlere bağlıyorsunuz, çıktısını nasıl denetliyorsunuz, maliyetini nasıl yönetiyorsunuz, güvenlik sınırlarını nasıl çiziyorsunuz ve insan mühendisliğini bu sürecin neresine koyuyorsunuz?

Benim görüşüm net: AI yazılım geliştirmede kalıcı. Ama iyi mühendislik hâlâ merkezde. Hatta belki de hiç olmadığı kadar merkezde. Çünkü araçlar güçlendikçe, onları doğru yere bağlama sorumluluğu daha da büyüyor.

Bedava yemek bitti demek biraz sert gelebilir. Ama mühendislik açısından güzel bir tarafı da var: Artık verimlilik iddialarını daha ciddi, daha ölçülebilir ve daha dürüst konuşmak zorundayız.

Okuma notları

• GitHub Docs: Copilot usage-based billing ve GitHub AI Credits
• GitHub Blog: Copilot planlarında kullanım bazlı modele geçiş
• Microsoft Agent Framework: Build 2026 ve agent sistemleri
• GitHub Blog: Copilot coding agent güncellemeleri