Технический контекст
Я зацепился тут не за очередной «генератор приложений», а за саму форму сборки. Схема выглядит так: из формализованных спецификаций LLM сначала собирает primitives, потом из них делает compounds, дальше формирует flows, а затем упаковывает всё в blueprints. Финал этой истории это полный семантический граф и готовый модуль-контракт.
Мне нравится, что на каждом уровне сидит валидатор. Не один большой чек в конце, когда уже поздно, а серия локальных проверок по слоям. Это очень приземлённая инженерная идея: не давать модели расползаться по пространству вариантов, а постоянно сужать коридор допустимых реализаций.
По сути, здесь бизнес-логика отделяется от конкретной реализации. Сначала описывается, что система должна делать, потом это сжимается в граф-контракт, и уже из него разворачивается scaffold. В open source обещают базовую библиотеку primitives, compounds, flows, пару blueprints и модуль, который из графа поднимет React-скаффолд.
Платная часть тоже логична: iOS на SwiftUI и React Native или Expo. То есть автор не просто рисует абстрактный DSL, а сразу привязывает его к реальной доставке продукта. И вот это уже интересно, потому что большинство таких историй умирает на этапе «мы красиво описали доменную модель, а дальше руками допиливайте сами».
Если смотреть на дату, это не ретро и не раскопки из архива. История свежая: формат graph contracts обещают открыть буквально в ближайшую неделю от исходного анонса. Публично индексированных аналогов именно с такой цепочкой primitives → compounds → flows → blueprints я пока не видел.
Что это меняет для бизнеса и автоматизации
Я бы не продавал это как «LLM теперь сам пишет продукт». Я бы продавал иначе: у нас появляется более надёжный слой между бизнес-требованием и кодом. И если этот слой формальный, валидируемый и платформенно-агностичный, то внедрение искусственного интеллекта в продуктовую разработку становится сильно менее хаотичным.
Самый жирный плюс здесь в том, что уменьшается поверхность галлюцинаций. Модель не прыгает сразу в React-компоненты, API-ручки и стейт-менеджмент. Она идёт маленькими блоками, где ошибка ловится раньше. Для ИИ автоматизации это почти всегда правильный ход.
Кто выигрывает? Команды, у которых много повторяемых бизнес-сценариев: внутренние кабинеты, CRM-модули, workflow-приложения, сервисные порталы. Там, где продукт можно декомпозировать в устойчивые flows и blueprints, такая архитектура ИИ-решений даст ускорение без резкого роста техдолга.
Кто проигрывает? Те, кто ждёт волшебную кнопку. Если доменная модель сырая, процессы в компании плывут, а спецификация живёт в головах у трёх людей, никакой graph contract не спасёт. Он только очень честно покажет, что у вас не оформлена сама логика.
Мы в Nahornyi AI Lab постоянно упираемся ровно в это место, когда делаем ИИ решения для бизнеса: проблема не в генерации кода как таковой, а в переходе от мутного описания задачи к структуре, которую можно проверить и воспроизвести. Поэтому мне этот подход близок. Он не про красивое демо, а про управляемую ИИ интеграцию в реальный delivery.
Я бы особенно присмотрелся к open-source части. Если базовые primitives и compounds окажутся достаточно универсальными, рынок быстро начнёт собирать поверх них вертикальные библиотеки под e-commerce, healthtech, backoffice и клиентские кабинеты. А дальше начинается самое интересное: разработка ИИ решений превращается из ручного ремесла в работу с контрактами, графами и валидируемыми шаблонами.
Меня зовут Вадим Нагорный, я в Nahornyi AI Lab руками собираю системы, где ИИ автоматизация должна не впечатлять на созвоне, а нормально жить в проде. Если хотите примерить такой подход на ваш продукт, приходите с конкретным кейсом. Я помогу разложить его на архитектуру, ограничения и реальный план внедрения.