Разработчик за 4 месяца внедрил новый тип данных Redis

Автор переработал код нового типа данных Array для Redis четыре месяца, начав работу ещё в начале января. В первом месяце он лишь набрасывал спецификации вручную, а затем переключился на ИИ. Сначала автор работал с Opus, но после выхода версии GPT 5.3 полностью заменил дизайн и разработку на инструментарий Codex. С тех пор для задач системного программирования использует только семейство GPT 5.x. Искусственный интеллект помог выработать идеальные компромиссы и определить, какие решения слишком усложнены. Начиная со второго месяца, процесс перешел в фазу автоматического написания кода, однако автор столкнулся с ошибкой в уровне индиректности. Он хотел, чтобы команды выдерживали запросы типа ARSET без огромных выделений памяти, а его прежняя структура из двух уровней директорий не подходила. Благодаря поддержке ИИ автор отказался от компромиссов и изменил внутреннее представление данных на супер-директорию из нарезанных плотных директорий по 4096 элементов. Такая архитектура сохранила логические свойства массива, но улучшила работу команд ARSCAN и ARPOP, которые теперь просматривают только существующие элементы, а не диапазон. Затем автор тщательно проверил каждую строчку кода и нашел множество скрытых неэффективностей. Вместе с ИИ он провел глубокую рефакторизацию модулей, после чего запустил стресс-тестирование. Во время моделирования кейсов автор задумал использовать массивы для хранения файлов, а позже — для создания централизованной базы знаний. Это привело к разработке новой команды ARGREP для работы с регулярными выражениями. Для их реализации он выбрал библиотеку TRE от Ville Laurikari, чтобы исключить патологические паттерны в расходе времени и памяти. Однако TRE показывала плохие результаты на простых случаях вроде foo|bar|zap, поэтому с помощью GPT автор оптимизировал её и добавил проверки безопасности. Глубокое погружение в сложный код позволило автору избежать уровня трудозатрат, который он бы проигнорировал иначе, а ИИ выступил в роли страховки. Автоматизация взяла на себя рутинные задачи, вроде добавления поддержки 32 бит, и сыграла роль виртуальной рабочей силы для поиска ошибок в алгоритмах. Ключевым моментом стало написание первоначальной огромной спецификации, которая стала фундаментом для детального аудита файлов sparsearray.c и t_array.c. В приложении к пулу на GitHub автор детально описывает сценарии использования, поэтому повторяться здесь нет смысла. Остается надежда на быстрое принятие PR, которое откроет новые возможности для платформы, где числовой индекс становится частью семантики данных.