Технічний контекст
Тут я звернув увагу не на черговий «генератор застосунків», а на саму форму збірки. Схема виглядає так: із формалізованих специфікацій 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 руками збираю системи, де ШІ-автоматизація має не вражати на дзвінку, а нормально жити в продакшені. Якщо хочете приміряти такий підхід на ваш продукт, приходьте з конкретним кейсом. Я допоможу розкласти його на архітектуру, обмеження та реальний план впровадження.