- Yazar, yapay zeka araçlarının kendisini daha hızlı hale getirmemesini en büyük neden olarak gösteriyor ve bu yüzden üretken yapay zeka kodlama araçlarını kullanmıyor
- Yapay zekanın ürettiği kodu incelemek ve anlamak için gereken sürenin, kodu doğrudan yazmaktan daha uzun sürebileceğini düşünüyor
- Kod kalitesi ve sorumluluğu hâlâ geliştiricinin kendisine ait olduğu için, yapay zeka kodunu incelemeden kullanmak riskli
- Yapay zekaya stajyer gibi bakılması gerektiği iddiasını eleştirerek, yapay zekanın öğrenemediğini ve hafıza kaybı olan bir stajyere benzediğini söylüyor
- Açık kaynak katkılarıyla yapay zeka kodu arasındaki farkı açıklarken, insanlarla etkileşimin yeni fikirler sunması nedeniyle değerli olduğunu vurguluyor
Giriş
- Birçok kişi bana üretken yapay zeka kodlama araçlarını kullanıp kullanmadığımı ve bu konuda ne düşündüğümü soruyor
- Bu yazıda, lehte ya da aleyhte tartışmalara girmeden yalnızca kişisel teknik deneyimimi toparlıyorum
- Yapay zekanın kod yazarken bana neden yardımcı olmadığını teknik açıdan açıklıyorum
Yapay zeka daha hızlı değil
- Üretken yapay zeka kodlama araçlarını kullansam da çalışma hızım artmıyor
- Yapay zeka kod yazsa bile kodun sorumluluğu bana ait, bu yüzden projeye eklemeden önce tüm kodu dikkatle inceleyip tamamen anlamam gerekiyor
- Kod inceleme, kod yazmak kadar zaman ve dikkat gerektiriyor; hatta sektörde "kodu okumak yazmaktan daha zordur" diye bir söz de var
- Yapay zekanın yazdığı koda bir "kara kutu" gibi güvenmek son derece sorumsuz bir tercih. Kodda hata çıkarsa hukuki ve maddi sorumluluk da programcıya ait
- Kalite düşüşü ve artan risk olmadan yapay zeka ile üretkenlik ya da gelir artışı sağlamak mümkün değil
Yapay zeka bir kaldıraç aracı değil
- Bazıları yapay zeka kodlama araçlarının verimliliği katladığını iddia ediyor, ancak bu bana göre öznel bir izlenimden ibaret
- Bazı kullanıcılar, yapay zekanın ürettiği kodu incelemeden ya da kısmen inceleyerek zaman kazanıyor; ama ben bu süreci atlayamadığım için bana faydası olmuyor
- Yeni bir dil ya da teknoloji öğrenirken yapay zeka kullanmanın verimli olduğu iddiasına da katılmıyorum. Yeni bir şey öğrenme sürecinin kendisi programlamanın keyfi
- Nitekim Rust, Go, TypeScript gibi farklı dilleri doğrudan kendim öğreniyorum ve bu deneyimi yapay zekaya devretmiyorum
- Çünkü tüm kodun sorumluluğu eninde sonunda bana ait
Yapay zeka kodu insan kodundan farklıdır
- Sık sık, "Açık kaynak katkıları da benim yazmadığım kod; peki neden yapay zeka koduna farklı davranıyorsun?" sorusuyla karşılaşıyorum
- Aslında açık kaynak PR'larını da zaman ayırıp titizlikle inceliyorum. Ama kullanıcılarla iş birliği, yeni fikirler ve motivasyon getiriyor
- Birden fazla yapay zeka ajanı çalıştırıp hata issue'larını çözen PR'lar almanın oyun değiştirici olduğu söyleniyor; ama sonuçta kod inceleme darboğazı insan olduğu için süreç aksine yavaşlıyor
- Yapay zeka araçları yaygınlaştıkça düşük kaliteli PR'lar sık üretilir oldu. Yapay zeka kodunda ince bir yabancılık hissi var ve PR'ı gönderen kişiye soru sorulduğunda çoğu zaman yanıt da gelmiyor
- Sorumlu kod katkısı ve açık kaynak topluluğuyla iletişim, insan kodunu ayıran önemli farklar
Yapay zeka ile stajyer arasındaki fark
- Yapay zekayı stajyere benzeten görüşler var ama bu ikisi temelden farklı
- Stajyerin ilk yazdığı kod çok inceleme ve zaman gerektirse de, geri bildirimle hızla gelişir
- Stajyerin gelişimine yapılan yatırım, sonunda bağımsızca sorumluluk verilebilecek önemli bir ekip arkadaşına dönüşür
- Yapay zeka araçları ise her yeni görevde bilgisini unutup yeniden başlar; gelişemez, deneyim biriktiremez
- Bu, hiç ilerleme kaydetmeyen bir stajyer gibidir ve üretkenlik artışına katkı sağlayamaz
Sonuç
- Bu yazıyla, üretken yapay zeka kodlama araçlarını kullanmanın teknik sorunlarını açık biçimde aktarmayı amaçlıyor
- Yapay zeka ile kodlamada "bedava öğle yemeği" diye bir şey yok
- Yapay zeka sayesinde hızlandıklarını veya daha üretken olduklarını söyleyenler, ya kalite standartlarını düşürüp ek risk alıyor ya da bu söylem yapay zeka satıcılarının çıkarına hizmet ediyor
- Programcıların her zaman nihai sorumlu kişi olduğunu unutmamak gerekiyor
5 yorum
copilot(claud) +codex(o3/4o/codex-mini 3 model eşzamanlı mcp) ile agent moduna tamamen yerleştim; ama bunu kullanan kişinin ve projenin karakterine göre etkisinin çok değiştiğini düşünüyorum.Ben aynı anda 5-6 workspace’te iş başlatıp tamamlanma sırasına göre kontrol ediyorum; model açık kaynak kodun içlerine kadar girip doğrulama yapan işleri tamamen üstlenebildiği için bunun epey iyi olduğunu düşünüyorum. Öğle arasında işleri başlatınca bir iki tanesi bitmiş oluyor. Bazen gece boyunca sürdüğü de oluyor ama
copilot rate limitdenen şey kara kutu olduğu için...Yüksek performanslı kernel ya da tüm call stack’i sadeleştirme, readability sağlama gibi insanlar için bağlam değişimi çok olduğu için zaman alan görevleri de prompt’u ve hedefi iyi verirsen yapabiliyor (insandan daha fazla kodu belleğinde tutabildiği için); böyle kodlarda patch review yapmak da kolay oluyor... Ayrıca API kullanım hataları ya da açık kaynak projenin kendi bug’ları nedeniyle oluşan arızaları yaşamış olanlar için, Agent’a bunu net şekilde doğrulatmak ruh sağlığı açısından da iyi geliyor...
Yine de sonuçta, bunu kullanan geliştiricinin patch’i anlayabiliyor olması gerekiyor. Bir de prompt vermeyi bilmesi lazım tabii. Deneyimle öğrenip problemi hızlıca formüle edip ortaya koyabilmeniz gerekiyor ki her şey oradan başlayabilsin. Nasıl ki formül olmadan yüksek performanslı kernel geliştirmek mümkün değilse. Sorunun chip/os seviyesinde mi, application seviyesinde mi, yoksa remote resource kaynaklı mı olduğunu sezmek hâlâ senior’ların rolü gibi görünüyor.
Copilot, ChatGPT türleri, Cursor vb. araçları bir ölçüde kullanmış biri olarak, bunların geliştirme araçlarında şablon ya da snippet düzeyindeki roller için oldukça uygun olduğunu düşünüyorum; ancak agent ya da iş arkadaşı seviyesinde değiller.
cursorkullanıyorum.chat modunda agent yerine ask’i tercih ediyorum; çünkü yine gözden geçirdikten sonra kendi koduma uygulanmasını istiyorum ve genel olarak ana metindeki bu tür dezavantajlara katılıyorum.
Buna rağmen üretken yapay zekayı kullanmaya devam edeceğim; çünkü benim düşünmediğim fikirler ya da kodlar ürettiği durumlar da çok oluyor, bu yüzden referans amaçlı olarak yeterince değerli olduğunu düşünüyorum.
Kişisel deneyimime göre, üretken kodlama araçlarını kullanma konusunda hissettiklerim de buna benzer.
Hacker News görüşleri
Bazı insanlar her yeni dil veya teknolojiyi öğrenirken merak ettikleri şeylerle karşılaşıyor; eskiden Google'da arama yapar ya da Stack Overflow'a soru yazıp yanıt beklerlerdi. Şimdi ise doğrudan ChatGPT veya Gemini'ye sorup çok daha hızlı yanıt alabiliyorlar, bu da üretkenliği ciddi biçimde artırıyor. Yalnızca sorulara hızlı yanıt almanın bile öğrenme sürecini hızlandırdığını vurgulamak istiyorum.
ChatGPT ve Gemini'nin doğru yanıtlar verebilmesinin nedeni, Stack Overflow dahil web'de zaten var olan bilgileri öğrenmiş olmaları. Herkes sadece AI kullanarak soru sorarsa, sonunda güvenilir açık bilgi kaynakları tükenebilir. Bu, bilgiyi yüksek maliyetle toplayıp satan ansiklopedi döneminin geri dönüşüne benziyor. Ayrıca yazarın eleştirdiği şeyin, soruları yanıtlayan araçlar değil, doğrudan kod yazan AI kodlama araçları olduğunu ayırarak anlatmak gerekir.
Bir zamanlar aşina olmadığım bir API'yi kullanırken program çöküyordu. Stack trace'i Gemini'ye verdim ve anında nedenine dair bir ipucu aldım; sadece iki satırı değiştirerek sorunu çözdüm. Sırf bu deneyim bile AI'nin değerini hissettirmeye yeter. Aşina olmadığınız bir alanda basit hatalar yüzünden uzun süre debelenmek zorunda kalmamak büyük avantaj.
Arama giderek blog spam'ini öne çıkarıyor; bunun yerine iyi hazırlanmış resmî dokümanlardan veya kullanıcı kılavuzlarından temelden öğrenmek daha eğitici. İyi API dokümanları okurken genel tasarımı ve ek özellikleri de doğal olarak öğreniyorsunuz. Blog örnekleri veya eğitimler anlık sorunu çözse de gerçek beceri gelişimine yardım etmiyor. Bir bakıma sadece ödevi sizin yerinize yapmış oluyor; bu yüzden ChatGPT'nin gerçek öz-öğrenmeyi teşvik ettiğini düşünmüyorum.
Zor problemlerde AI çıktısını mutlaka doğrulamak gerekir. AI otomatik tamamlama özelliğini kapatma nedenim de pratikte verim kazancının büyük olmaması ve gereksiz düzeltmelerin fazla olmasıydı. İlginç şekilde tamamen çevrimdışı yerel modellerle bile oldukça iyi başvuru materyali elde edilebiliyor. Google'ın yerleşik Gemini sonuçlarının da kalitesi pek iyi değil. Benim asıl kaygım, insanlar bilgiyi sadece AI üzerinden edinirse Stack Overflow gibi gerçek bilgi depolarının yok olabilmesi.
Küçük boilerplate araçlarda AI mükemmel. Tarayıcı uzantıları veya Tampermonkey script'leri gibi basit şeylerde neredeyse hiç dokümantasyona bakmadan hemen işe başlanabiliyor. Karmaşık olmayan kod otomatik tamamlama veya ufak düzeltmeler için de AI oldukça kullanışlı. Normalde başlamayacağım kadar küçük projeleri bile hızlıca halledebiliyorum.
Kodu bizzat yazmanın potansiyel faydası, problem için beyninizde güçlü bir mental model bırakmasıdır. Sonradan sorun çözme veya yeni özellik entegrasyonu sırasında bu “bilinçdışı” öğrenme etkisi çok büyük rol oynar. Gerçek beceri ancak kendi elinizle yapmış olmanın birikimiyle gelişir. Gördüğüm organizasyonlarda LLM devreye girdikten sonra bile üretkenlikte gerçek bir katlanma yaşanmadı. Belki de insanlar yalnızca daha az zihinsel çaba harcayıp kolay yolu seçmeyi üretkenlik sanıyor.
İnsanların daha az zihinsel enerjiyle sorun çözmeye alışıp bunu üretkenlik sanmaları durumunu çok iyi özetlediğini düşünüyorum. Google Research'ün 2024'te LLM üretkenlik etkisi üzerine yaptığı deneyde, kitapla öğrenen gruba kıyasla LLM kullanan grup aslında daha uzun süre harcadı; puan artışı da yalnızca konuya hakim olmayan acemilerde biraz görüldü. Buna rağmen birçok katılımcı kendini daha hızlı ve daha doğru sanıyordu; araştırmacılar bunu “bilişsel yükün azalması” ile açıkladı. İlgili makale bağlantısı https://storage.googleapis.com/gweb-research2023-media/pubtools/7713.pdf
Daha az zihinsel enerji kullanıp daha uzun süre çalışabiliyorsanız, gerçekte daha fazla iş hacmi kaldıramaz mısınız? Şu anda bile yüksek zorluktaki işlerde sınır 3-4 saat. Maratonu yürüyüş temposunda koşabiliyorsanız, toplam çıktı sonuçta artabilir diye bakan bir görüş de var.
Geleneksel kodlama ile AI kodlamanın ayrı beceriler olduğu kısmına katılıyorum. Ben de AI'nin kodlamanın yerini alacağı iddiasına oldukça şüpheyle bakıyorum. Ama prompt yönetimi veya bağlamı koruma gibi “AI kodlama”nın kendisinde de ciddi bir öğrenme eğrisi olduğunu ve birçok kişinin bunun değerini küçümsediğini düşünüyorum. Tıpkı el çizimiyle fotoğraf çekmenin farklı amaçlara hizmet etmesi gibi, burada da amaçlar farklı olabilir. Benim tercih ettiğim model, “zor işleri AI yapsın, genel tasarım ve orkestrasyonu ben üstleneyim” şeklinde.
LLM tabanlı kodlama, basit otomatik tamamlamanın ötesinde; iş tanımı-verilen geri bildirim-tekrar döngüsüyle ilerleyen bir dış kaynak kullanımı deneyimine benziyor. Fark, işlem hızı açısından LLM'nin, güvenilirlik açısından insanın üstün olması; ama uzun vadede bu sınır da giderek silikleşecek gibi. Ben özünde işin ayrıntılarıyla doğrudan uğraşmak isteyen biriyim. Altyapıyı ve programlamayı öğrenip derinine inmeyi sevdiğim için bu mesleğe başladım. Bu yüzden yönetici rolünden kaçınıyor, daha az kazansam bile doğrudan bir şeyler üretmeyi tercih ediyorum. AGI bir iş arkadaşı düzeyine gelirse belki o zaman yeniden ilgilenirim. “AI” adının kendisi de ileride o kadar özel görülmeyebilir.
AI kodlamanın öğrenme eğrisi düşünüldüğünden büyük olsa bile, yıllar süren piyano çalışmasına benzemez. Bugün var olan en yetkin AI kodlayıcıların bile en fazla 3 yıllık deneyimi var ve modeller sürekli değiştiği için geçmiş deneyimin önemli kısmı mevcut nesil modellere tam uymuyor. Ustadan öğrenme yapısının olmaması da ayrı bir sınır.
AI kodlama becerisi uzun vadede gerçekten değerli mi? Bugünkü AI araçlarının beceri setlerinin gelecek nesillere ne kadar aktarılabileceği konusunda şüpheliyim. Şu an verim artıyor olsa bile, model ve araçlar değişince bunun işe yaramaz hale gelme ihtimali akılda tutulmalı.
AI kodlama becerisi için birkaç dakika ya da en fazla bir saat yeterli diye düşünüyorum. Mecazi olarak GDB veya UNIX gibi kitap kitap derinleşilecek bir alan değil. Resim ve fotoğrafın temel ilkeleri ve hedefleri tamamen farklı olduğu için karıştırılmaması gibi, AI kodlama da mevcut kodlamadan tamamen farklı bir etkinlik.
Doğrudan kod yazmayı tercih etmenin tek nedeninin AI kodlamada yetersiz olmak olduğu yönündeki özgüvene katılmıyorum. Şimdiye kadar kullandığım düşük ücretli denemeler ve free trial'ların ROI'siyle bile karar vermek mümkün.
Uygulamada, AI kod incelemesi veya çıktı doğrulaması yapmak yerine AI'nin ürettiği kodu olduğu gibi PR'a koyup inceleme yükünü başkalarına atan bir kültür oluşuyor. Böyle durumlarda GenAI'nin gerçekten faydalı olmasından çok, işi başkasına itelemek için kullanılmasının yan etkisi daha büyük.
Ben de bunu yaşadım. Yönetici yeterince yetkin değilse, kimin gerçekten değer ürettiğini ayırt edemiyor. Ben kodlama ajanlarından gerçekten büyük değer alıyorum ama yetkin olmayan organizasyonların özensiz çıktıları ödüllendiren yapısı ciddi bir sorun.
Eğer birinin açtığı PR'lar sürekli AI çıktısını olduğu gibi içeriyorsa, geri bildirim biriktirilip ekip liderinin mutlaka bu konuya itiraz etmesi gerekir diye düşünüyorum.
Claude Code'u sık kullanan biri olarak, başkasının yazdığı kodu incelemenin, doğrudan kendiniz yazmaktan neredeyse zaman farkı olmaması iddiasına %100 katılıyorum. LLM'ler belli ölçüde işe yarıyor ama kontrolü ne kadar çok bırakırsanız, gerçek release'e ulaşmak o kadar uzun sürüyor. RSI belirtilerini hafifletmede faydalı oldu ama zaman kazancı etkisi çoğu zaman sanıldığından abartılı.
“Kodu illa incelemek zorunda mıyız?” sorusuna karşılık, ben genelde AI çıktısını noktasal olarak gözden geçiriyorum; spec dokümanını AI'ye yazdırıp son inceleme ve testleri ise kendim dikkatle yapıyorum. Aslında çoğu open source kütüphanenin kodunu da en baştan satır satır incelemiyoruz.
Burada “kendi yazdığım kodun farklı bir gözle ayrıca incelenmesine gerek yok” varsayımı var. Oysa gelecekteki ben de o kodun potansiyel bir okuyucusu. AI kodlama bu zihniyeti dayatıyor: net kabul kriterleri koymak, testler ve tutarlı kurallarla doğrulamak. Sonuçta daha sağlam ve iz bırakabilen bir geliştirme kültürünü teşvik ediyor.
Claude Code ile bug ayıklamada, “önce testi yazarsanız”, AI'nin dakikalar içinde düzeltme yapması sıradan hale geliyor. Yeni arama özelliği geldikten sonra karmaşık işler bile 5 dakikada çözülebiliyor; bu noktadaki zaman tasarrufu bana göre çok net hissediliyor.
RSI belirtilerini hafifletmek için kolları sürekli sıcak tutma yöntemi de tavsiye ediliyor.
“Her şeyi konuşmalı arayüz üzerinden yapmak istemiyorum; hibrit UI benimseyen örnekler var mı?” diye merak eden de var.
Generative AI kodlama araçları işin kolay kısımlarını hızlandırıyor ama zor kısımlarını daha da zorlaştırıyor. Aslında kod yazmanın kendisine giden süre o kadar büyük değil; dolayısıyla sadece o kısmı 100 kat hızlandırsanız bile toplam üretkenlik çok değişmiyor. Bu yüzden özellikle bunun için zaman harcamak istemiyorum.
Belirli bir stack'i ve problem alanını zaten avucunun içi gibi bilen bir mühendisin hiçbir araca ihtiyacı olmayabilir; öğrenmesine de gerek yoktur. Ama bu mantık pratikte çok anlamlı değil. Sonuçta araç seçimi kişisel optimizasyon meselesi.
Ben AI'ye algoritma yazdırıyorum, kodun nedenini açıklatıyorum, API çağrıları yaptırıyorum, belirli bir fonksiyonu uygulatıyorum. Tam bir uçtan uca kod değil belki ama debugger ile birlikte kullanma sıklığım giderek artıyor.
“Yoksa tesisatçı mısın?” diye esprili bir soru da var.
Yazarın “kodu doğrudan yazmak kadar, başkasının yazdığı kodu incelemek de aynı ölçüde ya da daha fazla zaman alabilir” sözüne, security audit gibi detaylı kod inceleme deneyimi olan biri olarak ben de katılıyorum. Ama AI çok basit rutin işlerde uzmanlaşırsa, kodu tek tek ayrıntılı incelemeye gerek kalmadan eBPF verifier benzeri kapsayıcı bir doğrulama yeterli olabilir. Fazla karmaşık sorun varsa PR'ı doğrudan reddederim. Basit tekrar eden kodlarda insanın titiz manuel incelemesine daha az ihtiyaç olabilir.
Yine de bunun gerçekten verimli olup olmadığı şüpheli. Onlarca PR açıp yalnızca birini geçirecekseniz, bir iş arkadaşının kodu çok daha güven verici olur. Zaman, para ve çevresel kaynak israfı üreten bir yapı pek sağlıklı görünmüyor.
Eğer gerçekten “tekrarlı Go fonksiyonu” ise, o kodu yazmanın zaten ne kadar anlamlı olduğu da tartışılır. Verimsiz ve yeniden kullanılabilirliği düşük bir kod için, sıradan bir kütüphaneden bir iki satırla çözülebilecek işi AI ile üretmenin anlamını görmüyorum.
Kodu okuma hızı yazma hızından yüksek olanlar için GenAI faydalı; tersine yazmak daha hızlı geliyorsa çok da ihtiyaç yok.
AI'nin yazdığı kodun neden insanın yazdığı koddan farklı biçimde incelenmesi gerektiği de sorgulanıyor.
Tekrarlı ve basit işler için IDE şablon bağlama ve değişken otomatik tamamlama özelliklerinin de yeterince iyi çalıştığı, üstelik bunun ücretsiz olduğu vurgulanıyor.
Stajyer ile AI kodlama yardımcıları karşılaştırmasında, stajyerin gerçek kodu, işi ve sistem geçmişini öğrendiği; AI'ye ise bağlamın tekrar tekrar anlatılması gerektiği belirtiliyor. Bu sınır hâlâ sürüyor.
Önemli bağlamı
mdcdosyalarına koyarsanız, sonraki sorumlu kişi de bunlardan yararlanabilir; hatta bu, dokümantasyon ve bilginin sürekliliğini güçlendirir diyen bir görüş de var.Bazı LLM'lerde sistem prompt'unun 14k uzunluğa çıkmasının nedeni de bu tarz şeyler oluyor.
Stajyerler gerçekten CARE ediyor olabilir.
Önemli iş bağlamını doğrudan sistem prompt'una koymak da mümkün.
Bugünkü AI modelleri özünde mevcut veri kalıplarını öğreniyor. Yaptıkları şey, başarılı örnek şablonlarını birleştirmek; temelden yeni bir çözüm üretmeye yönelen bir yapı değil. Bir sorun gördüklerinde, ilk ilkelerden hareket etmek yerine en benzer deneyimden cevabı bulmaya çalışıyorlar. İnsan uzmanlar First-principles, yani AI'nin zorlandığı temel ilkelerden mantıksal yaklaşım konusunda daha yetkin. AI benzerliği öncelediği için kalıplaşmış çözümler üretiyor; özellikle yenilik gerektiren alanlarda veya yerleşik pratiklerin işlemediği problemler karşısında sınırları belirginleşiyor. Context poisoning'e insanlar çok daha verimli tepki verebiliyor.
Ben AI'nin kod üretme tarafında çok büyük beklenti içinde değilim ama tekrarlı ve sıkıcı boilerplate işlerde AI N kat daha hızlı; hissiyat düzeyinde gerçekten çok büyük fark var. Somut bir örnek vereyim: ChatGPT'ye React Context tabanlı modal yapısı örneği istedim, hook'lar, provider ve ilgili yapıyı hemen çıkardı. Anında yaklaşık 30 dakika kazandırdı; bu tür tekrarlı işler için aylık 20 dolar kesinlikle boşa gitmiyor.
Böyle durumlarda çoğu zaman kütüphane dokümanlarındaki örneklerden alıp kullanmak da mümkün ve 5 dakikada en gerekli temel uygulamayı kendiniz de yazabilirsiniz. Ama üretken kod genelde mevcut duruma uyarlanmış bütüncül bir çözüm sunduğu için, sonrasında kademeli mimari iyileştirme ve refactoring aşamalarında rahatsız edici olabiliyor.
Ben de AI'yi çoğunlukla boilerplate veya ad-hoc script'ler için kullanıyorum. Karmaşık gerçek problemleri hâlâ tamamen AI'ye bırakmak zor. Özellikle sisteme derinlemesine inen sorunları insanın kendisinin ele alması gerekiyor ve bu süreçte edinilen içgörü önemli. Proje büyüdükçe ve birleşik unsur sayısı arttıkça AI'nin sınırlarının daha görünür hale geldiğini hissediyorum.