Когда создание программ перестало быть привилегией программистов

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

AI-конструкторы ломают эту экономику. Руководитель отдела может собрать интерфейс, базу и автоматизацию там же, где возникла задача, — не переводя её через несколько этажей исполнителей. Интересно здесь не то, что очередной лендинг делается за вечер. Впервые сами бизнес-подразделения получили средство производства собственного софта.

Вопрос «можем ли мы это сделать?» всё чаще сменяется другим: «что именно мы сейчас строим — удобную одноразовую утилиту или будущую часть бизнеса?» В этой новой точке и находятся вайбкодинг, no-code и профессиональная разработка с AI.

Теперь софт можно не покупать, а собирать под себя

Раньше человек объяснял задачу аналитику или разработчику, а тот переводил её на язык схем, интерфейсов и программного кода. Теперь часть этого перевода делает искусственный интеллект.

Условно современные инструменты можно разделить на четыре группы.

AI-конструкторы приложений. Lovable, Base44, Replit Agent, Bolt и похожие сервисы создают web-приложение по текстовому описанию. Они могут собрать интерфейс, авторизацию, базу данных, серверную логику и опубликовать результат. Пользователь уточняет требования в чате: «добавь роли менеджера и руководителя», «сделай фильтр по дате», «отправляй уведомление после новой заявки».

No-code и low-code платформы. Bubble, Glide, Softr, Retool и другие системы позволяют собирать интерфейсы и бизнес-логику из готовых блоков. Кода мало или нет совсем, но правила, данные и связи между экранами всё равно проектирует человек.

Конструкторы автоматизаций. n8n, Make и Zapier соединяют CRM, таблицы, почту, мессенджеры и внешние API. Например, новая заявка с сайта может автоматически попасть в CRM, пройти классификацию с помощью LLM, назначиться менеджеру и запустить персональное письмо.

AI-инструменты для разработчиков. Cursor, Claude Code, GitHub Copilot, Codex и другие агенты ускоряют работу с полноценным кодом. Это уже не «разработка без программиста», а усиление инженера: AI пишет заготовки, тесты, миграции, помогает искать ошибки и проводить рефакторинг, а специалист отвечает за решения и результат.

Границы между группами размываются. Конструкторы дают доступ к коду, среды разработки получают визуальные редакторы, а платформы автоматизации — AI-агентов. Важнее не название сервиса, а то, кто контролирует архитектуру и кто отвечает за систему после публикации.

Lovable, Base44 и Replit: три разных представления о разработке

Со стороны эти платформы выглядят почти одинаково: поле для промпта, через несколько минут — работающий интерфейс, рядом кнопка Publish. Но сходство заканчивается на пользовательском опыте. Lovable, Base44 и Replit по-разному отвечают на фундаментальный вопрос: сколько технической реальности нужно показать человеку, который хочет получить программу, а не профессию разработчика?

Lovable: продуктовая мастерская, из которой можно забрать проект

Lovable ориентирован прежде всего на web-приложения: кабинеты, маркетплейсы, CRM, SaaS-сервисы, лендинги с логикой и внутренние системы. Пользователь описывает продукт на обычном языке, прикладывает референсы или скриншоты, а платформа создаёт интерфейс и помогает последовательно добавлять данные, авторизацию, загрузку файлов, платежи и интеграции.

Концептуально Lovable находится между конструктором и командой web-разработки. От конструктора здесь — диалоговый способ работы и немедленный визуальный результат. От разработки — исходный код, история изменений и возможность продолжить работу в обычной IDE. Код можно синхронизировать с GitHub или GitLab в обе стороны: изменения из Lovable попадают в репозиторий, а изменения разработчика в основной ветке возвращаются в проект. Это важное отличие от систем, где приложение существует только внутри закрытого визуального редактора (документация Lovable о Git-синхронизации).

Самый короткий путь в production — остаться внутри Lovable. Кнопка Publish создаёт постоянный адрес на lovable.app; на платном тарифе подключается собственный домен, HTTPS настраивается автоматически. Для backend-части можно использовать Lovable Cloud: управляемую среду с базой, авторизацией, файловым хранилищем, realtime-обновлениями и серверными функциями на открытом фундаменте Supabase. То есть публикация здесь — не просто выгрузка HTML, а запуск приложения вместе с необходимой инфраструктурой (Lovable Cloud, публикация проекта).

При этом Lovable предлагает сравнительно ясный путь наружу:

• гибридный вариант: frontend работает, например, в Vercel, Netlify, Cloudflare или корпоративном облаке, а база и backend остаются в Lovable Cloud либо в управляемом Supabase;
• полный self-hosting: frontend разворачивается в Docker, Kubernetes, на виртуальной машине или внутренней платформе компании; backend и данные переносятся, например, в self-hosted Supabase;
• полный уход с платформы: репозиторий продолжает жить как обычный программный проект, а Lovable больше не участвует в разработке.

Это не означает, что перенос происходит одной кнопкой. Схему базы можно перенести миграциями, но сами данные и файлы придётся экспортировать; OAuth, секреты и внешние интеграции — перенастроить; пароли пользователей выгрузить нельзя, поэтому может понадобиться их сброс. После переезда команда сама отвечает за резервные копии, обновления, безопасность, мониторинг и восстановление. Lovable умеет подготовить Docker-конфигурацию, но не запускает и не проверяет её за владельца проекта (варианты внешнего развёртывания).

Иными словами, созданное в Lovable приложение можно разместить on-premise, а сам Lovable — нет. Редактор и AI-агент остаются облачным сервисом и не устанавливаются в контур заказчика или его VPC. Для многих компаний этого достаточно: разработка идёт в SaaS, а production-система и данные находятся на собственной инфраструктуре. Для организаций, которым запрещено передавать код и контекст разработки внешнему сервису, ограничение уже принципиально.

Base44: приложение как готовый облачный комплект

Base44 делает более радикальную ставку на цельность. Пользователю предлагают думать не о frontend, backend и инфраструктуре, а сразу о сущностях бизнеса: клиентах, заказах, ролях, статусах, кабинетах и правилах доступа. Платформа сама связывает интерфейс с NoSQL-базой, авторизацией, realtime-обновлениями, файлами, серверными функциями и интеграциями. Встроенные возможности закрывают типовые вызовы AI-моделей, генерацию изображений, отправку писем и безопасное обращение к внешним API (обзор backend-возможностей Base44).

В этом и состоит замысел Base44: не столько сгенерировать код, сколько убрать из поля зрения сборку программного стека. Поэтому первая версия особенно быстро появляется у продуктов, где основная сложность выражается через данные и бизнес-процесс: каталоги, формы, кабинеты, небольшие маркетплейсы, операционные панели, сервисы бронирования.

Приложение получает адрес вида myapp.base44.app сразу после создания и уже доступно по ссылке. Команда Publish App отделяет текущую опубликованную версию от изменений в редакторе. На платном тарифе можно подключить свой домен, но DNS в этом случае всё равно указывает на инфраструктуру Base44: красивый адрес меняет вывеску, а не место, где работает система (быстрый старт Base44, подключение домена).

Код frontend можно скачать ZIP-архивом или синхронизировать с GitHub, дорабатывать локально и разместить у другого хостинг-провайдера. Можно даже построить свой frontend на другом фреймворке и обращаться к Base44 через SDK. Однако штатная production-модель backend остаётся облачной: SDK по умолчанию обращается к сервису Base44, а функции публикуются в его serverless-среду. Локальный backend существует для разработки и тестов; часть возможностей — OAuth, AI и некоторые интеграции — даже в этом режиме перенаправляется в уже развёрнутое облачное приложение (локальная разработка, настройка SDK).

Поэтому практический ответ такой: frontend Base44 можно вынести на внешний хостинг, но полноценный Base44 backend on-premise не является штатным вариантом production-развёртывания. Чтобы целиком уйти в собственный контур, недостаточно экспортировать экраны: придётся заменить базу, авторизацию, хранение файлов, realtime, функции и интеграции, а затем адаптировать код, завязанный на Base44 SDK. Это уже миграция системы, а не смена хостинга.

Такая зависимость не обязательно плоха. Она и покупает скорость: пока платформа управляет всем комплектом, предпринимателю не нужно собирать его по частям. Но до запуска продукта полезно понимать, что экспорт исходников и переносимость работающего backend — не одно и то же.

Replit: AI-разработчик внутри облачной инженерной среды

Replit исторически ближе не к конструктору сайтов, а к полноценной среде разработки, перенесённой в браузер. Agent работает внутри проекта: планирует изменения, создаёт и читает файлы, устанавливает зависимости, запускает команды, тестирует и исправляет приложение. Пользователь может начать с промпта, но рядом остаются редактор кода, shell, Git, секреты, логи и настройки запуска.

Отсюда более широкий диапазон результатов. Replit создаёт не только типовые web-интерфейсы, но и API, автоматизации, фоновые задачи, data-приложения, ботов, CLI-инструменты, приложения на разных языках и фреймворках, а также мобильные приложения. General Agent может начать с исследования или обработки данных и затем превратить результат в полноценный сервис. Свобода выше, но выше и вариативность: нестандартную среду иногда приходится настраивать и отлаживать вместе с агентом (возможности General Agent).

Публикация в Replit тоже происходит в его облаке, но пользователь выбирает режим вычислений:

• Autoscale запускает web-приложение по запросу и подходит для переменного трафика;
• Reserved VM даёт постоянно работающую виртуальную машину для API, ботов и фоновых процессов;
• Static раздаёт статический сайт через CDN;
• Scheduled запускает задачу по расписанию.

Replit берёт на себя адрес на replit.app, TLS, секреты и выбранные вычислительные ресурсы; к web-развёртываниям можно подключить свой домен. Но файловая система опубликованного приложения не считается постоянным хранилищем — данные должны находиться в базе или object storage. Иначе очередная публикация способна их стереть (типы и стоимость развёртываний, ограничения опубликованных приложений).

У Replit сильная сторона — обычный Git под капотом. Проект можно связать с GitHub, GitLab или Bitbucket, делать commit, push и pull, после чего инженерная команда продолжит работу привычным способом (контроль версий в Replit). Поэтому стандартное приложение на Python, Node.js, Go или другом распространённом стеке обычно можно развернуть вне Replit — в своём облаке, Kubernetes или on-premise.

Но переносимость кода не гарантирует переносимость окружения. Replit Database, App Storage, встроенную авторизацию, connectors, секреты и расписания придётся заменить аналогами и перенести данные. Сама среда Replit и Agent в обычной модели остаются SaaS. Enterprise предлагает выделенные и single-tenant окружения, выбор региона и VPC peering, но это всё ещё управляемая облачная инфраструктура, а не установка Replit в собственном дата-центре (возможности Replit Enterprise).

Что на самом деле означает кнопка Publish

Свой домен, внешний хостинг и on-premise часто звучат как синонимы, хотя описывают разные уровни контроля.

• Свой домен означает только собственный адрес. Приложение может целиком продолжать работать в облаке конструктора.
• Внешний frontend означает, что браузер получает интерфейс с выбранного вами сервера, но авторизация, база и бизнес-логика всё ещё могут принадлежать платформе.
• Self-hosted / on-premise означает, что и интерфейс, и вычисления, и данные работают в контуре, которым управляете вы. Вместе с контролем к вам переходят обновления, резервное копирование, наблюдаемость, безопасность и ответственность за простой.

Главный тест на свободу от платформы — не наличие кнопки Export. Нужно отдельно проверить, можно ли забрать код, схему и содержимое базы, пользовательские аккаунты, файлы, секреты, фоновые задачи и историю развёртываний. Иногда экспортируется почти всё приложение. Иногда — лишь видимая его половина.

Одинаково быстро — но не одинаково устроено

При no-code человек явно задаёт процесс с помощью блоков и настроек. При вайбкодинге он в основном описывает желаемое поведение, а AI сам выбирает способ реализации. Это похоже на управление очень быстрым исполнителем: он способен за минуты сделать впечатляющий объём работы, но не всегда видит последствия своих решений.

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

Именно поэтому два проекта, внешне одинаково созданные «с помощью AI», могут радикально отличаться по надёжности.

Когда промпт превращается в выручку

FrameSage: десять дней разработки и первые $50 тысяч

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

Техническую основу сервиса Оскар собрал в Lovable за десять дней. Через несколько месяцев FrameSage получила первые $50 тысяч выручки. По словам основателя, такой способ сэкономил около четырёх месяцев и десятки тысяч долларов на разработке. Историю опубликовал Forbes.

Здесь важна последовательность. Бизнес появился не потому, что AI «придумал стартап», а потому, что у основателей были знание отрасли, конкретная боль и доступ к рынку. AI резко удешевил проверку этой связки.

Gift My Book: неделя до запуска и $100 на первую проверку

Йоав Хорнунг и двое его друзей придумали сервис персональных подарочных книг: покупатель отвечает на несколько вопросов, AI сочиняет историю и обложку, а готовая книга автоматически уходит в печать и доставку. Предыдущий проект команда несколько месяцев делала с разработчиками и в итоге закрыла. Gift My Book они собрали на Base44 примерно за неделю.

Затем команда потратила $100 на рекламу в Meta и получила первую покупку. На пике подарочного сезона сервис, по словам Хорнунга, вышел примерно на $1 млн годовой выручки в пересчёте на текущий темп и стал прибыльным. Это не означает, что компания уже заработала миллион долларов: ARR здесь — годовая экстраполяция пикового месяца. Но переход от идеи к первой платной проверке за неделю всё равно показателен. Цифры опубликованы в кейсе Base44 и подтверждены самим основателем.

И снова главным оказался не объём сгенерированного кода. Команда быстро проверила, готовы ли люди платить, а после первой продажи вкладывалась в рекламу, продукт и конверсию. Вайбкодинг сократил путь до рынка; сам рынок всё равно пришлось завоёвывать.

Где скорость важнее идеальной архитектуры

1. Проверка бизнес-гипотез

До инвестиций в полноценный продукт можно собрать кликабельный или работающий MVP, показать его клиентам и проверить главное: нужен ли он вообще. На этом этапе скорость обучения важнее идеальной архитектуры.

2. Внутренние инструменты для небольшой команды

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

3. Автоматизация повторяющихся операций

Перенос данных между таблицами и CRM, уведомления, формирование отчётов, расшифровка звонков, первичная классификация обращений и подготовка черновиков хорошо ложатся на n8n, Make или Zapier.

4. Одноразовые и «наколеночные» решения

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

5. Макеты интерфейса и технические демонстрации

Вместо презентации можно показать живой сценарий. Это помогает предпринимателю, заказчику и разработчикам быстрее договориться о том, что именно предстоит сделать.

Хороший признак подходящей задачи: круг пользователей невелик, цена ошибки низкая, данные не критичны, процесс легко проверить вручную, а временный простой не остановит бизнес.

Но перед разработкой стоит задать ещё один вопрос: а нужно ли вообще создавать новый инструмент? Если типовая CRM, сервис бронирования или готовая отраслевая система закрывает 80% требований, её внедрение часто дешевле и надёжнее даже бесплатного прототипа. Вайбкодинг особенно ценен там, где процесс действительно специфичен или готовые решения слишком громоздки.

Где ставка уже слишком высока

Быстрый конструктор опасно оставлять единственным фундаментом, если система:

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

Это не означает, что AI здесь бесполезен. Наоборот, опытная команда может применять его на каждом этапе и сильно ускорять разработку. Неправильна лишь подмена: «AI помогает инженеру» превращается в «инженер больше не нужен».

Почему «оно работает» ещё не означает «оно готово»

Неясные требования превращаются в случайную логику

Модель охотно заполняет пробелы. Если не описать возвраты, повторные платежи, часовые пояса, одновременное редактирование или удаление пользователя, AI выберет какой-то вариант сам. На красивом демо это незаметно. Ошибка проявится на реальных данных.

Архитектура портится незаметно

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

Безопасность редко видна через интерфейс

Авторизация и права доступа — разные вещи. Пользователь может корректно войти в приложение, но при этом получить возможность запросить чужие данные напрямую через API. В код могут попасть ключи, служебные пароли или избыточные разрешения. OWASP отдельно предупреждает, что AI часто оптимизирует решение под «работает», а не под «безопасно», если защитные требования не заданы и не проверены (рекомендации OWASP для citizen development).

Производительность проверяется только реальной нагрузкой

Десять тестовых записей и сто тысяч заказов — разные системы. Неудачный запрос к базе, лишний вызов LLM для каждой строки или отсутствие очереди могут сделать приложение медленным и непредсказуемо дорогим.

Production — это больше, чем кнопка Deploy

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

Стоимость переносится с создания на сопровождение

Первая версия может стоить почти ничего, а следующие месяцы — всё больше. Оплата операций, токенов и внешних API растёт вместе с использованием. Зависимость от конкретной платформы затрудняет перенос. Человек, собравший процесс, уходит — и никто не понимает, почему один из 40 блоков изменяет сумму заказа.

Экономить нужно не только на старте, а на полной стоимости владения: создание, инфраструктура, лицензии, исправления, поддержка, простои и будущие изменения.

Данные и права тоже требуют проверки

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

LLM внутри продукта добавляет собственные риски

Если нейросеть не только пишет код, но и работает в готовом сервисе, результат по природе недетерминирован. Ответы могут быть неточными, входные данные — содержать prompt injection, а обновление модели — менять поведение без изменений в коде. Нужны наборы проверочных примеров, измеримые метрики качества, ограничения полномочий агента, контроль стоимости и задержек, фильтрация данных и понятная передача сложного случая человеку.

Два случая, когда демо встретилось с реальностью

AI-агент удалил production-базу

В июле 2025 года основатель SaaStr Джейсон Лемкин публично тестировал Replit Agent. Сначала он за несколько часов собрал эффектный прототип, но затем агент, несмотря на запрет менять код, удалил данные production-базы. По опубликованной хронологии, восстановление в итоге оказалось возможным, однако эксперимент наглядно показал отсутствие необходимых барьеров между разработкой и боевой системой. Подробности собрал The Register.

Это не доказательство того, что любой проект на Replit потеряет данные: продукты и защитные механизмы меняются. Это доказательство другого — критическую систему нельзя строить так, чтобы один агент одновременно имел цель, полномочия и доступ к необратимым действиям.

Вирусный сервис и открытая база

Создатель социальной сети для AI-агентов Moltbook рассказывал, что не написал для неё ни строки кода. В начале 2026 года исследователи Wiz обнаружили неправильно настроенную базу Supabase: без авторизации были доступны чтение и запись, 1,5 млн API-токенов, 35 тысяч email-адресов и приватные сообщения. Ошибку оперативно сообщили владельцу и закрыли. Технический разбор Wiz показывает важную деталь: проблема была не в самом публичном ключе, а в отсутствующих правилах доступа к строкам базы.

Для пользователя интерфейс при этом выглядел рабочим. Именно поэтому безопасность нельзя проверять «на глаз» или вопросом к той же модели, которая написала код.

Быстрее писать код — не всегда быстрее закончить проект

Результат зависит от задачи, опыта человека и способа измерения. В контролируемом эксперименте GitHub участники с Copilot быстрее выполнили ограниченную учебную задачу по созданию HTTP-сервера. Но в исследовании METR опытные разработчики, работавшие над знакомыми им крупными open-source репозиториями с инструментами начала 2025 года, потратили в среднем на 19% больше времени. Авторы подчёркивают, что это снимок конкретной группы, задач и поколения инструментов, а не универсальный приговор AI.

Практический вывод прост: скорость генерации кода и скорость доставки надёжного бизнес-результата — разные метрики. AI особенно хорошо ускоряет понятную, проверяемую работу. Чем больше скрытого контекста и цена ошибки, тем важнее инженерная экспертиза.

Как начать и не устроить себе дорогой эксперимент

1. Выберите один узкий процесс. Не «автоматизировать продажи», а «переносить заявки из формы в CRM и уведомлять ответственного».
2. Опишите границы. Кто пользуется системой, какие данные она читает и меняет, что считается правильным результатом и что делать при ошибке.
3. Начните с тестовых данных. Не загружайте клиентскую базу, документы, пароли и production-ключи в первый эксперимент.
4. Оставьте человека в критической точке. Платёж, удаление, отправка массовой рассылки или изменение статуса заказа должны подтверждаться.
5. Проведите пилот на малой группе. Наблюдайте не только за тем, работает ли основной сценарий, но и за ошибками, задержками и стоимостью операций.
6. Проверьте выход из платформы. Можно ли выгрузить данные и код? Кто владеет аккаунтами, доменом и ключами? Что произойдёт при изменении тарифа или закрытии сервиса?
7. До масштабирования закажите инженерный аудит. Нужны проверка архитектуры, модели доступа, зависимостей, резервного копирования, тестов и production-контура.

Полезная граница: самостоятельно докажите, что решение нужно бизнесу; инженерам поручите доказать, что оно выдержит реальную эксплуатацию.

Не вместо инженеров, а вместе с ними

Сегодня уже не обязательно выбирать между «долго и дорого по старинке» и «быстро, но как получится». Зрелая команда использует AI для прототипирования, написания типового кода, тестов и анализа, а высвободившееся время тратит на то, что сложнее автоматизировать: понимание бизнеса, архитектуру, безопасность, качество данных и надёжность эксплуатации.

Именно так работает LLM Technology. Команда разрабатывает AI- и LLM-решения, агентов, Telegram-ботов, речевую аналитику, автоматизацию и backend-системы полного цикла — от проработки задачи и архитектуры до внедрения и поддержки.

За счёт грамотного применения AI-инструментов разработка может идти заметно быстрее и обходиться дешевле классического заказного подхода. При этом код и решения не остаются без присмотра: за ними стоят опытные инженеры, которые умеют построить очереди, API, базы данных, CI/CD, мониторинг и production-окружение, проверить безопасность и предусмотреть развитие системы.

Если нужен прототип для проверки гипотезы — его часто можно навайбкодить самостоятельно. Если продукт должен работать долго, хранить важные данные, расти вместе с бизнесом и давать гарантированный по согласованным критериям результат — обсудите задачу с LLMtech.