Redis array: Uzun geliştirme sürecinin kısa hikâyesi

 (antirez.com)
1 puan yazan GN⁺ 1 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Redis’in yeni Array veri tipi üzerindeki çalışma ocak başında başladı ve yaklaşık 4 ay sonra bir PR olarak açıldı; ilk ayda gereklilik, C yapıları, seyrek gösterim, halka tampon ve ARINSERT için dizi imleci anlamlarını içeren bir spesifikasyon yazıldı
  • İlk tasarım Opus ile birlikte rafine edildi ve GPT 5.3 yayımlandıktan sonra tasarım ve geliştirme Codex ile yürütüldü; yapay zekâ ile geri bildirim sürecinde uzlaşma noktaları ve aşırı tasarlanmış kısımlar sürekli gözden geçirildi
  • Uygulama, ARSET myarray 293842948324 foo gibi büyük indeks ayarlarının devasa tahsisler olmadan çalışmasını sağlayacak şekilde değiştirildi ve iç veri yapısı koşullara göre süper dizin, dilimlenmiş yoğun dizin ve gerçek dizi dilimleri arasında geçiş yapıyor
  • Her dilim varsayılan olarak 4096 öğe barındırıyor; ARSCAN ve ARPOP, tüm aralığın boyutuna değil gerçekten var olan öğe sayısına orantılı sürede mevcut dizileri tarayabiliyor
  • Markdown dosyalarını Redis dizisine koyma kullanım durumu ARGREP uygulamasına yol açtı; düzenli ifade desteği için TRE seçildi ve kullanım durumları Redis PR #15162 içinde özetleniyor

Uygulama ve gözden geçirme

  • İkinci aydan itibaren otomatik programlama yaklaşımıyla uygulamaya başlanırken üretilen kod sürekli gözden geçirildi
  • Uygulama çalıştıktan sonra da sparsearray.c ve t_array.c dâhil kod satır satır okunarak incelendi
  • Yapay zekâ sayesinde çok sayıda test vardı, ancak yüzeyde çalışan kodun en iyi olduğu anlamına gelmediği için küçük verimsizlikler ve tasarım hataları bulunup düzeltildi
  • Birden fazla modül elle ve yapay zekâ destekli biçimde yeniden yazıldı; üçüncü ayda da çeşitli yöntemlerle stres testleri yapıldı
  • Yüksek kaliteli sistem programlamasında insanın hâlâ tamamen işin içinde olması gerekiyor, ancak yapay zekâ; 32 bit desteği ekleme ve testler gibi yorucu işlerde, ayrıca karmaşık algoritmalardaki bariz hataları yakalamada bir güvenlik ağı sağlıyor
  • Başlangıçta yazılan kapsamlı spesifikasyon sonraki çalışmaların temeliydi ve kodun her satırını inceleyip uymayan yerleri düzeltmede de kritik rol oynadı

Kullanım durumları ve düzenli ifadeler

  • Kullanım durumları modellenirken Markdown dosyaları Redis dizisine konmaya başlandı ve dosyaların dizi veri tipiyle iyi eşleştiği sonucuna varıldı
  • Ajan iş yükleri için gerekli, Markdown dosyalarına dayalı merkezi bir bilgi tabanı oluşturma ihtiyacı ARGREP uygulamasına yol açtı
  • Düzenli ifade desteği için TRE seçildi; çünkü Redis’te düzenli ifadeler kullanılırken zaman veya alan açısından patolojik örüntüler olmaması isteniyordu
  • TRE, foo|bar|zap gibi kullanışlı örüntü eşleştirmelerinde oldukça verimsizdi; bunun üzerine GPT’nin yardımıyla optimize edildi, bazı potansiyel güvenlik sorunları düzeltildi ve testler genişletildi
  • Kullanım durumları Redis PR #15162 içinde ayrıntılı biçimde özetleniyor ve bu da sayısal indekslerin anlamın bir parçası olduğu bir veri tipinin Redis’te gerekli olduğu sonucuna götürüyor
  • Array PR’ının yakında kabul edilmesi, yeni kullanım durumlarının avantajlarının elde edilmesi umuluyor ve geri bildirim isteniyor

İlgili okumalar

1 yorum

 
GN⁺ 1 시간 전
Hacker News görüşleri

  • Açık söylemek gerekirse, bunu yapan kişi Redis'in orijinal yaratıcısı ya da onlardan biri
    Yani “ortalama bir geliştirici” değil ve LLM kullansa bile 4 ay sürmüş
    Bu yüzden bunu, tüm geliştiricilere Claude Code, Codex ve diğer yapay zeka kodlama araçlarına tamamen geçmeleri için talimat vermenin meşru olduğuna dair bir onay mührü gibi görmemek gerekir
    Özellikle sıradan startup CEO'larının görmesi gereken kısım bu

    • Deneyimli bir geliştiricinin kodlama ajanlarını ustalıkla kullanmasının uzmanlığını daha da büyütebildiğine dair oldukça güçlü bir kanıt gibi görünüyor
    • “O ortalama bir geliştirici değil ve LLM kullansa bile 4 ay sürdü” kısmı, asıl metne bakınca biraz farklı
      Orijinalde, “LLM'den önce de uygulamanın kendisini muhtemelen 4 ay içinde yapabilirdim. Değişen şey, aynı sürede çok daha fazla iş yapabilmiş olmamdı” deniyor
      Yani başlangıçtaki süre zaten 4 aydı; LLM sayesinde aynı süre içinde daha fazla iş yapılmış oldu
    • O ortalama biri değil ama yaptığı iş de elbette ortalama bir iş değil
      Ortalama geliştirici işi daha çok tesisat işleri ve CRUD gibidir

  • Şu anda kullandığım yöntem şöyle
    Önce yapay zeka yardımıyla Markdown olarak bir üst seviye tasarım dokümanı yazıyorum. Sonra aynı modeli bağlamı çıkararak ya da başka bir modele eleştirtip hata, eksik ve boşlukları bulduruyorum. Sonradan bakınca bariz görünen şeyleri hep yakalıyorlar
    Sonra bu bulguları özetletip ilk yapay zekaya yapıştırıyor ve fikrini soruyorum. Üzerinde uzlaşılan değişiklikleri yapıp uyguladıktan sonra, hiçbir model anlamlı bir öneri getiremeyene kadar bu düşmanca round-robin sürecini sürdürüyorum
    Ardından yapay zekaya bir plan çıkarttırıyorum ve o planı da birden fazla yapay zeka arasında yine düşmanca dolaştırıyorum. Sonunda oldukça sağlam bir plan çıkıyor
    Sonra uçtan uca test senaryosu planı gibi şeylere geçiyorum. Sistemin ölçeğine göre ilk gün, ilk hafta ya da ilk ayın sonunda kodlama için hazır hale geliyorum
    Kod üretildikten sonra bu kodu, spesifikasyonu ve planı başka yapay zekalara yapıştırıp hata, eksik ve boşluk aratıyorum. Yani uygulamayı yapan ana yapay zekayı sürekli diğer yapay zekalarla doğruluyorum
    Tabii ki kodu kendiniz de okumak zorundasınız. Çünkü yapay zekanın yayın kalitesindeki ince rötuşları kaçırdığını gördüm

    • Yapay zeka söyleminde sanki tamamen yeni bir gözetimsiz geliştirme paradigması açmışız gibi anlatılıyor ama bu, esasen Google'ın 10 yıldır kod üretme biçimine çok benziyor. Tek fark, farklı güven seviyelerindeki insanlar yerine yapay zeka kullanılması
      Bunu küçümsemek için söylemiyorum. Benim iş akışım da özünde aynı ve Google'la dalga geçmek gibi bir niyetim de yok. Asıl demek istediğim, burada yeni bir şey olmadığı
      Yapay zeka hem etkili hem etkisiz iş akışlarını muazzam biçimde hızlandırıyor. Böylece neyin etkili neyin etkisiz olduğu çok daha kısa sürede, neredeyse gerçek zamanlı olarak ortaya çıkıyor
    • Bu yaklaşımın, kodu doğrudan yazmaktan ne kadar daha hızlı ya da yavaş olduğunu merak ediyorum
    • Bu tür spesifikasyon odaklı geliştirme, AWS Kiro'nun temel farklarından biriydi: https://kiro.dev/docs/specs/
      Başka ajanlar da kullandığını söylemişsin; daha az cilalı kısımları başka ajanların parlatmasına dayanan kod incelemelerinde etkili olup olmadığını merak ediyorum. Ekip arkadaşlarım buna çok inanıyor ama ben insan gözden geçiriciler olmadan bunun ne kadar değerli olduğuna hâlâ şüpheyle bakıyorum
      “Başka bir yapay zekaya sor” yaklaşımı için, uygulamalı bilgisayar bilimlerinde tez-antitez-sentez daha uygun olabilir belki: https://en.wikipedia.org/wiki/Dialectic#Criticisms

  • antirez yazmış olsa bile, bu kadar özellik ve asgari PR açıklamasıyla 22.000 satırlık kod incelemesi yapmak kâbus gibi geliyor
    Postgres gibi büyük açık kaynak projelerin neden e-posta listelerinde geliştirildiğini anlıyorum. Ara tasarım kararlarını toplulukla tartışmak, ilgili özellikleri ayrı yamalara bölmek, artımlı inceleme yapmak ve sürümler arasında zaman bırakmak bu yüzden var

    • Kod, yorumlar dahil toplam 5.000 satır
      Seyrek dizi 2.000 satır
      t_array komutu ve üst katman uygulaması 2.000 satır
      AOF/RDB kodu yaklaşık 500 satır
      Geri kalanı testler, JSON komut açıklamaları ve deps altındaki TRE kütüphanesi
    • Postgres ve Redis; karakteri, geçmişi, katkı modeli ve geliştirme ekibi bakımından dramatik biçimde farklı projeler
      Hatta Redis'in temel özelliklerinin çoğu fiilen yazarın tek başına yaptığı işler
      Üstelik gözden geçirenler bu işi iyi biliyor ve düzgün şekilde ücret alıyorlar

  • Günümüzün en iyi yapay zekalarıyla yaşadığım deneyime çok benziyor. İnsan zekâsı ve yaratıcılığının yerine geçmekten çok uzak ama bir iş ortağı olarak son derece faydalı

    • Yapay zekanın, hep istediğim rubber duck programming ördeği olduğunu sık sık söylüyorum
    • Kodu neredeyse hiç görmeden geliştirdiğim projeler var. Kavramı, algoritmayı ve fikri ben tutuyorum; sorular ve ipuçları veriyorum, özellikle de ürün yönünü sahipleniyorum
      Ama Redis henüz bu noktada değil. Bir gün bu sunucu yazılımlarında da mümkün olursa, bugünkü geliştirme biçimi sona ermiş olacak
      Özellikler, düzeltmeler ve birikmiş deneyim yine değerli olmaya devam edeceği için projeler ve depolar kalır; ama programcının rolü, şimdiye kadar Linus'un çekirdekte üstlendiği role çok benzeyecek
      DeepSeek v4 çıkarım motoru gibi bazı projelerde şimdiden buna benzer şekilde çalışıyorum

  • array/regex heyecan verici görünüyor ve LLM ile kapasiteyi büyütme deneyimi de çok ilginç. Pek çok kişi farklı projelerde sessizce benzer şeyler deniyor
    Vibe coding ve ona yönelik tepki, bu çalışma biçimini tek başına açıklamaya yetmiyor

    • Ajanları kullanma biçimimin hiç de vibe coding olduğunu düşünmüyorum. Çünkü fazla derin şekilde dahil oluyorum ve her şeyi doğruluyor, kontrol ediyor, gözden geçiriyorum
    • “Vibe coding” ile ilgili sorun, bu terimi ortaya atan kişinin ona çok özel bir anlam yüklemiş olması. Kodu bakmadan, sadece “hissiyatla” yazılım üretmek
      Ama kısa süre içinde insanlar bunu yapay zeka destekli kodlamanın neredeyse her türü için kullanmaya başladı ve asıl anlamı hızla eridi

  • Özetle, artık Redis'e güvenilemez
    LLM'siz bir fork'u kim yapacak?

  • Sunulan kullanım örneklerinin bazıları ZSET ile de yapılamaz mı? Performans tarafını anlıyorum ama dizinin isteğe bağlı olarak seyrek gösterim kullanması gibi, yoğun değerler için de ZSET depolama biçimini isteğe bağlı optimize ederek yeni bir API yüzeyi eklemeden yapmak mümkün olabilirdi gibi geliyor
    Regex bileşeni ilginç ama burada da söylendiği gibi, dizi veri yapısına dik duran bir özellik gibi görünüyor. Yani başka yapılarda da kullanılabilir. Bu, Lua betikleriyle yapılması daha uygun bir şey değil mi? Lua performansı sorun ise, değer aralıkları döndüren herhangi bir komutun üzerine birleştirilebilecek şekilde OP'yi soyutlamanın bir yolu da olabilir
    Antirez'in bu alanda uzman olduğunu kabul ediyorum ama bu yeni özellik setinin bazı parçaları, mevcut özellikleri iyileştirmek yerine yeni özellikler inşa edip onları başkalarıyla birleştirmeye çalışan ve bu sırada gereğinden fazla karmaşıklık yaratan, LLM güdümlü geliştirmede sık görülen çözümler gibi hissettiriyor

    • Ne yazık ki değil. Sıralı kümeler spektrumun neredeyse tam karşı ucunda
      Anlamsal olarak temiz olsalar da skip list ile dizinin birleşimi yüzünden aşırı israfçılar
      Ayrıca iç gösterim bir dizi değilse, aralık sorguları ve ring buffer ihtiyaç duyulan kadar verimli ve sıkıştırılmış şekilde çalışamaz
      Teorik olarak her şeyle her şey yapılabilir ama her API'nin yapabileceği şeyleri ayırmak gerekir ki kullanım örneklerinden yararlanıp en iyi iç uygulamayı sunabilesiniz

  • antirez'e merak ettiğim şey şu: Nihai kod için fiilen tek seferde üretim denemesi yaptın mı? GEPA ile oraya kadar gidilip gidilemeyeceğini ve istenen sonucu çıkarmaya yönelik yönlendirme ya da prompt yöntemlerinden öğrenilecek bir şey olup olmadığını merak ediyorum
    Ya da sonuç, model sağlayıcılarının eğitim verilerini temizlemesi gerektiği olabilir

  • Salvatore, Automatic Programming/Coding terimini yaygınlaştırmak istiyor gibi görünüyor. (https://antirez.com/news/159)

    • https://en.wikipedia.org/wiki/Automatic_programming bilgisayar bilimlerinde yerleşik bir terimdir ve daha yüksek soyutlama düzeyindeki tanımlardan otomatik kod üretmeye yönelik her türlü mekanizmayı ifade eder
      Elbette LLM'ler deterministik değil ve kapsamları şaşırtıcı derecede geniş; ama bu, terimin onlara uygulanamayacağı anlamına gelmez
    • Ben de aynı işi tarif etmek için kullandığım kelimeleri giderek azaltıyorum. Çünkü zaman geçtikçe o işi daha sık yapıyoruz
      Yine de terimi auto-code diye kısaltmak faydalı olabilir

  • Çok yetkin geliştiricilerin bugünlerde yapay zekayla nasıl etkileşime girdiğini görmek her zaman ilginç
    @antirez: Projenin ilerleyen safhasında görünüşte ayrı bir özellik olan regex işlevini eklemen biraz tuhaf geliyor. Bu kararın arkasındaki gerekçeyi biraz daha anlatabilir misin?

    • Dizilerin metin dosyalarına çok iyi uyduğunu fark edince, aklıma gelen birçok kullanım örneğinin dönüp dolaşıp dosyalarda grep ihtiyacına takıldığını gördüm
      Sonra dosyalardaki AROP karşılığının ne olacağını düşündüm ve cevabın ARGREP olduğuna karar verdim
      Ardından kullanım senaryosuna göre en iyi aracı seçebilmek için hem hızlı tam eşleşmeyi hem de regex eşleşmesini ekledim
      Sonra OR ile bağlanmış çoklu string'lerde, regex iyi optimize edilirse daha hızlı olabileceğini fark ettim ve TRE'yi biraz özelleştirdim