2026’da Neden Kod Yazıyoruz?

• Yazılım mühendisinin rolü, kod üretmenin ötesine geçip bir yazılım fabrikası kurup sürdürmeye kadar genişledi; ancak sistemi anlamak ve iyileştirmek için hâlâ kodla doğrudan çalışmak gerekiyor
• Prompt’lar, AGENTS.md ve bilgi tabanlarıyla ajanlara yol gösterip sonuçları testler, linting, tip sistemleri ve değerlendirmelerle korursanız düşük performanslı modeller bile yeterince kullanılabilir değişiklikler üretebilir
• Doğrudan kod yazmak, İngilizce üzerinden geçmeden çalışma ortamında düşünmeyi sağlar; böylece yalnızca pasif kod incelemesiyle kaçırılması kolay güvenlik açıklarını, zayıf testleri ve gereksiz istisnaları bizzat hissettirir
• Ajanlar derleyiciden çok yeni katılmış bir stajyere benzer; mevcut kodu ve hatalı gereksinimleri muhafazakâr biçimde izler, hatta insanların tek seferlik hatalarını sarma ve dolaylı katmanlarla büyütebilir
• İnsanlar yaklaşımı bizzat deneyip kalıpları oturtmalı, ajanların da bunları tekrarlamasını sağlamalıdır; böylece otomasyonun üretkenliğinden yararlanırken sahiplenme duygusu ve muhakeme korunur

---

Ajanların Çalıştığı Yazılım Fabrikası

• Yazılım mühendisi yalnızca yazılımı değil, herkesin değişiklikleri prompt ile isteyip hemen dağıtabilmesini sağlayan montaj hattını da sürdürür
  • Prompt’lar, beceriler, AGENTS.md ve bilgi tabanları aracılığıyla ajanların başarılı olabileceği altyapıyı proaktif olarak kurar
  • Sonuçları sonradan testler, linting, tip sistemleri, değerlendirmeler ve başka yapay zekâlardan yararlanan otomatik değerlendirme ile korur
• Yeterli kısıtlar ve güncel bağlam sağlandığında, zekâ seviyesi düşük modeller bile yoldan sapmadan kullanılabilir değişiklikler üretebilir; bu yüzden insanların kod okumasına ya da doğrudan yazmasına gerek yokmuş gibi görünebilir
• Ancak Fable düzeyinde zekâya sahip bir ajan olsa bile, doğrudan kod yazmak İngilizce adlı ara katman olmadan çalışma ortamında doğrudan düşünmeyi sağlar
• Ajanın oluşturduğu diff ve yamaları pasif biçimde okumak, sistem mimarisiyle derin bağ kurmak için yeterli değildir
  • Kodla doğrudan uğraşınca, üzerine özellik eklediğinizde neyin bozulduğunu hissedebilirsiniz
  • Kodu düzenleyip birçok istisnanın eklenmediği tutarlı mimari ilkeleri belgelerseniz yazılım fabrikası da daha kararlı çalışır
  • Hata ayıklama sürecinde test stratejisinin zayıflıklarını bulup düzeltmek, yeni türden hataların tamamını engelleyebilir
• Yazılımı anlamanın tek yolu doğrudan kod yazmak değildir; mıknatıslanmış iğne ve titremeyen el örneğindeki gibi aşırı el işçiliğinde ısrar etmeye de gerek yoktur
  • Gerçek kodun çoğunu yapay zekâ üretse bile, doğrudan kod yazmak hâlâ yararlı bir araç olarak kalır

Doğrudan Kod Yazarak Düşünme Gücünü ve Sahiplenmeyi Korumak

• Yalnızca kod okuma ve onaylamadan sorumlu bir ters kentaur rolünde kalırsanız odak ve sahiplenme duygusu azalır, düşük kaliteli kodun incelemeden geçmesi kolaylaşır ve ince ayar yapmak zorlaşır
  • Ayrıntılara dikkat edilmezse güvenlik açıkları birikir; uzun vadede düşük kaliteli kod ajanları da olumsuz etkiler
  • İnsanlar yaklaşımı önce bizzat dener, ardından ajanların oturmuş kalıpları tekrarlamasını sağlarsa sonuçlara katılmaya ve onları sahiplenmeye devam edebilir
• İngilizce, hesaplamayı hassas biçimde ifade etmek için yetersiz belirtime sahip bir dildir
  • Algoritma çalışmalarında yürütülebilir adımlar halinde tasarlamak ve düşünmek gerekir
  • Duruma göre, tasarım alanı geniş düşük seviyeli diller ya da hesaplama ortamı daha sınırlı yüksek seviyeli diller seçilerek gereken hassasiyet ayarlanabilir
• Kodlama ajanlarını derleyici gibi görmek, kötü yazılmış kodun bile dağıtıma çıkarılabileceği bir tutuma yol açabilir
  • Ajanlar derleyiciden çok yeni katılmış stajyere yakındır
  • Eksik ve düşük kaliteli olabilecek mevcut kodu okur, hatalı değişiklik açıklamalarına dayanarak yeni değişiklikler üretirler
  • İnsanlar düşünce ve zevklerini bir stajyerler topluluğuna aynen devredemez; bu yüzden tüketici olarak kalmayıp doğrudan dahil olmalıdır
• Ajanların, kodu bulduklarından daha iyi durumda bırakma anlamındaki İzci kuralını kendiliğinden izlemesi zordur; bunu onlara yüklemek de zahmetlidir
  • Mevcut değişikliği olabildiğince güvenli kılmaya eğilimlidirler ve önceki kararları muhafazakâr biçimde korurlar
  • Bir kod tabanında bir insan bazı durumlar için dikkatsizce tarayıcı yerel depolamasını kullanınca, kalan durumlar arka uç veritabanında saklanmasına rağmen ajan bu kararı sürdürmek için sarma ve dolaylı katmanlar ekledi; kod satırı sayısı yaklaşık 3 katına çıktı
  • Bu muhafazakârlık, insanların verdiği tek seferlik yanlış kararları büyütebilir
• Kodu doğrudan silme ve keşfetme süreci, yalnızca İngilizce talimat vermeye kıyasla daha iyi bir mimariye ulaşmaya yardımcı olur
  • Koda ne kadar çok ilgi gösterirseniz düşünme gücünüz, yazar olarak duyunuz ve yazılım fabrikasını yönetme beceriniz o kadar güçlenir
• Yazılım fabrikasında mimari kalıplardan algoritmalara ve performansa kadar ayrıntılar önemlidir
  • Ajanlar değerlendirme, ölçüm ve koruma mekanizmalarına olan ihtiyacı artırdı; kişisel projelerde bile CI’ın sonradan yapılan bir iş değil, erken aşamada eklenmesini teşvik etti
  • Bu sayede yazılım geliştirme durumu büyük ölçüde iyileşti, ancak her montaj hattında hâlâ zayıf noktalar kalır
• Otomobil fabrikasında bile montaj hattını sökmeniz, içten yanmalı motorun ayrıntılarına inip %10 iyileştirme yapmanız ya da sahadaki bir sorunun neden erken fark edilmediğini bulmak için tüm gün fren balatası testlerini izlemeniz gereken zamanlar olur
  • Yazılımda da ayrıntılarla genel yapıyı birbirine bağlamak için neyi doğrudan ele alabileceğinize dair keyfî sınırlar çizmemelisiniz

[choijaekyu]

Çünkü token maliyeti yok :(

[GN⁺]

Hacker News yorumları

• Kod yazamıyorsanız kod incelemesi de yapamayacağınız apaçık görünüyor; ama Claude yazsın, Codex incelesin diyen insanlar ve şirketler var. Buna rağmen çıktıyı assembly ya da derlenmiş binary olarak değil de Python, Java gibi yüksek seviyeli dillerde istemelerinin nedeni sonuçta insanların kodu okuyabilmesi gerektiği
  Geliştiricilerin kodu okumasını, debug etmesini ve akıl yürütmesini bekleyip de tam da bu yeteneği geliştirecek eğitimi vermek istememek çelişkili bir tutum

  • Claude’a assembly yazdırılmamasının nedeni, assembly ile CRUD uygulaması yapmaya yönelik öğrenme materyalinin neredeyse hiç olmaması. LLM’lerin işleri yutmasından hoşlanmıyorum ama en ileri modellerin internette sayısız kez tekrarlanmış ve belgelenmiş işleri iyi yaptığı da bir gerçek; son birkaç on yılda yazılım geliştirmenin kayda değer bir bölümünün kalıplaşmış CRUD uygulamaları üretmekten ibaret olduğu da doğru
    Tüm yaratımı LLM’lere bırakırken sektörün gelişmeye devam edip edemeyeceği ise şüpheli
  • Kod yazma eylemi aynı zamanda düşünme eylemi olduğundan, kod yazmayı bırakırsanız düşünmeyi de bırakırsınız. Daha yüksek seviyede düşündüğünüzü söyleseniz bile, o üst seviye tasarımı da LLM’ler daha iyi yapar hale geleceği için bugünkü üstünlük yalnızca geçici
  • Sonuçta bu bir biliş biçimi farkı gibi görünüyor. Bazı insanlar için kod, İngilizce açıklamalardan daha kesin ve okunması daha kolaydır; deneyimli bir geliştirici yalnızca göz gezdirerek nasıl çalıştığını kavrar. Başkaları ise kod okumakta zorlanır ve doğal dili daha rahat bulur
    Bu, bir tarafın daha iyi olduğu anlamına gelmez; ayrıntılara daha az önem veren insanlar dünyayı yönlendirebilir ya da her problem farklı düzeyde incelik gerektirebilir
  • Casey Muratori ve Demetri Spanos bunu bir videoda ele almış gibiydi; binary’den kaçınmanın nedeni LLM’e duyulan güvenden çok makineden makineye değişen makine dili ve offset’ler ile bağlamı yorumlamanın zorluğuna yakın. Ghidra’nın ters derlediği C kodu ile geliştiricinin yazdığı C kaynak kodunun anlaşılabilirliği arasındaki farkta olduğu gibi, yüksek seviyeli diller kodun niyetini taşıyabilir
    Derleyici, LLM’in gerçekten derlenip çalıştırılabilen kod yazmasına yardımcı olur; ama doğrudan makine dili çıktısı verirse hiç çalışmama ihtimali yüksektir. Elbette hiç kod yazamıyorsanız inceleme yapmak çok daha zordur
  • Claude’un doğrudan assembly ya da binary çıktı vermesi gerektiğini gerçekten savunanlar da var. Ancak bunun, birden çok makine için assembly’ye derlenebilen yüksek seviyeli bir dile göre daha düşük taşınabilirliğe sahip olma ihtimali büyük

• “Bir program üretecek kadar kapsamlı ve kesin bir proje tanımına sektörde ne denir? Kod denir” — CommitStrip
  Doğru yazıldıysa kodun özü, temelindeki iş mantığını en basit biçimde ifade etmelidir. Tüm destek katmanlarını incelemek gerekmeyebilir; ama kodu okumadıysanız iş mantığını da tamamen bildiğiniz söylenemez

  • Orijinal bağlantı
  • Bu konuda yazılmış başka bir yazıda da spesifikasyon yerine kod kullanılması önerilmişti. Ajan’a kodla talimat vermek ya da izleyeceği örnekler oluşturmak da gayet olabilir
    https://softwaredoug.com/blog/2026/07/04/write-code-not-specs
  • Bu yüzden Lisp gerekiyor. Önce iş mantığının temel öğelerini dilin temel öğeleri haline getiren bir programlama dili oluşturup, sonra bu yeni dille işin ne yaptığını tarif eden basit bir program yazmak yeterli

• Önemli soru, elle kod yazmaya kimin para ödeyeceği. Müşteri kodun yazılmasına ya da üretilmesine değil, problemin çözülmesine para öder; dolayısıyla işi en düşük maliyet ve en az tantanayla çözen taraf alır ve AI araçlarının takvimi sıkıştırma avantajını görmezden gelmek zordur
  1990’lardan beri bu sektördeyim; olağanüstü olmayan geliştiricilerin vasat çıktılar üretmesi her zaman çok yaygındı. Elle yazılmış kod fazla romantize ediliyor; oysa gerçek kod tabanları zamanla bakımı zor ve hatalarla dolu hale gelmeye yatkındı, kötü yürütülen projeler de hiç yeni bir olgu değil

  • Aksine, az miktarda kodu bizzat yazmanın üretkenliği artırdığını düşünüyorum. Bir günü mimariyi elle yeniden düzenlemeye ayırmak, token maliyetlerinde binlerce dolar ve haftalar sürecek baş ağrısından tasarruf ettirebilir
    Şu an iki elimiz bağlı halde bir yazılım fabrikası inşa etmeye çalışıyoruz
  • Vasat geliştiriciler artık 10 kat daha fazla vasat çıktı üretiyor
  • Sağlık, havacılık ve nükleer enerji gibi yazılım kalitesinin önemli ve regüle olduğu sektörlerde elle kod yazmaya para ödenmeye devam edilmesini umuyorum. Ancak bu pazar nispeten küçük

• Odaklanmak ve anlamak için ajanı uzaktan izleyip kodu pasif biçimde okumakla yetinmeyip kodu bizzat deneyimlemek gerekir. Sonuçta bu, kendi zihinsel modelinizi eğitmeniz gerektiği anlamına gelir
  Kod yazarken bilinçaltı “bu doğru hissettiriyor” türünden pek çok yargı üretir; bu da yalnızca tekrar ve derin odaklanmayla gelişir, kod incelemesi ya da dokümantasyon okumakla sınırlı kalır. Böyle oluşmuş bir zihinsel modeliniz varsa, üretim ortamındaki bir arızanın hata mesajına bakarak nedeni hemen işaret edebilirsiniz; üretilmiş kodda ise yavaş, bilinçli düşünmeyle uzun süre aramanız gerekir
  LLM’in gerçekten faydalı olması için tüm kod bakımını üstlenip harici bir kütüphane gibi çalıştığını varsayabilmeliyiz; aksi halde sürekli sorun çıkması kaçınılmazdır

  • İnsanlarda da bu ayrımı zaten denedik ve o kadar kötü işledi ki fildişi kule mimarı gibi aşağılayıcı bir tabir bile doğdu. Gerçek sistemlerde uygulanması imkânsız teorik tasarımlar ortaya çıkar; uygulama ekibi ya da LLM mimarinin etrafından dolaşır; mimar ile uygulayıcı birbirini ıskalayan tartışmalar yaparken geliştirme hızı ciddi ölçüde düşer
  • Gözlemlenebilirlik alanında, yalnızca dinamik çalışma davranışına bakarak nedeni bulmak zorsa sistemi daha şeffaf ve gözlemlenebilir hale getirmek gerektiği düşünülür. İnsanlar yer değiştirebileceği ya da ayrılabileceği için üstün bireylerin zihinsel modellerine bel bağlanmaması gerektiği ilkesi zaten baştan beri geçerliydi, diyen bir görüş bu
    Hangisinin doğru olduğunu henüz bilmiyorum, daha fazla araştırıyorum

• 2026’da bile AI tarafından üretilen kod hâlâ berbat. Fable olsun, özel Pi/opencode LeetCode harness’ları olsun, sonuçlar korkunç; kendi kodunuzla AI kodu arasındaki kalite farkını ayırt edemiyorsanız size kötü bir haberim var

  • Benim kodum AI’dan kötüydü ya da hâlâ kötü; ama en azından para alıyorum, bu yüzden o kötü haber pek önemli değil

• Ajanın Boy Scout kuralına uymasını sağlamak için profil çalıştırma, kod kapsamını kontrol etme, eleştirel inceleme, rapor ve takip işleri yazma gibi şeyleri kurallarda açıkça belirtmiştim. Bugünün en ileri LLM’leri bu tür kurallara, birlikte çalıştığım insanların %90’ından çok daha iyi uyuyor; bunun kötü bir şey mi olduğu konusunda emin değilim.

  • Ajan, mevcut değişikliği olabildiğince güvenli hâle getirme yönünde eğilimli. Daha kahvemi bile içmeden, dalgınlıkla tarayıcı local storage’ını kullanmasını söyledim; geri kalan tüm durum backend veritabanındayken bile o hatalı kararı korumak için sarmalama ve dolaylı katmanlar ekleyip kod satırı sayısını neredeyse üç katına çıkardığı oldu.
    Ajan muhafazakâr davranıyor ve insanların tek seferlik hatalarını büyütebiliyor. Bunu çözmenin pek çok yolu var ve herkesin düşünme biçimi farklı; bu yüzden hem kodu okumadan ilerleyen yöntemler hem de doğrudan okuyup yazan yöntemler mümkün. Ancak LLM’den geçmeyen kodun kesinliğinden gelen fayda da büyük.

• Kodu kendim yazmamın nedeni, yazmazsam LLM’in aşırı fazla kod üretmesi. Problemi tamamen anlayıp genelleştirmek gerekiyor ki “Hello World”e 10 bin satır ve 5 soyutlama katmanı eklenmesin.
  LLM bir token tahminleyicisi olduğundan, çözülecek problem sayısı arttıkça ürettiği kod token’larının da artma eğilimi var.

  • LLM, bütünü bütüncül biçimde düşünmektense kodu savunmacı biçimde sarmalamayı seviyor; bu yüzden kolayca şişebiliyor. Buna karşılık insan geliştirici, çalışırken çevredeki kodu da toparlayan Boy Scout kuralını izleyebilir.
  • Peter Naur onlarca yıl önce programlamanın kaynak kod, spesifikasyon ve dokümanları mekanik olarak üretmek değil; sistemin her bir parçasının gerçek dünyadaki problemle nasıl örtüştüğüne dair derin bir zihinsel teori inşa eden insan faaliyeti olduğunu açıklamıştı. Programlamanın gerçek çıktısı, geliştiricilerin paylaştığı zihinsel modeldir.
    Çözülecek probleme sahip olan taraf insan olduğu için, problem anlaşılmazsa LLM’in gerçek ihtiyaçlarla ilgisiz bir problemi çözdüğü X/Y problemi doğabilir. LLM, kütüphaneler veya üst düzey diller gibi çekirdek olmayan unsurları daha iyi soyutlar; ancak problemin özü hâlâ biçimsel olarak ifade edilmelidir.
    Kısıtları tek tek ekleyerek istenen sonuca ulaşan vibe coding de sonuçta gevşek ve biçimsel olmayan bir programlamadır. LLM’e problemin çevresel kısımlarını bırakıp çekirdeği doğrudan yazmak ve anlamak daha iyidir.
  • İşimin %99’u C# olsa da LLM sayesinde hiçbir şey yapmadan, hep olmak istediğim düşük seviye programcı olduğumu iddia edebilir hâle geldim.
  • Şirketteki diğer modüllere benzer şekilde K8s üzerinde çalışacak bir proje yapılandırmasını istedim; LLM, Hello World implementasyonunun birim testlerini bile yazdı.
  • En yeni ABD modeline istemci tarafı bilgilerini gösteren küçük bir iş verdim; ilk handshake sırasında sunucunun istemciye bilgiyi aktarması için her iki taraftaki kodu da değiştirdi ve hatta gerçekten çalıştı. Ama o bilgi zaten istemcide vardı; yani yalnızca istemci kodunda tek bir satırı değiştirmek yeterliydi.
    Dışarıdan bakınca isteği kusursuz çözmüş görünüyordu ama gereksiz ve sakil bir koddu. Kullanıma göre token satan bir şirketin, problemi kabaca çözerken token tüketimini azamiye çıkaran Rube Goldberg tarzı çözümler üretmesi için ekonomik teşviki var; üstelik yalnızca üretirken değil, içine yeni bug’lar karışmış devasa kodla daha sonra uğraşırken de daha fazla token harcatıyor.
    Kopyala-yapıştır kodla alay eden insanların şimdi gelişigüzel yapıştırılmış koda hayran kalması komik.

• Kasım 2022’de ChatGPT 3.5’ten bu yana kaydedilen ilerlemeye bakınca, 4 yıl sonra hâlâ kod inceleyip incelemeyeceğimizden emin değilim. Yapay zeka aşırılıkçısı olmasanız bile mevcut hız korunursa 5–10 yıl içinde bugünkü biçimiyle yazılım mühendisliği ve geliştirme büyük olasılıkla ortadan kalkabilir.
  İnsanlara yalnızca UI tasarımı gibi işler kalabilir; geri kalan her şey soyutlanıp gerçek işi yapay zeka halledebilir.

  • Dileği tek seferde gerçekleştiren bir makineyse tek bir isteği kolayca işler; ancak yazılım binlerce dileğin birikimidir ve her köşede şunu istiyorum, bunu istemiyorum şeklinde ince kararlar verilmesi gerekir. Mevcut LLM yaklaşımında tüm bu kararları hâlâ insanın yönetmesi gerekiyor; fakat gelecekte bugün hayal edemediğimiz yöntemler ortaya çıkabilir.
  • Gelişimin aynı hızda süreceği varsayılıyor; ama bana kalırsa şimdiden bir ölçüde durgunluk bölgesine girilmiş durumda. Model büyüdükçe maliyetler üstel olarak artıyor ve sürekli daha büyük modeller eğitmenin kârlı bir iş olmadığı da oldukça görünür hâle geldi.
  • Her eylem için JavaScript gerektiren, bir giriş alanına yazı yazmayı bile düzgün beceremeyen web siteleri yapan beceriksiz insanları doğrudan suçlayamayacağımız geleceği şimdiden sevmiyorum. Görünüşü işlevin önüne koyan yöneticiler ve eğitim verisinin çoğunu oluşturan bu tür siteler yüzünden LLM aynı çöpleri çok daha büyük ölçekte üretirse varoluşsal bir kriz gelecek gibi.
    Web zaten yeterince berbat; en azından mevcut durumda beceriksiz insanları suçlayabilmemize izin verilsin.

• KPI baskısından bağımsız olarak fırsat buldukça kodu kendim yazıyorum; yapay zekadan da en fazla daha akıllı bir kod otomatik tamamlama bekliyorum.

• Kodlamayı sevdiğim ve beni gerçekten mutlu ettiği için kodu kendim yazıyorum. Sevdiğim bir işi bırakmam için bir neden yok.

  • Bilgisayara bir iş buyurup onu başka herhangi bir araçtan milyarlarca kat hızlı şekilde yaptığını izlemenin sihirli bir çekiciliği var.
  • Program tasarlamaktan ve kod yazmaktan keyif aldığım için bu alana girdim. Yapay zeka kullanımında geride kaldım ve daha fazla öğrenmem gerekecek; ama elle kod yazmayı asla bırakmak istemiyorum.
  • Kod yazarken bir de para kazanmak mutluluksa, şirket bu ödülü kesebilir. Vizenizi korumak için o gelire bağımlıysanız, değişime zorla uyum sağlayıp kodlamayı bırakma olasılığınız çok yüksek.