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