Redis array: 長い開発プロセスの短い話

 (antirez.com)
1 ポイント 投稿者 GN⁺ 2 시간 전 | 1件のコメント | WhatsAppで共有
  • Redisの新しいArrayデータ型の作業は1月初旬に始まり、約4か月後にPRとして提出され、最初の1か月で必要性、C構造体、疎な表現、リングバッファ、ARINSERT向けの配列カーソルの意味を含む仕様が作成された
  • 初期設計はOpusとともに磨き上げられ、GPT 5.3のリリース後はCodexで設計と開発を進め、AIとのフィードバック過程で折衷点や過剰設計された部分を継続的に見直した
  • 実装はARSET myarray 293842948324 fooのような大きなインデックスの設定でも巨大な割り当てなしに動作するよう変更され、内部データ構造は条件に応じてスーパーディレクトリ、スライス化された密なディレクトリ、実際の配列スライスの形へと切り替わる
  • 各スライスは基本的に4096要素を保持し、ARSCANとARPOPは範囲全体のサイズではなく実際に存在する要素数に比例する時間で既存の配列をスキャンできる
  • MarkdownファイルをRedis配列に入れるユースケースがARGREP実装へとつながり、正規表現サポートにはTREを選択し、ユースケースはRedis PR #15162に整理されている

実装とレビュー

  • 2か月目から自動プログラミング方式で実装を始め、生成されたコードを継続的にレビューした
  • 実装が動作した後も、sparsearray.cやt_array.cを含むコードを1行ずつ読みながら見直した
  • AIのおかげでテストは多かったが、表面的に動作するコードが最適であることを意味しないため、小さな非効率や設計ミスを見つけて修正した
  • 複数のモジュールを手作業およびAI支援で書き直し、3か月目にはさまざまな方法でストレステストを行った
  • 高品質なシステムプログラミングでは依然として人間が完全に関与する必要があるが、AIがあれば32ビット対応の追加やテストのような疲労の大きい作業や、複雑なアルゴリズムにある明白なバグ検出でセーフティネットになる
  • 初期の大きな仕様作成はその後の作業の中核であり、コードのすべての行をレビューして合わない部分を修正するうえでも重要だった

ユースケースと正規表現

  • ユースケースをモデリングする中でMarkdownファイルをRedis配列に入れ始め、ファイルは配列データ型と相性がよいという結論に至った
  • エージェント作業に必要なMarkdownファイルベースの中央知識ベースを作るため、**ARGREP**の実装へとつながった
  • 正規表現サポートのためにTREを選択し、Redisで正規表現を使う際に時間や空間の面で病的なパターンがあってはならないという理由があった
  • TREはfoo|bar|zapのような有用なパターンマッチングで非常に非効率だったため、GPTの助けで最適化し、潜在的なセキュリティ問題もいくつか修正し、テストも拡充した
  • ユースケースはRedis PR #15162に詳しく整理されており、数値インデックスが意味の一部になるデータ型がRedisには必要だという結論につながった
  • Array PRがまもなく受け入れられ、新しいユースケースの利点を得られることを期待し、フィードバックを求めている

関連記事

1件のコメント

 
GN⁺ 2 시간 전
Hacker Newsのコメント

  • はっきりさせておくと、これは Redisの作者本人、あるいはその一人がやったことだ
    彼は「平均的な開発者」ではなく、LLMを使っても4か月かかった
    だから、これを根拠にすべての開発者へClaude Code、Codex、そのほかのAIコーディングツールへ完全移行せよと指示してよいという承認印のように受け取るべきではない
    特に普通のスタートアップCEOが見るべき点だ

    • 経験豊富な開発者がコーディングエージェントを巧みに使えば、専門性をさらに増幅できるという、かなり強い根拠には見える
    • 「彼は平均的な開発者ではなく、LLMを使っても4か月かかった」という部分は、原文を見ると少し違う
      原文では「LLM以前でも実装そのものはおそらく4か月以内にできただろう。変わったのは、同じ期間でもっと多くのことができた点だ」と述べていた
      つまり当初の期間はもともと4か月で、LLMのおかげで同じ期間内により多くの作業をこなしたということだ
    • 彼は平均的ではないが、彼の作業も当然ながら平均的な作業ではない
      平均的な開発業務は 配管作業やCRUD に近い

  • 現在使っているやり方はこうだ
    まずAIの助けを借りて 上位設計書 をMarkdownで書く。その後、同じモデルでも文脈を外したり、別のモデルに批判させたりして、バグ・欠落・抜け穴を探させる。後から見れば明らかなことを、いつも見つけてくれる
    それからその発見を要約させて最初のAIに貼り付け、意見を聞く。合意した変更を作って反映し、どのモデルも意味のある提案ができなくなるまで、この敵対的なラウンドロビンを続ける
    その後はAIに計画を作らせ、その計画も複数のAIの間で敵対的に回す。最終的にはかなり堅牢な計画になる
    次にエンドツーエンドのテストケース計画などへ進む。システムの規模によっては、初日、最初の週、最初の月が終わるころにコーディングの準備が整う
    コードができたら、そのコードと仕様、計画を別のAIに貼り付けてバグ・欠落・抜け穴を探させる。実装を担当した主AIを、別のAIで継続的に検証する方式だ
    もちろんコードは自分で読む必要がある。AIが 仕上げ品質の細部の磨き込み を見落とすのを見てきたからだ

    • AI言説では、私たちはまったく新しい 無監督開発パラダイム を開いたということになっているが、実際にはGoogleが10年間コードを書いてきたやり方とほぼ同じだ。ただし、信頼水準の異なる人間の代わりにAIを使っているだけだ
      皮肉を言いたいわけではない。私のワークフローも本質的には同じだし、Googleを笑いたいわけでもない。むしろ新しいことは何もないという意味だ
      AIは効果的なワークフローも非効果的なワークフローも、どちらも猛烈に加速する。そのおかげで、何が効果的で何が非効果的かが、はるかに短時間で、ほとんどリアルタイムに明らかになる
    • そのやり方が、自分で直接コードを書くのと比べて どれくらい速いのか、遅いのか が気になる
    • こうした 仕様駆動開発 はAWS Kiroの中核的な差別化要素だった: https://kiro.dev/docs/specs/
      他のエージェントも使っていると言っていたが、粗い部分を別のエージェントが磨くようなコードレビューで効果を見たのか気になる。私の同僚たちは強く信じているが、個人的には人間のレビューアなしで価値があるのか、まだ懐疑的だ
      「別のAIに聞く」という方式は、応用計算機科学では正・反・合のほうがより適しているのかもしれない: https://en.wikipedia.org/wiki/Dialectic#Criticisms

  • antirezが書いたものだとしても、この程度の機能セットと最小限のPR説明だけで 22,000行のコードレビュー をするのは悪夢のように聞こえる
    Postgresのような主要オープンソースが、なぜメーリングリストで開発されるのか理解できる。途中の設計判断をコミュニティと議論し、関連機能も別パッチに分け、段階的にレビューし、リリース間隔も空けて進めるやり方だ

    • コードはコメント込みで合計 5,000行 だ
      疎配列が2,000行
      t_array コマンドと上位層の実装が2,000行
      AOF/RDBコードが約500行
      残りはテスト、JSONコマンド説明、deps 配下のTREライブラリだ
    • PostgresとRedisは、性格、歴史、貢献のされ方、開発チームが劇的に異なるプロジェクトだ
      実際、主要なRedis機能の大半は筆者が一人で作ったものだ
      しかもレビューアはこの仕事をよく理解しており、報酬もきちんと受け取っている

  • 現在の最高水準のAIを使った私の経験と非常によく似ている。人間の知能や創造性の代替物 にはほど遠いが、協業相手としては極めて有用だ

    • AIは、私がずっと欲しかった ラバーダック・プログラミングのアヒル だとよく言っている
    • コードをほとんど見ずに進めるプロジェクトもある。概念、アルゴリズム、アイデアは自分が握り、質問やヒントを与え、特に製品の方向性を自分が持つ形だ
      しかしRedisはまだそうではない。いつかサーバーソフトウェアでこれが可能になれば、今日の開発のやり方は終わるだろう
      機能、修正、経験の蓄積は依然として価値があるので、プロジェクトとリポジトリは残るだろうが、プログラマーの役割は、これまでLinusがカーネルに対して果たしてきた役割と非常によく似たものになるだろう
      DeepSeek v4推論エンジンのような一部のプロジェクトでは、すでにそのような形で作業している

  • array/regexへの期待があり、LLMで能力を拡張した経験も非常に興味深い。複数のプロジェクトで、静かに似たような試みをしている人は多い
    バイブコーディング と、その反発だけでは、こうした作業スタイルをうまく説明できない

    • 私はエージェントを使ったやり方をまったく バイブコーディング だとは思わない。深く関与しているし、すべてを検証・確認・レビューしているからだ
    • 「バイブコーディング」の問題は、その用語を作った人がかなり具体的な定義を与えたことにある。コードを見ず、ただ「ノリ」でソフトウェアを作ることだ
      ところがすぐに、人々はほぼあらゆる形のAI支援コーディングにこの言葉を使い始め、元の意味は急速に失われた

  • 要するに、もう Redisを信頼できなくなった ということだ
    LLMなしのフォークは誰が作るんだ？

  • 提示されたユースケースの一部は ZSET でも実現できるのではないか？ 性能面の観点は理解できるが、配列が選択的に疎表現を使うように、密な値に対してZSETの格納方式を選択的に最適化すれば、新しいAPIサーフェスなしでも可能だったように思える
    正規表現コンポーネントは興味深いが、ここでも言及されているように、配列データ構造とは直交する機能に見える。つまり他の構造でも使える。これはLuaスクリプティングでやるほうが適切ではないか？ Luaの性能が問題なら、値の範囲を返す何らかのコマンドの上に組み合わせられるよう、OPを抽象化する方法もありそうだ
    Antirezがこの分野の専門家であることは尊重するが、この新機能群の一部は、LLM主導開発でよく見かける解法のように感じる。既存機能を改善するより新機能を作り、ほかの機能と組み合わせたほうが効果的かもしれないのに、機能を過度に複雑にしてしまう感じだ

    • 残念ながらそうではない。ソート済み集合は、スペクトラムのほぼ反対側にある。意味論的にはきれいだが、スキップリストと配列の結合 のため非常に無駄が多い
      また、内部表現が配列でないなら、範囲クエリとリングバッファは必要なだけ効率的かつコンパクトには動作できない
      理論上は何ででも何でもできるが、各APIでできることを分離してこそ、ユースケースを活かした最適な内部実装を提供できる

  • antirezに聞きたい。最終コードとして、事実上の ワンショット生成 を試してみたのか？ GEPAでそこまで行けるのか、望む結果を引き出す誘導やプロンプトのやり方から学べることがあるのか気になる
    あるいは結論として、モデル提供者が学習データを整理すべきだということなのかもしれない

  • Salvatoreは Automatic Programming/Coding という用語を広めたいように見える。(https://antirez.com/news/159)

    • https://en.wikipedia.org/wiki/Automatic_programming は、計算機科学で認められた用語であり、より高い抽象レベルの記述からコードを自動生成する、あらゆるメカニズムを指す
      もちろんLLMは非決定的で、しかも驚くほど広い範囲を持つという点で非常に特殊だが、それでもこの用語が当てはまらないわけではない
    • 同じことを説明する言葉を、私もだんだん減らすようになっている。時間がたつほど、私たちが「その」作業をする頻度が増えているからだ
      ただし用語を auto-code に縮めると役立つかもしれない

  • 非常に熟練した開発者たちが最近AIとどう相互作用しているのかを見るのは、いつも興味深い
    @antirez: プロジェクト後半で、見た目には別機能の 正規表現機能 を導入したのは少し奇妙に感じる。その判断根拠をもう少し説明してもらえるか？

    • 配列がテキストファイルにとてもよく合うと気づいたあと、思いつく多くのユースケースが、結局はファイルに対するgrepが必要だという事実に突き当たった
      そこで、ファイルにおけるAROPに相当するものは何かと考え、答えはARGREPだと判断した
      その後、ユースケースに応じて最適なツールを使えるよう、高速な完全一致と正規表現一致の両方を入れた
      そして、ORで結ばれた複数の文字列では、正規表現の最適化がうまくいけばより高速になり得ると分かり、TREを少し特化させた