6 puan yazan GN⁺ 2026-02-09 | 3 yorum | WhatsApp'ta paylaş
  • Yapay zeka kodlama araçları, kod yazma gibi kolay işleri otomatikleştirirken, geliştiricilere araştırma, bağlamı kavrama ve doğrulama gibi zor işleri bırakan yapısal bir sorun ortaya çıkarıyor
  • Geliştiricinin yapay zeka çıktısını kendisi anlamadan "Yapay zeka benim yerime yaptı" demesi, geçmişteki StackOverflow kopyala-yapıştır alışkanlığına benzer bir risk işareti
  • Vibe coding, prototipleme için yararlı olsa da gerçek production ortamlarında yapay zeka zaman kazandırmak yerine daha fazla zaman harcatabiliyor
  • Yapay zeka sayesinde bir kez hızlı dağıtım yapıldığında bu, yeni temel seviye haline geliyor ve sürekli sprint baskısı ile tükenmişliğe yol açan bir yönetim sorunu doğuruyor
  • Asıl nokta, yapay zekayı çözüm sağlayıcısı olarak değil bir araştırma aracı olarak kullanmak ve geliştiricinin tüm kodun sorumluluğunu elinde tutması

"Yapay zeka benim yerime yaptı" sözünün sorunu

  • Geçmişte geliştiriciler StackOverflow yanıtlarını, makaleleri veya GitHub issue'larını okuyup bağlamı kendileri doğruladıktan sonra sonuca varırdı
    • Kimse "Google kodu benim için yazdı" ya da "arama sonuçlarında 1 numara olduğu için doğrudur" demezdi
  • Son dönemde "Yapay zeka benim yerime yaptı" ifadesi ortaya çıkmaya başladı
    • Bu, ya gerçekte olanı abartmak ya da geliştiricinin sonuca kendisinin varmadığı anlamına geliyor
    • Her iki durumda da sorun var ve StackOverflow'dan kod kopyala-yapıştır edildiğindeki kaygının aynısı doğuyor: yapıştırılan kod gerçekten anlaşıldı mı

Vibe coding'in sınırları

  • Vibe coding ilk başta eğlenceli ve prototipleme ya da düşük riskli kişisel projeler için faydalı
    • Ancak gerçek iş ortamında her kod satırının bir sonucu vardır
  • Kişisel bir projede yapay zeka ajanından belirli bir dosyaya test eklemesi istendiğinde, 500 satırlık dosya 100 satıra düştü
    • Yapay zeka başka bir şeyi silmediğini iddia etti, ardından dosyanın zaten hiç var olmadığını öne sürdü
    • git geçmişi gösterilince özür diledi ve önce dosyanın varlığını kontrol etmesi gerektiğini kabul etti
  • Bu örnekte yapay zeka desteği, zaman kazandırmak yerine daha fazla zaman harcattı
    • Ajanla tartışmak ve dosyayı geri yüklemek, testleri doğrudan yazmaktan daha uzun sürdü
  • Aynı şey bir sağlık hizmetleri kod tabanında yaşansa, ciddi sonuçlar doğurabilir
  • Bu yüzden yapay zekayı çözüm sağlayıcısı değil araştırma aracı olarak kullanmak önemli; yapay zekanın ne zaman yanıldığını anlamak ise pratik gerektiriyor

Zor kısmın daha da zorlaşması

  • Kod yazmak, geliştirme işinin baştan beri kolay kısmıydı
    • Zor olan; araştırma yapmak, bağlamı anlamak, varsayımları doğrulamak ve belirli bir yaklaşımın neden doğru olduğunu bilmektir
  • Kolay kısmı yapay zekaya devretmek işi azaltmıyor, geriye sadece zor işlerin kalmasına yol açıyor
    • Yapay zeka zaten cevabı verdi diye araştırmayı atlarsanız, yapay zeka çıktısını değerlendirecek bağlamın kendisi de ortadan kalkar
  • Başkasının kodunu okuyup anlamak, kod yazmaktan çok daha zor bir iştir
    • Yapay zeka tarafından üretilen kod özünde başkasının kodudur
    • Yani geliştiricinin iyi olduğu kısmı (yazma) makineye verip daha zor kısmı (okuma ve review) geride bırakmış olursunuz
    • Üstelik bunu, bizzat yazarak biriken bağlam olmadan sadece review yapmak zorunda kaldığınız bir durumda yaparsınız

Sprint beklentileri ve tükenmişlik

  • Yapay zeka yardımıyla ya da başka bir nedenle bir kez hızlı dağıtım yapıldığında, bu yeni temel seviye olur ve aynı hızın sürekli sürdürülmesi beklenir
    • Konuşma "Bunu nasıl yaptın?"dan "Bunu neden her seferinde yapamıyorsun?" noktasına kayar
  • Bu bir mühendislik sorunu değil, yönetim sorunudur
  • Yorulmuş mühendisler edge case'leri kaçırır, testleri atlar ve bug'ları production'a çıkarır
    • Daha fazla incident → daha fazla baskı → daha fazla sprint şeklinde bir kısır döngü oluşur
  • "Yapay zeka 10 kat üretkenlik sağlar" iddiasına karşılık, gerçekte olan şey 0.1x mühendisin 1x hale gelmesi olabilir
    • Teknik olarak 10 kat olabilir; ama asıl soru bunun gerçekten üretkenlik artışı mı olduğu, yoksa daha önce ne kadar az araştırma yapıldığının ortaya çıkması mı olduğudur
  • Tükenmişlik ve düşük kaliteli kodun production'a çıkması, yapay zekanın üretkenlik kazancını dengeler

Kıdemli beceriler, junior güven seviyesi

  • Yapay zeka kodlama ajanlarına kod yazma becerisi açısından kıdemli düzeyde, ama çıktılarına güven açısından junior mühendis düzeyinde yaklaşmak gerekir
    • Kod iyi görünebilir ve muhtemelen çalışır, ancak deneyimi olmadığı için daha dikkatli kontrol etmek gerekir
  • Bir benzetmeyle, yapay zeka kodlama ajanı hızlı okuma becerisi çok güçlü birinin aniden ekibe katılması gibidir
    • Araştırmaya yardımcı olabilir ve kod yazabilir, ama geçen hafta önemli arka plan ve bağlamın konuşulduğu toplantılara katılmamıştır

Kod sahipliğinin önemi

  • Geliştirici, yalnızca kendi yazdığı kodda değil yapay zekanın ürettiği kodda da sorumluluk sahibi olmalıdır
  • Gerçekçi olmayan hız hedefleri nedeniyle yapay zeka çıktısı kopyala-yapıştır edilirse, 6 ay sonra yeni bir ekip üyesi o kodu anlamaya çalıştığında ya da gece 2'de bir arıza çıktığında sorun yaşanır
    • "Bunu yapay zeka yazdı" demek hiçbir durumda işe yaramaz

Yapay zeka zor kısımda nasıl yardımcı olabilir

  • Bir production bug örneği: büyük bir sürümden hemen sonra kullanıcılar saat dilimi gösterimindeki bir edge case bug'ını bildirdi
    • Sorumlu geliştiricinin 30 dakika sonra derse gitmesi gerekiyordu ve diğer herkes çoktan işten çıkmıştı
  • Araştırma için yapay zeka kullanıldı; bug'ın son değişikliklerden kaynaklandığı belirlendi ve yeniden üretme yöntemi açıklandı
    • Bazı deprecated metodlar, mevcut saat dilimi farkındalıklı metodlardan önce uygulandığı için saat dilimi dönüşümü doğru yapılmıyordu
    • 15 dakika içinde kök neden, çözüm fikri ve araştırma notları bir GitHub issue'sunda toplandı
  • Sorumlu geliştirici düzeltmeyi doğruladı, başka bir ekip üyesi de test ve dağıtımı tamamladı
    • Acil durum olmadan, mesaiye kalmadan sorun çözüldü
  • Bu örneğin gösterdiği temel nokta şu: yapay zeka araştırmanın tekrar eden işlerini üstlenirken, insan bağlam sağlar ve doğrulama yapar
  • Yapay zeka araştırma, doğrulama ve bağlamı anlama yönünde kullanılmalı; aksi halde kolay işler daha kolay, zor işler daha zor hale gelen yapı kalıcılaşır

3 yorum

 
tested 2026-02-11

> Yapay zeka geliştirmeyi zorlaştırmıyor
> Aksine, insanların bunca zamandır görmezden geldiği gerçekten zor kısımları ortaya çıkarıyor
> Son 15 yıldır geliştiriciler zaten “insan versiyonu vibe coding” yapıyordu — Stack Overflow’dan kopyala-yapıştır yapıyor, plan olmadan refactoring yapıyor ve “benim laptop’ımda çalışıyorsa yeter” anlayışıyla çalışıyordu
> Şimdi bunu yapay zeka yapınca, birden herkes plan yapmaya ve test yazmaya çalışıyor
> Eğer yavaşlasa bile kalite iyileşiyorsa, asıl ilerleme budur

 
pencil6962 2026-02-11

Bana göre kopyala-yapıştır yapan geliştirici, LLM kullansa da yine kopyala-yapıştır yapıyor
Asıl kaliteye çok önem veren geliştiriciler ise buna daha da fazla önem veriyor gibi görünüyor

 
GN⁺ 2026-02-09
Hacker News görüşleri
  • AI destekli araçlarla birlikte kod yazmak, mevcut insan merkezli kodlamadan tamamen farklı yeni bir beceri
    Elimizdeki diller, framework'ler ve geliştirme ilkeleri insanın sınırlarını aşmak için var, ama AI'nın sınırları farklı
    Karmaşık problemleri çözerken sadece bir prompt verip sonuç almak yerine, diyalog ve yinelemeli tasarım yoluyla problem alanını keşfetme süreci faydalı oldu
    AI'nın hataları ya da halüsinasyonları, aslında problemi gerçekten anlayıp anlamadığımı gösteren bir sinyal gibi çalışıyor

  • Ben vibe coding yöntemiyle retro emülatör ve assembler yapmayı denedim; az sayıda prompt ile bile iyi sonuç aldım
    Ama daha önce yaptığım belirli bir endüstriyel uygulamanın özel bölümlerini denediğimde, ne kadar prompt verirsem vereyim sonuçlar berbattı
    GitHub'da binlerce emülatör örneği var, ama benim yapmaya çalıştığım şey için hiç örnek yoktu
    Sonuç basit — bazı şeyler kolay, bazılarıysa hiç olmuyor

    • Ben bu tür problemlere "utanç verici derecede kolay çözülmüş problem (embarrassingly solved problem)" diyorum
      GitHub'da çok örnek varsa, LLM'nin gizil uzayında da vardır ve istenildiğinde çıkarılabilir
      Senin denediğin şeyde ise öyle örnekler yoktu, mesele buydu
    • Ben de benzer bir başarısızlık yaşadım ama problemi daha küçük parçalara ayırıp net anlattığımda Gemini birkaç denemede çalışan kod verdi
      Sektöre özgü framework'ler vibe coding ile ele alınması zor şeyler, ama problemi sadeleştirince AI çok daha hızlı yardımcı oluyor
    • Sonunda LLM'nin aslında "hizmet olarak cargo culting", yani taklit etme hizmeti olduğunu fark edince sınırları daha net görünüyor
  • vibe coding'i tamamen benimsersen etkileyici sonuçlar çıkarabilirsin ama teknik borç öyle büyüyor ki sonunda makinenin kölesi gibi hissediyorsun
    AI binlerce satır kodu senin yerine yazdığında, o yapıyı anlamak ya da gözden geçirmek çok zorlaşıyor
    Sonunda tek kullanımlık kod ve yazılımın artacağını düşünüyorum — belirli bir sorunu çözen uygulamalar kolayca yapılır ama sürdürülebilir SaaS için büyük risk taşır

  • AI, güçlü bir çarpan etkisi (force multiplier) yaratan bir araç
    Kod tabanının temeli kötüyse AI da o stili aynen kopyalıyor
    Tersine, temiz ve tutarlı bir temel varsa AI o kaliteyi koruyarak şaşırtıcı derecede iyi çalışıyor
    Sonuçta mesele temel tasarım (foundation)
    Çoğu kod tabanı zaten bakımı zor ve ölçeklemesi güç bir yapıda; AI sadece bu sorunu daha görünür hale getiriyor
    İnşaatta olduğu gibi, temel zayıfsa en iyi araçların bile sınırı var

    • Ama AI bütün yapıyı tam olarak anlayamadığı için, zamanla iyi bir yapı bile yavaş yavaş çöküyor
    • İlk kez AI-native bir proje yürüttüm; tüm gereksinimleri, toplantı notlarını ve tasarım belgelerini ChatGPT ile Codex'e verdim, ayrıca çalışma sürecini Markdown olarak kaydettim
      Bunu yapınca sonraki geliştirici de projenin bağlamını (context) eksiksiz anlayabildi
    • Ben de benzer bir deneyim yaşadım. Başta Codex dağınık düzeltmeler yapıyordu ama temeli yeniden tasarlayınca çok daha iyi kod üretmeye başladı
      Sonuçta AI'nın düzgün çalışması için önce temel soyutlamaları düzeltmek gerekiyor
    • Ama gerçekçi olmak gerekirse kusursuz bir temel neredeyse hiç yok
      Gereksinimler sürekli değişiyor ve verimlilik uğruna tavizler veriliyor
      Sonunda zaman ve fırsat maliyeti, kalitenin önüne geçiyor — çünkü insanlar planlara kusursuz biçimde sadık kalamıyor
    • Bir de şu soru kalıyor: “Peki AI'nın kurduğu temel nasıl olacak?”
  • AI, can sıkıcı kısımları daha az can sıkıcı hale getiriyor
    Ama LLM ile tartışmak zaman kaybı
    Değişiklikleri küçük parçalarda yapmak, işe yararsa commit etmek, yaramazsa atıp yeniden denemek daha verimli
    AI her derde deva değil; doğru aracı seçmek önemli

    • Versiyon kontrolünü ya da IDE'nin önceki sürümü geri yükleme özelliğini kullanmamak aptallık olur
      Elinde silah olan bir çocukla oynayacaksan kurşun geçirmez yelek giymelisin
    • LLM ile tartışma başladıysa, yeni bir prompt ile baştan başlama zamanı gelmiştir
    • AI bazen test kodunu iyi yazar ama sık sık testleri manipüle edip geçirir
    • Hatta “ilk sataşan AI olmuştu” diye şaka yapanlar da var
  • “Başkalarının kodunu okumak, yazmaktan daha zordur” sözü sık geçiyor ama bana garip geliyor
    Benim doğrudan yazmam yarım gün sürecek bir fonksiyonu okumak ve gözden geçirmek için 10-15 dakika yeterli oluyor
    Doğru kodu doğrulamak, onu üretmekten çok daha kolay

    • Ben okuma ile düzenlemeyi (editing) ayırıyorum
      Sadece okumak kolay ama yapıyı anlayıp iyileştirme noktalarını bulmak olan düzenleme çok daha fazla emek gerektiriyor
    • Ama gerçekte bazen kendi yazdığım kodu bile sonradan anlayamadığım oluyor
      Çünkü yazıldığı andaki bağlam (context) kayboluyor
    • “Okumak daha uzun sürer” sözü aslında birikimli zaman kavramından çıkmış gibi ama yanlış anlaşılmış olabilir
      Esasında mesele okumanın daha zor olması değil, insanların sıfırdan yazmayı daha çok sevmesi
    • Bazılarına göre ise “neyin doğru olduğunu anlamadan doğrulama yapılamaz”; bu yüzden okuma da sonuçta yazmak kadar zor
  • Doğru bakış açısı şu: “AI her şeyi kolaylaştırıyor ama bu başlı başına yeni bir beceri ve öğrenmesi zor”
    Şu an AI'nın ENIAC dönemindeyiz; yüksek seviyeli diller ya da işletim sistemlerine denk gelen kavramlar henüz yok
    İleride bağlam mühendisliği (context engineering) diye bir alan doğacak ve bugünkü yöntemler ilkel görünecek
    Yapıyı iyi kurarsan AI'nın yetenekleri pratikte sınırsızmış gibi görünüyor

    • Ama insanlar sadece kolay kısmı görüyor ve maliyeti görmezden geliyor
      “AI ile yaptım” demek, aslında “harici bir şirketin CPU kaynaklarını büyük ölçekte kullandım” demek
      Benim tamamen sahip olduğum bir AI ajanı ortaya çıkana kadar bunu gerçek ilerlemeden çok gezegen ölçeğinde kaynak hırsızlığına daha yakın görüyorum
  • AI geliştirmeyi zorlaştırmıyor
    Tam tersine, insanların bugüne kadar görmezden geldiği gerçekten zor kısımları ortaya çıkarıyor
    Son 15 yılda geliştiriciler zaten “vibe coding'in insan versiyonunu” yapıyordu — Stack Overflow'dan kopyala-yapıştır, plansız refactor, “benim laptop'ta çalışıyorsa yeter” anlayışı
    Şimdi bunu AI yapınca, bir anda herkes plan yapmaya ve test yazmaya başladı
    Yavaşlasa bile kalite iyileşiyorsa, asıl ilerleme budur

  • Bugünkü 'maraton içindeki sprint' kültürü AI yüzünden daha da hızlanıyor
    Ama AI gözetimsiz kullanılırsa çok çabuk raydan çıkıyor ve başkasının yazdığı kodu okumak, kendi kodunu düzeltmekten çok daha yorucu

  • AI'ya “bu dosyaya test ekle” dedim, 500 satırlık dosya 100 satıra düştü
    Nedenini sorunca “orijinal dosya yoktu” diye cevap verdi
    git geçmişini gösterince özür diledi ve “önce var olup olmadığını kontrol etmeliydim” dedi
    Dün de “o dosyayı unut” dedim, gerçekten dosyayı silmiş

    • Bu tür başarısızlık örnekleri, aracın hâlâ olgunlaşmamış olmasından kaynaklanıyor; versiyon kontrolü varsa büyük bir sorun sayılmaz
      Bir miktar geri alma maliyeti, AI'nın sağladığı değere kıyasla katlanılabilir düzeyde