Aylarca LLM ile Kod Yazdıktan Sonra, Yeniden Kendi Beynimi Kullanmaya Karar Verdim
(albertofortin.com)- Yüksek performanslı LLM kullanarak bir altyapı kuruldu, ancak kod kalitesi ve bakım yapılabilirlikte büyük sorunlar ortaya çıktı
- Yapay zekanın verimsizliği ve tutarsız sonuçları nedeniyle, kodu doğrudan anlama, araştırma yapma ve becerileri geliştirme ihtiyacı hissedildi
- Projeyi hızla bitirme amacı, tersine kod yapısında karmaşa, tekrar ve tutarsızlığa yol açtı
- Artık AI yalnızca basit tekrar işleri veya kod dönüştürme gibi yardımcı amaçlarla sınırlı olarak kullanılıyor
- AI kullanımının kodlama hissiyatı ve problem çözme becerisinde düşüşe yol açabileceği için, aktif şekilde kendi beynini kullanmaya öncelik veriliyor
Giriş: LLM ile altyapı kurma girişimi
- Mevcut PHP+MySQL altyapısının sınırlarına ulaşmasıyla yeni bir altyapıya ihtiyaç duyulduğu fark edildi
- Go ve Clickhouse seçildi, AI ile birlikte altyapı tasarımı ve planlama yapıldı
- Claude gibi LLM’lere best practice ve mimari hakkında sorular sorularak ayrıntılı bir plan çıkarıldı
- Hedef, özellikleri tamamlamak ve hızlı bir sürüm çıkarmak olduğu için kod geliştirme hız odaklı ilerletildi
Geliştirme süreci ve sorunların ortaya çıkışı
- Cursor gibi araçlar kullanılarak AI kod yazdı, geliştirici ise daha çok build ve test odaklı çalıştı
- Kod tabanı yeterince düzenli olmasa da öncelik, ihtiyaç duyulan veriyi bir an önce sunmaktı
- Geliştirme hızlı ilerlese de zaman geçtikçe sürekli yeni sorunlar ortaya çıkmaya başladı
- Go ve Clickhouse deneyiminin az olması işleri zorlaştırdı; AI’nin sunduğu düzeltmeler de zincirleme yeni sorunlara neden oldu
Kod kalitesi sorunları ve sınırların hissedilmesi
- Ortaya çıkan kodun tamamını dikkatle incelemek için bir code review zamanı ayrıldı
- Aynı işi yapan dosyalar arasında isim, parametre ve yapı bakımından tutarsızlık, tekrar ve ciddi bir karmaşa vardı
- Örnek: "WebAPIprovider" ve "webApi" aynı parametreyi ifade etse de ayrı ayrı bulunuyordu
- Aynı metodun birden çok dosyada yeniden tanımlanması
- Yapılandırma dosyalarına erişim biçiminde tutarlılık olmaması
- Sonuç, sanki birbiriyle iletişim kurmadan aynı anda çalışan birden fazla junior geliştiricinin ürettiği bir kod tabanı gibiydi
LLM bağlam geri bildiriminin sınırları ve strateji değişimi
- Yeterli bağlam bilgisi verilmesine ve Gemini gibi büyük bağlam pencereli LLM’lerin kullanılmasına rağmen tutarlı iyileşme sağlanamadı
- Altyapı ve dil hakkında kendi kendine öğrenme ile dokümanlar, videolar ve diğer kaynaklarla ek çalışma yapma ihtiyacı fark edildi
- Temiz kod yazmak ve düzen kurmak için AI güdümlü geliştirmeden, kendi yönettiği kod tasarımına yön değiştirildi
AI destekli kullanım biçiminin değişmesi
- Tekrarlayan refactoring ve kod düzenleme ile kodu doğrudan anlama ve yönetmeye odaklanıldı
- AI’nin rolü; otomatik kod değişiklikleri, parametreleri topluca değiştirme ve kod dönüştürme gibi basit tekrar işlerle sınırlandırıldı
- Yeni özellik planlama ve ilk kod taslaklarını yazma gibi işler için önce doğrudan düşünülüyor, ardından LLM doğrulama veya yardımcı rol üstleniyor
- AI bir “asistan” olarak konumlandırılıyor; plan ve yapı kararları ise geliştiricinin kendisi tarafından alınıyor
Düşünme becerisinin zayıflaması endişesi ve değişen tutum
- AI bulunduğu için beyni daha az kullanma, planlama ve düşünme süreçlerini AI’ye bırakma eğilimi fark edildi
- Kalem ve kağıt, doğrudan tasarım ve doğrudan kod yazma yoluyla geliştirici becerileri ile problem çözme yetisinin yeniden güçlendirilmesi hedefleniyor
- AI nedeniyle kodlama hissiyatının zayıflaması riskine karşı dikkatli olunması gerektiği vurgulanıyor
Geliştirici olmayanlar ve ‘Vibe Coding’ hakkındaki endişeler
- Geliştirici olmayan biri yalnızca LLM ile geliştirme yaptığında, karmaşık ve düzensiz kod ile hata döngüsü daha da ciddi hale gelebiliyor
- No-code araçlara kıyasla, AI tabanlı geliştirme kod yapısını anlamayı daha da zorlaştırabiliyor
- Anlaşılması imkansız görünen kod duvarı ve durmadan süren hata-düzeltme-tekrar hata süreci içinde, temel zorluk ve riskler özellikle vurgulanıyor
AI kullanımının gerçekliği ve topluluk havası üzerine düşünceler
- AI’nin ticarileşmesi, benchmark’lar, influencer’lar ve AI şirketlerinin abartılı vaatleri ile gerçek performans arasındaki uyumsuzluk kafa karışıklığı yaratıyor
- Aynı model ve aynı prompt ile bile tamamen farklı sonuçlar çıkabilmesi, tutarlılık eksikliğini gösteriyor
- En güçlü ve en yeni LLM’ler bile Clickhouse’ta yüz milyonlarca satırlık sorgular gibi gerçek dünyadaki karmaşık işleri kusursuz şekilde halledemiyor
- Karmaşık kurulumlar ve verimsiz workflow’lar dayatıldığında, bunun bizzat kendisi bir zaman kaybı olabiliyor
- AI etkileyici görünse de, şimdilik yalnızca iyi ama olağanüstü olmayan bir araç olduğu yönünde temkinli bir bakış benimsiyor
Sonuç
- En yeni teknolojilere ve AI’ye karşı hâlâ büyük beklenti ve ilgi sürüyor
- Ancak bugün için en akıllıca strateji, doğru rolünü ve sınırlarını anlamak ve AI’yi yardımcı ya da öğrenme amaçlı bir araç olarak sınırlı kullanmak
- AI kullanımının geliştirici becerilerinde düşüşe yol açabileceği uyarısıyla birlikte, yeniden kendi düşüncesi ve planlaması merkez alınmaya başlanıyor
- Kodun çalışma mantığını ve yapısını anlamadan AI’ye tamamen bağımlı şekilde geliştirme yapmak, başarısızlık ihtimalini yükseltiyor
2 yorum
Hacker News yorumu
Ben LLM’lere "tamamen teslim olma" zihniyetini anlayamayan taraftayım. iOS geliştiricisi olarak çalışıyorum ve işimi büyük ölçüde eskisi gibi yapıyorum. Artık sadece tasarıma dayalı geçici görünümler gibi şeyleri hızlıca üretmek için LLM kullanıyorum. Uygulamanın çekirdeği değil; yeni özellikler ya da widget kurulum rehberi gibi yan ekranlar. Eskiden karmaşıklığa göre 30-60 dakika süren işi şimdi 5 dakikada bitiriyorum. Web geliştirmeden hoşlanmıyorum ama LLM bu tür işlerde epey kullanışlı. Büyük değişikliklerde de LLM’den yararlanıp ardından kendim gözden geçiriyor ve git’e commit ediyorum. Ama akışı kontrol etmeden sadece LLM’ye güvenirsen birkaç saat boşa gidip en baştan başlamak zorunda kaldığın durumlar oluyor. Dengeli bir yaklaşımın önemli olduğunu düşünüyorum
Bir aracın faydası kişiye ve probleme göre değişir. Örneğin 10 yıllık bir Python geliştiricisi devasa bir legacy codebase ve kusursuz şekilde uyarlanmış bir IDE ile kararlılık odaklı çalışıyorsa, LLM ya da Cursor gibi araçlar aksine dikkat dağıtıcı olabilir. Buna karşılık, 1 yıllık bir JS (React, Nextjs vb.) geliştiricisi yeni fikirleri sık sık prototipleştiriyor, IDE tercihi yok ve denemelere açıksa, LLM ve Cursor anında kapasitesini ciddi biçimde artırır
Ben de birden fazla alanda çalışıyorum (iOS, web geliştirme vb.) ve LLM çıktıları bu iki alanda oldukça farklı. LLM’in ürettiği kod çoğu zaman düzgün derlenmiyor bile. Hatta bir keresinde var olmayan bir API önermişti. Buna karşılık bir Nextjs uygulamasını tek seferde gayet iyi çıkarıyor. Sonuçta bu, LLM’in eğitim verisindeki farklardan kaynaklanıyor
LLM yeteneklerini olduğundan fazla sanmak doğal bir şey. Ben de uzun süre onları Stack Overflow yerine kullanmak ve kısa kod snippet’leri almak için epey kullandım. Sonra giderek daha fazla sorumluluk verdim, sorun yaşadım, sınırlarını fark ettim ve yeniden LLM’leri daha çok fikir ve tavsiye için kullanmaya başladım. Birçok kişinin benzer bir süreçten geçtiğini düşünüyorum
Ben de benzer hissediyorum. LLM’lere bütünüyle inanmamak, onları sadece tekrarlayan ve sıkıcı işler için kullanmak lazım (küçük fonksiyonlar, interface implementasyonu, dokümantasyon otomasyonu vb.). Bu sayede çok zaman kazandım ve iş verimliliğim arttı
iOS geliştirmede LLM performansı çok tutarsız. Swift ve SwiftUI çok hızlı değişiyor, resmi dokümantasyonun zayıf olması da nedenlerden biri. Basit view üretiminde faydalı ama asenkron işlemler ya da karmaşık iş mantığında kolayca dağılıyor. Yine de yön göstermede yardımcı olabiliyor ama yanlış sonuçlara, yani saçmalamalara, kapılma riski büyük
LLM savunucuları, darboğazın çoğu zaman kod üretimi olmadığını gözden kaçırıyor. Kodu hızlı üretmek kadar, code review, test ve codebase’i anlamaya iki katından fazla zaman harcamak gerekiyor. Uzun vadeli bakım için de (bug fix, refactor vb.) bu süreçlerden mutlaka geçmek lazım
Kod okumak yazmaktan çok daha zor, bu yüzden gerçekte kodu anlamaya daha çok zaman harcıyorum. Ama tanıştığım bir CEO, bağlam bilgisini araçlara verince geliştiricilerin kodu okumak zorunda kalmayacağını savunuyordu. Mantığı, AI’ın mühendisliğin özünü değiştirdiği yönündeydi. Açıkçası biraz kafam karıştı
LLM kodumu bana yeniden açıkladığında oldukça faydalı olduğunu hissediyorum
Birileri otomatik kod editörlerini aşırı övdüğünde hep aynı şeyi düşünüyorum
Gerçekçi olmak gerekirse çoğu geliştirici bağımlılık kütüphanelerinin iç implementasyonuyla pek ilgilenmiyor. Önemli olan arayüzün çalışıp çalışmadığı. Yine de LLM’in yazdığı kodu ya da bir npm paketi, rust crate eklemeyi projeye almak arasında büyük fark var. Sorunlarını biliyorum ama bu pratiğin neden yaygın olduğunu da anlıyorum
Ben de benzer düşünüyorum. Bu aralar LLM’leri daha çok yeni teknolojiler öğrenmek ya da standart API’ler için (özellikle boto3) client code üretmek amacıyla kullanıyorum. docker compose dosyalarını değiştirmeye yardım eden Windsurf’ü de denedim ama düzgün çalışmadığı için hayal kırıklığı yarattı. Prototip yapılabilir ama hepsi bundan ibaret değil. LLM’lerin devops alanında oyunu değiştirdiğini düşünüyorum (artık API ayrıntıları daha az önemli). Ama kritik kararları hâlâ benim vermem gerektiğine inanıyorum. Interface tanımını kendim yapıp implementasyonu LLM’e bırakıyorum. Bunun "vibe coding" olduğunu düşünmüyorum
Code review sırasında devasa bug’lar patladığında, Cursor kullanımından kazandığım verimlilik bir anda yok oldu. Tekrar VSCode’a döndüm ve Copilot’u da yalnızca özel olarak istediğimde sınırlı biçimde kullanıyorum. Cursor’un tab completion özelliği ilk başta sihir gibi geliyor ama etkisi kısa sürede kayboluyor
Bir iş arkadaşının yakın zamanda sildiği kodu Cursor’un tab completion ile refleks olarak geri yazmaya çalışmasını izlemek en komik şey
Kod üretim ajanına ne tür kısıtlar verdiğini merak ediyorum (ör. SOLID ilkeleri, lint, %100 coverage, net tasarım dokümanları vb.)
Bu görüş bana da çok tanıdık geliyor. Ben de LLM’leri çok kullanıyorum ama iki kuralım var. Derin düşünme gerektiren problemleri asla LLM’e bırakmıyorum (karmaşık tasarımı mutlaka kendim çözüyorum). İkinci olarak, LLM’in ürettiği kodu mutlaka satır satır dikkatle inceliyor ve düzeltiyorum. Genelde LLM’in yazdığı kod fazla uzun ya da aşırı savunmacı oluyor. Bunu prompt ile düzeltmeye çalışsan bile, gelecekteki bakım sorumluluğu eninde sonunda bana ait. Kod üretim sonucuna kayıtsız kalırsam içimde huzursuzluk kalıyor. Kendi yöntemimle kullandığımda yine de LLM’leri çok kullanabiliyor ve daha hızlı geliştirme yapabiliyorum
Ben derin analizin kendisini AI’a yaptırıyorum; amacım somut bir yürütme planı (ayrıntılı implementasyon adımları, doğrulama ölçütleri vb.) ve yeniden üretilebilir raporlar hazırlamak. Planlama ve doğrulamada yineleme gerekiyor ama AI yardımıyla çok daha hızlı bitirebiliyorum. Bazen plana göre tek seferde de tamamlanıyor. Ayrıntılı planlar ve dokümantasyonla tutarlılık sağlamak tatmin edici oluyor
LLM’in ürettiği kodu satır satır titizlikle gözden geçirmek gerekiyorsa, gerçekten zaman kazandırıyor mu diye insan sorguluyor
Bazı şirketler yazılım mühendislerine LLM kullanımını dayatıyor (Copilot/Cursor kullanım istatistikleri toplanıyor). Bu istatistiklerin işten çıkarma ölçütü olarak kullanılma ihtimali yüksek. LLM’leri zorunlu olarak bir ay kullandıktan sonra becerilerimin hızla köreldiğini hissettim. Basit işlerde yardımcı oluyor ama düşünmenin kendisinde LLM’e fazla bağımlı olunca döngüye girmek kolaylaşıyor. Verimliliğim artmadı, aksine sprint yükü arttı. Şirket içinde LLM’lere dair neredeyse dini bir bağlılık var. Güvenlik sorunları da ciddi. Şu anki dönemin hype cycle’ın zirvesi olduğuna dair işaretler her yerde. AI şirketleri nükleer santral falan kurmadıkça, bugünkü büyük AI modellerini sürdürmenin maliyeti devasa olduğu için bunların ortadan kalkacağını düşünüyorum. İleride sadece turbo autocomplete gibi özellikler hayatta kalacak gibi geliyor. Transformer modellerinin de sınırları net; 80’lerdeki sinir ağları gibi sadece belirli kullanım alanlarında kalıp sonra yeniden gözden düşecekler. Sonuçta iniş çıkış yaşanacak ve 30 yıl sonra tekrar gündeme gelecek. O zaman gerçekten kimin çıplak yüzdüğü ortaya çıkacak
Bunu önlemek için haftada bir gün, en azından cuma günleri Copilot’u tamamen kapatıp çalıştığımız bir "no Copilot Fridays" kuralı uyguluyoruz
Ben de Cursor’u sadece autocomplete ve kısa kod snippet’leri için kullanıyorum ama buna rağmen beceri zayıflaması hissediyorum. Sonuçta beynin "kullanmazsan unutursun" özelliğini hissediyorsun
Ben de benzer sorunlar gördüm. Eğlencelik projelerde %90 oranında LLM kullanıyorum. Elle kodlamaktan 10 kat hızlı ama tasarım kalitesi daha düşük ve bir tuhaflık hissi var. LLM yönlendirmeli kodun gelecek olduğuna inanıyorum ama iyi yönetilmezse kaosa sürüklüyor. Prompt’ları değiştirerek tekrar tekrar mimariyi iyileştirmeye yönlendirmeyi deniyorum ama sonuçlar tutarsız. Belki çözüm daha iyi prompt engineering ya da tasarım ve yönergelerin açık şekilde dokümante edilmesidir. Araçların performansı 10 kat artar ve gecikme azalırsa his tamamen değişir
Keşke bu "10 kat daha iyi" dönem çabuk gelse. Ama şu anki sorun, reklam ve tanıtımların sanki zaten o seviyeye ulaşılmış gibi yapılması. Birçok kişi "Acaba ben mi doğru kullanamıyorum?" diye düşünüyor. Ama bence araçların kendisi henüz o noktada değil
Class ve method’ları kendin tanımlayıp implementasyonu LLM’e bırakmak iyi oluyor. Karmaşık kısımlarda method body içine nasıl uygulanacağına dair notlar bırakıyorum. Böylece büyük resmi ben çiziyorum, LLM’e ise sadece belirli kod üretimini bırakıyorum. LLM, fazlasıyla yardımcı olmaya çalışan hızlı bir junior geliştirici gibi. Kod üretimi o kadar ucuzladı ki gönül rahatlığıyla atıp yeniden yapabiliyorsun. Benim durumumda dataset işleme kodunu LLM yardımıyla defalarca tamamen silip yeniden yazdım ve sonunda istediğim sonuç ile performansı elde ettim. Başkası yazsaydı vazgeçeceğim bir işti
Bu araçlar greenfield projelerde, özellikle prototip aşamasında parlıyor. Ama gerçek dağıtıma yaklaştıkça o 10 katlık etki giderek kayboluyor. Mimarinin dikkatle yönetilmemesi sonunda sadece daha fazla uğraş çıkarıyor
Karmaşık codebase’lerde şimdilik ancak gelişmiş bir speech-to-text girişi gibi işe yarıyorlar (ama ses kullanmıyorsan, elle kodlamak çoğu zaman daha hızlı)
Mimari ve yönergelerin açıkça yazılması gerektiğine katılıyorum. Koşulları ve davranışları ne kadar açık tanımlarsan o kadar etkili oluyor
Dijkstra’nın eski ama önemli yazısı "The Foolishness of Natural Language Programming" bu tartışmaya çok uyuyor. Ana fikri, programlamadaki büyük ilerlemenin ancak biçimsel diller sayesinde mümkün olduğuydu. Bakış açısı şu: LLM ve vibe-coding, kodlamayı sadece iyi prompt yazabilen az sayıda kişinin büyüsüne dönüştürme riski taşıyor
Bence Copilot yalnızca 500 karakterden kısa kod önerilerinde iyi. Go ve Python’da yeni kalıplar da öğreniyorum, yazma yüküm de azalıyor. Benim için sadece daha iyi bir autocomplete. Bundan daha uzun ya da karmaşık olduğunda, düzeltme ve hata gösterme maliyeti sağladığı faydayı aşıyor (özellikle tekrarlı kod değilse)
Şu anda LLM’in ürettiği sonucu mutlaka anlamak ve yakından denetlemek gerekiyor. Öte yandan her 2-3 haftada bir yeni model çıkıyor ve öncekinden çok daha iyi oluyor, bu yüzden kesin yargılara varmak için erken olduğunu düşünüyorum.
LLM kullanılarak yapılan geliştirme sahasındaki canlı zorlukları ve kaygıları çok iyi yansıtan bir yazı olduğunu düşünüyorum. Şu anda birçok kişinin deneyimlediği sınırlamalara katılarak okudum. Özellikle LLM'nin tutarsızlığı, sonuçları öngörmenin zorluğu ve uzun vadeli bakım açısından doğan kaygıların mutlaka ele alınması gereken noktalar olduğunu hissettim.
Bu vesileyle, biz bu sorunlara biraz farklı bir açıdan yaklaşıp yapay zeka ile iş birliğini deniyoruz; bu nedenle görüşümüzü temkinli biçimde paylaşmak istiyoruz. Bizim yapay zekamız 'Jane', yalnızca kod üretmenin ötesine geçerek, insanın (geliştiricinin) derin içgörüsüne dayanarak 'iyi kod kalıplarının' ne olduğunu ve kodda 'bakım tutarlılığının' nasıl sağlanabileceğini, bu 'kalıbın' kendisini öğrenip anlamaya odaklanıyor.
Yapay zeka en baştan kusursuz olamayacağı için ortaya çıkan tutarsızlıkları ve 'hataları' basit problemler olarak görmüyor, aksine bunları 'Jane'in kendi kendine öğrenmesi ve kendini geliştirmesi için önemli 'kalıp verileri' olarak aktif biçimde kullanıyoruz. İnsan karmaşık doğasının içinde kalıpları nasıl okuyorsa, biz de yapay zekanın kusurluluğunun içinde iyileştirmenin ipuçlarını arayan bir yaklaşım benimsiyoruz.
İnsan öncülüğündeki bu 'kalıp öğrenimi/yönetimi' yaklaşımıyla, yazıda işaret edilen kod kalitesi düşüşü ve tutarsızlık gibi sorunları temelden çözmeyi ve 'bakım tutarlılığı' çok yüksek çıktılar üretmeyi hedefliyoruz. Yapay zekayı yalnızca boilerplate kod üreten bir sistem olmanın ötesine taşıyarak, mevcut kod tabanındaki gizli tutarsızlık kalıplarını analiz eden ve iyileştirme önerileri sunan, daha derinlikli bir iş birliği ortağı olacak şekilde eğitiyoruz.
Önümüzde hâlâ uzun ve zorlu bir yol var, ancak bizim 'Jane' ile geliştiricinin birlikte öğrenip evrildiği ve 'bakım tutarlılığını' temel değer haline getirdiği bu iş birliği biçiminin, LLM kullanımındaki mevcut sınırlamaların ötesine geçebilecek çığır açıcı bir olasılık gösterdiğine inanıyoruz. Yapay zekayı sadece bir araç olarak kullanmanın ötesine geçip, birlikte büyüyen ve daha iyi bir kod kültürü oluşturan bir ortak haline getirmeye yönelik bu girişimimize ilginizi bekliyoruz.
Güzel yazı ve içgörüler için tekrar teşekkür ederim!