- Yapay zeka kodlama araçlarını kullanarak giderek daha büyük işleri onlara devrettikçe şaşkınlık yaşadım, ancak ortaya çıkan işlerin tutarlılık ve yapısal bütünlükten yoksun olduğunu gördüm
- Ayrıntılı şartnameler yazsam da yapay zeka ajanları uzun vadeli bağlamı koruyamıyor veya tasarımı evrimleştiremiyor, bunun sonucunda tüm kod tabanı heterojen parçalardan oluşan bir kümeye dönüştü
- Kod parçaları tek tek bakıldığında eksiksiz görünüyor, ancak bütün olarak yapısal dağınıklık (sloppy) ve bağlam çöküşü ortaya çıkıyor
- Bu deneyimlerin sonunda yazar, yapay zekanın ürettiği kodla kullanıcı güveninin veya veri korumasının garanti edilemeyeceğine karar veriyor ve yeniden kodu bizzat yazma yöntemine dönüyor
- Yapay zeka ile kodlama hâlâ faydalı, ancak teknik borç ve geliştirici kontrolünün kaybına yol açabileceği için dikkatli kullanılmalı
Yapay zeka ile kodlamanın ilk heyecanı ve sınırlarının fark edilmesi
- Kullanıcıların çoğu yapay zeka ile kodlamaya basit işlerle başlıyor, ardından giderek daha karmaşık görevleri ona verip performansına hayran kalıyor
- Ancak belli bir noktadan sonra yapay zekanın hataları ve tutarsızlığı görünür hâle geliyor ve beklentiyle gerçeklik arasında bir fark oluşuyor
- Kullanıcılar sonuç tatmin edici olmadığında bunu kendi prompt sorunları olarak görüp daha ayrıntılı şartnameler yazmaya çalışıyor
- Obsidian gibi araçlarla ince ayrıntılı teknik dokümanlar hazırlasalar da yapay zeka bunları uzun vadede geliştiremiyor
Şartname temelli yaklaşımın başarısızlığı
- Gerçek geliştirme süreçlerinde tasarım dokümanları, keşif ve uygulama sürecinde sürekli değişen ‘canlı belgeler’dir
- Ancak yapay zeka ajanları ilk şartnameye sabitleniyor ve esnek biçimde değiştirme ya da yeniden yorumlama yapamıyor
- Karmaşık yapılarla uğraşırken ajanlar problemin genel bağlamını kaybetme veya işi zorlayarak sürdürme eğilimi gösteriyor
- Sonuç olarak kod dışarıdan eksiksiz görünse de iç tutarlılık ve yapısal bütünlükten yoksun kalıyor
Kod kalitesinin çöküşü ve ‘vibecoding’in sınırları
- Yapay zekanın yazdığı kod parça parça bakıldığında çok iyi görünebiliyor, ancak bütünde anlamsız bir birleşime dönüşüyor
- Yazar, tüm kod tabanını inceledikten sonra içinde ‘saf dağınıklık (slop)’ bulunduğunu fark ediyor
- Yapay zeka promptlara ve kendi iç tutarlılığına sadık, ancak tüm sistemin uyumu ya da komşu kalıpların tutarlılığı konusunda dikkat göstermiyor
- Bu, tıpkı bazı paragrafları çok iyi ama bütün bölümü berbat olan bir ‘vibewriting’ durumuna benziyor
İnsan merkezli geliştirmeye dönüş
- Yazar, yapay zekanın ürettiği kodun ürün olarak dağıtılamayacağına veya kullanıcı verisini korumak için kullanılamayacağına karar veriyor
- “Bu kodla kullanıcıya yalan söylemeyeceğim” kararıyla birlikte yeniden doğrudan kod yazmaya dönüyor
- Kodu doğrudan yazdığında hız, doğruluk, yaratıcılık ve üretkenliğin aksine arttığını hissediyor
- Değerlendirme yalnızca basit kod üretim hızına göre değil de genel geliştirme verimliliğine göre yapıldığında insanın üstünlüğü ortaya çıkıyor
Yapay zeka ile kodlamanın sürmesi ve dikkat edilmesi gerekenler
- Yazar, bazı işlerde LLM’leri sınırlı ölçüde kullanmaya devam ediyor (yaklaşık %40)
- Tekrarlayan işler veya basit kod üretimi için faydalı, ancak teknik borç ve kodu anlama düzeyindeki düşüş zamanla birikiyor
- Uzun vadede geliştiricinin kod tabanına dair zihinsel modeli kaybetmesi ve yapay zeka olmadan sorun çözemeyecek hâle gelmesi riski var
- Hareket hâlindeyken (tren, uçak vb.) yapay zeka bağımlılığı nedeniyle üretkenliğin %0’a düşmesi gibi durumlar da yaşanabiliyor
- Diğer geliştiriciler, “‘Yeter ki şartnameyi iyi yaz’ anlayışı waterfall modelinin yeniden üretimidir; oysa gerçek geliştirme doğaçlama keşif ve etkileşim gerektirir” diye belirtiyor
Sonuç
- Yapay zeka ile kodlama hâlâ güçlü bir araç, ancak tüm sistemin bağlamını ve yapısal tutarlılığını koruma becerisi yetersiz
- İnsan geliştiricinin sezgisel yargısı ve doğaçlama ayarlama yeteneği hâlâ temel unsur olmaya devam ediyor ve
yapay zeka yalnızca yardımcı bir araç olarak, dikkatle kontrol edilen bir biçimde kullanılmalı
9 yorum
Vibe coding kavramı ortaya çıkalı henüz tam bir yıl bile olmamışken bu ne biçim SNS tarzı bir gösteriş havası yahu haha
Spesifikasyonu inceltmeye emek vermek gerekiyor.. Spesifikasyonu gerçekten yazılım mühendisliğinde öğrendiğimiz FM usulüne göre hazırlayıp iyice düzenledikten sonra, izlenebilirlik yönetimi yaparak güncelleyip çalışmak iyi olur.
Proje yaparken şartname şablonunu ve prompt sürümünü hep yükseltiyorum ama artık yavaş yavaş yazılım mühendisliğini gerçekten biraz daha derinlemesine çalışmam gerekip gerekmediğini düşünmeye başladım.
Yazarın hâlâ bazı işlerde LLM'leri sınırlı ölçüde kullandığı görülüyor (yaklaşık %40)
Yukarıdaki ifadeye bakılırsa, yazarın da AI'yi tamamen bırakmak gerektiğini savunmadığı anlaşılıyor.
Bunu iyi kullanmanın yollarını düşünmeye devam etmemiz gerekiyor gibi görünüyor. Yapay zekayı bırakıp geliştirme yapmanın, adım adım geride kalmak anlamına geldiğini düşünüyorum.
Bu yazının yazarı zaten onu iyi kullanmanın bir yolunu kullanmıştı ama buna rağmen yapay zekayı daha iyi kullanma yönünde düşünmek gerektiğini düşünüyorum.
(Sadece hâlâ çok fazla deneme-yanılma var...)
Şartnameyi güncelleyin
Doğru. Hook ekleyip uygulama tamamlandığında spesifikasyonu güncelleyebiliriz; olmasa bile spesifikasyonu elle güncelleyen bir command ya da skill ekleyebiliriz, haha
Ah, yaşlanmak istemiyorum.
Hacker News yorumları
Bana göre AI'nın temel şeyleri fazla iyi yapması aslında tehlikeli
Öğrenciler “AI benim yerime yapıyor” deyip doğrudan kod yazmamaya başlıyor ve sonuçta ara adımları ya da zor kavramları bizzat öğrenemiyorlar
Bir CS öğretmeni olarak öğrencilere “makine değil, kodu bizzat sen yazmalısın” diye özellikle vurguluyorum
Forklift ile ağırlık kaldırmak kolaydır ama kas yapmaz
Öğrenme sürecindeki acı, gelişimin tam merkezindedir
Elbette iş hayatında çıktı daha önemlidir ama yine de üst düzey düşünebilen insanlara ihtiyaç var
Adayın teorik bilgisi kusursuzdu ama kendi yazdığı kodun nasıl çalıştığını hiç açıklayamadı
Sonunda “çoğunu GenAI yazdı” diye itiraf etti; ‘öğrenilen şey’ ile ‘bizzat yapılan şey’ arasındaki uçurum çok büyüktü
‘Kod nasıl yazılır’dan çok ‘kod nasıl çalışır’ı öğretmek daha önemli
Eskiden assembly ile doğrudan yazılan dönemler vardı ama bugün ondan daha değerli olan şey derleyicinin mantığını anlamak
Çoğu insan derleyici ya da OS'yi doğrudan yazmayacak olsa da, bu ilkeleri bilmek programlama dillerinin sınırlarını anlamaya yardımcı olur
Derleyiciler ilk çıktığında da aynı tartışma yaşandı ve sonunda daha yüksek soyutlama seviyelerine çıktık
Sadece basit implementasyon yapmak düşünceyi derinleştirmiyor
Implementasyonu AI'ya bırakırsanız sonunda ‘gözleri bağlı insanların birbirine yol göstermesi’ gibi bir durum oluyor
Kodu bizzat ele alıp düşünme süreci şart
“AI basit işleri iyi yapar ama büyük işleri daha da iyi yapar” sözüne katılmıyorum
Pratikte hep hayal kırıklığı yaratan sonuçlar aldım
Kod düzgün çalışmıyordu ya da sürekli tekrarlayan düzeltme talimatları gerekiyordu
Geri bildirim döngüsü zorsa, sonunda tek geri bildirim kaynağı yine siz oluyorsunuz ve o anda AI'nın sınırlarını sert biçimde hissediyorsunuz
Örneğin TaskManager yapısını ya da bellek sahipliği kurallarını net biçimde anlatırsam, testleri bile geçen kod üretiyor
Ryan Dahl gibi “artık kodu kendim yazmıyorum” diyenler var ama bu, tekrarlayan geri bildirimlerle adeta birlikte çalışır gibi cilalandığı için mümkün oluyor
AI'ya bir çocuk eğitir gibi yaklaşmak gerekiyor
Girdi, çıktı ve beklenen hataları açıkça yazıp tekrar tekrar deneyerek düzeltiyorum
Claude soru soruyor, araştırma yapıyor, hatta kod incelemesi bile yapıyor
Sanki yetkin bir junior geliştiriciye mentorluk veriyormuşum gibi hissettiriyor
Başta “vibe coding”i açık fikirle denedim ama zamanla şüpheci oldum
Tekrarlı ve net kodlarda iyi ama işin çekirdek iş mantığı için uygun değil
Claude çoğu zaman spesifikasyonu görmezden geliyor, aynı mantığı birden fazla kez tekrar ediyor ya da düzelttim deyip olduğu gibi bırakıyor
Modelin giderek köreldiği hissi de var
Artık sadece tasarım tartışmaları ya da debugging için kullanıyorum
AI'nın doldurduğu ‘sıkıcı kısımlar’ın çok olması, en başta kod yapısının yanlış kurulduğunu da gösterebilir
LLM bu noktada hâlâ faydalı
Zaten birçok geliştirici hazır bir tasarımı alıp sadece implementasyon yaptığı için, AI hızı artırabiliyor
“AI tasarım değişikliklerini yansıtamıyor” iddiasına katılmıyorum
Hatta bence “bu zaten insanın rolü”
Örneğin API yapısını değiştir dediğinizde, AI ilgili tüm parçaları bulup güncelleyebilir ve testleri de çalıştırabilir
Uygulama ayrıntılarına gereğinden fazla takılıyor ya da kavramsal doğrulamayı atlıyor
Yine de insanların yazdığı testler de çoğu zaman benzer, o yüzden anlaşılır buluyorum
Kodu doğrudan yazmayınca soyutlamadaki pürüzlü ve dengesiz kısımları hissedemiyorsunuz; bu da sonunda yapısal kalite kaybına yol açıyor
Koddaki olgunluğu belirleyen fark da bu
Ama asıl önemli olan, hangi işlerin gerçekten manuel müdahale gerektirdiğini ayırt edebilmek
Yine de verim almak için pahalı abonelikler (ör. Claude Max 200 dolar) gerekiyor
AI araçlarındaki ustalığı nesnel olarak değerlendirecek bir yönteme ihtiyaç olduğunu söylüyorlar
“2 yıldır vibe coding yapıyordum” sözü bana şüpheli geliyor
Karpathy bu terimi daha sadece 1 yıl önce ortaya attı (kaynak)
İlginç olan, GPT'nin kendisinin kullanacağı API'yi tasarlayıp o API'ye göre implementasyon yapması
Ama sonrasında modellerin kendini düzeltme/kopyalama ile ilgili konuşmaları engellemeye başladığı söyleniyor
Tam ajan tabanlı araçlar olmasa bile ChatGPT ya da Claude ile bu rahatça yapılabiliyor
artık araştırma aşamasından itibaren AI ile birlikte çalışarak iyi sonuç aldığını söylüyor
Öğrencilere hep “TV'de spor izlemek egzersiz yapmak değildir” diyorum
Vibe coding de aynı şekilde; kodu gerçekten kendi elinle yazınca gelen bir tatmin var
AI'nın ürettiği ‘yarı tamamlanmış kod’ sayesinde yeniden motivasyon buluyorum
Gerçek mühendislerin ‘vibe coding’i körü körüne yaptığından emin değilim
Ben daha çok konuşarak yontulan bir kod geliştirme tarzı kullanıyorum
Gereksinimleri ortaya koyuyor, AI ile birlikte tasarımı gözden geçiriyor ve yapıyı aşamalı olarak olgunlaştırıyorum
Bu süreç yavaş ama işbirliğini ve düşünce derinliğini koruyor
AI, çok büyük miktarda koddan öğrendiği için yeni fikirler öneriyor; ben de deneyimimle bunları ayarlıyorum
Sonunda AI bana genişletilmiş bir sürümüm gibi (me++) hissettiriyor
Henüz her şeyi tamamen bir ajana bırakmaya hazır değilim ama en üretken yöntem bu gibi görünüyor
Bana göre AI'nın yazdığı kod bölümleri çok iyi ama bütünü darmadağın bir roman gibi
Bölüm bölüm bakınca kusursuz ama genel bağlamda kafa karıştırıcı
Öyleyse 10 bin satırlık vibe-coded bir kod tabanının düzgün çalışmasını beklemek de fazla iyimser olur
İnsanın düşüncesi ve duygusu yansımadığında kullanıcı deneyimi de tutarlılığını kaybediyor ve bilişsel sürtünme ortaya çıkıyor
Tasarım net olduğunda LLM, boilerplate işleri patlayıcı biçimde hızlandırıyor
Ama tasarım hâlâ insanın işi
Projesine GitHub açık sürümü üzerinden bakılabiliyor
LLM'in ürettiği kodun parça parça çok iyi ama genel yapısının zayıf olduğunu kabul ediyorum
Ama kod tabanını anlayıp doğrudan incelerseniz bunu fazlasıyla telafi etmek mümkün
Vibe coding, prototip geliştirme için mükemmel
Hızlıca bir his edinip sonrasında refactor ederek büyütmek etkili bir yaklaşım
Yani yalnızca sonuca bakarak karar vermek, onlara göre asıl vibe coding