Управляйте идеями, а не кодом

Июльский пост 2026 года от Сальваторе Санфилиппо, написанный вскоре после его возвращения в Redis и начала работы над DwarfStar, локальным движком инференса LLM. Его тезис, сначала высказанный в X, а затем развёрнутый здесь: большинство программистов сейчас успевают меньше, чем могли бы, потому что продолжают читать код. Если вы контролируете идеи, лежащие в основе программы, построчно просматривать её функцию за функцией медленно и обычно бессмысленно.

Он аккуратно отделяет этот подход от vibe coding. Vibe coding запрашивает готовый продукт и принимает всё, что вернётся. То, что описывает antirez, находится на противоположном полюсе: вы держите архитектуру в голове, осознанно формулируете промпты и расспрашиваете модель о том, как устроен тот или иной фрагмент ("how is exactly the design of that part? How does it work?"), чтобы проверить, сходится ли ментальная модель. Результат, которым вы управляете, - это дизайн, а не строки.

Аргументация

Три причины отказаться от ревью кода, которые он приводит:

Объём. Сгенерировать сейчас можно куда больше кода, чем прочитать, к тому же вывод LLM обычно ещё и многословен. Ревьюить по 5000 строк в день - нежизнеспособный рабочий процесс.

Сильные и слабые стороны LLM. Они хорошо пишут локально оптимальный код и хуже справляются с крупными идеями (хотя и прогрессируют). Построчное чтение проверяет то, в чём они и так сильны, игнорируя то, где они ошибаются. Разумнее оценивать архитектуру.

Альтернативные издержки. В рабочем дне восемь часов. Время, потраченное на чтение кода, - это время, отнятое у того, что antirez теперь считает главной частью работы: определять, что должна делать программа, искать новые направления, придумывать оптимизации и много тестировать (QA).

Он опирается на The Mythical Man-Month - "controlling the ideas" взят из Брукса, и antirez отмечает, что книга 1970-х годов описывает нынешнюю эпоху точнее, чем почти всё, что было написано с 2000 по 2020 год. Это та же бруксовская линия, которую разбирает no-silver-bullet-llms: принципиальная сложность заключается в архитектуре и концепциях, а не в наборе текста.

Шлак появился задолго до AI

antirez возражает противникам AI, задавая вопрос: почему протестующие сейчас люди не ужасались состоянию софта все последние десять лет? По его мнению, кодовые базы прогнили задолго до появления моделей, поэтому видеть в AI источник шлака - значит не знать истории. Он подозревает, что за этим сопротивлением во многом стоит идеология.

В качестве доказательства он приводит работу над DwarfStar. Он реализовал инференс для двух моделей (DeepSeek v4 и GLM 5.2) с широким применением автоматизации, но настаивает: нельзя просто сказать "реализуй XYZ" и ждать, что всё заработает, - нужно понимать архитектуру, целевую производительность и то, как стыкуются части. Сверяя свою реализацию с другими системами инференса на корректность, он обнаружил, что в чужих системах порой было больше ошибок: тонкие баги во внимании (attention), которые накапливаются и ухудшают вывод модели, сломанные реализации indexed-attention, выполняющие лишнюю работу при превышении определённой длины контекста. Его мысль в том, что строгая архитектура вместе с тестами превосходит ручное написание (или вычитывание) GPU-ядер, а AI больше всего помогает именно в таких быстро меняющихся областях с высоким риском ошибок.

Исключение для Redis

Маттео Коллина (Matteo Collina) задал очевидный вопрос в ответе на исходный твит: разве ты не говорил, что проверяешь весь сгенерированный AI код, попадающий в Redis? antirez отвечает, что да, проверяет, но теперь считает это по большей части бессмысленным - особенно начиная с GPT 5.5 и ещё сильнее с Fable и GPT 5.6. Он всё ещё находит вещи, которые ему не нравятся стилистически (он переписал часть кода при работе над Redis Arrays и делает то же самое для грядущей оптимизации sorted sets, экономящей 50% памяти), но объясняет это вопросом вкуса, а не корректности. Файлы других контрибьюторов по его меркам часто оказываются "куда хуже", хотя их авторы вовсе не плохие программисты.

Он продолжает ревьюить из уважения к пользователям: Redis настолько распространён, что люди будут открывать файлы и править их вручную. Но будь у него развязаны руки, он потратил бы это время на дополнительное тестирование, на следующую идею оптимизации и на то, чтобы LLM написала DESIGN.md для каждой структуры данных - идеи, хитрости реализации, архитектуру простым языком. Именно это, по его мнению, и нужно будущему контрибьютору: прочитать архитектуру, понять идеи, а затем натравить агента на изменения, обладая правильной ментальной моделью. Он также признаёт, что ревью от моделей (Fable, GPT 5.6) найдёт в PR по sorted sets больше реальных ошибок и состояний гонки, чем его собственный просмотр. Redis остаётся исключением, которое он допускает; для большинства же проектов ревью, по его мнению, потеряло смысл.

Единственное сомнение

Исключение, в котором antirez не уверен, - начинающие программисты (джуниоры), которым не хватает опыта для построения ментальной модели. Он не знает, нужно ли им будет глубоко понимать код, но сомневается, что учиться стоит на ревью вывода LLM. Куда лучше, по его мнению, изучать язык, написав небольшой интерпретатор, простую базу данных, хеш-таблицу - выстраивая ментальную модель напрямую. Вычитывание одноразового JavaScript для сайта клиента ничему полезному не учит.

Место в общей картине

Этот тезис приводит к тому же выводу, к которому с другой стороны подошёл simonw-vibe-coding-agentic. Саймон Уиллисон (Simon Willison) с чувством вины признался, что перестал вычитывать каждую строчку даже для продакшена. antirez делает тот же шаг, но без всякого чувства вины: он утверждает, что построчный ревью никогда и не приносил высокой ценности, так что отказ от него - это не деградация стандартов, а исправление курса. Обе публикации очерчивают сдвиг консенсуса среди опытных инженеров в 2026 году: построчный ревью сгенерированного кода уходит в прошлое; остаётся владение архитектурой.

Это также перекликается с clean-code-coding-agents, где утверждается, что чистая структура с агентами важна ещё больше, поскольку грязный код впустую расходует контекст. Противоречия здесь нет: antirez пишет очень чистый код именно для того, чтобы он оставался читаемым, а его предложение о DESIGN.md продиктовано тем же инстинктом, но ориентировано на агента, а не на человека-читателя. Разногласие касается лишь того, куда человеку направлять внимание: статья о чистом коде предлагает проверять структуру, а не корректность, а antirez предлагает не проверять ни то, ни другое, а вместо этого писать документ с описанием архитектуры.

Ракурс с Redis перекликается с redis-cost-of-ambition, написанным парой месяцев ранее о той же работе над sorted sets и arrays с внешней точки зрения: Лейфер (Leifer) воспринял PR с типами массивов как раздувание функциональности, тогда как antirez здесь рассматривает те же PR как обычную поддержку, которую он делает вручную из эстетических соображений.

Из обсуждения

В треде на Hacker News (225 баллов, 189 комментариев) проявился сильнейший контраргумент, на который antirez не отвечает. Несколько комментаторов отметили, что управление на уровне идей работает лишь до определённого масштаба. Один заметил, что моделям "плевать на ваши идеи, они хотят делать то, что популярно в их обучающих данных": они куда лучше поддерживают кодовую базу на Django или React, чем самодельную архитектуру из дизайн-документа, и на объёмах свыше миллиона строк вы получаете три или четыре разные версии одной и той же концепции, разбросанные по всему коду. Комментатор проекта на Rust объёмом 600 тысяч строк возразил: дублирования на масштабе не возникает, если непрерывно рефакторить и опираться на тесты (его кодовая база примерно на 75% состоит из тестов). Разногласие на самом деле упирается в то, переживает ли ментальная модель из дизайн-документа сжатие и длинный контекст, или же модель незаметно скатывается к шаблонам по умолчанию из обучающих данных.

Контраргумент

reviewing-ai-code (Тома Депьер / Thomas Depierre) отталкивается от того же наблюдения: построчный ревью вывода LLM не масштабируется - но делает противоположный вывод. Там, где antirez предлагает отказаться от ревью и держать в руках архитектуру, Депьер утверждает, что ревью - это единственный ответ, который вообще предлагался на проблему "LLM часто ошибаются", и что code-review-throughput-limits делают его невозможным на масштабе; отказ от него не решает проблему корректности, а просто бросает её на произвол судьбы. Оба сходятся в том, что позиция "проверять всё" несостоятельна, но расходятся в том, способно ли что-то её заменить. benchmarking-opus-5-slopcodebench - первый материал в этой вики, способный рассудить их эмпирически: он оценивает, остаются ли ранние чекпоинты модели собираемыми при появлении новых требований, не требуя от модели судить о чистоте кода.

С двух других сторон к этой позиции примыкают ещё два взгляда. why-software-factories-fail отчасти соглашается, но останавливается на полпути: Хорти (Horthy) тоже перекладывает на человека архитектуру, а не строки, но его объяснение того, как обучаются модели для кодинга (награда - один бит за зелёные тесты, а для поддерживаемости быстрого оракула нет), объясняет, почему он продолжает читать диффы там, где antirez готов остановиться. how-do-we-stop-vibe-coding тянет в другую сторону: признавая, что строки - не тот уровень, автор отрицает, что архитектуры в голове достаточно, поскольку ментальная модель загнивает первой. Клос (Klos) хочет вынести идеи наружу в виде артефакта, который можно автоматически проверять на соответствие коду, - по сути, это DESIGN.md от antirez, к которому прикрутили механизм контроля.

Ближайший союзник

claude-is-not-a-compiler (Джош Бличер Снайдер / Josh Bleecher Snyder, июль 2026 года) приходит к той же мысли - держите архитектуру, не читайте строки, - но использует другой метод и даёт частичный ответ на приведённое выше возражение с HN. Вместо того чтобы расспрашивать одну модель об архитектуре для сверки своей ментальной модели, он собирает систему несколько раз параллельными циклами агентов и сравнивает результаты через diff (differential-spec-analysis), исходя из того, что внимания заслуживают как раз те решения, о которых агент даже не спросил. Накапливаемый им документ с набитыми шишками - это то же самое предложение antirez о DESIGN.md, только полученное эмпирически, а не написанное заранее. Он называет эту практику vibe-engineering и настаивает на границе, которую проводит и antirez: решения остаются за инженером, агент лишь удешевляет их принятие.

Тот же тезис как биография

Позже, в июле 2026 года, antirez переформулировал этот тезис на примере Линуса Торвальдса в being-linux-torvalds: редким шагом был отказ от написания кода ради удержания архитектуры, и именно на это место работа с LLM сажает эксперта. Дополнением здесь выступает выпад против vibe coding - не из пренебрежения, а как указание на неверную модель того, чем автоматическое программирование является для человека с готовыми навыками.

Цитаты

If you control the ideas of your software, looking at the code itself is suboptimal and often pointless.

Nobody should anymore look at this code, but only at the ideas the code contains.

It may be a lot more useful if they learn some programming language and implement a small interpreter, a small database, an hash table and so forth.