Slow Software: в защиту медленной разработки систем

Июльская запись 2026 года в блоге SIGOPS от Айрин И. Чжан, занимающейся системами со сверхнизкой задержкой (Demikernel, Cornflakes, Capybara). Её тезис идёт вразрез с устоями собственной области: разработку самой критичной инфраструктуры следует намеренно замедлять. Трение, которое раньше возникало само собой, исчезло, и Чжан предлагает вернуть часть этих барьеров осознанно.

Разрушенная связь

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

Эти барьеры создавали грубую, но важную, по мнению Чжан, корреляцию: чем больше софта зависело от системы, тем больше сил требовалось на её создание, и чем шире был радиус поражения при сбое, тем больше времени естественным образом уходило на его предотвращение. Важность и время разработки двигались рука об руку.

За двадцать лет эти препятствия исчезли одно за другим. Гиперскейлеры развёртывают оборудование непрерывно. Облачный софт релизят еженедельно или чаще. ИИ пишет системный код, минуя рутину базовых инструментов. В итоге важность компонента теперь полностью отвязана от времени, нужного на его написание. Та же тяга к внедрению ИИ одинаково применяется к тестовой инфраструктуре, сетевой маршрутизации, управлению дата-центрами и операционным системам - коду с принципиально разной ценой ошибки, который теперь пишется с одинаковой скоростью.

Почему это бьёт именно по системному уровню

Конкретный пример Чжан - согласованность данных. Распределённые системы опираются на гарантии нижележащего слоя хранения, а эти гарантии часто представляют собой слабые, плохо задокументированные модели согласованности. ИИ не способен корректно рассуждать о них, не держа в контексте всю кодовую базу системы хранения - базу, которая может быть недоступна и сама постоянно меняется. В результате модель меняет код так, что нарушает предположения о согласованности, а программист, тоже не держащий эти нюансы в голове, бездумно пропускает правку. Всё выглядит нормально ровно до момента, пока широкий радиус поражения не обрушит каждый сервис, доверявший сломанному компоненту.

Её аналогия: мы охотно пользуемся вещами, сделанными быстро и дёшево (полуфабрикаты, IKEA), но при этом хотим иметь и то, что так не делается (свежие овощи, дороги и мосты). Проблема в том, что обычно мы не видим разницы, пока не случится беда - проблемы со здоровьем или рухнувший мост. В софте кроется та же ловушка: нет надёжного способа заранее, до первого сбоя, отличить критическую инфраструктуру от всего остального.

Предложение: трение как преимущество

В качестве решения она предлагает движение "slow software" по аналогии со slow food. Суть не в том, чтобы затормозить разработку вообще всего. Нужно вычленить важную инфраструктуру, где медленная разработка - плюс, а не минус, и снова связать важность со временем сборки. Чем больше зависимостей у компонента, тем больше сил должно уходить на его создание; чем тяжелее последствия сбоя, тем больше усилий нужно прикладывать, чтобы его избежать.

Опытные инженеры уже делают этот выбор по наитию - она ссылается на Марка Руссиновича, говорившего об умении понимать, какой код нужно читать внимательно, а какой можно пропустить, и о ценности наставничества для передачи этого чутья. Однако Чжан считает, что эту интуицию необязательно нарабатывать годами проб и ошибок. Вместо исчезнувшего естественного сопротивления среды она предлагает внедрить искусственные барьеры в само окружение разработки: осознанное трение, требующее от программиста личной ответственности до того, как он закоммитит изменения во что-то критичное. Издержки быстрой системной разработки вполне реальны; главный шаг Чжан - сделать эти издержки видимыми прямо в процессе написания кода, а не постфактум, когда всё уже сломалось. Быстрое написание на старте лишь откладывает боль на потом - и больнее всего бьёт по молодым разработчикам, которым этот код предстоит поддерживать.

Она подчёркивает, что это не позиция против ИИ. ИИ отлично подходит для прототипирования и рутинного шаблонного кода: скриптов сборки, тестовых стендов, фреймворков оценки, перебора пяти алгоритмов кэширования без ручного написания каждого. У такого кода маленький радиус поражения, поэтому он и должен делаться быстро. Разделение строится по радиусу поражения, а не по используемым инструментам.

Взгляд со стороны академических исследований

Та же эрозия затронула и академические исследования систем. Раньше создание прототипа стоило дорого, поэтому идея, дошедшая до реализации, обычно заслуживала публикации. Теперь прототипы дёшевы, и конференции завалены сырыми статьями: исследователи сначала пишут код и подают заявку, перекладывая сложный вопрос о жизнеспособности идеи на плечи рецензентов. Это всё равно что пытаться по макету здания определить, простоит ли оно десятилетия непогоды. Опытные рецензенты иногда способны вынести вердикт, но этот сдвиг перекладывает самую тяжёлую часть исследовательской работы со студентов на проверяющих и приводит к выгоранию последних. Чжан призывает найти искусственный регулятор на замену былой трудоёмкости прототипирования, а также заняться исследованиями того, как оценивать системы по критериям поддерживаемости и практичности, а не только по производительности и универсальности.

Связи с другими идеями

Этот тезис перекликается с рядом других страниц. В peril-of-laziness-lost схожая мысль подаётся под индивидуальным углом: Кантрилл отмечает, что LLM лишены продуктивной лени, к которой человека вынуждает ограниченность времени, из-за чего бесконтрольная генерация раздувает системы; Чжан утверждает то же самое на системном уровне и предлагает восстановить утраченное ограничение архитектурно, а не надеяться на его случайное возвращение. В credibility-as-slop-test показано, что защитой от дешёвого правдоподобного контента выступает артефакт человеческого масштаба, за который автор ручается лично; искусственные барьеры Чжан - это системно-инженерный вариант той же идеи использования трения как фильтра. agentic-coding-fatigue описывает трение, которое оператор испытывает невольно в виде усталости от принятия решений, тогда как Чжан хочет вводить трение намеренно в точках наибольшей ответственности. А no-silver-bullet-llms подкрепляет это количественно: метрики нестабильности от DORA и CircleCI - это и есть проявление "широкого радиуса поражения при слишком быстрой разработке" на масштабе индустрии.

В we-are-not-special показана цена такого подхода. Собеседники Хиллела Уэйна рассказывают, что на программное обеспечение привыкли полагаться именно из-за максимальной скорости итераций: программиста зовут спасать положение, когда электроника или механика работают с перебоями. Его пример - Boeing 737 MAX, где система MCAS появилась лишь потому, что проблему с аэродинамикой обнаружили поздно и решили закрыть её программной заплаткой. Этот перекос возник задолго до ИИ; Чжан лишь показывает, что отвязка времени разработки от её важности сделала проблему повсеместной.

Нерешённым остаётся конкретный механизм. Чжан очерчивает контуры решения - искусственные барьеры, регулирующие фильтры, удобство поддержки как первоклассный критерий оценки, - но признаёт, что готовых деталей у неё нет. Есть лишь уверенность, что сообщество разработчиков систем уже не раз пересматривало свои практики и способно сделать это снова. Запись на Lobsters не собрала комментариев, так что взвешивать контраргументы пока рано.