Все вокруг теперь программисты

Короче, у Gergely Orosz в The Pragmatic Engineer вышла интересная статья про новый тренд: крупные компании начали создавать собственные аналоги Lovable для сотрудников.

И нет, не для разработчиков!

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

Вот вам два примера. 1. Ramp и их Glass

Ребята собрали собственную платформу для вайб-кодинга внутренних приложений.

Причём первую версию сделали всего два инженера за несколько недель.

Теперь любой сотрудник может описать, что ему нужно, подключить корпоративные источники данных и получить работающее приложение.

Например, маркетолог собрал себе CRM с более чем 50 полями и фильтрами.

И знаете, что самое интересное?

В Ramp создание первого инструмента через Glass уже стало частью онбординга новых сотрудников!

А 13 октября компания вообще вывела Glass на внешний рынок.

2. Stripe и их Harbor

Здесь ещё интереснее.

Один инженер за 40 дней создал внутренний инструмент для генерации интерактивных прототипов.

И вот результаты с мая 2026 года:

• Более 12 000 созданных прототипов. • Более 3 000 сотрудников воспользовались инструментом. • 25% сотрудников Stripe создали хотя бы один прототип.

Причём используют его не только дизайнеры.

Финансисты собирают интерактивные отчёты вместо презентаций, продавцы калькуляторы ROI, аналитики - дашборды.

А самое интересное технически: Harbor интегрирован с другими AI-инструментами Stripe через MCP. То есть прототип можно передать coding-агенту для дальнейшей реализации.

Оооокей! А зачем делать свой Lovable, когда уже есть готовые?

Orosz выделяет несколько причин:

1. Данные. Корпоративную информацию не хочется отправлять в сторонние сервисы. Своя платформа позволяет контролировать доступ к ней. 2. Интеграции. Можно сразу подключить внутренние API, базы данных и другие системы компании. 3. Стандарты. Генерируемые приложения используют корпоративную дизайн-систему, а не выглядят как результат очередного хакатона. 4. Стоимость внедрения. Иногда собрать собственный инструмент оказывается сопоставимо по усилиям с выбором вендора, согласованием безопасности и последующим внедрением. 5. Компетенции. Инженеры заодно учатся строить собственную AI-инфраструктуру.

А теперь моя любимая часть!

Кажется, мы наблюдаем довольно интересную трансформацию роли инженерных платформ.

Раньше у нас был внутренний заказчик, который приходил к разработчикам и говорил:

• Ребята, сделайте мне дашборд, форму или какой-нибудь маленький инструмент!

Разработчики брали это в бэклог, приоритизировали, обсуждали, оценивали…

А через полгода сообщали, что в этом квартале ресурсов нет. 😁

Теперь этот же сотрудник может собрать себе нужный инструмент самостоятельно.

И вот тут возникает интересный вопрос.

Если создавать приложения сможет каждый, кто будет отвечать за весь этот зоопарк?

Кто управляет доступами? Кто контролирует стоимость исполнения? Что делать, когда автор приложения увольняется? И кто гарантирует, что какой-нибудь вайб-кодер не откроет доступ ко всей корпоративной базе?

Кажется, ответ опять - платформенные команды.

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

И, на мой взгляд, это куда более интересная история, чем очередное ускорение написания кода на 30%.

Потому что мы меняем не скорость разработки.

Мы меняем то, кому вообще нужна команда разработчиков для создания программного обеспечения.