- Yapay zeka kodlama ajanları kod yazma hızını dramatik biçimde artırıyor, ancak geliştirme sürecinde en önemli kısım hâlâ anlama ve problem çözme olmaya devam ediyor
- LLM kullanarak hızlıca kod üretmek mümkün, ancak genel bağlamı yeterince kavrayamaması nedeniyle son işlem çalışmaları ve anlama için daha fazla zaman harcanıyor
- Bu da üretkenliğe dair beklenti ile gerçek verimlilik arasında bir fark yaratıyor ve geliştiricilerin istediği yaratıcı işler yerine test, refaktöring, dokümantasyon gibi tekrarlı ve yorucu işlere zaman harcamasına yol açıyor
- Geçmişteki 'tech lead ikilemi' gibi, kısa vadeli sonuçlar için karmaşık işleri yapay zekaya veya kıdemli çalışanlara yığmak uzun vadede ekip yetkinliğinin düşmesine ve krize neden olabiliyor
- LLM'leri güçlü bir junior mühendis olarak görmek ve doğrulanmış geliştirme süreçlerini yapay zeka ile iş birliğine uygulamak suretiyle sürdürülebilir yazılım teslimi yapısı kurulmalı
Sorunun tanımı: Kodlamanın kendisinden daha önemli olan şey
- Yazılım geliştirme, problem çözme odaklı bir iştir
- Gerçek kodlama, geliştiricinin tüm düşünce ve analizinin yalnızca son kısmına karşılık gelir
- Geliştirici, kodun dışında da alanı anlama, gereksinimleri ayrıştırma, soyutlama, yan etkileri değerlendirme, kademeli test, hata düzeltme gibi çeşitli işler yapar
- Geleneksel geliştirme akışı: yeterince düşünüp sonra kod yazmak
- Yapay zeka ile kodlama çağında ise desen önce kod, sonra anlama yönüne kayıyor
Yapay zeka ile kodlamadaki dönüşüm: Önce kodun üretildiği paradigma
- Claude Code gibi yapay zeka kodlama ajanları kodu hızlı üretse de tüm sistem bağlamını tam olarak kavrayamaz
- İnsanın inceleme, test ve entegrasyon süreci zorunludur; ayrıca yapay zekanın yazdığı kodu sonradan anlamak da çok zaman alır
- Pazarlamada kodlama hızındaki artış öne çıkarılsa da, gerçekte çalışan yazılım teslimi üretkenliğindeki artış sınırlıdır
- Geliştiriciler, yapay zekanın ürettiği çıktıların test edilmesi, tekrarların ayıklanması, dokümantasyonu, altyapı yönetimi gibi tekrarlı ve zor işlere daha fazla zaman ayırır
- Gerçek kodlama keyfi azalır, tekrarlı işler ise artar
Teknik liderlerin eski ikilemi
- Bir mühendis tech lead rolünü üstlendiğinde ekibin teknik teslim sorumluluğunu da taşır
- Ekip içindeki deneyimin tek kişide toplanması üretkenlik dengesizliği yaratır
- Adil dağıtım (ekip üyelerinin gelişimini öncelemek) ile işleri belli kişilere yığma (hızlı geliştirmeye odaklanmak) arasında çatışma vardır
- Yığma yaklaşımı kısa vadede büyük kazanç sağlasa da, deneyimin tek elde toplanması nedeniyle ekibin uzun vadeli risklerini artırır (dayanak kişinin olmaması, tükenmişlik, destek vermenin zorlaşması)
- Sağlıklı bir ekip kültürü için gelişim ile verimlilik arasında denge kurmanın yolu gerekir
İyi liderliğin özü: Süreç ve büyüme arasındaki denge
- Deneyimli mühendislerin bilgi birikiminin tüm ekip tarafından öğrenilmesi için çeşitli geliştirme ilkeleri ve framework'lerin uygulanması gerekir
- Örnekler: Extreme Programming, code review, kademeli dağıtım, modüler tasarım, test güdümlü geliştirme, pair programming, dokümantasyon, continuous integration
- Nihai hedef: yeniden çalışmayı en aza indirmek, iş birliğini en üst düzeye çıkarmak, bireysel gelişimi teşvik etmek
Yapay zeka ajanlarıyla iş birliği: Yeni ekip lideri rolü
- En yeni LLM tabanlı kodlama ajanları, inanılmaz hızlı bir junior geliştiriciye benzer
- Mevcut junior'ların aksine, LLM'lerin öğrenme yeteneğinin olmaması ve hız sınırının bulunmaması gibi belirgin farkları vardır
- Yapay zeka kaliteyi artırmaktan çok sürekli hızı artırmaya odaklanır; insanın bağlam ve alan bilgisini ise yetersiz kavrar
- İki iş birliği deseni vardır:
- Yapay zeka destekli mühendislik: daha yavaş olsa da verimli ve sürdürülebilir ekip çalışmasını hedefler
- Vibe coding: hızlı sonuç üretmeye odaklanır, ancak zamanla geri döndürülemez bir karmaşa biriktirir
- Bu, Silikon Vadisi'ndeki kod büyümesinin geleneksel kör noktasına benzer: kısa vadeli kazançların ardından büyüme sınırına çarpılır
Yapay zeka ile kodlama tuzağında hayatta kalmanın pratik yolu
- LLM'ler kendi bağlamlarını bilmeden rastgele biçimde kod üretir
- Mühendisler, yapay zekaya net yapı, standartlar ve süreçler sunarak ham çıktıyı gerçek bir hizmete dönüştürmelidir
- Geleneksel geliştirme döngüsündeki best practice'leri, yapay zeka ile iş birliği ortamına sıkı biçimde uygulayan yeni bir playbook gerekir
- Aşamalara göre başlıca yapay zeka kullanım yöntemleri:
- Spesifikasyon tanımı: edge case analizi, hedef kapsamına odaklanma
- Dokümantasyon: tekrar kullanılabilir kılavuzlar ve kanıtlar oluşturma
- Modül tasarımı: bağlamı sınırlayarak kavrayışı artırma
- Test güdümlü geliştirme: uygulamadan önce test case üretimi, regresyonu önleme
- Kodlama standartları: stil ve kaliteyi koruma
- İzleme: log'ların otomatik analizi ve içgörü çıkarımı
Sonuç
- Yazılım teslimi, yalnızca kod yazmakla gerçekleşmez; yapay zeka ile insan arasında verimli bir iş birliği yapısının kurulması şarttır
- LLM'leri ultra hızlı junior geliştiriciler olarak görmek ve doğrulanmış geliştirme süreçlerini uygulamak, ölçeklenebilir ve yüksek kaliteli yazılım sunmayı mümkün kılar
2 yorum
Hacker News görüşü
Sadece “teknoloji insanı tembelleştirir” iddiasına dayanmayan anti-AI argümanları görmek istiyorum. Ciddi biçimde LLM ile kod üretmeyi denemiş olan herkes, planlama-kurgulama-test-etme-geriye dönük değerlendirme döngüsünün hâlâ çok önemli olduğunu hisseder. Dikkatsizce öylesine çalıştırırsan hemen bozulmaya çok müsaittir. Bu döngüyü iyi uygularsam, sevdiğim mimari tasarım ve sonuç deneyimini test etmeye çok zaman ayırabiliyorum. LLM kolay kısımları hızlıca hallettiği için, sonunda geriye bizim yapmamız gereken daha az ilginç ve daha az takdir gören işler kalıyor. AI’ın uzmanlığı parlatan alanlarında, işin kendisinden keyif alanlarla düşünme deneyiminden keyif alanlar arasındaki görüş farkı çok belirginleşiyor. Düşünmeyi sevenler, AI sayesinde neredeyse tamamen o alana odaklanabiliyor. Buna karşılık, bizzat yazmayı ve elle müdahale etmeyi seven biri için AI, sevdiği kısmı elinden alıyor
AI kod üretimiyle ilgili olarak, teknolojinin insanı tembelleştirmesi fikrinden ziyade, AI’ın ürettiği koda dair derin anlayışı elimizden alması daha önemli bir eleştiri bence. Yazılım mühendisinin özü kod üretmek değil, bütün sistemi tasarlamaktır. Burada önemli olan, kodun nasıl çalıştığına dair düşünce modeli (mental model) ve alan uzmanlığıdır; kod ise bu zihinsel modelden türeyen bir çıktıdır. Belirli bir ölçeğin üzerindeki projelerde, kodu bizzat yazan kişi değilsen o kodu tam olarak bilmek zordur. Bu zihinsel modeli kurmazsan başka sorunlar da peşinden gelir. LLM tabanlı kodlama ajanları sözdizimi düzeyindeki akıl yürütmede sınırlara sahip olduğu için ölçeklenebilirlikte zayıflık gösteriyor
Kendi fikrimi söyleyecek olursam, bazen Cline gibi AI araçları kullanıyorum ama giderek doğrudan yazarak kodlama oranım artıyor. Sebebi, çoğu durumda bunun kodlamayı sadece prompt yazımıyla değiştirmesi. Prompt yazma ve akıl yürütme süresi, benim ellerimle doğrudan kod yazma süremden kısaysa AI kullanıyorum; ama bu genelde sadece refactoring gibi hız sınırına geldiğim durumlarda geçerli oluyor. Çoğu işte kendim yapsam 10 dakika, AI ile yapsam prompt yazıp çalıştırıp 8 dakika sürüyor. Hatasız ve düzgün olursa 2 dakika kazanıyorum, ama düzeltme ya da yeniden prompt gerekirse bu kez 10-12 dakika sürüyor; bir de AI kredisi harcanmış oluyor, yani en kötü senaryo. Bu hesabı yaptıkça, hem kod kalitesi hem de harcanan süre açısından el yordamıyla yapmanın daha güvenli olduğu sonucuna varıyorum
Teknolojinin insanı dikkatsizleştirdiği iddiası hakkında, genel olarak teknoloji çoğu zaman insanı daha dikkatli de yapar. Sorun, bu AI teknolojisinin kullanıcıyı dikkatsizliğe itme ihtimalinin yüksek olması. Benim ilgim kodlamanın eğlenceli kısımları değil; ben tasarımın (mimari) kendisini daha çok tercih ediyorum. Eğer niyeti doğrudan koda yansıtabilseydim o yöntemi kullanırdım. Ama chatbot arayüzü niyeti dolaylı ve eksik biçimde aktarıyor; bu yüzden yüksek seviyeli kod üretiminde kullanınca, kafamdaki model ile gerçek kod anlayışım hızla birbirinden uzaklaşıyor ve geride kırılgan bir temel bırakıyor. Elbette satır satır titizlikle inceleyebilirim ama bu da aracın amacına ters. AI ile kodlama, “10 kat hızlı” hissi yüzünden ayrıntılı uygulama ile makro düzeyde anlama arasındaki kopukluğu teşvik ediyor. Aslında yapısal kısımları daha az düşünmek, AI kodlamanın pazarlanan başlıca faydalarından biri; fakat bu anlayış boşluğu sonra sorun çıkarıyor. İyi otomasyon güvenilir ve öngörülebilirdir; üst seviye değişmezleri anlamak yeterlidir. Ama chatbot kodu bu güvenceleri vermez ve sonunda her şeyi elle doğrulamak zorunda bırakan bir yapı oluşturur. Burada güvenlik ve güvenilirlik tersine daha da zor hale geliyor
“Düşünen kısma odaklan” mantığını o kadar sık gördüm ki artık bayat geliyor. Sorun şu: Yıllarca fiilen işin içinde bulunmamış birinin sadece düşünerek derinlikli bir faaliyet yürütebileceğinden şüpheliyim. Sonuçta, bizzat yapma deneyimi olmadan düşünmenin kendisi bile giderek yüzeyselleşme riski taşıyor
Benim görüşüm şu: Debug etmek, yazmaktan daha zor; dolayısıyla benim yazmadığım kodu debug edeceğime kendim yazmam daha iyi
Bu tür tartışmaları okurken her seferinde aklıma gelen şey, yazarın acaba benimle aynı araçları mı kullandığı oluyor. Ben Claude Code ile basit boilerplate’ten karmaşık algoritmalara kadar, son derece kafa karıştırıcı büyük codebase’lerde bile neredeyse her şeyi üretebiliyorum. Elbette %100 doğru değil ama çok yaklaşıyor. Üstelik bazen benim düşünmediğim algoritmaları da öneriyor. Bu araçlar bana en az 10 kat zaman kazandırıyor
Bu yazı fena değil ama iki yanılsama görüyorum. Birincisi, deneyimli bir geliştirici LLM kullandığında bile yeterli araştırma, ön düşünme ve tasarım hâlâ zorunlu. Hatta LLM’i düzgün kullanmak için normalden daha çok düşünüyor, farklı tasarım seçeneklerini karşılaştırıyor ve bütün yapıyı çiziyorum. Eskiden bu süreci belgelemezdim ama artık tasarım dokümanı olarak bırakıyorum. İkincisi ise LLM’in gelişmeyen junior geliştiriciye benzediği iddiası; ikisi tamamen farklı. İnsan bir junior geliştirici bir insandır, LLM ise bir araç. Önemli noktanın, junior ile çalışınca birikimli değer oluştuğu ama LLM ile oluşmadığı söylense de, bunun da doğru olmadığını düşünüyorum. LLM öğrenmese bile ben onu çok daha verimli biçimde ehlileştiriyor ve daha iyi kullanmayı öğreniyorum. Üründe LLM’i iyi uygulamanın daha çok başındayız; dolayısıyla doğal olarak bileşik bir büyüme değeri görülüyor
“LLM öğrenmese bile ben öğreniyorum” fikrine katılıyorum ama yine de LLM’in kullanıcıyla etkileşimden gerçekten öğrenmesini isterdim. Benim istediğim, oturum içeriğini dosyaya kaydedip/yükleyebilmek ve LLM’in daha önce öğrendiği bütün bağlamı eksiksiz şekilde kavraması. Bazı frontend UI’larda oturumu kaydetme/geri yükleme var ama önemli nokta şu: a) bu tür bir “yeniden öğrenme” LLM’in mevcut context window’unu etkilememeli (hatta mümkünse bu kavram tamamen ortadan kalkmalı), b) kesinlikle kayıpsız olmalı. Özetleyip devam etme, RAG gibi yöntemler zaten var ama bunların hepsinde bilgi kaybı ya da ancak mevcut etkileşim tetiklenirse geri yüklenebilme gibi temel sınırlamalar var. Örneğin, dün LLM’e bir fonksiyonu açıklayıp oturumu kaydettim diyelim; bugün oturumu geri yükledikten sonra görünürde hiç bağlantısı olmayan bir soru sorsam bile, LLM’in eski bağlamı da hesaba katarak cevap vermesini isterim. İstediğimde açıkça yeni bir başlangıç (clean slate) yapabilmeyi de sağlayan bir yöntem olmalı bence
Doğru. Yazılımın genel üretkenliğinde düşünme süresi, fiilen kod yazma süresinden çok daha büyük pay tuttuğu için, LLM kodlama kısmını hızlandırsa bile toplam üretkenlikte veya iş gücü talebinde dramatik bir değişim yaratmıyor
DO NOT WRITE ANY CODE YET prompt’u ile başlamak benim de varsayılanım. Bu, LLM’in ne yapmaya çalıştığını önce anlamanın ve kontrolü elimde tutmanın yolu. Ben kod yazmaktan çok mantık/problem çözme/sistem entegrasyonu gibi tasarım tarafını daha eğlenceli buluyorum
Copilot’un Ask modu, GPT-5 Codex’in Plan/Chat modu gibi, kod dosyalarını değiştirmeden sadece plan yapabilen özellikler var. Codex’i birkaç gündür kullanıyorum; yeterince talimat verince oldukça etkileyici
Ben de çoğunlukla “önce planı söyle” gibi, LLM’den somut uygulamaya geçmeden önce planı istemeyi tercih ediyorum
Bu yazı, Microsoft’un pazarlama materyallerini alıntılayıp %10 üretkenlik artışı iddia ediyor; oysa Harvard araştırmasında gerçekte tam tersine %10 üretkenlik düşüşü kaydedilmiş. Belirli bir şirketin tanıtımı yerine, önce bağımsız araştırma sonuçlarını alıntılayan yazıları tercih ederim
Bu yazının tam aktaramadığı kilit noktalardan biri olarak, Casey Muratori’nin söylediği “öğrenme odaklı bir zihniyetle programlıyorsan AI aslında anlamsızdır” fikrine katılıyorum. Kişisel olarak AI kod üreticilerinin sadece tek seferlik, atılacak kodlarda işe yaradığını düşünüyorum. Ciddi biçimde öğrenmek istediğim alanlarda, kod üretimini AI’a bırakmamanın öğrenme etkisini en üst düzeye çıkardığını hissettim. “AI güdümlü mühendislik” bazıları için kesinlikle anlamlı olabilir ama en azından benim için, kod bloklarını bizzat elimle yazdığımda hem daha çok eğleniyorum hem de sonuç genelde daha iyi oluyor. İlgili video, 5 dakika
Claude Code kullanırken düşünmeye çok daha fazla zaman harcıyorum. Yapmak istediğim özelliği 400-600 kelimeyle tarif etmek eskiden yaptığım bir şey değildi; şimdi ise daha fazla bilgiyi ciddi biçimde derleyip topluyorum. Bu tür düşünme sayesinde daha hızlı ve daha iyi sonuçlar çıkıyor ama aynı zamanda koda dair anlayışım da eskisine göre biraz azalıyor. Yine de Claude Code kullanan deneyimli geliştiricilerin daha az düşündüğü iddiasına katılamam. Muhtemelen birçok kişi ajanları neredeyse sadece prompt yazarak kullandığı için verimsiz kullanıyor; ama bunu ajanın suçu olarak görmüyorum
Bu tür tartışmaları görünce, şu anın hâlâ belirsiz bir geçiş dönemi olduğunu düşünüyorum. Gelecek yıl civarında bugün yaptığımız bu tartışmaların “fazla düşünülmüş” diye görülmesi muhtemel. İnternetin yaygınlaşmasından önce ve sonra “geçici heves”, “yanlış yatırım” gibi soruların çok sorulduğu döneme benziyor
Bu tür yazıların sık sık kaçırdığı noktalar şunlar
AI kod yardımının artılarını, eksilerini ve trade-off’larını sistematik biçimde sıralayan bir yazı olmasını isterdim. Ahlaki değer yargılarını (iyi/kötü) işin dışında tutarak tartışmak gerek. “Kodlama becerisi” benim kimliğimin bir parçası olduğunda buna özellikle soğukkanlı yaklaşmanın zor olduğunu kabul ediyorum
Her gün kendi kendime “30 yıl daha dayan, sonra emekli olursun” diye gaz veriyorum. Machine learning alanında 10. yılım, bilgisayar başında olmaktan da işten de yoruldum. Sadece çimenlere uzanıp yuvarlanmak istiyorum
“Düşünme&kodlama vs düşünme&düzeltme” grafiği ilginç. Son zamanlarda Codex kullanırken AI’ın kodumu çok değiştireceğini kesin sanmıştım. Gerçekte ise, sorunun kaynağı kodla hiç alakalı olmadığında zaman korkunç ölçüde tüketiliyor. Yakın zamanda kimlik doğrulama problemi yüzünden uzun süre sadece kodu didik didik ettim, ama meğer sebep VM’in ipv6 yapılandırmasındaki arızaymış
Katılıyorum. AI ile kodlama yaptığımda sonradan yapılması gereken işlem çok fazla olduğu için bunu gerçek iş süreçlerine entegre etmek ve bakımını sürdürmek çok zor oluyor.
Birlikte geliştiriyormuşuz gibi mümkün olduğunca çok gidip gelerek ilerlesek bile, kodun bir kısmını doğrudan kendimiz yazmadığımız için çoğu zaman akıldan uçup gidiyor.
Bence sınırlar kesinlikle gerekli.