- Redis'in yaratıcısı antirez, AI ve LLM'leri sık kullanıyor ancak mevcut noktada insanın problem çözme yeteneğinin LLM'lerin çok ilerisinde olduğunu düşünüyor
- Redis Vector Sets içinde ortaya çıkan karmaşık bir hatayı düzeltme sürecinde LLM'lerin sınırlarını bizzat deneyimledi
- LLM'lerin önerdiği algoritmalar standart ya da basit çözümlerle sınırlı kalıyor
- İnsan geliştiricilerin yaratıcı yaklaşımı, LLM'lerin ulaşmakta zorlandığı yenilikçi çözümler üretmede daha avantajlı
- LLM'ler fikir doğrulama ya da bir tartışma partneri olarak çok faydalı, ancak nihai yaratıcılık insanda kalıyor
Giriş: İnsan ve LLM karşılaştırması
- Benim AI ve LLM'lere karşı hiçbir önyargım yok
- Uzun süredir LLM'leri günlük olarak kullanıyor, fikir test etme, kod inceleme, alternatif keşfi gibi birçok amaçla yararlanıyorum
- AI'ın bugünkü seviyesi açıkça pratik ve etkileyici olsa da, insan zekâsıyla arasındaki farkın hâlâ büyük olduğunu vurguluyorum
- Son dönemde AI üzerine dengeli bir tartışma yürütmenin zorlaştığını hissettiğim için bunu yazma ihtiyacı duydum
Redis Vector Sets hata vakası
- Yakın zamanda Redis içindeki Vector Sets ile ilgili bir hatayı düzeltiyordum
- Redis'teki çalışma arkadaşlarım yokken, dosya veri bozulmasına (RDB/RESTORE) karşı ek koruma işlevi eklemiştim
- Bu özellik varsayılan olarak kapalı ve checksum geçse bile bozulmayı önlemeyi amaçlayan ek bir güvenlik katmanı
- Sorun, HNSW veri yapısının grafik gösterimini RDB'ye serileştirme hızını optimize etme sürecinde ortaya çıktı
- Düğümler arası bağlantı listeleri tamsayı olarak kaydediliyor, deserileştirme sırasında tekrar pointer'a dönüştürülüyordu
- HNSW'nin kendi implementasyonunun bir özelliği olan çift yönlü bağlantı garantisi nedeniyle, grafik/bellek bozulduğunda şu sorunlar oluşabiliyordu
- A'nın B'ye bağlı olduğu kaydedilmiş olsa da B'nin A'ya bağlı olmaması (numaralandırma hatası vb.)
- B düğümü silindiğinde çift yönlü bağlantı ihlali yüzünden A→B bağlantısının kalması ve daha sonra B->A aranırken use-after-free hatası oluşması
- Veri yüklendikten sonra tüm bağlantıların gerçekten 'çift yönlü' olup olmadığını doğrulamak gerekiyordu
- Saf algoritma uygulanırsa karmaşıklık O(N^2) oluyordu. Büyük veri setlerinde (~20 milyon vektör) yükleme süresinin 45 saniyeden 90 saniyeye çıktığı görüldü
LLM kullanımı ve sınırları
- Gemini 2.5 PRO ile sohbet ederek daha verimli bir yöntem sordum ve LLM'nin önerilerini inceledim
- LLM'nin ilk önerisi: komşu düğüm listelerini sıralayıp ikili arama (binary search) uygulamak; bu zaten çok bilinen bir yöntemdi
- Büyük bir iyileşme sağlamadığını söyleyip ek fikirler istedim ama daha iyi bir yanıt alamadım
- Benim önerdiğim alternatif yöntem: bağlantı çiftlerini
A:B:X biçiminde kaydedip (sıralama ve çift yön ayrımını kaldırarak) bir hash tablosunda ekleyip silmek
- LLM bunun iyi bir fikir olduğunu söyledi, ancak anahtar üretim performansı ve hashing maliyeti gibi dezavantajlara dikkat çekti
snprintf olmadan sabit uzunluklu anahtarları memcpy ile işleyerek verimi artırma fikrini de ben ekledim
İnsan yaratıcılığı ve LLM sınırları
- Daha sonra hash tablosu olmadan bir accumulator üzerinde XOR tekniği kullanma fikrini ortaya attım
- Pointer çiftleri (ve seviye bilgisi) accumulator'a XOR'lanıyor, çift yönlü bağlantılar varsa birbirini götürüp 0 oluyor, eksikse bir iz kalıyor
- Ancak çakışma olasılığı ve pointer'ların tahmin edilebilirliği sorunları vardı; LLM de buna katıldı
- Bir sonraki iyileştirme: rastgele seed/hashing (
murmur-128 ve urandom seed'i) birleştirip 128 bit accumulator üzerinde XOR uygulamak oldu
- Sonunda accumulator değerinin 0 olup olmadığına bakarak çift yönlü bağlantının sağlanıp sağlanmadığı anlaşılıyordu
- LLM bu yöntemin hem genel hatalara hem de dış saldırganlara karşı daha dayanıklı ve aynı zamanda verimli olduğunu değerlendirdi
Sonuç
- Sonunda güvenilirliğini değerlendirip uygulamaya alıp almamaya karar vermek için analizi tamamladım
- Bu örnekte, insan geliştiricinin yaratıcı ve standart dışı yaklaşımının, LLM'nin sunduğu sınırlı yanıtlardan daha iyi olduğu görüldü
- LLM'ler fikir doğrulama ve entelektüel sohbet ortağı ('akıllı ördek' rolü) olarak son derece faydalı
- Ancak nihai yaratıcı çözüm üretme yeteneğinde insan üstünlüğü açık
7 yorum
redis yakında geri kalacak galiba
Bisikletle koşuyu yarıştırmak gibi hissettiriyor.
antirez %1’lik insan geliştiricilerden biri. %1’lik insan geliştiricilerin LLM’lerden daha iyi olmaya devam edeceğini düşünüyorum. Ama %99 için ne olacağını bilmiyorum.
Yapay zeka ile sorun gidermeye çalışıp tamamen başarısız olduktan sonra, sonunda sorunu kendi başıma çözdüğüm birçok kez oldu.
LLM'lerin yüksek seviyeli ve yaratıcı görünmesi, böyle metinler üzerinde eğitilmiş olmalarından kaynaklanıyor; ayrıca bu sonuçları iyileştirmek için sayısız bilim insanının bu bilgiyi doğrulayıp eğitim verisinin kalitesini artırdığını düşünüyorum.
Ama zaman geçtikçe trendler değişiyor ya da duruma göre farklı bir yaratıcılık gerekiyor; bu yüzden sonuçta onu kullanan kişinin kendi durumuna uygun şekilde yaratıcılığını ortaya koyması gerekmiyor mu..
Hacker News görüşleri
Bu, benim deneyimimle tam olarak örtüşüyor. Aslında LLM asistanlarının bana sağladığı en büyük değer, oldukça zeki bir “rubber duck” rolü üstlenmeleri. Bazen bu “ördek” bana itiraz ediyor, hatta düşüncelerimi daha da rafine hale getiriyor. (Rubber duck debugging nedir?) Ama bence herkesin es geçmek istediği asıl soru şu: “Bu değer 2 yıl sonra da devam edecek mi?” Ben de cevabı bilmiyorum
LLM benim için bir rubber duck değil, daha çok bir “yanlış cevap makinesi”. İnternette cevap almanın en iyi yolu yanlış bir cevap paylaşmaktır diye bir söz vardır; bende tam olarak o işe yarıyor. LLM’ye basit ama can sıkıcı bir iş verdiğimde öyle yanlış sonuçlar çıkarıyor ki, sonunda sinirlenip öfkeyle işi gidip kendim yapıyorum
Fazla kendine güvenen bir ördek gibi; gerçek becerisine kıyasla aşırı özgüven sergiliyor. LLM’lerle konuşup yolunu kaybeden çok fazla insan gördüm
Benim için LLM, API’leri iyi bilen ama mimari konusunda sağduyudan yoksun bir junior geliştiricinin benim altımda çalışmasına benziyor. Saçma hatalar yapmasından endişe ettiğim için, çoğu PR’ı ekip incelemesine göndermeden önce tam 3-4 kez gözden geçiriyorum. Bunun sayesinde beynimi başka sorunlara çevirebilmem güzel
2 yıl sonra bu değer korunur mu? Benim için mesele “bu tartışmayı geçmek istiyorum”dan çok, “Biz 2 yıl sonrasına kadar oraya varabilecek miyiz?” sorusu. Dünya şu anda o kadar istikrarsız ki 6 ay sonrasını bile öngörmek imkânsız
Benim için LLM, pair programming yaptığım bir ekip arkadaşı gibi. Fikirleri konuşabileceğim biri, kod incelemesi ve alternatifler sunan bir varlık. Ayrıca bilmediğim özellikleri kullanarak bir şeyler öğrenmemi de sağlıyor
Bu yorum başlığını okuyunca, herkesin biraz “insanlar vazgeçilmez”, “LLM debug yapamaz”, “LLM yanlış yönlendirir” gibi fikirlere umut bağladığı hissine kapıldım. Elbette bunlar doğru, ama 2 yıl önce imkânsız olan otomatik kod üretimi inanılmaz ilerledi ve hâlâ da hızlı tempoda gidiyor. Bundan sonra ilerleme hızı bir “Pareto yasası” gibi yavaşlayabilir ama kesinlikle gelişmeye devam edeceğini düşünüyorum. Geçenlerde r/fpga’da LLM ile ilk sürüm testbench üretmeyi başardığımı anlattım; bunu hiç denememiş insanların ihtimali baştan reddetmesini görmek beni gerçekten şaşırttı
Bu tavır profesyoneller arasında çok yaygın. /r/law (hukuk subreddit’i) tarafına da uğradım; Dario Amodei’nin hukuk alanındaki yapay zeka hakkındaki sözlerine verilen anlık küçümseyici tepkiyi bizzat gördüm. Belki bu bir uyum mekanizması ya da mevcut duruma razı olma hali olabilir, ama ekonomik ve toplumsal değişimlere karşı geleceğe hazırlanma kapasitesi açısından çok kötü bir şey olduğunu düşünüyorum
Bu, assembly’nin temel olduğu dönemde programlama dilleri ortaya çıktığında programcıların onları (gerçekle pek ilgisi olmasa da) verimsiz, esneklikten yoksun ve aşırı basitleştirilmiş diye küçümsemesine benziyor. Bu tür tepkiler, yeni teknolojinin gerçek değeriyle çok ilgisi olmadan doğal olarak ortaya çıkıyor
LLM’ler bir süre patlayıcı şekilde büyüdü ama son modellerde sanki gerileme varmış gibi de hissediliyor. Test kodu üretiminde iyi sonuç veriyorlar, ancak LLM yeni özellik geliştirme gibi işlerde fazla derine girdiğinde işler garipleşiyor. Yeni projelerde ya da basit web uygulamalarında iyi çalışıyor ama büyük ölçekli veya legacy kodda refactoring ve özellik ekleme işlerinde etkisi çok yüksek değil. Örneğin Claude ya da ChatGPT’nin tüm D3 API’sini tamamen uydurması gibi durumlara sık sık rastlıyorum
Sonuçta sen kendi yerine geçecek şeyi kendin inşa ediyorsun, iş arkadaşların ise temkinli davranıyor
ChatGPT-4o, VHDL yazımında inanılmaz bir yetenek gösteriyor. Bugün de düşük seviyeli bir controller prototipi üretirken şaşırtıcı sonuçlar gördüm
Gerçek yazılımı düzgün yazmak için gereken bağlam, LLM’ler için fazla büyük. Yazılım dediğimiz şey özünde “işin koda dökülmüş hali”. LLM satış ekibinin müşteriye verdiği türlü özel sözleri, departmanlara özgü örtük kuralları nasıl bilebilir? Şu anda LLM’lerin çözebildiği alan genel ve sınırlı. İş iki sınıfı geçtiğinde ya da 20-30 dosyayı aştığında, en üst düzey LLM’ler bile yolunu ve odağını kaybediyor. Bağlamı koruyamadıkları için gereksiz code churn artıyor. LLM’lerin gerçek geliştiricilerin yerini alabilmesi için çok daha fazla bağlamı içine alması, kurum genelinden bağlam toplayabilmesi ve uzun soluklu projelerde düşünce akışını koruyabilmesi gerekir. Bu sorunlar gerçekten çözüm aşamasına geldiğinde işte o zaman gerçekten endişelenmeye başlayacağım
LLM’lerin geliştiricilerin yerini alıp almayacağını her tartıştığımızda, herkesin unuttuğu bir nokta var: gerçek software engineering, kod yazmanın dışında yapılacak tonla iş içeriyor. Kod yazmak aslında küçük bir parça. Önemli olan sosyal beceriler, gereksinim analizi, müşterinin aslında ne istediğini ortaya çıkarmak; üstelik çoğu zaman müşteri bile ne istediğini tam bilmiyor ve mühendis bunun ne olduğunu anlamaya çalışırken uğraşıyor. İnsanlar için bile zor olan bir şeyi LLM’nin başarabileceğini sanmıyorum
Sonuçta mesele bir feedback loop, yani müşterinin gerçekten kullanıp anında geri bildirim verdiği tekrar eden süreç. Sohbet arayüzü müşteri geri bildirim döngüsünde çok güçlü, agent’lar da yeni sürümleri hızlıca üretiyor. LLM’ler soyutlama, farklı component sistemleri, genel yapı tasarımı ve gereksinim analizi gibi işlerde de yeterince başarılı olabilir. Esas mesele yineleme hızının ne kadar yüksek olduğu. Modellerin dayanıklılığı ve IQ’su sürekli gelişiyor. Software engineering’in tamamı zaten otomasyon aşamasına girmiş durumda. Muhtemelen 5 yıl sonra insan tek başına çalışırsa büyük bir bottleneck olacak. Yapay zeka ile derin entegrasyon olmadan geri kalmamak mümkün olmayacak
2000’lerde offshoreing (yurt dışı geliştirici outsourcing’i) furyasında da tam olarak böyle bir sorun vardı. Yurt dışındaki ekipler düzeltme talep etmeyi ya da sorun çıkarmayı zor buluyordu, bu yüzden sadece söyleneni yazıp geçtiler ve sonuçta birikmiş bir yığın oluştu. Yapay zekada da benzer bir şey olacak gibi görünüyor. Sonuçların da benzer olacağını düşünüyorum
LLM’ler baştan itibaren software engineering yapmıyor. Ama bu illa bir sorun değil. Gerçekte pek çok başarılı program, “software engineering” olmadan da gayet iyi çalışıyor. Özellikle de kimsenin cloud maliyet yapısını umursamadığı ortamlarda. Hatta gelecekte, IT iş ortağı gibi teknik sezgisi olan birinin hiçbir yazılım mühendisi yardımı almadan tüm uygulamayı oluşturacağını düşünüyorum. Green energy sektöründe bu zaten her gün yaşanan bir gerçek. Ama sorun bakım, ölçekleme ve verimlilik gerektiğinde patlıyor. İşte o zaman “Python’da list mi yoksa generator mü kullanılmalı?” gibi konular önem kazanıyor ve gerçek mühendisliğe ihtiyaç duyuluyor
5 yıl sonra neredeyse hiç kod tasarlamıyor olabiliriz. Zaten 1 yıl öncesine kıyasla yazdığım kod miktarı inanılmaz azaldı. Ama bu, sürecin sadece bir parçası; geliştiricilerin tamamen ortadan kalkacağı anlamına gelmiyor
Öte yandan sadece “coder” rolü ciddi ölçüde yer değiştiriyor. LLM’lerin iyi olduğu alan tam da burası. Sık sık yalnızca “şu API’yi al, şu değeri üret” türü ticket’lara bakan, müşteri ihtiyacını anlama veya analiz işine hiç girmeyen, adeta beyni devre dışı coder’lar oluyor ve bu alan hızla temizleniyor. Asıl software engineering bambaşka bir alan ama basit coder’lara olan talebin çok büyük olduğunu görmezden gelmemek lazım
Yalnızca insanların, programın soyut kavramlarını ve yaratıcı problem çözümünü üstlenebilme yeteneğine sahip olması çok önemli bir nokta. Programcılar mantığın mimarlarıdır ve bilgisayar insan düşünce biçimini komutlara dönüştüren araçtır. Araçlar, insanı taklit edip belirli görevler için kod üretmede iyi olabilir ama temel soyut tasarım ve inşa rolünü üstlenemez. Modeller sadece kod yazmakla kalmayıp bir spesifikasyona göre tüm projeyi baştan sona kurabilir hale gelirse, geliştiricinin rolü de yeniden değişecektir
Her zaman “hangisi daha iyi” sorusuna iş bazında yaklaşmak gerekiyor. LLM’ler tekrarlı ve formüle dayalı işlerde (CSS sözdizimini düzeltmek, bilinen kütüphanelerin çağrı biçimlerini hatırlamak gibi) artık benden çok daha iyiler. Eskiden zamanımı alan bu tür “ufak tefek olaylar” artık neredeyse anında çözülüyor ve bundan çok memnunum
Temel CSS’in ötesindeki stil işlerinde LLM çıktısı aslında pek iyi değil. Efekti net şekilde tarif etmek zor olduğunda ya da iş incelikli hale geldiğinde, en önemli sonucu veremeyip tek bir yaklaşıma saplanıp kaldıkları çok oluyor
Benim zayıf olduğum konuda (SQL) LLM çok daha iyi, ama iyi bildiğim konuda (CSS) benden kötü. Ölçütün çok net ortaya çıktığını düşünüyorum
“Çoğu geliştiriciden daha iyi” sözüne de, CSS bilmedikleri için insanlara LLM daha iyiymiş gibi görünmesine de katılıyorum. Aslında birçok kişi CSS’ten hoşlanmadığı için öğrenmiyor ve mecburen kullanıyor; bu yanlış anlamanın nedeni de bu. Şirket gerçek bir CSS uzmanı işe alamayıp ucuza kaçmak istiyorsa LLM bir alternatif olabilir, ama işi gerçekten iyi yapan birini tutabilecek durumdaysa LLM elbette kıyaslanamaz. Sonuçta LLM’nin rakibi yeteneksiz geliştirici oluyor
Ana dilde ya da tam bilmediğim alanlarda LLM autocomplete büyük yardım sağlıyor. Ama “refleks olarak hatırlama becerisi” geliştirmeden yalnızca LLM’ye dayanırsan, bu aracın önerdiğini değerlendirecek yetkinliğin eksik kalır ve zayıf çözümlere mahkûm olma riski büyür
“İyi kod” konusunda kaygı duyan çok insan görmek sevindirici ama bunun pratikte bir anlamı olmamasından korkuyorum. Yazılım sektörü uzun zamandır iş dünyası tarafından ele geçirilmiş durumda ve bunun tam olarak ne zaman olduğunu bile bilmiyorum (Bill Gates 1976’daki açık mektubu yazdığında mı?). Asıl sorun, hissedarların ve yöneticilerin kodu daha az umursayıp kâr arttığı sürece memnun olmaları. Geliştiricilerden ve kullanıcılardan kültürel bir direnç gelmezse bu yapı sürecek gibi görünüyor
Geliştirici/kullanıcı tarafında kültürel direnç olmazsa iş biter sözüne karşılık, hâlâ iyi kod üreten pek çok şirket olduğunu ve her yerin felaket olmadığını söylemek isterim. Sorun kod kalitesi değil; kapitalist iş hedeflerini etik olarak kabul edip etmediğimiz. Güzel yazılım ile gerçek dünya arasındaki denge en önemli şey. Ben de hem geliştirici hem kurucu olarak açık kaynağı ve mühendisliği seviyorum, ama aynı zamanda yeterince rahat yaşamak da istiyorum
Kod işin motorudur. Kötü kod kötü işe çıkar. Hosting ekipleri (fiziksel firewall, vmware, proxy vb.) ile public cloud (QEMU, netfilter, basit cihazlar vb.) arasındaki fark çok belirgin. Kimin kimi ele geçirdiğini ve geleceğin ne olacağını kimse öngöremez
Dün gece tüm zamanımı o3 ile boğuşarak harcadım. Hayatım boyunca hiç Dockerfile yazmamıştım; bu yüzden GitHub deposunu o3’e verip işi otomatik çözmesini istemiştim, ama ortaya çıkan şeyi debug etmek için saatler harcadım. Var olmayan şeyler ekliyor, olmayan şeyleri siliyor ya da birbirine karıştırıyor,
python3ilepythonarasındaki temel fark gibi konularda bile kafası karışıyordu. Sonunda sinirlenip Google Docs’a baktım ve mesele hemen çözüldü. Yapay zeka harika bir araç olabilir ama her şeyi çözen sihirli değnek değil; mutlaka birinin “uyanık” kalması gerekiyorLLM/AI ile çalışan verimliliğini artıran şirketler gelişecek, çalışanları tamamen değiştirmeye çalışan şirketler ise başarısız olacak gibi geliyor. Kısa vadede CEO’lar/yöneticiler kısa dönem sonuçlardan memnun kalıp gelecekteki büyümeyi kemiren kararlar alabilir
Tam isabet. LLM’leri programcının asistanı olarak kullanmak doğru, tamamen yerine koymak değil. Teknolojiyi ölçülü şekilde benimsemek en doğru yol
Çalışan değiştirerek kısa vadeli değer yaratmanın şirkete fayda sağlayabileceği fikri bence ilginç. Yani orta-uzun vadede şirkete zarar verse bile, geçici olarak hisse fiyatını yükseltmek mümkün olabilir
Kod asistanları ortak ve gerekli bir araçtır; insanın yerini alacak bir silah değildir. Rakiplerin de aynı AI aboneliğini alabildiği bir çağda insanları gerçekten ikame edemezler
Sahadan bir deneyim paylaşımı: Eskiden geliştiriciydim, şimdi yöneticiyim ama hâlâ kod yazıyorum. LLM asistanları yardımcı oluyor ama bazen rahatsız edici de olabiliyor. Beklenmedik kod önerilerini durmadan fırlattıklarında niyetimden farklı bir yöne kayabiliyorum ve bunları gözden geçirmek de zaman alıyor. Muhtemelen ayar meselesi ama varsayılanın sadece ben komutla çağırdığımda görünmesi olmasını isterdim. Kesin olan bir şey var: tüm kodu ya da bir fonksiyonu LLM’ye yazdırsam bile mutlaka kendi inceleme sürecimden geçiriyorum
Zed editöründe böyle bir “hafif öneri” modu var (ayrıntılar). Keşke tüm editörler böyle bir mod sunsa
Bugünlerde startup’ta birçok işle uğraşırken LLM’nin ürettiği UI’leri pek sevmiyorum. Building block gibi temel parçalar faydalı ama Claude’a uzun kod bloklarını tamamen emanet ettiğimde, istediğim sonuca ulaşmak için sayısız kez yeniden çalışmak gerekiyor
https://freederia.com ai bilim insanı sitesi gibi bir birlikte var olma ilişkisini sürdürecekler.