Перейти к содержанию
Публикация AiManual

PDI Brew: как агентная платформа без кода разворачивает приложения за секунды

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

Коротко

Что будет в материале

  1. 01

    Архитектура PDI Brew: два агента, которые заменяют команду разработки

  2. 02

    Безопасность и управление по умолчанию: как PDI Brew не становится «теневым IT»

  3. 03

    Экономика платформы: $5–15 в месяц за приложение - реальность или маркетинг?

  4. 04

    PDI Brew в контексте no-code революции: почему это больше, чем просто генератор форм

Внутренний бэклог PDI Technologies разрастался годами. Сотрудники запрашивали простые инструменты для учёта, аналитики, трекинга, а команда разработки физически не успевала закрывать тикеты. Каждый такой запрос проходил стандартный цикл: брифинг, оценка, проектирование, разработка, тестирование, деплой. Среднее время поставки измерялось неделями. В 2025 году компания переломила ситуацию радикально - запустила PDI Brew, агентную платформу на AWS, где сотрудник описывает нужный инструмент на естественном языке и получает полностью развернутое мультитенантное веб-приложение за считанные секунды.

Результат: время поставки внутренних инструментов сократилось с недель до минут. Non-developer сотрудники самостоятельно развернули сотни приложений. Средняя стоимость одного приложения - $5–15 в месяц. Безопасность корпоративного уровня встроена по умолчанию: каждое приложение наследует SSO через Microsoft Entra ID, работает в рамках scoped IAM-ролей, шифрует трафик по HTTPS и логирует всё в централизованную систему наблюдения.

В этом разборе - архитектура PDI Brew, механика двух агентов, которые заменяют команду разработки, встроенные гардрейлы для GenAI, экономика платформы и границы её применимости.

Архитектура PDI Brew: два агента, которые заменяют команду разработки

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

Разделение принципиально. Планировщик работает с неструктурированным вводом на естественном языке - здесь нужна генеративная модель. Провижининг-агент оперирует детерминированной логикой: классификация, выбор инструментов, вызов API AWS. Никакой импровизации на этапе создания инфраструктуры. Это исключает галлюцинации там, где они стоят денег и создают дыры в безопасности.

Планировщик: от естественного языка к JSON-манифесту

Планировщик принимает описание задачи от пользователя и генерирует JSON-манифест - формальный контракт, который описывает, какое приложение нужно создать. Реализовано два пути ввода:

  • Навык в ИИ-ассистенте. Сотрудник пишет или произносит запрос в корпоративном чат-интерфейсе: «Сделай мне дашборд для отслеживания загрузки команды по проектам с фильтром по кварталам». Навык обрабатывает запрос и формирует манифест.
  • Amazon Bedrock внутри доверительного периметра AWS. Для сложных сценариев, где нужна более тонкая настройка, планировщик вызывает Bedrock напрямую. Это сохраняет данные внутри облачного контура компании и не требует проксирования через внешние сервисы.

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

Провижининг-агент на AWS Lambda: детерминированная оркестрация

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

  1. Классификация рабочей нагрузки. Агент анализирует манифест и относит приложение к одному из заранее определённых типов: CRUD-интерфейс, дашборд, форма сбора данных, workflow-инструмент. Никакой вероятностной модели - жёсткая детерминированная классификация на основе структуры манифеста.
  2. Выбор инструментов. Для каждого типа нагрузки зашит проверенный стек сервисов AWS. Например, CRUD-интерфейс получает связку API Gateway + Lambda + DynamoDB, дашборд - Amplify Hosting + AppSync + Athena. Агент не изобретает архитектуру на лету, а применяет шаблоны, прошедшие аудит безопасности.
  3. Оркестрация создания ресурсов. Агент последовательно вызывает API сервисов AWS, создаёт и связывает ресурсы, применяет IAM-политики, настраивает HTTPS и подключает SSO. Весь процесс занимает секунды.

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

Безопасность и управление по умолчанию: как PDI Brew не становится «теневым IT»

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

Каждое приложение, созданное платформой, автоматически наследует корпоративные политики безопасности:

  • Единый вход через Microsoft Entra ID. Никаких отдельных учётных записей. Пользователи входят с теми же корпоративными учётными данными, что и во все остальные системы компании. Мультитенантность реализована на уровне данных, а не на уровне аутентификации.
  • Scoped IAM-роли. Каждое приложение получает минимально необходимые права. Роль привязана к конкретному приложению и не даёт доступа к другим ресурсам AWS-аккаунта.
  • Обязательный HTTPS. Весь трафик шифруется. Незашифрованные эндпоинты не создаются.
  • Централизованная наблюдаемость. Логи, метрики и трейсы всех приложений стекаются в единую систему мониторинга. Команда безопасности видит всё, что происходит, без необходимости настраивать observability для каждого инструмента отдельно.

Отдельный уровень защиты - управляемый доступ к генеративному ИИ. Платформа предоставляет приложениям возможность использовать GenAI, но с тремя обязательными механизмами контроля:

  • Гардрейлы. Модели ограничены в том, какие ответы они могут генерировать. Никакого выполнения произвольного кода, никаких запросов к внешним API без явного разрешения.
  • Двенадцатисчетчиковый бюджетный контроль. Для каждого приложения задаётся лимит затрат на вызовы GenAI. При его достижении доступ блокируется автоматически. Двенадцать счётчиков позволяют разбить бюджет по разным типам операций и моделям.
  • Полный аудит. Каждый запрос к GenAI логируется: кто, когда, с каким промптом, какой ответ получен. Это закрывает вопросы compliance и позволяет расследовать инциденты.

Такой подход превращает платформу из потенциального источника «теневого IT» в контролируемую среду, где скорость развертывания не противоречит требованиям безопасности. Это особенно важно для компаний, которые уже прошли путь от хаотичных пилотов GenAI к платформенному подходу - 70-80% корпоративных пилотов не доходят до продакшена именно из-за отсутствия таких встроенных механизмов контроля.

Экономика платформы: $5–15 в месяц за приложение - реальность или маркетинг?

Цифра $5–15 в месяц выглядит подозрительно низкой. Разберём, из чего она складывается. Типовое внутреннее приложение в PDI Brew - это лёгкий веб-интерфейс с парой экранов, простой бизнес-логикой и небольшой базой данных. Под капотом это минимальный набор сервисов AWS:

  • Lambda. Основные вычисления. Для приложения с низкой нагрузкой - десятки тысяч вызовов в месяц - счёт стремится к нулю в рамках бесплатного тира.
  • DynamoDB. Бессерверная база данных. Для типового внутреннего инструмента с парой гигабайт данных и умеренным количеством запросов - единицы долларов в месяц.
  • API Gateway. Эндпоинты для фронтенда. При небольшом трафике - копейки.
  • Amplify Hosting. Хостинг статического фронтенда. Бесплатный тир покрывает большинство внутренних приложений.

Суммарно такое приложение действительно укладывается в $5–15 в месяц. Для сравнения: традиционная разработка аналогичного инструмента силами внутренней команды - это минимум 40-80 часов работы разработчика. При ставке $50-100 в час только стоимость создания составляет $2000-8000, не считая поддержки. PDI Brew сокращает эти затраты на два порядка.

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

PDI Brew в контексте no-code революции: почему это больше, чем просто генератор форм

Рынок no-code платформ существует давно: Airtable, Retool, Bubble, Microsoft Power Apps. Все они решают задачу создания приложений без программирования, но через визуальное конструирование - перетаскивание компонентов, настройку свойств, соединение блоков. Это быстрее разработки с нуля, но требует обучения платформе и понимания её модели данных.

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

Второе отличие - полнота результата. Многие no-code инструменты генерируют формы или дашборды, которые живут внутри платформы-хоста. PDI Brew создаёт самостоятельные мультитенантные веб-приложения на выделенной облачной инфраструктуре. Каждое приложение - это отдельный стек ресурсов AWS со своим доменом, своей базой данных, своими политиками безопасности. Это не виджет внутри чужой платформы, а полноценный инструмент, который можно развивать и интегрировать с другими системами.

Этот подход вписывается в более широкий тренд на агентные платформы, где ИИ не просто отвечает на вопросы, а выполняет действия в реальной инфраструктуре. Автономные AI-агенты уже трансформируют SDLC, меняя роли разработчика, тестировщика и архитектора. PDI Brew - пример того, как агентный подход выходит за рамки генерации кода и начинает управлять облачной инфраструктурой напрямую.

Ограничения и вызовы: что остаётся за кадром

Информация о PDI Brew основана на предоставленном описании, и не все технические детали раскрыты. Важно честно обозначить вероятные ограничения платформы.

Типы поддерживаемых приложений. Платформа ориентирована на внутренние инструменты: дашборды, CRUD-интерфейсы, формы, простые workflow. Создать клиентский продукт с кастомным UX, сложной бизнес-логикой и интеграциями с внешними системами через PDI Brew не получится. Это инструмент для разгрузки разработчиков от типовых задач, а не замена продуктовой разработке.

Кастомизация за пределами манифеста. JSON-манифест описывает приложение на высоком уровне. Если пользователю нужно поведение, которое не укладывается в предусмотренные шаблоны, платформа не поможет. Придётся подключать разработчиков и дорабатывать приложение вручную - либо на уровне кода, либо через другие средства автоматизации, такие как инструменты для превращения прототипов в production-ready MVP.

Зависимость от вендора. PDI Brew глубоко интегрирована с AWS: Lambda, Bedrock, DynamoDB, Amplify. Перенести платформу на другого облачного провайдера или on-premise инфраструктуру без переписывания провижининг-агента невозможно. Это осознанный выбор: глубокая интеграция даёт скорость и безопасность, но ценой привязки к экосистеме.

Не для внешних продуктов. Платформа заточена под внутренние инструменты с корпоративной аутентификацией. Создать на ней SaaS для внешних клиентов с биллингом, кастомным брендированием и мультитенантностью на уровне клиентов не выйдет. Для таких задач потребуются другие решения - например, агентные платформы с более гибкой оркестрацией, такие как гибридные ИИ-агенты на Amazon Bedrock AgentCore, которые Mobileye использовала для обработки тикетов с точностью 98%.

Выводы: стоит ли внедрять агентные платформы уже сегодня?

PDI Brew - это не эксперимент и не пилот. Это работающая платформа, которая ежедневно обслуживает сотни внутренних приложений в PDI Technologies. Ключевые результаты измеримы: время поставки сокращено с недель до минут, стоимость одного приложения - $5–15 в месяц, сотрудники без технических навыков самостоятельно создают инструменты под свои задачи.

Архитектурный подход с разделением на планировщик и детерминированный провижининг-агент снимает главный риск агентных систем - неконтролируемое поведение в production-окружении. Генеративный ИИ работает только там, где нужна интерпретация естественного языка. Создание инфраструктуры выполняется по жёстким шаблонам с предсказуемым результатом.

Встроенные механизмы безопасности - SSO, scoped IAM-роли, бюджетный контроль GenAI, полный аудит - делают платформу приемлемой для корпоративных стандартов. Это не «теневое IT», а контролируемая среда ускоренной разработки.

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

Подписаться на канал