Yapay Zekâ ile Geliştiricilerin %20 Daha Hızlı Hissetmesi: Aslında %19 Yavaşlamışlar.

Saat 02.00 ve bu kodun ne yaptığını kimse bilmiyor

Saat 02.00 ve ödeme sistemi çökmüş durumda.

Nöbetçi mühendis, çöken hizmeti ekrana getirip okumaya başlar. Suçlu, üç hafta önce bir “baş parmak yukarı” emojisiyle onaylanan 400 satırlık bir fonksiyon. Takımdan bunu kimse yazmamış. Bunu bir ajan yaklaşık dokuz saniyede yapmış ve o anda herkes bunu oldukça havalı bulmuştu.

Şimdi çok daha az havalı.

Bu sahneye sürekli dönüp duruyorum, tek bir çalışma yüzünden. 2025 yılında METR, deneyimli açık kaynak geliştiricilerle düzgün bir rastgele deney yürüttü. AI araçlarıyla gerçek görevleri tamamlamaya 19% daha uzun sürdü. Ardından, AI’ın kendilerini yaklaşık 20% daha hızlı yaptığını tahmin ettiler.

(Adil olmak gerekirse, bu 2025’in başlarındaki araçlardı ve METR o sayının günümüz için okunmaması gerektiğini belirtti. Araçlar artık daha iyi. Ama nasıl hissettirdiğiyle gerçekten ne kadar hızlı olduğu arasındaki bu boşluğun? Bence bu yerinde duruyor.)

Kayıt için, ben AI karşışı değilim. Her gün kullanıyorum ve hiç olmadığım kadar fazla şey üretiyorum. Buradaki amacım maliyetler dürüstçe anlatmak, çünkü kimse bunları LinkedIn‘de paylaşmıyor. Sayıları (yanlış olan birkaç viral içeride), genç geliştiricilere ne olduğunu, kütüphanelerin neden bozuk olandan daha fazla endişe verdiğini ve hangi iki kurala karar verdiğimi anlatacağım.

Önce, sayılar

Bir akşam, sürekli paylaşılan istatistikleri kontrol ettim. Çoğu ayakta kalıyor.

CodeRabbit, geçen Aralık ayında 470 gerçek çekme isteğini inceledi ve AI ortaklığında yazılan kodun %75 daha fazla mantık hatası ve 2.74 kata kadar güvenlik sorunu içerdiğini buldu. Harness, 500 mühendis liderini anketledi ve %67’si artık AI kodunu hata ayıklamaya daha fazla zaman harcadıklarını söyledi. Ve Stanford’ın maaş verileri, 22 ile 25 yaşları arasındaki geliştiricilerin, son 2022 zirvesinden neredeyse %20 daha aşağıda olduğunu gösteriyor; bu da gerçekten beni uykusuz bırakan.

Ama paylaşmayı bırakacağım birkaç tanesi var. “Geliştiricilerin %63’ü AI kodunu hata ayıklamaya daha fazla zaman harcıyor” sayısı her yerde dolaşıyor ve ben bunu herhangi bir gerçek çalışmaya izleyemedim. Ve eğer hâlâ “Stack Overflow %25 düştü”nü alıntılayorsanız, bu eski. Temmuz 2026’da siteye yaklaşık 1.400 yeni soru geldi. En iyi ayı, 2014’te 200.000’i aştı.

İlginçtir ki, bu ay yayımlanan Stack Overflow’un kendi 2026 Geliştirici Anketi durumu iyi özetliyor. Geliştiricilerin çoğu artık iş yerinde yapay zekâyı kullanıyor, neredeyse yarısı çıktısına yalnızca kolayca doğrulayabildiğinde güveniyor ve yalnızca %6,6’sı önemli bir kararda ona güvenirdi.

Sayınca elinize geçen daha önce hiç olmadığı kadar kod, ama onun daha az anlaşılması ve zaman zaman “tasarruf ettiğimiz” şeyin sessizce temizliğe dönüştüğü görülüyor.

Araç alışverişini bırakın, daha iyi brief’ler yazmaya başlayın

Bu yıl, önceki beş yılda IDE’leri değiştirdiğimden daha fazla yapay zekâ aracını değiştirdim. Sanırım siz de öylesiniz. Her birkaç haftada bir daha iyisi piyasaya çıkıyor, bu yüzden herhangi birine sadık kalmak biraz anlamsız geliyor.

Sonuçlarımı gerçekten değiştiren sıkıcı bir şeydi: ajanlara daha küçük işler vermeye başladım.

Modeller 2025’in sonlarına doğru belirgin biçimde iyileşti. Ama benim için daha büyük sıçrama, tek bir ajandan her şeyi yapmasını istememden geldi. İşimi artık parçalara bölüyorum: Önce plan, sonra mimari, sonra inşaat, sonra hata ayıklama; her biri kendi adımı olarak.

Seneler içinde aldığınız biletleri düşünün. “Giriş uç noktasına dakikada beş deneme olacak şekilde hız sınırlaması ekle, 429 döndür” bitirebileceğiniz bir bilettir. “Uygulamayı daha güvenli hale getir” ise bir haftayı kaybetme biçimidir. Ajanlar farklı değildir, ancak ne demek istediğinizi sormaya geri gelmezler. Sadece tahmin ederler.

Bu yüzden planı yazarım, gerçekten okurum (insanların atladığı adım bu) ve ancak o zaman bir ajan koda yaklaşır.

Kabullenmem biraz zaman alan bir şey daha: bu araçlar deterministik değil. Tam olarak aynı soruyu on dakika sonra yapıştırsanız bile farklı bir cevap alabilirsiniz. Araçlarınızla güncel kalmak eskiden iyi olurdu ama zorunluluk değildir. Şimdi işin bir parçası. Geçen ay işe yarayan şey bu ay işe yarayabilir ya da yarayabilir; bunu bilmenin tek yolu, tıpkı yeni bir ekip arkadaşının nasıl düşündüğünü öğrenir gibi, ajanlarınızın nasıl davrandığını öğrenmeye devam etmek.

Yapay zekâ temelinizin yanlış olduğunu size söylemez

Bunu şimdi birkaç kez, biraz farklı biçimlerde yaşandığını gördüm.

Birinin küçük bir web uygulaması fikri oluyor ve bunu yapması için bir yapay zekâya başvuruyor. Bir saat sonra, son derece uygun bir ilişkisel veri tabanı ile çalışan bir taslak ortaya çıkıyor. Kesin tablolar, yabancı anahtarlar, her şey özenle birbirine bağlanmış.

Ardından, fikirler böyle değişir: Fikir kayar. Veriler dağınık çıkıyor ve şekilleri sürekli değişiyor; asıl gereken şey, içeri giren her şeyi kabul edebilecek gevşek bir JSON sütunu gibi bir şey oluyor.

Yapay zekâ bunu fark etmiyor. “Bak, bu şema artık uymuyor” demek için hiçbir zaman durup düşünmüyor. Sadece orijinal tasarımın etrafına yeni özellikleri sıkıştırarak inşa etmeye devam ediyor. Her değişiklik biraz daha yavaş ve biraz daha kırılgan hale geliyor; en son sürümü çekmek, başkasının kulesiyle oynanan bir Jenga oyununa benziyor.

Sorunu çzen şey daha zeki bir istem (prompt) değildi. Birinin veri tabanını çöpe atıp iki sıradan tablo ile yeniden başlama kararı vermesi gerekiyordu: biri zaman içinde her değişikliği kaydeden, diğeri ise güncel durumu tutan. Yapay zekâya bunun yeni şekil olduğu söylendiğinde, kod neredeyse anında sadeleşti.

İşte “vibe coding”a (ruh haliyle kodlama) dair asıl şikayetim bu. Bu araçlar, önlerindeki neyse onun üzerine inşa etmede başarılı. Önlerindeki şeyin yanlış olduğunu söylemekte ise çok kötü. Bu sorumluluğu üstlenecek birinin yine olması gerekiyor.

Eski kod tabanlarında iş daha da zorlaşıyor. Yeşil saha (greenfield) kolay: Ne istediğini tarif ediyorsun ve hızla tamamını alıyorsun. Son %10’luk kısım, sistemin yaşlandığı yer; gerçek her kod tabanı, yıllar içinde biriken kabuklar, yarıda kalmış yeniden düzenlemeler ve kimse yapıldığını hatırlamadığı kararlar taşıyor. Ajanlar (agents) yine de bir şeye başlamadan önce bu geçmişi doğru doğru anlamakta zorlanıyor. Biz bunu eskiden dokümantasyon, tasarım incelemeleri ve kod bir sonraki aşamaya geçmeden önceki kontrollerle hallediyorduk. Bu alışkanlıklar hâlâ önemini koruyor; muhtemelen insanlardan daha fazlasıyla ajanlar için.

Yapay zekâ iyi ekipleri iyileştiriyor, dağınık ekipleri de daha da dağınık yapıyor

Google’ın 2025 DORA rapori, teknoloji sektöründe neredeyse 5.000 kişiyle anket yapmış; beni etkileyen alıntı, yapay zekânın bir güçlendirici (amplifier) gibi çalıştığı yönündeydi. Bir ekibi düzeltmiyor. Ekibin zaten ne olduğunu ses seviyesini artırıyor.

Sistemleriniz gevşek bağlıysa ve geri bildirim döngüleriniz hızlıysa, gerçek kazanımlar görürsünüz. Her şey birbirine dolanmış ve sürümler haftalar sürüyorsa, çok az şey elde edersiniz. DORA ayrıca, AI kullanımının artık daha hızlı teslimatla eşleştiğini ve aynı zamanda üretimdeki istikrarsızlığın artmasıyla birlikte geldiğini tespit etti.

GitClear’ın verileri aynı yöne işaret ediyor. 2020 ile 2024 arasında 211 milyon değiştirilen kod satırını analiz ettiler ve 2024, kopyala-yapıştır satırlarının taşınan satırları geçtiği ilk yıl oldu. Taşınan satırlar temelde yeniden düzenlemeye (refactoring) dair bir gösterge. Yani, daha fazla kopyalama ve daha az temizlik.

Bunu muhtemelen kendi depo (repo) ortamınızda da görmüşsünüzdür. AI, zaten var olan üç validateEmail’den birini kullanmak yerine dördüncü bir validateEmail yazıyor. Hepsi çalışıyor, işte tam da bu yüzden kimse onları silmiyor; bir gün kuralı değiştirmeniz gerektiğinde dördünü birden bulmak zorunda kalana kadar.

Ekiniz zaten sarsık mimariye, seyrek testlere ve aceleye getirilmiş incelemelere sahipse, AI sizi kurtarmaz. Sadece aynı hataları daha hızlı yaparsınız.

Prototipi kurun. Ama onu yayınlamayın.

Pazarlama ürün yöneticilerinin (PM) ve alan uzmanlarının artık bir fikrin kendi ham prototiplerini kendileri kurabilmelerinden gerçekten memnunum. Bir özellik tanımlaması yazıp mühendislerin onu tam niyet ettikleri şekilde okuyacağını ummak yerine, fareyle gezinebilir, zorlayıcı kısımları kendileri deneyebilirler ve ne istediklerini bilerek gelebilirler. Bu baş başına haftaları kurtarır.

Risk, bizim eski bir alışkanlığımızdır: ilk prototip yavaşça üretim sisteminin yerine geçer. AI bunu çok daha cazip hale getirir, çünkü artık prototip bir öğleden sonra ortaya çıkar ve bitmiş gibi görünür.

Ama aslında bitmemiştir. Ona bir taslak gibi davranın, sonra düzgün bir şekilde yeniden düzenleyin ya da öğrendiklerinizle sıfırdan yeniden kurun.

İşte önerdiğim bir iş akışı. Dağınık prototipi, hikâyenin nasıl oturduğunu keşfettiğiniz yol olarak görün, yayınladığınız şey olarak değil. Ne inşa ettiğinizi öğrendikten sonra, bunu düzgün bir özellik tanımlamasına dönüştürmek için AI’dan yararlanın. Sonra prototipi çöpe atın ve yalnızca tanılama üzerinden yeniden kurun. Yüzlerce iterasyondan kalan kod artıklarını, çıkılmaz sokakları ve ölü dosyaları kaybedersiniz, ancak öğrendiklerinizi korursunuz.

Ayrıca son “yayına alma” aşamasının açıkça tek bir deneyimli kişinin sorumluluğunda olması gerektiğini düşünüyorum. Sıkıcı soruları soran kişi. Bu kırılırsa, onunla birlikte başka ne kırılır? Giriş yapma, ödeme veya müşteri verilerini etkiliyor mu? Günümüzde bu kişi genellikle AI çıktısı ile üretim arasındaki tek gerçek denetleyici, bu yüzden bunun kimseyin gerçek bir işi olması, “vakit kalırsa yapılan bir şey” değil.

Bu rol, ekipler birden fazla ajanı yan yana çalıştırmaya başladığında—biri planlayan, biri inşa eden, biri hata ayıklayan—daha da önem kazanır. İş unvanları bulanıklaşır ve mühendis, tüm süreci yönlendiren ve sondaki kararı kendisi veren kişi haline gelir.

Ekipler aynı zamanda küçülecek. Bir zamanlar on kişilik bir ekip gerektiren iş, iki veya üç kişiye indirgenecek: fikri şekillendiren, ajanları yönlendiren ve üretimi üstlenen biri.

Ve başarısızlığın gerçekten kabul edilemediği her durumda, güvenlik açısından kritik mühendislikten, yani yazılım uçaklarında her değişikliğin kimin ya da ne yazdğından bağımsız olarak katı, denetlenen bir süreçten geçmesi dünyasından faydalanırım. Asıl amaç daha fazla test etmek değil. AI’ın yazdığının gerçekten kastedileni yapıp yapmadığını kontrol etmek.

Junior geliştiricilerin işlerini kaybetmediler. Eğitim alanlarını kaybettiler.

Bu, yazması en zor olduğum kısım, çünkü ben de bir zamanlar juniordum ve küçük, sıkıcı biletlerden ne kadar öğrendiğimi hatırlıyorum.

62 milyon ABD işçisine yapılan Harvard çalışması, AI benimseyen firmalarda junior personel sayısının altı çeyrek içinde yaklaşık %9 düştüğünü, üst düzey personel sayısının ise neredeyse değişmediğini ortaya koydu. ABD hükümeti verileri de ilginç. Temelde başkasının belirlediği özelliklere kod yazmak anlamına gelen “bilgisayar programcısı” olarak sınıflandırılan işler, 1980’den beri en düşük seviyesine, %27,5 düşdü. “Yazılım geliştirici” işleri ise neyin nasıl yapılacağına karar veren kişilerdi ve neredeyse değişmedi.

Yani şirketlerin yeni mühendisler istemeyi bıraktığını düşünmüyorum. Onlara verme alışkanlıkları işi kaybettiler. Küçük hataları düzeltmek ve basit ekranlar oluşturmak juniorların öğrendiği yordu ve bu şimdi bir ajanın saniyeler içinde bitirdiği tam da iş.

Eğer bugün yeni başlıyor olsaydım, enerjimi sistemleri anlamaya yatırırdım. Parçaların birbiriyle nasıl örtüştüğünü, ilk hafta alınan bir kararın altıncı ayda neden baş ağrısına dönüştüğünü. Söz dizimi artık ucuz; bir saat içinde bir yapay zekâdan taslak bir iOS uygulaması ya da bir logo alabilirsiniz. Bu uygulamanın var olması gerekip gerekmediğini ve neyi kıracağını bilmek, değerin şu anda bulunduğu yer.

Aynı zamanda bilgisayar bilimi derslerinin temellere dönmesi, bir dili beş kez öğretmek yerine daha iyi olurdu. Pilotlar aerodinamiği öğrenir, basılacak butonları değil; işte tam da bu yüzden kılavuzda yer almayan bir durumla karşılaştıklarında toparlayabilirler.

Bunun LinkedIn’de nasıl ortaya çıktığını zaten görebiliyorsunuz. Yapay zekâ ile gerçek ilerleme kaydeden gönderilerde bulunanlar, genellikle sağlam bilgisayar bilimi temellerine sahip olanlar; sorundan ve elde edilmek istenen sonuçtan başlar, oraya ulaşmak için farklı yaklaşımları denemekten çekinmezler. Tüm kimlikleri bir dil ya da bir çerçeveye dayananlar ise çoğu zaman yedek kulüvesinde kalmış gibi konuşur.

Zaten bir işe yerleşmiş genç geliştiriciler için iyi bir orta yol, kum havuzunda prototipleme. Onlara üretim ortamından uzakta yapay zekâ ile keşfetmeleri için gerçek problemler verin ve öğrendiklerini gözden geçirin. Bu, coşkularını faydalı bir yere yönlendirir ve onlara bir ajanı nasıl doğru şekilde yönlendirecklerini öğretir; ki bu da hızla temel beceri haline geliyor.

Umut verici bazı işaretler var. IBM, 2026’da ABD’deki giriş seviyesi işe alımını üç katına çıkaracağını, yazılım geliştiriciler de dahil olmak üzere, genç pozitonları müşteri çalışmaları ve yapay zekâ çıktısının doğrulanması gibi konular etrafında yeniden düzenledikten sonra açıkladı. Her şirket bunu yapmayacak, ancak genç pozisyonun silinmek yerine yeniden düzenlenebileceğini gösteriyor.

Bazı yapay zekâ değişiklikleri diğerlerinden daha fazla şüpheyle karşılanmayı hak eder

Bir ajan bana bir değişiklik teslim ettiğinde, okumaya başlamadan önce bunun hangi türde bir değişiklik olduğunu anlamak işi kolaylaştırır. Yaklaşık olarak altısı var:

• Yeni kod: yeni dosyalar veya fonksiyonlar, mevcut olanlardan hiçbiri dokunulmadan. Genelde sorun olmaz.

• Mevcut mantığa düzenlemeler.

• Kod, yapılandırma veya veri kaldırmları.

• Çok sayıda dosyaya yayılan büyük yeniden yazımlar.

• Adlandırma değiştirme ve biçimlendirme gibi temizlik işleri. Tek başlarına zararsızdır, ancak dikkate değer değişikliği gizlemede ustadırlar.

• Sessiz davranış değişiklikleri, korkutucu olanlar bunlar. Bir API biraz farklı bir şey döndirmeye başlar, ön yüz kırılır ve derleme aşamasında hiçbir şey hata vermez.

Bir aracın dokunmasına izin verilen şeyi sınırlandırmazsanız, tek bir görev bu altı alanın tamamına dolaşabilir. Sonuncusu ise genellikle bir testten değil, bir müşteriden şikayet olarak yüzünüze vurur.

İşte o 2.000 satırlık PR’lar hakkında

Araçlar yeniden yazımları sever. Küçük bir düzeltme istersiniz ve 15 dosyaya yayılan 2.000 satır geri döner. Standup toplantısında etkileyici görünür ve dürüst olmak gerekirse, araçların buna yön verdiğini düşünüyorum.

Mesele şu ki, bir model doğru görünen bir şeye göre optimize edilir. İyi bir mühendis ise çalışan en küçük değişikliğe göre optimize edilir. Bunlar aynı hedef değil.

Büyük AI değişiklikinin daha sık geri alındığını varsayarak girişimde bulundum. Karşılaştığım veri çoğunlukla hayır diyor. Greptile yüz binlerce PR’a baktı: bazı araçlar insanlardan daha az, bazıları ise daha sık geri alındı, ancak büyük araç PR’ları büyük insan PR’larından daha sık geri alınmıyordu. Google’ın 3,52 milyon kod değişikliğine yönelik çalışması, AI değişikliklerinin de biraz daha az sık geri alındığını buldu. Maliyetin ortaya çıktığı yer inceleme. O Google çalışması, AI değişikliklerinin engelleyici inceleme yorumlarını 1,92 kat daha fazla topladığını buldu. Faros’un 22.000 mühendisi kapsayan 2026 raporu ise ortanca inceleme süresinin yüzde 400’den fazla, hiç incelemeden birleştirilen PR oranının ise yüzde 31 daha fazla olduğunu buldu.

Benim endişem devasa AI PR’larının gürültülü şekilde başarısız olması değil. Başarısız olmamaları. Onaylanıyor ya da incelemeden tamamen geçiliyor, çünkü biri bir Perşembe öğleden sonra 4’te bu boyutta bir farkı düzgün biçimde inceleyemez ve herkes fısıldaşarak testlerin bunu yakaladığını umar.

Aslında uyuduğum iki kural

Bir ajanı biraz da dördüncü espresosunu almış, çok yetenekli yeni bir çalışan gibi düşünüyorum. Hızlı, hevesli, zaman zaman gereksiz cesur ve kesinlikle üretim ortamında baş başına bırakamayacağın biri.

İlk kural, farkların yaklaşık 50 satıra sabitlenmesi. Bir şey çok daha büyük şekilde geri geliyorsa, onu gözden geçirmeye çalışmıyorum. Uğraşıp çözmekten neredeyse her zaman daha hızlı bir şekilde çöpe atıyor, brief’i sıkılaştırıp tekrar çalıştırıyorum. 50 satır, okuyup gerçekten arkasında durabileceğim bir miktar. Ondan çok daha fazlası ise yalnızca “onayla”ya tıklayabileceğim bir şey.

Ekinizin uydurduğu bir sayı seçin, sonra bunu CI’da katı bir kontrol haline getirin. Bir PR sınırı aşarsa, daha net bir spec talebiyle geri döner. Devasa bir fark genellikle işin büyük olduğundan değil, brief’in muğlak olduğundan işaretidir.

İkincisi, gizli verilerin dışarıda tutulması. Ortam değişkenleri, API anahtarları, jetonlar, parolalar: Bunların hiçbirinin bir ajana yaklaşması, ben izlemedikçe söz konusu değil. Bir anahtarı bir kez isteme kutusuna yapıştırırsanız, oturumun sonunda onu bir düzine dosyada kodlanmış olarak bulabilirsiniz. Bu yüzden gizli veriler, herhangi bir AI çalışması başlamadan önce bir kasaya veya bir ortam değişkeni referansının arkasına konmalı. CodeRabbit’ın kendi önerileri de büyük ölçüde aynı şeyi söylüyor: kimlik doğrulama işlemlerini tek bir yerde tutun, kodlanmış paroları engelleyin ve her PR’da güvenlik taramaları çalıştırın.

Bana bir kezden fazla kurtaran birkaç küçük alışkanlık:

• Ajanın özelliği yazmadan önce testler yazmasını sağlayın

• Linter’ınızda kopya kodu denetimlerini açın, böylece dördüncü validateEmail çağrısı işaretlensin

• Sadece farkı değil, planı okuyun, çünkü kötü kod çoğu zaman kötü bir plan olarak başlar

Bunların hesabını biri ödeyecek

Ucuz kod daha sonra pahalı çıkmaya meyillidir. Onların çoğunu hızlı moda yazılım gibi düşünüyorum. Şekildeyken harika görünüyor, birkaç ay sonra parçalanmaya başlıyor.

Ve etkiler kendi depolarımızın çok ötesine yayılıyor. Tailwind, hiç olmadığı kadar popüler olsa da, kurucusu Ocak ayında GitHub üzerinden dokümantasyon trafiğinin 2023’ün başlarından beri yaklaşık yüzde 40 düştüğünü, daha sonra da gelirlerin yaklaşık yüzde 80 azaldığını belirtti. İnsanlar dokümantasyonu açmak yerine bir yapay zekâdan soru soruyor, bu yüzden projeyi finanse eden ücretli ürünlere hiç rastlamıyor. Dört mühendisten üçü işten çıkarıldı. Kodlamayı öğrendiğimiz bir sürü insanın bulunduğu Stack Overflow, eskiden sorulan soruların çok küçük bir kısmını alıyor. Yapay zekânın öğrendiği yerler yapay zekâ nedeniyle kuruyor ve bir sonraki modellerin ne öğreneceğine dair henüz iyi bir cevabın olmadığını düşünüyorum.

Fiziksel bir fatura da var. IEA, veri merkezlerinin 2030’a kadar yaklaşık 945 TWh elektrik kullanmasını bekliyor; bu, bugünkünden iki katından fazla ve bir yılda Japonya’nın kullandığından biraz fazla, en büyük itici güç de yapay zekâ. Üstelik soğutma için gereken tüm su da buna ekleniyor.

Ve ödediğimiz fiyatlar asıl fiyatlar hiç değildi. Risk sermayesi, yaktığımız her token’in büyük bir kısmını karşılıyordu ve bu artık geri çekiliyor. GitHub Copilot, Haziran ayında istekleri saymayı bıraktı ve token başına fatura uygulamaya başladı; Gartner ise yapay zekâ kodlama maliyetlerinin 2028’e kadar ortalama bir geliştiricinin maaşını geçeceğini tahmin ediyor.

Düzeltme ne kadar büyük olabilir? Kimse bilmiyor, ancak duygunun ne kadar hızlı dönebileceğini gördük. 2025’in Ocak ayında DeepSeek ucuz ve yetkin bir model yayımladığında, Nvidia tek günde yaklaşık 593 milyar dolarlık bir piyasa değeri kaybetti; bu, Wall Street’teki herhangi bir şirket için bir rekor. Bu arada harcamalar yükselmeye devam ediyor. Zylo’nun 2026 endeksi, kurumsal harcamaların yerel yapay zekâ uygulamalarına bir yıl içinde iki katından fazla arttığını buldu ve Eylül güncellemesi bu sıçramayı yüzde 334 olarak belirledi. Dot-com balonu 2000’de patladığında, teknoloji sektörü bugünkünün çok küçük bir parçasıydı. Bugün yaşanacak bir şok, çok daha büyük ve yapay zekâya çok daha fazla bağımlı bir şeye vurur.

Bu DeepSeek anının umut verici yanı, verimliliğin hızlı bir şekilde iyileşebileceği. Azıyla daha fazlasını yapan modeller, maliyet tarafındaki en iyi haber ve onlara şiddetle ihtiyacımız var, çünkü insanların vaat ettiği her şeyi çalıştırmak için gereken enerji ve donanım henüz mevcut değil.

AI’nın ortadan kaybolacağını düşünmüyorum. ABD ve Çin buna çok fazla harcama yapıyor; tahminim, temel AI hesaplamalarının bir süre sonra yollar ya da elektrik şebekesi gibi bir muamele görmeye başlanması.

Ancak sınırsız tüketim dönemi kapanıyor; belirsiz istemlerle ve devasa yeniden yazımlarla token yakarak iş yapan ekipler bunu ilk fark edecek.

Ya biz nerede kalıyoruz?

2027 için bir öngörü: Öncelikle insanlar için değil, AI ajanları için tasarlanmış programlama dillerini görmeye başlayacağız. Zaten küçük ölçekte başladı. Mayıs ayında Vercel Labs, ajanlarla kodlama için inşa edilmiş, derleyicisi ajanlarla yapılandırılmış, makinenin okuyabildiği komutlar aracılığıyla iletişim kuran deneysel bir dil olan Zero’yu açık kaynak olarak yayımladı. Hâlâ erken günler ve insanlar tarafından tasarlandı, ancak nereye gittiğini görmek mümkün.

Ve dürüst olmak gerekirse, yukarıdakilerin hepsine rağmen yıllardır olmadığı kadar eğlenceli kod yazıyorum. Bir cumartesi sabahı bir fikri başlatabiliyor, akşama kadar çalışan bir prototipi yayına alabiliyorum. Bir süre önce bunu küçük bir ekip ve çeyreğin çoğu alırdı.

Yani AI geliştiricilere yardım mı ediyor yoksa zarar mı veriyor? İkisi de; hangisini elde edeceğiniz çoğunlukla alışkanlıklara bağlı. Sistemler üzerinde düşünen, değişiklikleri küçük tutan ve son kararı insana bırakanlar çok iyi durumda. İlk taslakları yayımlayan ve okunmayan kod farklarını onaylayan ekipler ise henüz görmedikleri bir faturayı biriktiriyor.

Bu da beni o gece 2’deki uyarıya götürüyor. Çözüm “daha az AI kullan” değildi. Gece 2’de bir şey bozulduğunda, en azından ekipteki bir kişinin sistemin nasıl çalıştığını bilmesini sağlamak.

Sizce bir AI tarafından üretilen, inceleme yapmanız istenen en büyük PR ne? Orada durumun ne kadar kötü olduğuna meraklıyım.

Umarım bundan keyif almışsınızdır ve yeni bir şey öğrenmişsinizdir. LinkedIn’de her zaman öneri ve tartışmalara açığım. Doğrudan mesajlarla bana ulaşın.

Siradaki yazıda görüşmek üzere, keşifleriniz keyifli olsun!