Гибкий софт: прочная база + собственный код

Рынок инструментов для продуктивности переживает очередной тектонический сдвиг. ИИ снизил порог входа в разработку настолько, что полноценную ОС на нём пока не соберёшь, а вот небольшое приложение для личных задач — вполне. Сложнее становится, когда в уравнение добавляется «командная работа»: в одиночку можно ломать и переделывать до тех пор, пока результат не устроит, а вот в команде внезапно нужны хранилище данных со связями, одновременное редактирование, уведомления, история изменений, права доступа — то есть весь набор атрибутов совместной работы.

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

Представим небольшую грибную ферму с десятком сотрудников (пусть выращивают шампиньоны), которой нужен софт для управления всеми процессами. Скорее всего, там используют Google Sheets — рынок слишком узкий для специализированного софта (хотя, как оказалось, слишком узких рынков не бывает: специализированные инструменты для грибных ферм всё же существуют).

Вариантов несколько. Ирония в том, что ни один из них не идеален.

1. Собрать с нуля (Claude Code, Codex) — с 2024 года.
   1. Проблема: при промпт-кодинге с нуля приходится думать обо всём — хостинге, авторизации, базовых правах доступа, базе данных. Первые 80% даются легко, а вот последние 20% — тяжело.
   2. Надежда на будущее: в конце концов ИИ станет настолько мощным, что будет делать всё правильно и быстро.
2. Vibe-coding (Lovable, v0) — с 2023 года.
   1. Проблема: чуть лучше первого варианта, поскольку сразу есть хостинг, база данных, авторизация и деплой из коробки, и приложение выглядит готовым быстрее. Но как только требования выходят за пределы возможностей генератора — упираешься в стену.
   2. Надежда на будущее: более мощные модели улучшат ситуацию, а сами вендоры будут добавлять всё больше компонентов, смещаясь в сторону «прочная база + кастомный код».
3. Low-code и конструкторы приложений (Retool, Softr) — с 2017 года.
   1. Проблема: эта категория уже десять лет продаёт «прочную базу + кастомный код»: авторизация, права доступа, хостинг и журналы аудита из коробки. Но это база приложения, а не база работы. Предполагается, что данные живут где-то в другом месте, а даже когда такие вендоры добавляют собственную базу данных, там хранятся данные приложения — без совместной работы, комментариев и истории изменений.
   2. Надежда на будущее: движение глубже в сторону «прочная база + кастомный код». Открытый вопрос — сможет ли база приложения достаточно быстро вырасти в базу для работы.
4. Собрать в гибком инструменте (Notion, Fibery) — с 2013 года.
   1. Проблема: выглядит заманчиво, поскольку многое уже готово из коробки. Сложность в том, чтобы подогнать инструмент под свой процесс. Такие инструменты достаточно гибкие, но могут не покрывать специфические потребности — не хватает точек расширения.
   2. Надежда на будущее: добавить больше точек расширения и дать пользователям vibe-кодить недостающие ~20% сценариев — тогда эти инструменты тоже окажутся на территории «прочная база + кастомный код».
5. Купить специализированный инструмент — с 1999 года.
   1. Проблема: по-прежнему хороший вариант, если специализированный инструмент создан именно под вашу область и хорошо ей соответствует. Подходит, если кастомизация не нужна.
   2. Надежда на будущее: движение в сторону гибкости для таких вендоров почти невозможно (да и не нужно). Как только инструмент становится универсально гибким, он перестаёт быть специализированным.

80% прочной базы + 20% кастомного кода

Что происходит на рынке инструментов для продуктивности? Похоже, идеальное решение — иметь прочную базу, покрывающую 80% (базы данных, права доступа, история, совместная работа, уведомления), и позволять пользователям комбинировать эти элементы и расширять их кастомным кодом.

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

Прочные базы

Раньше единственными прочными базами были компилятор и ОС — всё остальное оставалось вашей проблемой. Прекрасное время настоящих хакеров!

Теперь есть роскошь более высоких абстракций. Самый интересный вопрос — где остановиться. Например, специализированный инструмент без какой-либо кастомизации максимально прочен, но именно отсутствие кастомизации во многих случаях делает его непригодным. С Codex прочная база практически отсутствует, зато выразительная сила огромна и можно построить почти всё что угодно (выразительная сила — это то, насколько сильно можно подогнать инструмент под свои точные нужды).

Обе крайности неоптимальны для рынка инструментов продуктивности — нужно искать золотую середину.

Прочная база должна покрывать то, что одинаково для любой команды, а кастомный код — то, что делает вашу команду уникальной.

Текущие прочные базы различаются по сути:

• Vibe-coding платформы дают техническую базу (серверы, необработанная база данных, авторизация)
• Low-code платформы дают базу приложения (UI-компоненты, коннекторы, контроль доступа)
• Гибкие инструменты дают рабочую базу (сами данные хранятся там же, вместе со всем, что нужно команде вокруг этих данных)

Ниже — более подробная таблица всех вариантов. Символ ★ отмечает то, что определяет саму категорию — причину её существования.

Кастомный код

Если база покрывает то, что одинаково для любой команды, кастомный код покрывает остальное: уникальные интерфейсы (экран сбора урожая для планшета в теплице), бизнес-логику (правила качества партии грибов), интеграции (API оптового клиента, датчики влажности). Эти 20% невелики по объёму, но это именно ваша компания, и ни один вендор никогда не смоделирует её точно правильно.

Неожиданное возвращение кода вместе с LLM в конце 2025 года привело к иронии: теперь все no-code и low-code инструменты всё больше полагаются на код!

Но кастомный код работает хорошо только при выполнении условий:

• Он наследует базу. Права доступа, история и целостность данных применяются к кастомному коду автоматически. Если каждому сгенерированному приложению нужны собственная авторизация, хранилище и журнал аудита — дело плохо.
• Он ограничен. Кастомный код может сломать сам себя, но не может повредить базу (а в случае повреждения откат должен быть простым). Плохое приложение должно быть неудобством, а не инцидентом с потерей данных.

ИИ-кодинг уже породил две новые категории инструментов (в духе Codex и в духе Lovable), но он же даёт low-code и no-code инструментам возможность решать проблемы кастомизации быстрее, проще и глубже. Раньше расширения через кастомный код давались тяжело (вспомним экосистему плагинов Jira), а теперь это может быть легко.

Куда движется рынок инструментов продуктивности?

У программистов всегда была полная выразительная сила, но даже они не создают много персональных инструментов — просто потому что это отнимает много времени. Теперь ситуация меняется, и полезный персональный инструмент можно vibe-кодить за часы.

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

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

Все стремятся в одну и ту же территорию, но пути разные:

• Vibe-code инструментам предстоит построить базу. Пересборка прочных баз пока занимает много времени и является условием жизнеспособности решения.
• Гибким инструментам предстоит добавить выразительной силы. Пока им не хватает гибкости, чтобы дать пользователям нужную им свободу.
• Low-code инструментам нужно и то, и другое. Сейчас они посередине и должны двигаться в обе стороны.
• Возможно, ИИ «с нуля» сделает всю эту карту неактуальной — но пока нет.

Кто из вендоров или сегментов доберётся до этой территории первым и хватит ли там места на многих? Ставка на то, что места хватит: прочные базы различаются по сути — одни строятся для ИТ-отделов, собирающих внутренние инструменты, другие для команд с интенсивной совместной работой, третьи для энтузиастов, решающих собственные задачи.

Если выбираете инструмент сегодня…

Год назад было 3 варианта, теперь их 5.

Работаете в одиночку? Можно vibe-кодить с удовольствием. Специализированный инструмент покрывает 90% процесса? Купите его. Но для команды с развивающимся процессом, как та грибная ферма, сегодня стоило бы начать с гибкого инструмента. База уже есть — партии, заказы, история, права доступа. А недостающие 20% с каждым месяцем всё легче vibe-кодить. Например, с Fibery Custom Apps можно очень быстро получить кастомизированный интерфейс под многие сценарии.

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

Итоги

В 2019 году ставка была сделана на no-code инструменты, в 2025-м код неожиданно вернулся. Это возвращение переворачивает рынок. Долгие годы вендоры продавали интерфейсы, а база (хранилище, права доступа, история) оставалась скучной сантехникой под капотом. Теперь интерфейсы генерируются за минуты, а построение базы всё ещё занимает годы.

Новые ставки таковы:

• Прочные базы + кастомный код выигрывают рынок продуктивности
• У гибких инструментов хорошие шансы добраться туда первыми, поскольку добавление точек расширения занимает кварталы, а построение прочной базы — годы

Проверить эту гипотезу можно будет к 2030 году — тогда станет ясно, избавилась ли та самая грибная ферма от своих таблиц.

P.S. Это эссе рассматривает гибкий софт со стороны рынка продуктивности. Со стороны исследований стоит заглянуть в манифест Ink & Switch «Malleable Software» и в текст Джеффри Литта «Malleable software in the age of LLMs».