Redis array: kisah singkat dari proses pengembangan yang panjang

• Pengerjaan tipe data Array baru Redis dimulai pada awal Januari dan diajukan sebagai PR sekitar 4 bulan kemudian; pada bulan pertama, ditulis spesifikasi yang mencakup kebutuhan, struct C, representasi sparse, ring buffer, dan semantik kursor array untuk ARINSERT
• Desain awal disempurnakan bersama Opus, lalu setelah GPT 5.3 dirilis, desain dan pengembangan dilakukan dengan Codex; dalam proses umpan balik dengan AI, titik kompromi dan bagian yang terlalu banyak dirancang terus ditinjau
• Implementasi diubah agar pengaturan indeks besar seperti ARSET myarray 293842948324 foo dapat berjalan tanpa alokasi raksasa, dan struktur data internal beralih sesuai kondisi menjadi super directory, dense directory yang di-slice, atau bentuk slice array aktual
• Setiap slice pada dasarnya menampung 4096 elemen, dan ARSCAN serta ARPOP dapat memindai array yang ada dalam waktu yang sebanding dengan jumlah elemen yang benar-benar ada, bukan ukuran seluruh rentang
• Kasus penggunaan menaruh file Markdown ke dalam array Redis mengarah pada implementasi ARGREP, TRE dipilih untuk dukungan regular expression, dan kasus penggunaan dirangkum di Redis PR #15162

---

Implementasi dan peninjauan

• Mulai bulan kedua, implementasi dimulai dengan pendekatan pemrograman otomatis sambil terus meninjau kode yang dihasilkan
• Setelah implementasi berjalan, kode termasuk sparsearray.c dan t_array.c tetap ditinjau baris demi baris
• Berkat AI, jumlah pengujian menjadi banyak, tetapi kode yang tampak berjalan di permukaan belum tentu optimal, sehingga inefisiensi kecil dan kesalahan desain dicari lalu diperbaiki
• Beberapa modul ditulis ulang secara manual maupun dengan bantuan AI, dan pada bulan ketiga dilakukan stress test dengan berbagai cara
• Dalam pemrograman sistem berkualitas tinggi, manusia tetap harus terlibat sepenuhnya, tetapi dengan AI ada jaring pengaman untuk tugas yang melelahkan seperti menambahkan dukungan 32-bit dan pengujian, serta untuk mendeteksi bug yang jelas dalam algoritme yang kompleks
• Penulisan spesifikasi besar di awal menjadi inti dari pekerjaan berikutnya, dan juga penting saat meninjau setiap baris kode serta memperbaiki bagian yang tidak sesuai

Kasus penggunaan dan regular expression

• Saat memodelkan kasus penggunaan, file Markdown mulai dimasukkan ke dalam array Redis, dan disimpulkan bahwa file tersebut sangat cocok dengan tipe data array
• Hal ini mengarah pada implementasi ARGREP untuk membuat basis pengetahuan terpusat berbasis file Markdown yang dibutuhkan untuk pekerjaan agen
• TRE dipilih untuk dukungan regular expression, dengan alasan bahwa saat menggunakan regular expression di Redis, tidak boleh ada pola patologis dari sisi waktu maupun ruang
• TRE sangat tidak efisien untuk pencocokan pola berguna seperti foo|bar|zap, sehingga dengan bantuan GPT dilakukan optimasi, beberapa potensi masalah keamanan juga diperbaiki, dan pengujian diperluas
• Kasus penggunaan dijelaskan secara rinci di Redis PR #15162, dan mengarah pada kesimpulan bahwa Redis membutuhkan tipe data di mana indeks numerik menjadi bagian dari makna
• Diharapkan PR Array segera diterima, manfaat dari kasus penggunaan baru bisa diperoleh, dan umpan balik pun diminta

[GN⁺]

Komentar Hacker News

• Perlu diperjelas, ini dikerjakan oleh pencipta asli Redis atau salah satunya
  Dia bukan “developer rata-rata”, dan bahkan dengan LLM pun butuh 4 bulan
  Jadi ini jangan dianggap sebagai cap persetujuan bahwa semua developer sekarang bisa disuruh pindah total ke Claude Code, Codex, atau alat coding AI lainnya berdasarkan ini
  Ini terutama bagian yang perlu dilihat oleh para CEO startup biasa

  • Ini tampak seperti bukti yang cukup kuat bahwa ketika developer berpengalaman mahir memakai coding agent, keahlian mereka bisa diperkuat lebih jauh
  • Bagian “dia bukan developer rata-rata, dan bahkan dengan LLM pun butuh 4 bulan” sedikit berbeda jika melihat teks aslinya
    Di teks aslinya tertulis, “bahkan sebelum LLM, implementasinya sendiri mungkin bisa diselesaikan dalam 4 bulan. Yang berubah adalah dalam periode yang sama saya bisa menyelesaikan jauh lebih banyak pekerjaan”
    Artinya periode awalnya memang 4 bulan, dan berkat LLM dia bisa mengerjakan lebih banyak hal dalam periode yang sama
  • Dia memang bukan orang rata-rata, tapi pekerjaannya juga jelas bukan pekerjaan rata-rata
    Pekerjaan pengembangan rata-rata lebih dekat ke plumbing dan CRUD

• Metode yang sekarang kupakai seperti ini
  Pertama, dengan bantuan AI aku menulis dokumen desain tingkat atas dalam Markdown. Lalu model yang sama, tetapi tanpa konteksnya, atau model lain, diminta mengkritiknya untuk mencari bug, hal yang terlewat, dan celah. Saat dilihat belakangan, mereka selalu menemukan hal-hal yang tampak jelas
  Lalu aku minta temuan itu diringkas, menempelkannya ke AI pertama, dan meminta pendapatnya. Setelah perubahan yang disepakati dibuat dan diterapkan, putaran round-robin yang adversarial ini terus dilakukan sampai tidak ada model yang bisa memberi usulan yang bermakna
  Setelah itu aku minta AI membuat rencana, dan rencana itu juga diputar secara adversarial di antara beberapa AI. Pada akhirnya keluar rencana yang cukup solid
  Berikutnya lanjut ke hal seperti rencana test case end-to-end. Bergantung pada ukuran sistemnya, menjelang akhir hari pertama, minggu pertama, atau bulan pertama, semuanya siap untuk mulai coding
  Setelah kode dibuat, kode itu bersama spesifikasi dan rencananya ditempelkan ke AI lain untuk mencari bug, hal yang terlewat, dan celah. Jadi AI utama yang mengerjakan implementasi terus divalidasi oleh AI lain
  Tentu saja, kodenya tetap harus dibaca langsung. Aku pernah melihat AI melewatkan polish detail kualitas akhir

  • Dalam wacana AI, kita seolah telah membuka paradigma pengembangan tanpa pengawasan yang sepenuhnya baru, padahal ini pada dasarnya hampir sama dengan cara Google membuat kode selama 10 tahun terakhir. Bedanya hanya manusia dengan tingkat kepercayaan berbeda diganti AI
    Ini bukan sindiran. Alur kerjaku pada dasarnya juga sama, dan bukan berarti mau menertawakan Google. Justru maksudnya tidak ada yang benar-benar baru
    AI mempercepat alur kerja yang efektif maupun yang tidak efektif secara luar biasa. Hasilnya, apa yang efektif dan apa yang tidak efektif jadi terlihat jauh lebih cepat, nyaris secara real-time
  • Aku penasaran seberapa jauh lebih cepat atau lambat cara itu dibanding menulis kode langsung
  • Pengembangan berbasis spesifikasi seperti ini adalah pembeda utama AWS Kiro: https://kiro.dev/docs/specs/
    Kamu juga bilang memakai agent lain, jadi aku penasaran apakah kamu melihat hasil bagus dari code review di mana bagian yang kurang rapi dipoles oleh agent lain. Rekan-rekanku sangat yakin, tapi secara pribadi aku masih ragu apakah ini bernilai tanpa reviewer manusia
    Pendekatan “tanya AI lain” mungkin lebih cocok dijelaskan dalam ilmu komputer terapan sebagai tesis-antitesis-sintesis: https://en.wikipedia.org/wiki/Dialectic#Criticisms

• Bahkan jika ditulis oleh antirez, melakukan review 22.000 baris kode dengan kumpulan fitur sebesar ini dan penjelasan PR yang minimal terdengar seperti mimpi buruk
  Aku jadi paham kenapa open source besar seperti Postgres dikembangkan lewat mailing list. Keputusan desain di tengah jalan dibahas dengan komunitas, fitur terkait dipecah jadi patch terpisah, direview bertahap, dan dirilis dengan jeda antarversi

  • Total kodenya 5.000 baris termasuk komentar
    Array sparse 2.000 baris
    Perintah t_array dan implementasi lapisan atas 2.000 baris
    Kode AOF/RDB sekitar 500 baris
    Sisanya adalah test, deskripsi perintah JSON, dan library TRE di bawah deps
  • Postgres dan Redis adalah proyek yang sangat berbeda dari sisi sifat, sejarah, cara kontribusi, dan tim pengembangnya
    Pada praktiknya, hampir semua fitur utama Redis adalah hasil kerja penulis secara sendirian
    Lagi pula para reviewernya sangat paham pekerjaan ini dan dibayar dengan layak

• Ini sangat mirip dengan pengalamanku menggunakan AI terbaik saat ini. Jauh dari pengganti kecerdasan dan kreativitas manusia, tapi sebagai kolaborator sangat amat berguna

  • Aku sering bilang AI adalah bebek karet untuk pemrograman yang selalu kuinginkan
  • Ada proyek-proyek yang kukembangkan hampir tanpa melihat kodenya. Aku memegang konsep, algoritme, dan ide, sambil memberi pertanyaan dan petunjuk, terutama memiliki arah produknya
    Tapi Redis belum sampai di sana. Begitu suatu hari ini memungkinkan di software server, cara pengembangan masa kini akan berakhir
    Akumulasi fitur, perbaikan, dan pengalaman tetap bernilai, jadi proyek dan repositorinya akan tetap ada, tetapi peran programmer akan menjadi sangat mirip dengan peran yang selama ini dijalankan Linus pada kernel
    Pada beberapa proyek seperti mesin penalaran DeepSeek v4, aku sudah bekerja dengan cara seperti itu

• array/regex terdengar menarik, dan pengalaman memperluas kemampuan dengan LLM juga sangat menarik. Banyak orang diam-diam mencoba hal serupa di berbagai proyek
  Vibe coding dan reaksi balik terhadapnya saja tidak cukup untuk menjelaskan cara kerja seperti ini dengan baik

  • Aku sama sekali tidak menganggap cara dia memakai agent sebagai vibe coding. Dia terlalu terlibat, dan memverifikasi, mengecek, serta mereview semuanya
  • Masalah dengan “vibe coding” adalah orang yang menciptakan istilah itu memberi definisi yang sangat spesifik. Yaitu membuat software hanya berdasarkan “feeling” tanpa melihat kodenya
    Tapi tak lama kemudian orang mulai memakai istilah ini untuk hampir semua bentuk coding berbantuan AI, sehingga makna aslinya cepat hilang

• Singkatnya, sekarang Redis jadi tidak bisa dipercaya
  Siapa yang akan membuat fork tanpa LLM?

• Bukankah sebagian use case yang diajukan juga bisa dilakukan dengan ZSET? Aku paham sudut pandang performanya, tetapi seperti array yang secara opsional memakai representasi sparse, rasanya penyimpanan ZSET juga bisa dioptimalkan secara opsional untuk nilai yang padat tanpa menambah permukaan API baru
  Komponen regex-nya menarik, tetapi seperti yang disebut di sini, itu tampak sebagai fitur yang ortogonal terhadap struktur data array. Artinya, itu juga bisa dipakai di struktur lain. Bukankah ini lebih cocok dilakukan dengan scripting Lua? Jika performa Lua yang jadi masalah, mungkin ada cara untuk mengabstraksikan OP agar bisa dikombinasikan di atas perintah apa pun yang mengembalikan rentang nilai
  Aku menghormati bahwa Antirez adalah pakar di bidang ini, tetapi sebagian dari kumpulan fitur baru ini terasa seperti solusi yang sering muncul dalam pengembangan berbasis LLM: membuat fitur baru alih-alih meningkatkan fitur yang ada, dan terlalu mengomplekskan fitur padahal mungkin lebih efektif jika dikombinasikan dengan fitur lain

  • Sayangnya tidak begitu. Sorted set berada hampir di sisi spektrum yang berlawanan. Secara semantik memang rapi, tetapi sangat boros karena gabungan skip list dan array
    Selain itu, jika representasi internalnya bukan array, query rentang dan ring buffer tidak bisa bekerja seefisien dan sekompak yang dibutuhkan
    Secara teoretis, kita bisa melakukan apa saja dengan apa saja, tetapi kemampuan setiap API perlu dipisahkan agar use case-nya bisa dimanfaatkan untuk memberi implementasi internal yang optimal

• Aku penasaran untuk antirez, apakah dia sudah bereksperimen dengan generasi one-shot untuk kode akhirnya? Aku ingin tahu apakah dengan GEPA itu bisa dicapai, dan apakah ada pelajaran dari teknik pengarahan atau prompting untuk menarik hasil yang diinginkan
  Atau mungkin kesimpulannya justru para penyedia model perlu merapikan data pelatihan mereka

• Sepertinya Salvatore ingin memopulerkan istilah Automatic Programming/Coding. (https://antirez.com/news/159)

  • https://en.wikipedia.org/wiki/Automatic_programming adalah istilah yang diakui dalam ilmu komputer, yang merujuk pada semua mekanisme untuk menghasilkan kode secara otomatis dari deskripsi dengan tingkat abstraksi yang lebih tinggi
    Tentu saja LLM sangat khas karena non-deterministik dan cakupannya luar biasa luas, tetapi itu bukan berarti istilah ini tidak berlaku
  • Aku juga makin mengurangi kata-kata untuk menjelaskan hal yang sama. Seiring waktu, kita akan makin sering melakukan pekerjaan “itu”
    Tapi mungkin akan membantu kalau istilahnya disingkat menjadi auto-code

• Selalu menarik melihat bagaimana developer yang sangat terampil berinteraksi dengan AI belakangan ini
  @antirez: Di tahap akhir proyek, memperkenalkan fitur regex yang secara kasatmata tampak sebagai fitur terpisah terasa agak aneh. Bisa jelaskan lebih lanjut dasar pertimbangannya?

  • Setelah sadar bahwa array sangat cocok untuk file teks, banyak use case yang bisa kupikirkan akhirnya mentok pada kebutuhan grep di file
    Jadi aku memikirkan apa padanan AROP untuk file, dan jawabannya adalah ARGREP
    Setelah itu, agar alat terbaik bisa dipakai sesuai use case, aku memasukkan baik pencocokan exact yang cepat maupun pencocokan regex
    Lalu aku menemukan bahwa untuk beberapa string yang digabung dengan OR, regex bisa lebih cepat jika dioptimalkan dengan baik, jadi aku sedikit mengkhususkan TRE