Antirez про новый Redis Array: 4 месяца работы и AI как safety net для системного кода
Salvatore Sanfilippo (antirez) опубликовал короткий рассказ о четырёх месяцах работы над новым нативным типом Array в Redis (PR #15162). Главное наблюдение: AI стал «safety net» для системного программирования — позволил не идти на компромисс по архитектуре и вынес часть громоздких задач без выгорания. Перевод.
Salvatore Sanfilippo (antirez) опубликовал короткий рассказ о четырёх месяцах работы над новым нативным типом данных в Redis — Array. Работу он начал в первых числах января. Его наблюдение, ради которого пост и написан: AI стал рабочей опорой («safety net») для системного программирования. Он позволил Сальваторе не идти на компромисс по архитектуре, прогонять громоздкие задачи без выгорания и дотягиваться до уровня сложности, который один человек обычно пропускает. PR #15162 только что приземлился в репозиторий.
Перевод и пересказ короткой заметки автора Redis для русскоязычной аудитории — четыре месяца разработки, изменение внутренней архитектуры в середине пути, ARGREP с регулярными выражениями через TRE и общий вывод про связку «человек + AI» в инфраструктурном коде.
Главное
Что вышло. В Redis приземлился новый нативный тип Array с поддержкой числового индекса как части семантики (PR #15162). Четыре месяца работы; команды ARSET, ARSCAN, ARPOP, ARGREP, ARINSERT.
Спецификация — первое. Месяц ушёл на ручное написание спецификации: обоснование типа, C-структуры, разрежённое представление, семантика курсора для ring buffer и ARINSERT. Сначала с Opus, потом с GPT 5.3 / Codex.
Архитектура поменялась в середине. Изначально были два уровня директорий и slices двух типов (sparse и dense) — этого не хватило для ARSET с очень большими индексами. Перешёл на «super directory of sliced dense directories» с slice по 4096 элементов. Без AI «срезал бы углы» — с AI пошёл на extra mile.
ARGREP с regex. При тестировании Сальваторе начал хранить файлы Markdown в Array — для своей базы знаний. Так появилась идея ARGREP. Взял библиотеку TRE (за гарантии по времени против патологических паттернов), оптимизировал её для матчинга foo|bar|zap и закрыл несколько проблем безопасности.
Главный вывод. AI — не замена человека в системном программировании, но «safety net» для громоздких задач (32-битная поддержка, тесты алгоритмов) и виртуальная команда ревью. Спецификация по-прежнему пишется человеком, и она же ключ ко всем последующим этапам.
Месяц первый: спецификация руками
Сальваторе подчёркивает: даже с AI первый месяц был полностью ручной работой над спецификацией. Документ описывает обоснование нового типа, C-структуры, разрежённое представление, точную семантику курсора для ring buffer и команды ARINSERT.
Дальше пошёл back-and-forth с моделью: сначала с Claude Opus, потом, когда вышел GPT 5.3, переключился на Codex. С тех пор все системные задачи делает только на GPT 5.x. Промежуточные обсуждения с моделью качественно меняли спецификацию: интеллектуальные вызовы про лучший дизайн, что переусложнено, что — недостаточно проработано.
Месяцы второй и третий: автокодинг и пересмотр архитектуры
Со второго месяца Сальваторе начал реализацию через automatic programming (его термин для написания кода с AI-ассистентом): постоянное ревью того, что пишет модель. И тут наткнулся на проблему — выбранный уровень индирекции оказался неправильным.
Изначально была схема: два уровня директорий и slices (sparse и dense). Этого не хватало для сценария вида ARSET myarray 293842948324 foo — то есть когда индекс большой, а массив должен оставаться разрежённым без огромных аллокаций.
Поскольку у меня был AI, я не пошёл на компромисс — решил пройти extra mile.
Под определёнными условиями структура данных меняет внутреннюю форму, превращаясь в super directory из sliced dense directories, которые в свою очередь указывают на сами array slices (по 4096 элементов на slice по умолчанию).
Это и дало одновременно «как настоящий массив» с точки зрения внутреннего представления, и нужные характеристики по памяти. ARSCAN и ARPOP теперь сканируют существующие массивы за время, пропорциональное числу элементов, а не длине диапазона.
Затем — чтение всего кода построчно. Тип покрыт массивным тестированием (опять же с помощью AI), но «работает поверхностно» не значит «оптимально». Сальваторе нашёл много мелких неэффективностей и дизайн-ошибок, которые ему не нравились, и начал процесс ручной и AI-ассистированной перезаписи модулей.
Появление ARGREP — от своей задачи к команде
Когда стресс-тестирование Array на разных кейсах подтвердило, что структура годится, Сальваторе начал моделировать сценарии использования. И тут, как часто бывает, личная задача подсказала фичу: он начал хранить файлы Markdown прямо в массивах — потому что они хорошо ложатся в этот тип.
Параллельно работал с агентами на других задачах и понял, что ему нужна централизованная база знаний из файлов Markdown под нужные навыки. Из своей потребности родился ARGREP. Но захотелось не просто поиска по подстроке — захотелось регулярных выражений.
Выбор библиотеки regex — отдельная история. Сальваторе остановился на TRE от Ville Laurikari: когда regex встраивается в Redis, важно гарантировать отсутствие патологических паттернов по времени и памяти. Но у TRE оказалась неэффективность в одном специфичном и очень полезном кейсе — матчинг alternation вида foo|bar|zap.
С помощью GPT он оптимизировал библиотеку для этого кейса, заодно зафиксил несколько потенциальных проблем безопасности и расширил тесты. После этого ARGREP с честным regex был готов к мержу.
Главное наблюдение: AI как safety net
Сальваторе формулирует главный вывод так: для high-quality системного программирования по-прежнему нужно быть полностью вовлечённым — но AI расширил «зону комфорта». Без него Сальваторе не пошёл бы на тот уровень сложности, который выбрал для нового типа.
AI выступил safety net в двух конкретных аспектах:
- Громоздкие задачи без выгорания. Например, поддержка 32-битной архитектуры, которую он добавил и протестировал отдельно. Это та работа, что обычно отнимает мотивацию и силы — с AI она прошла без обычного истощения.
- Виртуальная команда ревью, которая отлавливает очевидные баги в сложных алгоритмах. Не замена тестам и не замена самому Сальваторе — но дополнительный слой, который ловит «глупости» до того, как они уйдут в код.
При этом Сальваторе подчёркивает: огромная начальная спецификация — ключ ко всему остальному. Без неё невозможно было ни прогнать ревью каждой строки в sparsearray.c и t_array.c, ни решать, что переписывать, ни понимать, какой именно компромисс ты только что принял.
Часто задаваемые вопросы
Что такое Redis Array и зачем он нужен?
Это нативный тип данных в Redis для случаев, когда вам нужен числовой индекс как первоклассная часть семантики — то, что ни Hash, ни Sorted Set, ни List не дают. Внутри он реализован как иерархическая структура: super directory, sliced dense directories и array slices по 4096 элементов. Разрежённое представление автоматически превращается в плотное при определённых условиях. Команды: ARSET, ARSCAN, ARPOP, ARGREP, ARINSERT. Сценарии использования подробно описаны в самом PR #15162.
Что значит «automatic programming»?
Сальваторе вводит этот термин для процесса написания кода с AI-ассистентом. Подчёркивает, что результаты сильно зависят от человека, который ведёт процесс — от его интуиции, дизайн-вкуса, постоянной коррекции и идеи продукта. Это не «vibe coding», когда модели дают общее описание и принимают всё, что она генерирует. Это совместная работа с моделью как с расширением собственного мышления.
Какие модели использует Сальваторе?
Для системного программирования — только GPT 5.x (через Codex). До этого использовал Claude Opus. Для разных задач рекомендует чередовать как минимум две модели: «back-and-forth» между ними помогает увидеть пространство решений с разных углов.
Можно ли сейчас использовать Redis Array?
PR #15162 только что приземлился в репозиторий. Сальваторе пишет: «Надеюсь, Array PR будет принят скоро». Скорее всего, в ближайших релизах Redis тип будет уже доступен. Следить — на redis/redis и в апдейтах проекта.
Что взять на заметку разработчику
- Сначала спека, потом AI. Если задача системная — потратьте первый этап на ручное написание спецификации. AI может качественно её прокачать через диалог, но не сгенерировать с нуля.
- Не идите на компромисс по архитектуре, если AI это закрывает. Громоздкая правильная реализация теперь под силу одному человеку. Если внутреннее представление кажется «не тем» — пересоберите его, пока спека ещё свежая в голове.
- Ревью каждой строки. AI хорош в тестах и поверхностном «работает», но качество кода остаётся за вами. Без построчного чтения после того, как «всё работает», оптимизировать дизайн — на ощупь.
- Чередуйте модели. Хотя бы две (например, GPT 5.x и Claude). Это не страховка от падений API, а способ увидеть проблему с разных углов.
- Следите за тем, что под рукой. Сальваторе нашёл идею ARGREP не через roadmap, а через собственный сценарий: хранил Markdown в Array, понадобился полнотекстовый поиск.
Выводы
История Redis Array — короткий, но содержательный кейс того, как меняется планка инфраструктурного программирования с приходом AI-ассистентов. Не «AI пишет код», и даже не «AI делает программиста быстрее в 5 раз». А «AI убирает потолок сложности, который раньше задавался выгоранием и страхом ошибиться в дальнем углу системы».
Похожий тренд мы недавно разбирали со стороны GitHub: их CTO признал, что план по 10-кратному наращиванию мощностей пришлось переписывать в 30-кратный — потому что объём AI-сгенерированного кода вырос быстрее, чем планировали. Со стороны автора одиночного проекта это выглядит так же: новый этаж сложности достижим без новой команды.
Источник: Redis array type: short story of a long development — antirez.com.
