Один испорченный файл undo в NeoVim снова вытащил на свет старый, но болезненно актуальный вопрос: что такое гуманный интерфейс и есть ли у разработчика обязанность беречь работу пользователя. Повод кажется мелким, пока речь не заходит о более чем десяти годах истории изменений, которые можно потерять из-за несовместимого поведения инструмента.
По данным The Register, спор начался после истории Дэвида Чизнолла, участника проекта CHERI и давнего пользователя Vim. Он включал persistent undo: механизм, при котором редактор хранит историю изменений отдельно и позволяет откатываться не только в пределах текущей сессии, но и спустя недели или месяцы. При попытке перейти на NeoVim редактор перезаписал его файл undo от Vim. Позже Чизнолл уточнил, что предупреждение было, но ожидал от инструмента безопасного поведения. Это ожидание и стало главной точкой конфликта.
Чизнолл связал случившееся с первым законом Джефа Раскина: компьютер не должен вредить работе пользователя или своим бездействием позволять ей пострадать. Раскин, один из ключевых людей раннего проекта Macintosh в Apple, сформулировал свои три закона в книге The Humane Interface, вышедшей в 2000 году. Они явно отсылают к законам робототехники Айзека Азимова из рассказа Runaround, опубликованного в 1942 году: только вместо роботов речь идёт о программах, интерфейсах и цене ошибок в повседневной работе.
Три закона Раскина звучат предельно приземлённо. Компьютер не должен портить вашу работу. Компьютер не должен тратить ваше время и заставлять делать больше, чем нужно. Интерфейс можно считать гуманным, если он учитывает человеческие потребности и слабости. В 2026 году это уже не манифест для дизайнеров оконных систем, а базовый чек-лист для любого инструмента, которым пользуются разработчики, аналитики, редакторы, инженеры инфраструктуры и все остальные люди, у которых рабочий день и так не резиновый.
С NeoVim история получилась особенно нервной, потому что редакторы кода для многих разработчиков не просто программы, а почти продолжение руки. Vim десятилетиями держал совместимость поведения вокруг undo, и Чизнолл прямо указал, что привык не думать о сохранности этой истории. В этом и суть доверия к инструменту: пользователь не обязан каждый раз проводить мысленный аудит форматов, путей хранения и вариантов повреждения данных, особенно если программа работает в зоне, где цена сбоя измеряется годами накопленного контекста.
Реакция сообщества предсказуемо раскололась. Часть пользователей NeoVim восприняла критику как нападение на любимый инструмент. The Register отдельно упоминает раздражение сторонников NeoVim и спор вокруг того, что редактор рекомендован в Omarchy, а на сайте проекта до недавнего времени использовалась цитата DHH. После резкой дискуссии эту цитату убрали примерно в те же дни, когда появились посты Чизнолла и Марцина Вихары о долге заботы перед пользователем. Для open source это знакомый сюжет: техническая правота, предупреждения в документации и реальные ожидания пользователей часто живут в разных комнатах.
Важная деталь: спор не про то, хороший NeoVim или плохой. Он про то, где проходит граница ответственности между автором инструмента и человеком, который на него опирается. Формально можно сказать: было предупреждение, пользователь сам рискнул, формат мог отличаться. Практически же разработчики знают, что такие ответы плохо масштабируются. Если программа может уничтожить или перезаписать ценные данные, безопасный вариант должен быть поведением по умолчанию: создать копию, отказаться от операции, потребовать явного подтверждения с понятным описанием последствий, использовать отдельное хранилище.
Для русскоязычной IT-аудитории в этой истории есть очень прикладной урок. Команды часто обсуждают DX, скорость поставки, качество CI, удобство внутренних платформ, но редко формулируют простой принцип: инструмент не должен наказывать пользователя за доверие. Это касается не только редакторов. Миграции баз данных, автогенераторы конфигов, панели управления облаками, CRM, HR-системы, low-code-платформы и внутренние админки каждый день принимают решения, которые могут сберечь или уничтожить чью-то работу.
Отдельный слой спора — старая культура Unix и C, где сложность часто воспринимается как плата за мощность. The Register пишет об этом жёстко: в такой школе дизайна есть элемент мачизма, удовольствия от освоения неудобного инструмента. Для опытных инженеров это может быть частью профессиональной идентичности. Для бизнеса это уже риск: если продукт требует героизма от пользователя, он дороже в поддержке, хуже внедряется и чаще ломает процессы там, где никто не ждал поломки.
Гуманный интерфейс не означает примитивный интерфейс. Он означает предсказуемый, бережный и честный. Сложные инструменты могут оставаться сложными, но они не должны молча перезаписывать историю, скрывать необратимые действия за туманными предупреждениями или считать внимательность пользователя последней линией защиты. Особенно в разработке, где один неудачный дефолт способен испортить не файл, а доверие к целому стеку.
Законы Раскина пережили Macintosh, Canon Cat, эпоху десктопов, веб-приложения и нынешний всплеск генеративных ассистентов. Похоже, их придётся заново прикладывать к каждому новому слою софта: от терминальных редакторов до AI-инструментов, которые уже пишут код, меняют проекты и предлагают правки. Следующий большой вопрос для разработчиков звучит не про функции, а про заботу: умеет ли наш инструмент остановиться до того, как пользователь потеряет работу?