66 puan yazan xguru 2026-01-28 | 15 yorum | WhatsApp'ta paylaş

Kodlama iş akışındaki değişim

  • 2024 Kasım’da oran %80 manuel+otomatik tamamlama, %20 ajan tabanlı kodlamayken, Aralık’ta bu oran tersine dönerek %80 ajan tabanlı kodlama, %20 düzeltme/rötuş haline geldi
  • Fiilen İngilizce programlama yapılan bir duruma geçildi; yani LLM’e hangi kodu yazacağını sözlü olarak tarif etme biçimi
  • Rahatsız edici bir yanı var, ancak yazılımı büyük ölçekli "kod aksiyonları" birimleriyle ele alabilme gücü son derece faydalı
  • Buna uyum sağlamak, ayarlarını yapmak, kullanımını öğrenmek ve nelerin mümkün/nelerin mümkün olmadığını kavramak, verimi daha da artırıyor
  • Yaklaşık 20 yıllık programlama kariyerindeki en büyük temel kodlama iş akışı değişimi ve bu sadece birkaç hafta içinde gerçekleşti
  • Benzer bir şeyin kayda değer sayıda (çift haneli yüzde oranlarında) mühendisin başına geliyor olması muhtemel, ancak genel kamu farkındalığının düşük tek haneli yüzde seviyelerinde olduğu tahmin ediliyor

IDE / ajan sürüsü / hata olasılığı

  • "Artık IDE’ye gerek yok" ya da "ajan sürüsü" etrafındaki abartının şu aşamada fazla olduğunu düşünüyor
  • Modeller hâlâ hata yapıyor; gerçekten önemli bir kod söz konusuysa şahin gibi izlemek gerekiyor ve yanında büyük bir IDE açık tutmak şart
  • Hataların niteliği değişti: artık basit sözdizimi hataları değil, biraz dikkatsiz ve aceleci bir junior geliştiricinin yapabileceği türden ince kavramsal hatalar
  • En yaygın hata türü: kullanıcı yerine yanlış varsayımlar kurup, doğrulamadan yola devam etmek
  • Ek sorunlar:
    • karmaşıklığı yönetememek
    • açıklayıcı soru sormamak
    • tutarsızlıkları ortaya çıkarmamak
    • trade-off’ları sunmamak
    • itiraz etmesi gerektiğinde itiraz etmemek
    • hâlâ bir miktar yağcılığa meyilli (sycophantic) olmak
  • Plan modunda daha iyi, ancak hafif bir satır içi plan moduna ihtiyaç var
  • Kod ve API’leri gereğinden fazla karmaşıklaştırma eğilimi de var; soyutlamaları şişiriyor ve iş bittikten sonra ölü kodu temizlemiyor
  • Bazen 1000 satır boyunca verimsiz, şişkin ve kırılgan bir yapı kuruyor; sonra “Bunu böyle yapmasak olur mu?” diye sorunca “Tabii ki!” deyip hemen 100 satıra indiriyor
  • Görevle ilgisiz olsa bile hoşuna gitmeyen ya da yeterince anlamadığı yorumları ve kodu değiştirdiği/sildiği durumlar hâlâ var
  • CLAUDE.md içine yönergeler koyup basit düzeltmeler denense bile bu sorunlar ortaya çıkıyor
  • Tüm bu problemlere rağmen bu hâlâ saf anlamda devasa bir iyileşme ve manuel kodlamaya geri dönmek çok zor
  • Mevcut iş akışı: solda ghostty pencere/sekmelerinde birkaç Claude Code oturumu, sağda ise kodu incelemek ve manuel düzenlemek için bir IDE

Israrcılık (Tenacity)

  • Ajanın durmaksızın bir şeye asıldığını görmek çok ilginç
  • Yorulmuyor, morali bozulmuyor ve bir insanın çoktan bırakıp sonra tekrar dönerim diyeceği durumlarda bile denemeye devam ediyor
  • Bir şeyle uzun süre boğuşup 30 dakika sonra sonunda başardığını izlemek, "AGI hissi veren" anlar gibi
  • Dayanıklılığın işin temel darboğazı olduğu fark ediliyor ve elde bir LLM olduğunda bu dramatik biçimde artıyor

Hız artışı

  • LLM destekli çalışmanın “hız artışı”nın nasıl ölçüleceği net değil
  • Yapmak istediği şeyler kesinlikle çok daha hızlı hissettiriyor, ancak asıl etki başta planlanandan çok daha fazlasını yapabilmek:
    • Önceden kodlamaya değmeyecek her türlü şeyi artık kodlayabiliyor
    • Bilgi/beceri eksikliği nedeniyle daha önce dokunamadığı kodlara erişebiliyor
  • Bu bir hız artışı, ama daha büyük kısmı muhtemelen genişleme (expansion)

Kaldıraç etkisi

  • LLM’ler belirli bir hedef karşılanana kadar döngü çalıştırmada çok iyiler ve “AGI hissi veren” sihrin büyük kısmı burada
  • Ne yapacağını tek tek söylemek yerine, başarı kriterlerini verip izlemek gerekiyor
  • Önce test yazdırıp sonra o testleri geçmesini sağlamak gerekiyor
  • Bunu browser MCP ile birlikte döngüye koymak gerekiyor
  • Önce doğruluğu çok yüksek olma ihtimali olan naif algoritmayı yazdırıp, sonra doğruluğu koruyarak optimizasyon istemek gerekiyor
  • Yaklaşımı emrediciden bildirimselleştirene kaydırmak, ajanın daha uzun süre döngüde kalmasını ve daha fazla kaldıraç yaratmasını sağlıyor

Eğlence

  • Beklenmedik olan şey, ajanla birlikte programlamanın daha eğlenceli hale gelmesi
  • Boşluk doldurma tarzı sıkıcı işler ortadan kalkıyor ve geriye yaratıcı kısım kalıyor
  • Tıkanma/duraksama (eğlencesiz hâl) azalıyor ve daha fazla cesaret hissediliyor — çünkü birlikte pozitif ilerleme sağlayacak her zaman bir yol var
  • Tersini hissedenler de var: LLM ile kodlama, kodlamanın kendisini seven mühendisler ile bir şeyler inşa etmeyi seven mühendisleri ayırıyor

Körelme (Atrophy)

  • Kodu manuel yazma becerisinin yavaş yavaş körelmeye başladığı fark ediliyor
  • Üretim (kod yazma) ile ayırt etme (kodu okuma) beyinde farklı yetenekler
  • Programlamadaki küçük sözdizimsel ayrıntılar yüzünden yazarken zorlanılsa da, kod incelemesi yapmakta sorun yaşanmıyor

Slopocalypse

  • 2026’nın GitHub, Substack, arXiv, X/Instagram ve genel olarak tüm dijital medyada slopocalypse’in (düşük kaliteli yapay zeka üretimi içerik seli) yılı olacağı öngörülüyor
  • Gerçek ve somut iyileşmelerin yanı sıra çok daha fazla yapay zeka abartısı üretkenlik tiyatrosu göreceğiz (bu mümkünse tabii)

Sorular

  • "10X mühendis"e ne oluyor? — ortalama ile en iyi mühendis arasındaki üretkenlik oranı? Bu oranın ciddi biçimde artması mümkün
  • LLM ile donanmış bir dünyada, generalistler uzmanları giderek daha fazla geçecek mi? LLM’ler boşluk doldurma (mikro) işlerinde, büyük stratejiye (makro) kıyasla çok daha iyi
  • Gelecekte LLM ile kodlama nasıl hissettirecek? StarCraft oynamak gibi mi? Yoksa Factorio oynamak ya da müzik icra etmek gibi mi?
  • Toplumun ne kadar büyük bir bölümü dijital bilgi emeği yüzünden darboğaza giriyor?

TLDR

  • Claude ve Codex gibi LLM ajan yetenekleri, 2025 Aralık civarında bir tür tutarlılık eşiğini aşarak yazılım mühendisliği ve ilgili alanlarda bir faz kayması (phase shift) yarattı
  • Zekâ kısmı, bir anda diğer her şeyin — entegrasyon (araçlar, bilgi), yeni organizasyonel iş akışlarına duyulan ihtiyaç, süreçler, daha genel yayılım — belirgin biçimde önüne geçmiş gibi hissettiriyor
  • 2026, sektörün bu yeni yetenekleri sindirmeye çalıştığı yüksek enerjili bir yıl olacak

15 yorum

 
xguru 2026-01-28

Bu yazıdaki içerik temel alınarak Claude Code'un çalışma biçimini iyileştiren bir skills sürümü de yayımlanmış görünüyor.

Karpathy-Inspired Claude Code Guidelines : https://github.com/forrestchang/andrej-karpathy-skills

 
click 2026-01-28

Aklıma takılan bir soru bu: Zaten elle kod yazmaya alışmış insanların LLM’leri denetlemesi iyi hoş ama yeni öğrenenler sadece LLM’in ürettiği koda bakarsa bunun doğru mu yanlış mı olduğunu anlamakta zorlanacaklar gibi geliyor.
Eskiden assembly ile kod yazanlar, derleyiciler çıktığında "saçma sapan assembly çıktısı veren derleyiciye nasıl güveneyim" diye düşünmüşler miydi acaba?
O zaman da C ile yazarken assembly çıktısının istedikleri gibi çıkmasını yönlendirerek kod yazıyorlardı herhalde.
Yapay zeka çağı daha da ilerlediğinde, insan denetimi olmadan doğal dille tamamlanmış bir ürünün düzgün şekilde ortaya çıkıp çıkmayacağını merak ediyorum.

 
pencil6962 2026-01-29

İnsanların kod yazdığı dönemde de galiba çalışmazsan neyin yanlış gittiğini bilmiyordun haha

 
jokerized 2026-01-29

Assembly uzmanları hâlâ derleyicilere söyleniyor. Sonuçta önemli olan, aşırı düzeyde optimizasyon gereken durumlarda böyle uzmanlara ihtiyaç duyulması; bunu yapay zekaya uyarlarsak, yapay zeka ne kadar gelişirse gelişsin, işi uç düzeyde çok iyi yazan insanları geçmesi zor olabilir. Genel anlamda ise artık hiçbir insan yapay zekayı yenemez. Bir kez daha bir AlphaGo anı olarak AlphaCode karşılaşması olsa eğlenceli olurdu.

 
beoks 2026-01-28

Ortaya çıkan kodu analiz edip anlamaya çalışma çabası varsa sorun olmayabilir.

Derleyici biraz farklı bir kavram; kurallara dayalı olarak assembly ürettiği için deterministik bir alanda yer alıyor, bu yüzden bir kez gözden geçirildiğinde aynı sorun sonrasında tekrar etmiyor. Ancak LLM olasılıksal bir alanda çalıştığı için sorunun yeniden ortaya çıkma ihtimali var.

Bu olasılıksal doğruluk daha da gelişirse yüzde 100'e yaklaşır mı bilinmez, ama doğal dildeki gereksinimin kendisi belirsizse sonuç da sonunda belirsiz olacağından, iyi bir nihai ürünün sonuçta yine insana bağlı olduğunu düşünüyorum.

 
dbs0829 2026-01-28

Ben de öğrencilik döneminden beri LLM'lerle tanışan junior arkadaşlar için endişeleniyorum. Junior işe alım havuzunun biraz kötüleşmiş olabileceğini düşünüyorum ama bunu kanıtlamak da yine zor...

 
gulbi135 2026-01-28

Benim kişisel görüşüm, yalnızca CS bilgisi varsa çok da fark yok gibi geliyor.
Ya da belki de şu anda kullandığım yöntem, elleri aşırı hızlı olan ve tüm kodu yazıp veren bir arkadaşla pair programming yapıyormuşum gibi kullandığım için böyledir...

 
click 2026-01-28

Sonuçta derinlemesine geliştirme yapınca bir noktada soyutlama katmanının içini bilmek gereken zaman geliyor.
Doğal dil istemleri ile üretilen kod arasındaki uçurum fazla büyük olduğu için, istemden LLM soyutlama katmanının içine girmek zor görünüyor.

Şu anda bizim yaptığımız, zihnimizdeki spesifikasyon kavramını bir istem olarak LLM’e iletip ardından yazılan kodu tekrar okuyarak doğrulamak.
Bu yüzden daha çok başkasının yazdığı kodu review etmek gibi; soyutlamanın içine giriyormuş hissi vermiyor.

 
pencil6962 2026-01-29

Sanırım o %20’yi fazlasıyla ihmal ediyormuşum
Son zamanlarda AI’ın çözemediği bir bug’la karşılaşınca... her derde deva olmadığını, ama ben onu öyle sanmaya başladığımı fark ettim

 
[Bu yorum gizlendi.]
 
hmmhmmhm 2026-01-28

Ah... hahaha

 
ragingwind 2026-01-28

Buna büyük ölçüde katılıyorum. Son projede yaklaşık 100 bin satır commit ettim (gerçek kod miktarı daha fazla) ve ortalama 2-3 ajan kullanıyorum. Sanırım kodun yaklaşık %95’ini ajanlar yazıyor.

 
ragingwind 2026-01-28

Ancak testler ya da ölü kodlar için hâlâ bakım gerekiyor ve test senaryoları ile testin başarı koşullarına dair ayrıntılar gerekli. Neyin, ne ölçüde yapılacağının yönetimi önemli. Bunu yapabilmek için yalnızca planın değil, aynı zamanda harness oluşturan mimarinin ve Rules gibi ayarların da sürekli güncellenmesi gerekiyor.

 
GN⁺ 2026-01-28
Hacker News yorumları
  • Ajanın yorulmadan denemeye devam ettiğini görmek ilginç
    GPU ve NPU harıl harıl çalışırken, normalde paylaşmayacağımız verileri bile teslim ediyoruz
    Şu anda kullanışlı bir takas gibi görünüyor ama uzun vadede bağımlılık ve toplumsal sorunlar büyüme riski taşıyor
    Sonunda bu dev bekçilere bağımlı hale gelen bir yapıya dönüşebilir

    • Sebatın son 20 yılda teknoloji sektöründe başarının temel unsurlarından biri olduğunu düşünüyorum
      • Yeni protokol ya da framework icat edenlerden çok, karmaşık sistemleri sonuna kadar bırakmayıp çözen insanlar vardı
      • Claude gibi modeller tam da bu sebatı gösteriyor
    • Ama bu tür sebat her zaman iyi değil
      • Çoğu zaman çekiçle vidayı çakmak gibi, sorunu verimsiz bir yöntemle çözmeye çalışıyormuş gibi görünüyor
      • Kısa vadede sonuç veriyor ama uzun vadede yan etkiler bırakıyor
    • Yapay zekanın her zaman doğru yolda gittiğini söylemek zor
      • Test olmayan yerlerde yeni bug'lar üretebiliyor ya da bir insanın doğal olarak uyacağı örtük kuralları bozabiliyor
      • Sonunda “biraz daha coin atarsan bu kez gerçekten düzelteceğim” hissi veriyor
    • Maliyet konusunun abartılı bir endişe olduğunu düşünüyorum
      • Zaten Kimi K2.5 ve GLM 4.7 gibi açık modeller ticari seviyeye yaklaşmış durumda ve işletim maliyetleri de düşük
      • Asıl para eğitim aşamasında harcanıyor; çıkarım tarafı ise kâr bırakan bir yapı
    • “AI giderek ucuzlayacak” sözüne katılıyorum
      • İnsanlık tarihinde pahalı kalmaya devam eden teknoloji neredeyse hiç olmadı
      • Nitekim maliyetler geçen yıla kıyasla yarıya inmiş durumda
  • Yapay zekayla çalışırken beynin körelmesinden daha büyük sorun, insanın kendinden memnun ve bezgin hale gelmesi gibi görünüyor
    İlk başta hızlı sonuçlar dopamin patlaması yaratıyor ama tekrar ettikçe AI sanki projenin yönünü kendi kafasına göre çekiştiriyormuş gibi hissettiriyor
    Sonunda benim istediğim yaratıcı deneyler kayboluyor ve AI'ın latent uzay çekimine kapılıyorum
    Bu, adeta doomscrolling gibi; bir sonraki çıktıyı görme isteğiyle süren bağımlılık yapıcı bir döngü

    • Ben de benzer bir şey yaşadım
      Rust ve Bevy ile çok oyunculu bir oyun yapıyorum ama kod çalışsa bile benim anlamadığım bir kod haline geliyor
      Eskiden buraya gelmek için aracı tamamen anlamış olmam gerekirdi; şimdi ise yarı çalışan bir oyun yaptım ama ECS'nin ne olduğunu bile bilmiyorum
      Bakım ya da acil müdahale düşünülünce bu gerçekten tehlikeli bir durum
    • Sorun sadece beynin körelmesi değil, öğrenme yönünün değişmesi
      Artık kendimiz düşünmeyi unutup modeli öğrenmeye odaklanıyoruz
      LLM kullanma biçimi sürekli değiştiği için sonuçta sonsuz bir öğrenme koşu bandında duruyoruz
    • Öte yandan bazıları “kod yazmak bisiklete binmek gibidir” diyor
      Uzun ara verilse de his kalır, yeniden binince çabuk geri gelir
    • Bir başka sorun da 'okuma körelmesi'
      LLM bilmiyorsa doğrudan vazgeçen ve dokümantasyon okumak istemeyen geliştiriciler artıyor
      Belgeyi bizzat okuyup ekran görüntüsüyle gösterdiğinizde bile “acaba doğru mu?” diye şüphe ediyorlar
    • LLM kullanımının TikTok tarzı dopamin döngüsüne benzediğini hissediyorum
      Kısa süreli haz için sürekli prompt atıyor, “bu kez ne çıkacak” diye bekliyorsunuz
  • LLM ile kod yazma, 'kod yazmayı sevenler' ile 'bir şey inşa etmeyi sevenleri' ayıran bir dönüm noktası oluyor
    Ben sonuç üretmeyi seven bir builder olduğum için bu değişim bana keyif veriyor
    Buna karşılık kod yazma eyleminin kendisinden hoşlananlar bu gidişattan rahatsız oluyor

    • Ben de onlardan biriyim
      Programlamanın cazibesi sorunu yapılandırma ve onu bizzat hayata geçirme sürecindeydi
      Şimdi ise “kod yazan ben değilim, sadece talimat veren benim” gibi hissettiriyor; bu yüzden ilgim azalıyor
    • Aslında bu tartışma yeni değil
      Geçmişte de compile vs interpret, typed vs untyped, hızlı teslim vs bakım yapılabilirlik gibi karşıtlıklar vardı
      Sonunda başarılı yazılımlar, kaotik ilk aşamadan istikrarlı ölçeklenme aşamasına geçiş sürecinden geçer
      AI'ın bu sürece yardımcı mı olduğu, yoksa onu daha da karmaşık mı hale getirdiği konusunda hâlâ emin değilim
    • Başka bir açıdan bakınca 'tasarımın kendisinden hoşlanan insanlar' da var
      Sadece ortaya çıkan üründen değil, sistem yapısını kurma sürecinden keyif alıyorlar
    • LLM şüpheciliği, top-down ile bottom-up geliştirme tarzlarının çatışması olarak da görülebilir
    • Ama “AI'a güvenilebilir mi” sorusu hâlâ ortada
      İnsan takım arkadaşlarında sorumluluk ve güven vardır, LLM'lerde ise yoktur
  • AI'ın 10 kat verimlilik artışı getirebileceği fikri ilginç
    DevOps, geliştirme-operasyon iş birliği biçimini değiştirerek yüksek performanslı ekipler yarattı ve bu da ekip versiyonu bir 10X'e yakın etki doğurdu
    AI ile kod yazmayı iyi kullanmak için, DevOps'ta olduğu gibi sürekli iyileştirme, iş akışı değişimi ve otomasyon/doğrulama yoluyla güven inşa etme süreci gerekiyor
    DevOps da yeni kavramların öğrenilmesini ve ekip kültürünün değişmesini gerektirdiği için geniş ölçekte yayılması zaman almıştı; AI ile kod yazma da öğrenme/kültür değişimi olmadan, 10X potansiyeli olsa bile yavaş adapte olabilir
    Yerleşmesi için eğitim ve mühendislik kültüründe değişim gerekiyor

  • LLM'lerin büyük ölçekli codebase'lerde işe yaramadığını hissettim
    Özellikle karmaşık ve etkileşimi yoğun kodlarda neredeyse hiç yardımcı olmuyor

    • Buna rağmen ben Claude Code ile %98'i yazılmış bir iOS uygulamasını 3 ayda tamamladım
    • “Bu tür örneklerin çoğu greenfield projeler
      Bunu mevcut büyük/karmaşık codebase'lere sokmak, ayrıntılı incelemeyle sınırlı değişiklikler yapılmıyorsa riskli
      Basit yapılarda dosya listesini verip uygulamayı ajana bırakma yaklaşımı etkileyici ama karmaşıklık arttıkça sonuç almak için prompt'ların giderek daha ayrıntılı talimatlara inmesi gerekiyor
    • “ChatGPT değil, Codex ya da Claude CLI gibi yerel bağlam araçları kullanmak gerekir”
    • Opus 4.5 modeli gerçekten dönüm noktasıydı
      Önceki modellerin aksine artık karmaşık monorepo'larda bile somut yardım sağlıyor
    • “LLM işe yaramıyor” değerlendirmesi bağlam eksikliğinden kaynaklanıyor olabilir
      Aynı bilgiyle yeni bir ekip üyesi çalışsa daha iyi olur muydu, bununla karşılaştırmak gerekir
    • LLM'ler, LLM'lerin oluşturduğu codebase'lerde daha iyi çalışmaya eğilimli
      Ticari şirket içi codebase'ler, müşteri taleplerine göre tekrar tekrar geliştirilirken dağınık hale gelir; ilk varsayımlar ve gereksinimler zamanla birbirinden sapar ve teknik borç oluşur
      LLM kullanıp helper ayırma/modülerleştirme/yeniden adlandırma gibi refactor'larla yapıyı güncel gereksinimlere göre temizlerseniz, sonrasında ajan davranışı daha öngörülebilir hale gelir
    • İyi dokümantasyon, mimari açıklamaları ve stil rehberi gibi proje bağlamını düzenlemek çok önemli
      Gereksinimleri/kabul kriterlerini/kullanıcı hikâyelerini markdown ile düzenleyip, planı ayrıntılı yazdırıp ardından uygulamaya geçen aşamalı bir akış gerekiyor
  • AI'ın sebatı ve dayanıklılığının insan sınırlarını aştığı nokta etkileyici
    Araştırmalar da zekâdan çok sebatın (grit) başarıyla daha yakından ilişkili olduğunu söylüyor
    LLM'ler, bütçe izin verdiği sürece sınırsız sebat gösteriyor

  • Son birkaç ayda AI performansının hatta gerilemiş gibi hissettirdiğini düşünüyorum
    Kuralları unutuyor, aşırı planlama ve aşırı tasarlanmış kod üretiyor
    Yine de frontend'de (HTML + Tailwind) hâlâ faydalı

    • Buna biri “bu adeta FrontPage dönemine geri dönmek gibi” dedi
    • Başkası da “o herhalde Sonnet modelidir, Opus 4.5 dene” dedi
  • IDE'lere ya da ajan sürülerine yönelik aşırı beklentilerin henüz erken olduğunu düşünüyorum

    • 10 yıldır kullandığım JetBrains'i bırakıp sadece Zed ve Claude Code kullanıyorum
    • Eskiden aylar süren işleri artık birkaç saatte tamamlayabiliyorum
  • iPhone uygulaması geliştirirken Claude'un İngilizce prompt tabanlı kod üretme yeteneğine hayran kaldım

    • Swift deneyimi olmadan, sadece C++ geçmişiyle bile gayet ilerlemek mümkün oldu
    • Büyük prompt'lar yerine özellikleri küçük parçalar halinde ekleyip gözden geçirme yöntemi çok daha verimli
    • Buna Prompt → Review → Test (PRET) adlı yeni bir iş akışı diyorum
 
heycalmdown 2026-01-28

> LLM ile kodlama, mühendisleri kodlamanın kendisini sevenler ve bir şeyler üretmeyi sevenler olarak ayırıyor

Ben de çevremden duyduklarımı toparlayınca, sonunda gerçekten böyle ikiye ayrılıyor gibi geliyor.