Все вокруг теперь программисты
Короче, у 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%.
Потому что мы меняем не скорость разработки.
Мы меняем то, кому вообще нужна команда разработчиков для создания программного обеспечения. 
