Yapay zeka, çalışan bir ürünü sizin yerinize yapmaz; bu hâlâ sizin işiniz

• Yapay zeka, birkaç dakika içinde UI ve veritabanına sahip bir prototip oluşturabilir, ancak ilk çalışan sürümden prodüksiyon seviyesinde bir ürüne giden mesafeyi kısaltmaz
• Gerçek bir üründe ölçeklenebilirlik, hata işleme, gözlemlenebilirlik, güvenlik, kimlik doğrulama ve veri yapısı gibi, söz dizimi yazmaktan çok mühendislik muhakemesi gerektiren sorunlar kalır
• Bilgisayar biliminin değeri kod üretmekten çok, sistemlerin nasıl çalıştığını ve neden başarısız olduğunu anlamayı sağlayan zihinsel modellerde yatar; bunlar olmadan verimsiz sorguları veya yarış durumlarını fark etmek zordur
• Gereksinimleri mekanik biçimde koda dönüştürme talebi azalacak olsa da, yetkin mühendisler tekrar eden işleri yapay zekaya bırakıp uzmanlık gerektiren sorunlara odaklanarak çok daha hızlı çalışabilir
• Yapay zekayı anlayışın yerine koyarsanız, bozulan sistemleri düzeltmek, genişletmek veya devretmek zorlaşır; bu yüzden önce temel bilgileri öğrenip ardından yapay zeka araçlarını kullanmak gerekir

---

Prototip ile ürün arasındaki boşluk

• Bir fikri doğal dille anlattığınızda, birkaç dakika içinde UI ve veritabanı içeren, amaçlanan işlevi yerine getiren çalışan bir prototip elde edebilirsiniz
• Ancak dizüstü bilgisayarda çalışan bir prototip, gerçek ortamda çeşitli sorunlar gösterebilir
  • Yükü kaldıramaz ve hata işleme yeteneklerinden yoksundur
  • API token’ları sızabilir
  • Demo için kurulmuş veri modeli, ikinci kullanıcı eklendiği anda çökebilir
  • Kimlik doğrulama, doğrulanmamış varsayımlara dayanır ve güvenli olup olmadığı belirsizdir
• Dağıtım aşamasına gelindiğinde, “çalışıyor” ile “hazır” arasındaki büyük prodüksiyon boşluğu ortaya çıkar

Zor kısım, kod yazdıktan sonraydı

• Yazılım mühendisleri daha önce de bir şeyi hızla ayağa kaldırabiliyordu; asıl zaman alan kısım bunun sonrasındaydı
  • Ölçek büyüse bile ayakta kalacak sistemler tasarlamak
  • Kullanıcılar beklenmedik yollardan girdiğinde oluşan istisnaları ele almak
  • Arızaları fark etmeyi sağlayacak gözlemlenebilirlik kurmak
  • Üç yıl sonra daha az pişmanlık yaratacak veri mimarisi kararları almak
• Yapay zeka, ilk çalışan sürüme ulaşma süresini büyük ölçüde kısalttı, ancak o sürümden prodüksiyon seviyesinde bir sisteme giden mesafeyi azaltmadı
• Hızlı istek-yanıt-sonuç döngüsü, geliştirme sürecinin geri kalanının da sıkıştığı izlenimini veriyor; oysa yazılımın zor problemleri en başından beri söz dizimi yazmak değildi
• Ne inşa edileceğine, nasıl yapılandırılacağına, neyin erteleneceğine ve ne zaman hayır deneceğine karar veren muhakeme, prototiple prodüksiyon sistemini birbirinden ayırır

Bilgisayar bilimi neden hâlâ gerekli

• Yapay zeka tarafından üretilen koda erişimin kolaylaşmasıyla, yeni girenler arasında algoritmalar, veri yapıları, işletim sistemleri ve teoriyi yıllarca öğrenmenin gerekip gerekmediğini sorgulayanların sayısı artıyor
• Bilgisayar bilimi eğitiminin değeri yalnızca kod yazma becerisinde değildir; sistemlerin nasıl çalıştığını, nasıl bozulduğunu ve neden o sonuçların ortaya çıktığını anlamayı sağlayan zihinsel modeller oluşturur
• Bu temel olmadan, yapay zekanın ürettiği kodun potansiyel arızalarını tespit etmek zordur
  • 50 milyon satırlık bir tabloda tam tablo taraması yapan bir sorgu
  • Eşzamanlı yük altında yarış durumu yaratan bir cache stratejisi
  • Mevcut gereksinimi çözerken bir sonraki problemi çok daha zor hâle getiren bir mimari
• Temel bilgi yoksa, modelin muhakemesine bütünüyle bağımlı hâle gelirsiniz
  • Model, muhakeme değil örüntü eşleme temelinde, amaca uygun olduğunu varsaydığı kodu hevesle üretir
  • Üretilen kod doğru ve yaygın pratiklere uygun görünebilir, ama prodüksiyonda başarısız olabilir
  • Sorunu fark edecek bilginiz yoksa, teşhis günler sürebilir
• Anlayış ile çıktı arasındaki mesafenin kısaldığı bugün, bilgisayar bilimi öğrenmek için iyi bir zamandır; dağıtık sistemleri gerçekten anlayan bir öğrenci, bunları 10 yıl öncesine göre çok daha kısa sürede kurabilir

Otomatikleşen işler ve büyüyen üretkenlik

• Gereksinimleri satır satır uygulamaya dönüştüren mekanik kodlama işlerine olan talep gerçekten azalıyor ve bu alan otomatikleşiyor
• Üretkenlik dağılımının alt kısmı sıkışırken, üst sınırı genişliyor
  • Modern yapay zeka araçlarını kullanan yetkin bir mühendis, 5 yıl önce hayal etmesi zor bir hızda çalışabilir
  • Bunun nedeni zor problemlerin ortadan kalkması değil, zaman ve dikkat tüketen mekanik işlerin büyük ölçüde halledilmesidir
  • Böylece kazanılan zaman, gerçekten uzmanlık gerektiren işlere ayrılabilir
• Geride kalacak mühendis, yapay zekayı nasıl kullanacağını bilmeyen kişi değil, yapay zekayı anlayışın yerine kullanan kişidir
  • Muhakeme edemediği sistemleri vibe coding ile kurar
  • Arızaları düzeltemez ya da büyümüş bir sistemi genişletemez
  • Bakımı devralacak kişiye kendi yaptığını açıklayamaz

Daha yüksek bir soyutlama seviyesinde çalışmak

• Gereken değişim yalnızca yeni araçları benimsemek değil, temellere bağlı kalarak daha yüksek bir soyutlama seviyesinde çalışmaktır
• Yapay zekayı derin bilginin yerine geçen bir araç değil, bir güç çarpanı olarak kullanan mühendisler akranlarının önüne daha hızlı geçebilir
  • Modelden ne üretmesini istediklerini anlarlar
  • Üretilen kodu, sanki junior bir mühendisin pull request’ini inceliyormuş gibi eleştirel gözle değerlendirirler
  • Yalnızca özellik açıklamaları vermez, mimari düzeyde konuşurlar
  • Modelin önerilerine ne zaman karşı çıkılması gerektiğine karar verirler
• Bu, mevcut becerilerin yeni bir yetkinlikle değiştirilmesi değil; mevcut becerilerin yeni bir ortamda uygulanarak çok daha yüksek kaldıraç elde edilmesidir
• Prototipten sonra da gerçek mühendislik muhakemesi gerekir; güvenilir yazılımı yayımlayan geliştiriciyle yalnızca demo yayımlayan geliştiriciyi ayıran yetenek budur
• Öğrenme sırası önce temel bilgiler, sonra yapay zeka araçları olmalıdır

[GN⁺]

Hacker News yorumları

• Bir yan projede birkaç ay boyunca LLM ile yazılmış kodu çöpe atmayı düşünüyorum. Tasarım spesifikasyonlarını özenle yazıp mevcut bir kod tabanı üzerinde çalışmış olmama rağmen, tek tek değişiklikler mantıklı görünse de bütün olarak birçok parçanın ince ince hizadan çıktığı karmaşık bir yığın hâline geldi.
  Raporlar ya da makalelerde de her bölüm makul görünürken belgenin tamamı tuhaf hissettiriyor. İnsanlar ayrıntı işlerinde yavaş olsa da LLM’lerin henüz yapamadığı üst düzey akıl yürütmeyi yapıyor gibi. Kusuru söylediğinizde “tamamen haklısın” diyor ama kendi kendine gözden geçirirken bunu bulamıyor.
  Yaygın JS framework’leri, Tailwind ve ORM ile basit CRUD uygulamaları yapmak gayet mümkün olabilir; ama eskiden de SaaS şablonları satın alınabiliyordu ve iyi yapılmış el işi boilerplate’in vibe coding sonucundan daha iyi olma ihtimali yüksek.

  • Tam otonom programlamadan çok LLM destekli programlamayı giderek daha fazla kullanıyorum. Opus gibi modeller iyi tasarımı anlamaktan ziyade hedefe ulaşana kadar değişiklik yapıyor; insanın toparlaması gereken kod ve aşırı araştırma işi bırakma eğiliminde.
    Başkalarının PR’larında da prompt’taki sorunu yüzeyde çözen ama uzun vadeli bakımı zorlaştıran uygulamaları sık görüyorum. Bu yüzden uygulama adımlarını ve tasarımı kendim belirliyor, küçük açık kaynak modellerle ya da Claude 4.5·4.6 ile adım adım çalışıyorum. API keşfi ve boilerplate yazımı hızlandığı için elle yapmaya göre birkaç kat daha hızlı oluyor; üstelik bilgi körelmiyor, kod tabanı da bozulmuyor.
  • Karmaşık ve aşırı tasarlanmış çözümlere saplanıp kaldıktan sonra yürüyüşe çıkınca ya da başka bir işle uğraşınca basit çözümü fark ettiğim çok oldu. LLM her şeyi anında ele alarak düşünme, çıkmazda olduğunu fark etme ve bir sonraki işle çatışmaları değerlendirme zamanını elimizden alıyor.
  • Benim yan projemde de artık kodu tamamen anlamak ve güvenle doğrudan değiştirmek zorlaştı; ama artık buna gerek olmadığını düşünüyorum. Neredeyse 20 yıl boyunca güzel kod yazdım, şimdi üretkenliğe ve çıktıya odaklanmak istiyorum; Codex spagetti kodu anlayabildiği sürece kişisel projeler ya da küçük bağımsız geliştiriciler için sorun değil.
    Yapay zeka, makine dilinin üzerine yüksek seviyeli dillerin gelmesi gibi teknoloji yığınının üzerine eklenen yeni bir katman; bu yüzden bırakmayı bilmek gerekiyor.
  • Asıl değer koddan çok oraya varırken edinilen öğrenmedeydi. Zorlanma sürecinde gerçek gereksinimler ve teknik zorluklar tekrar tekrar keşfedilir; yapay zeka ise bu süreci atlayıp hedefe yüzeysel olarak ulaşılmış gibi gösterir.
    Bu, yapay zekanın işe yaramadığı anlamına gelmiyor; gereksinimler ve nihai doğrulama üzerine daha derin düşünmek, sürecin değerli sonuçları garanti edeceğine dair güveni azaltmak gerekiyor.
  • Yeni bir aile takvimi projesinde yapay zekanın hızından yararlanarak kullanıcı deneyimi sorunlarını inceltiyorum. Özellikleri yapıp birkaç gün kendimiz kullandıktan sonra hoşuma gitmeyen yerleri düzeltme döngüsünü tekrarlayarak v1 özelliklerini tamamlamayı hedefliyorum.
    Renklerden ya da uzun, gereksiz yere süslü iş mantığından hoşlanmıyorum; ama şu anda önemli olan eşimle gerçekten işe yarar biçimde kullanıp kullanmadığımız ve sonuç olumlu. Sonrasında UI’ı kendi zevkime göre yeniden tasarlayıp backend gereksinimlerini netleştirdikten sonra, bakım ve genişletme kolay olsun diye baştan yazacağım.
    Claude ailesi prototipleme ve gereksinim keşfinde çok iyi; sonrasında düzgünce yeniden yapma sürecini kolaylaştırıyor.

• Basit bir doğrulama ölçütü, son 12·24·36 ayda gerçekten harika yeni ürünler ya da mevcut ürünlerde büyük iyileştirmeler görüp görmediğimiz. Benim kullandığım harika yeni ürünler yalnızca tercih ettiğim LLM’ler ve o laboratuvarlar aksine daha fazla insan işe alıyor.
  12 ay sonra da iyileşme yoksa “LLM’ler ancak Şubat 2027’de yeterince iyi oldu, bu yüzden henüz değerlendiremeyiz” iddiasının tekrarlanacağını düşünüyorum.

  • Claude Code’un web ve VS Code sürümlerinin hâlâ bug dolu olup olmadığı da iyi bir ölçüt. Neredeyse her agent döngüsü bozuluyor ve zorunlu yenileme gerekiyor; bazen bu bile çözmüyor. Anthropic’in fiilen sınırsız LLM bütçesi ve yayımlanmamış modelleri de var.
  • LLM’lerin her derde deva olduğunu savunmuyorum ve kontrollü biçimde kullanıyorum; ancak son dönemdeki otomatik zafiyet keşfi ilginç bir gelişme. Chrome, yalnızca haziran ayında son 2 yıldakinden daha fazla bug düzeltti.
    https://news.ycombinator.com/item?id=49120097
    En son Apple güvenlik güncellemeleri ve haziran Android güvenlik bülteni de muazzam sayıda zafiyeti düzeltti. Bunların önemli bir kısmı C/C++ gibi güvenli olmayan dillerden kaynaklandı; ancak LLM’ler açıkça tanımlanmış ve sapma ihtimali düşük dönüştürme işlerinde güçlü olduğundan Rust gibi güvenli dillere taşıma konusunda da yararlı.
  • Proje yayınlama hızı eskisiyle benzer, ama yapay zeka araçları sayesinde çıktılar çok daha tamamlanmış ve özellik açısından zengin hâle geliyor. Eskiden yalnızca mutlu yol çalışacak şekilde yayınlardım; artık iptal, hesap dışa aktarma, gizlilik politikası ve mobil-web uygulamasının tamamını büyük çaba harcamadan sunabiliyorum.
  • Sadece birkaç geliştirici topluluğuna bakınca bile bu araçlar çıktıktan sonra yeni ürün sayısı üç katına çıktı. Yayınlanan tüm yazılımları ve yapay zeka kullanılıp kullanılmadığını izleyen bir liste de yokken, kişinin kendi doğrudan iyileşme görmediği için bunların var olmadığını düşünmesi tuhaf.
    Sağlık alanında da ürün sayısı hızla arttı; kalite değişken ama hiçbir sonuç olmadığı söylemi nesnel olarak yanlış.
  • Pratik kullanıma geçen şeyin geçen yılın sonundan itibaren olduğunu düşünüyorum; ama son dönemde hobi yazılımlarında belirgin bir patlama olduğu doğru. Ne kadar iyi sürdürüleceği ayrı bir mesele.

• Ürün çalışınca “kod tabanının prodüksiyona hazır olup olmadığını, 1 milyon dolara satılma kriterlerini karşılayıp karşılamadığını incele” diye istemeyi öneririm. O zaman yapay zeka, az önce iddia ettiği seviyenin yanına bile yaklaşamadığını ortaya koyar; ne kadar kandırıldığınızı gösteren bir ‘milyon dolarlık prompt’ olur.

  • Hacker News’te iki yazı gördüm; ikisinde de en üst yorumlar “Yapay zeka kod yazamaz ve yakında çökecek” diyordu. Yıllardır her gün bu araçları başarıyla kullanan insanlara bunun hâlâ serap olduğunu iddia etmelerini anlamakta zorlanıyorum.
  • Berbat kod tabanları da 1 milyon doların üzerinde fiyatlara satıldı.
  • O hâlde Oracle Database’in kaç milyon dolara satılması gerektiğini merak ediyorum.
    https://news.ycombinator.com/item?id=18442941
  • Sorunları düzeltmesini isteyip aynı soruyu yeniden sorarsanız, düzeltmeden sonra da benzer eleştirileri tekrar sunacaktır.
  • OpenClaw’un kaça satıldığını düşünmekte fayda var.

• LLM’leri iki şekilde kullandım. Birincisi, Opus 4.6 ve Node arka uçla, kişi sırasına göre Slack kanalına bildirim gönderen bir eklentiyi ve Google Meet katılımcılarına göre konuşma zamanlayıcısını vibe coding ile yaptım. İç araçlar oldukları için uygulamayı çok iyi anlamasam da GCP’de sorunsuz çalışıyorlar; kişi başı aylık 20 dolar olan Slack aracı maliyetini tümü için aylık 0,07 dolar altyapı maliyetine düşürdüm
  Tek seferde yapılmış şeyler değildi; ayrıntılı planlama, adım adım uygulama ve test ekleme süreçlerinden geçti. İkincisi, uzun vadeli ürünlerde ekip mimariyi tasarlayıp gözden geçiriyor ve ayrıntılı JIRA ticket’ları oluşturduktan sonra Opus’a aktarıyor. Modelin bir uygulama planı hazırlamasını sağlıyor, ancak mühendis onayladıktan sonra kod yazdırıyoruz
  Hızlı MVP ya da kavram kanıtı için ilk yöntem iyi; ama uzun vadeli bir ürünse MVP’yi atıp ölçeklenebilirliği ve temiz mimariyi en baştan planladıktan sonra LLM’i kodlama işçisi olarak kullanmak gerekir. LLM’ler, insanların uzun süre sürdürebileceği mimari ve temiz kod konusunda karar vermede hâlâ zayıf

  • Tek seferlik, düşük riskli uygulamaları vibe coding ile yapmakta harikaydı; ama aynı yöntemle devasa bir legacy codebase içinde özellik geliştirmek tam bir kâbusa dönüştü

• Ayırt etme ölçütü, AI çıktısını tüketmenin keyifli olup olmadığı. Yazı, video, ses, restoran menüsü, kıyafet fotoğrafı, belge, havaalanı kontrolü, reklam vb. hiçbirinde keyifli değil; LLM’lerin ise gelişmiş arama motoru veya soru-cevap aracı olarak değerli olduğunu düşünüyorum

  • Birçok tüketici, asgari eşiği karşılayıp çalıştığı sürece düşük kaliteyi umursamaz. Ev aletlerinde, yazılımda ve fast food’da da aynı olgu vardı
    Yapay zeka sonunda bu eşiği karşılarsa, üretilen çıktılar el yapımı ürünlere hâkim olacak; insanların doğrudan yaptığı ürün ve hizmetler de bugünün zanaat ürünleri gibi ancak çok daha yüksek fiyatlarla satın alınabilir hale gelecek gibi görünüyor
  • İyi AI çıktılarının farkına varmadan zaten sürekli keyfini çıkarıyor olabiliriz. Kimse berbat tek seferlik üretilmiş çıktıları sevmez
  • İnsanların her ay toplamda onlarca milyar dolar harcadığına bakılırsa, gerçekten sevdikleri söylenebilir
  • AI çıktısını yalnızca hammadde olarak görüyorum; kitlesel müşterilere doğrudan sunulacak bitmiş ürün olarak değil
  • Sorun AI olması değil, düşük kalite. AI olduğu açıkça belli olsa bile iyi yapılmış çıktılar seviliyor

• Başka şirketlerin vibe coding sonuçlarını toparlayıp gerçekçi sistemlere dönüştürme işi çok artacak. Tek tek projelerin değeri düşse bile sayıları artacak ve yardım olmadan düzgün çalışmama ihtimalleri yüksek
  Yazılım mühendisi olmayan bir şirketin Claude Code ile kendi ana işi dışındaki işleri yaptığını, ama yine de çalışanın kodla oyalanmak yerine işe alınma amacına uygun işi yapmasını istediğini söylemişti
  Özel üretim kolaylaştıkça tek tip ürünleri satmak zorlaşacak; ancak gerçekten özelleştirilmiş sonuçlar teslim etmek için hâlâ çok iş gerekiyor. Hem doğrudan geliştirme deneyimi hem de ilgili iş alanı bilgisi olan kişi iki kat avantajlı olacak
  İnsanlar genelde neye ihtiyaçları olduğunu bilmez; bu yüzden ihtiyacı ortaya çıkarıp sunan danışmanlığın özü aynı kalır. Yazılım ucuzladıkça daha fazla müşteriyle çalışmak mümkün olur

  • Koda dokunmaması gereken o çalışanın kim olduğu belirsiz

• Yazının temel mantığı kusurlu. Prototip yaptıktan sonra yapılacak iş kaldıysa, o işi de yapmaya devam edersin. AI kullanımını tek seferde dört satırlık bir prompt’la bir şey üretmekle özdeşleştiriyor gibi; köklü bir içgörüden çok, eleştirisiz bir özrasyonalizasyon gibi görünüyor

  • Test kapsamı yetersiz, gereksinimleri belirsiz ve dağıtım biçimi standart dışı olan bir codebase’de LLM kullanma deneyimimle birebir örtüşüyor. Mutlu yolun dışına çıkınca production’ı bozan kötü varsayımlar yapmaya başlıyor; en zeki modeller bile böyle bir ortama uygun mimari düzeyine erişemiyor

• Mühendislik geçmişim olmasa da sezgisel olarak doğru geldi; kart oyunu yaparken bunu birkaç kez yaşadım. Başta iyi gidiyordu, ama standart 52 kartlık bir kart kütüphanesi getirdiği için özel etkinlik kartları ekleyemedim; kart nesnesi tabanlı esnek bir veri modeline ihtiyaç vardı
  En baştan söylerseniz çözebilir; ama yazılımı tek kullanımlık görür ve deneyimli bir mühendis gibi uygulamayı derinlemesine düşünmezseniz böyle gereksinimler akla gelmez. AI tarafından üretilen yazı ve kodun sorunu, üretim sürecinin içinde yer alan düşünme eylemini elinizden almasıdır
  Öte yandan her yazılımın ölçeklenebilir, hızlı ve bakımı kolay olması gerekmez. Milyonlarca kişinin kullanacağı altyapı ve uygulamalarda gerekir; ama aile için yemek planlama uygulamasının Google’daki on binlerce çalışanın alerji ayarlarını desteklemesine gerek yok
  AI, yazılımı ev yemeği gibi bir araç haline getirebilir. Ev yemeğinin kusursuz bir yemek olması gerekmez; aileyi doyurması ve birine emek verilmiş bir hediye olması yeterlidir

• Ürünler tek bir istekle yapılabiliyor olsaydı, dış kaynak şirketleri çoktan ürün şirketlerine hâkim olurdu. Ürün geliştirmenin önemli bir kısmı ilk prototip/MVP sonrası yineleme çalışmalarında gerçekleşir
  Yalnızca teknik taraf değil; sorunu uzun süre kurcalayıp acının kök nedenini anlamak ve hem kullanıcı deneyimi hem de teknoloji tarafında çözmek gerekir. Eskiden de dış kaynak şirketlerine ürün “prompt” edilebiliyordu; buna rağmen müşterilerle yıllarca konuşup uzmanlık biriktiren ürün şirketlerine para ödenmesinin nedeni buydu

• Yazının başlığını daha iyi özetleyen başlık The Prototype Isn't the Product olurdu. AI ile “genelde çalışan” tek kullanımlık prototipler ve kişisel uygulamalar şaşırtıcı derecede hızlı yapılabiliyor; ancak kalite ve bakımın önemli olduğu yazılım mühendisliği hâlâ zor ve yavaş
  Gösterişli vibe coding demoları çok, ama büyük ölçekli legacy codebase’lerde ya da gündelik, gösterişsiz uzmanlık işlerinde AI’ın ne kadar yararlı olduğuna dair tartışma az
  Vibe coding ile yapılmış 3D oyun prototipi durdu diye pazar sabahı 06.00’da telefon almazsınız; ama az önce güncellediğiniz 24 saat çalışan sistemde bug çıkarsa o telefonu mutlaka alırsınız