29 июня 2026 года сооснователь Heroku и автор концепции 12-Factor App Адам Уиггинс публично выступил уже не в защиту очередного облачного паттерна, а за local-first архитектуру. В подкасте, как пишет InfoQ, он предложил пересобрать привычную модель разработки вокруг офлайн-работы, низкой задержки и более жесткого контроля пользователя над своими данными. Для русскоязычной IT-аудитории это важный сигнал: человек, который когда-то помогал нормализовать облачный подход, теперь довольно прямо говорит, что ставка на «все в облаке» зашла слишком далеко.
Суть позиции Уиггинса не в отрицании облака. Он не предлагает вернуться в эпоху файлов на флешке и локальных папок без синхронизации. Его тезис аккуратнее и потому опаснее для статус-кво: облако должно остаться, но перестать быть единственной точкой истины для пользовательского софта. По его словам, многие цифровые инструменты проигрывают не потому, что у них мало AI или плохой дизайн, а потому что базовая архитектура делает их зависимыми от сети, центрального сервера и чужого решения о том, когда и как пользователь получит доступ к собственным данным.
Уиггинс говорит об этом не как внешний критик. Heroku в свое время был одним из символов раннего облачного сдвига: платформа упростила деплой, автоматизировала инфраструктурные ритуалы и фактически помогла индустрии привыкнуть к мысли, что серверная часть может жить где-то далеко и это нормально. Позже, уже в исследовательской лаборатории Ink & Switch, Уиггинс занялся другой проблемой: как совместить удобство URL-шеринга, совместного редактирования и постоянной синхронизации с тем, что классическое локальное ПО до сих пор делает лучше облачных сервисов, а именно скоростью отклика, офлайн-доступом и предсказуемым владением данными.
Ключевой технический аргумент здесь связан с CRDT — структурами данных, которые позволяют нескольким копиям состояния сходиться без центрального арбитра и без болезненных конфликтов на каждом шаге. Еще несколько лет назад разговоры о CRDT часто оставались в зоне академических докладов, экспериментальных редакторов и красивых демо. Уиггинс утверждает, что эта стадия пройдена: технология дозрела до производственного уровня. В качестве признака зрелости он указывает на то, что подобные подходы уже используются в реальных продуктах, а не только в исследовательских лабораториях. Для разработчиков это, пожалуй, главный практический вывод из всей беседы: local-first архитектура перестает быть идеологией для энтузиастов и начинает выглядеть как нормальный инженерный выбор в задачах, где задержка и автономность действительно влияют на ценность продукта.
Второй сильный тезис Уиггинса касается систем контроля версий за пределами кода. Он прямо говорит, что следующий крупный скачок продуктивности может прийти не из очередного чат-бота, а из переноса примитивов Git-подобной работы в документы, таблицы и другие «некодовые» артефакты. Ветка, слияние, diff, история изменений, возможность безопасно экспериментировать без страха сломать общее состояние — для разработчиков это повседневность, а для остальных офисных инструментов до сих пор почти роскошь. Да, в текстовых редакторах есть история версий, а у юристов — redlining, но это фрагменты, а не полноценная модель работы. Если такая логика действительно придет в массовые продуктивити-инструменты, выиграют не только инженеры. Продуктовые команды, аналитики, редакции, исследователи и операционные подразделения смогут работать с данными и документами так, будто это тоже репозиторий, а не хрупкий общий файл, который все боятся трогать.
Отдельно Уиггинс заходит на территорию, где сейчас особенно много шума, — AI-интеграции. Его позиция здесь тоже идет против доминирующего тренда на тотальную централизацию. Он предполагает гибридную модель, в которой небольшие локальные модели берут на себя основную массу рутинных задач, условные 80% пользовательской продуктивности, а большие облачные LLM подключаются только там, где действительно нужен тяжелый inference. В этой логике AI перестает быть исключительно сервисом «сходи в дата-центр и спроси разрешения», а становится частью локальной вычислительной среды пользователя. Для бизнеса это означает более интересную экономику: меньше постоянной зависимости от внешнего API, ниже риски по задержке и приватности, понятнее сценарии работы в средах с ограниченным интернетом или жесткими требованиями к данным.
Здесь, конечно, нет серебряной пули, и Уиггинс это отдельно признает. Local-first архитектура подходит не для любого класса систем. Есть домены, где централизованная модель проще, дешевле и честнее с точки зрения эксплуатации. Есть продукты, где офлайн-режим не дает заметной пользы, а локальное хранение только усложняет поддержку. Есть команды, которым рано тащить CRDT и распределенную синхронизацию, потому что они еще не решили базовые вопросы продуктовой модели. Но для инструментов совместной работы, редакторов, knowledge-систем, внутренних приложений и софта с высокой ценой задержки этот подход все чаще выглядит не экзотикой, а способом сделать продукт банально лучше. И это уже вопрос не архитектурной моды, а конкурентного преимущества.
Для российского и русскоязычного рынка разговор особенно практичный. Здесь прекрасно понимают цену офлайн-режима, чувствительность к инфраструктурной зависимости и необходимость держать критичные пользовательские сценарии ближе к устройству, а не только к чужому облаку. Поэтому слова Уиггинса интересны не как красивая смена идеологического флага, а как признак более широкого разворота отрасли: после десятилетия поклонения cloud-native индустрия начинает заново учиться строить софт, который сначала полезен пользователю, а уже потом удобен платформе. Если этот сдвиг закрепится, то главным вопросом ближайших лет будет не «чем заменить облако», а какие продукты первыми смогут превратить local-first архитектуру из инженерной идеи в заметное рыночное преимущество.