Більшість систем, які ми робимо для бізнесу, не набирають вручну з нуля, а описують. Структуру даних, екрани та зв’язки між ними ми задаємо трьома невеликими мовами, а генератор Fractal 2 перетворює опис на базу даних, REST API з документацією, адмінку, інтерфейс на React і технічне завдання. Далі про те, як це влаштовано: фронтенд, бекенд, інфраструктура, місце ШІ в процесі та перевірки, без яких генерації не можна довіряти.
Усі скриншоти зняті з робочого стенда. Наскрізний приклад: меблева фабрика «Дубрава», дані в ньому тестові. Студія Fractal 2 на скриншотах має російськомовний інтерфейс, а сам застосунок «Дубрави» україномовний.
Підхід: опис замість коду
Звичайна розробка тримає одну й ту саму систему в кількох місцях одночасно: у ТЗ, у схемі бази, у коді бекенду, у типах фронтенду, у документації API. Кожну зміну треба внести всюди, і за пів року ці місця починають розходитися. Документація бреше, фронтенд чекає на поле, якого вже немає, а інтеграція ламається на рівному місці.
У Fractal джерело одне, і воно написане трьома мовами:
- SFL (Structurer Fractal Language) описує дані: таблиці, поля, типи, зв’язки та модулі;
- IFL (Interface Fractal Language) описує екрани: сітку, компоненти, поля й переходи, а також директиви бізнес-логіки;
- ISFL описує карту екранів: які екрани є, на яких патернах вони побудовані та як пов’язані між собою.
З цього опису генератор отримує все інше. Тому зміна структури займає хвилини, а документація й код не розходяться за визначенням: вони збираються з одного місця.
Так виглядає SFL. Один рядок описує одну колонку, поле із закінченням _id стає зовнішнім ключем, знак оклику робить поле обов’язковим:
Користувач|user
Ім’я|name !
Пошта|email !
Замовлення|order
Користувач|user_id !
Сума|sum float(10,2)
Статус|status
Створено|created_atПрефікс назви таблиці задає модуль, як в Odoo: sales_order потрапляє в модуль продажів, wh_stock у складський. За модулями автоматично діляться меню адмінки, розділи API, ER-діаграми та розділи технічного завдання.
Від ТЗ клієнта до робочої системи
У фабрики «Дубрава» сорок працівників, два цехи, склад плит і фурнітури, три салони та сайт. Усе в Excel і месенджерах, замовлення губляться, терміни зриваються. Директор хоче бачити кожне замовлення від заміру до монтажу, рахувати вартість із матеріалів і робіт, планувати завантаження цехів, вести склад і закупівлі та контролювати оплати.
Цей текст аналітик вставляє в студію як є, файлом або голосом. Далі шлях такий:
- Claude розкладає ТЗ на екрани, патерни та моделі. Виходить карта ISFL, яку аналітик править на графі: додає екрани, з’єднує переходи стрілками.
- За картою Claude проєктує схему даних із модулями та коментарями. Парсер SFL перевіряє відповідь і в разі помилок повертає її на виправлення.
- Генератор будує базу, бекенд, API, адмінку та екрани, а потім перевіряє, що все відповідає.
Для «Дубрави» це 22 таблиці та 157 колонок у трьох модулях (клієнти й замовлення, виробництво, склад) і 18 екранів, у яких 60 компонентів і 237 елементів. Жодної помилки й жодного попередження парсера.
Фронтенд: React, що збирається з опису
Кожен екран IFL стає сторінкою на React 19 і TypeScript 7 з компонентів нашого UI-кіту на Material UI 9. Дані надходять через TanStack Query, збиранням займається Vite, графіки малює Chart.js, мапи Leaflet. Інтерфейс адаптивний від 360 px, є світла й темна теми, мови українська, російська та англійська.
Головне архітектурне рішення тут: типи TypeScript і клієнт API генеруються з тієї самої схеми, що й бекенд. Якщо в SFL змінилося поле, фронтенд дізнається про це на етапі перевірки типів, а не від користувача в продакшені.
Фронтенд лише показує. Розрахунки, перевірки та зміни даних живуть на сервері, тому правила неможливо обійти з браузера. Компоненти, які не можна описати стандартними патернами, створюються заготовкою один раз і далі належать розробникові: генератор їх не перезаписує.
Адмінку не пишуть окремо. Вона будується за метаданими схеми: таблиця, пошук, фільтри, сортування, картка з пов’язаними записами, форма й видалення для кожної моделі, меню за модулями.
Бекенд: спершу API, логіка тільки на сервері
Сервер працює на PHP 8.4 і Yii 2, база MySQL 8.4 на InnoDB із зовнішніми ключами та utf8mb4. Кожна таблиця одразу стає REST-ресурсом: списки зі сторінками, фільтри за полями та зв’язками, пошук, сортування, розкриття зв’язків одним запитом, агрегати, дії та методи сервісів. Опис API у форматі OpenAPI 3.1 генерується з SFL, інтерактивна документація відкривається за адресою /docs.
Фронтенд і адмінка звертаються до того самого API, що й зовнішні системи. Тому інтеграція з CRM, 1С, сайтом чи ШІ-агентом не потребує окремої розробки: API вже є і вже описаний.
Бізнес-логіка живе тільки в сервісах на сервері. Директиви IFL перетворюються на їхні методи: події до і після збереження, дії кнопок, розрахунки для екранів. Тіло методу пише людина або КодГен, про нього нижче.
Безпека ввімкнена за замовчуванням:
- права за ролями перевіряються на сервері, інтерфейс їх лише відображає;
- секретні колонки облікових записів недоступні у фільтрах та агрегатах;
- токен приймається тільки в заголовку
Authorization: Bearer; - запити студії, що змінюють дані, несуть окремий заголовок проти CSRF, а після 10 невдалих входів за 10 хвилин вхід блокується.
Чому Yii 2, а не модний фреймворк? Ядро 2.0.55 без відомих вразливостей працює на PHP 8.4 і MySQL 8.4. Переписувати робочий фундамент заради моди означає витрачати гроші клієнта на те, чого він не побачить.
Конвеєр генерації та зміни без втрати даних
Генерація йде фоновим завданням із журналом кроків: у PHP-FPM ліміт 45 секунд, а збирання проєкту триває довше. Студія показує перебіг кроків у реальному часі.
Дві речі роблять перегенерацію безпечною на будь-якому етапі проєкту:
- Власний код не губиться. Базові класи й тека
_generatedперезаписуються, заготовки створюються один раз, а маніфест зберігає хеші файлів і видаляє застарілий файл, тільки якщо його ніхто не правив. - База змінюється міграціями. Режим змін порівнює SFL із живою базою, пише міграцію Yii з відкатом і застосовує її. Колонки, яких немає в описі, не видаляються. Історія міграцій і кнопка відкату є в студії.
Тому систему клієнта можна розвивати разом з описом, а не заморожувати після першої версії.
Де працює ШІ і чому йому можна довіряти
У генераторі працює Claude Opus 5.5 через Agent SDK за підпискою. Він розкладає ТЗ на екрани, проєктує схему даних, наповнює довідники (статуси, типи, етапи) і пише користувацькі компоненти та методи сервісів. Ми використовуємо його у двох режимах, і обидва обмежені:
- Відповідь суворо за JSON-схемою. Без інструментів і доступу до файлів. Відповідь перевіряє парсер, а в разі помилки вона до двох разів повертається на виправлення.
- Агент КодГену. Читає тільки код проєкту і пише тільки в дозволені файли: користувацький компонент і сервіси екрана. Після правок запускається перевірка типів, помилки йдуть на одне коло виправлення, заборонені виклики відкочуються.
Файли .env, секрети й рантайм для ШІ закриті, оточення моста урізане до токена підписки та шляху до програм. Завдання для КодГену можна надиктувати голосом просто в студії: компонент додається рядком в IFL, генератор створює заготовку, агент її дописує.
Інфраструктура: одна для всіх проєктів
Усі проєкти працюють у Docker Compose. Контейнер застосунку з PHP-FPM 8.4 і Node 24 спільний для проєктів, зі спільним vendor, MySQL 8.4 окремо, з резервними копіями та завданнями за розкладом. Вхід для всіх адрес тримає Caddy з TLS.
Кожен контейнер має ліміт пам’яті та процесора. Це свідоме рішення: генерація, тести й відео мають іти поруч з іншою роботою, а не з’їдати машину. Журнали й метрики контейнерів збирає OpenTelemetry і надсилає в ClickStack (ClickHouse і HyperDX), налаштований ощадливо.
Перевірки: генерації не можна вірити на слово
Fractal 2 перевіряється на трьох рівнях:
- Тести генератора: 45 тестів і 1 277 перевірок за 1,3 секунди. Парсери, патерни, модулі, міграції з відкатом, генератори коду, ТЗ і захист КодГену.
- Кожна генерація: перевірка типів усього фронтенду та HTTP-перевірка: вхід, список і запис кожного ресурсу з розкриттям зв’язків, методи сервісів, кожен екран і адмінка.
- Браузер: Playwright відкриває кожен екран, заповнює й надсилає форми, застосовує фільтри, сортує таблиці, створює та видаляє записи в адмінці.
Прогін за десятьма проєктами реєстру 27 жовтня 2026 року: 799 сторінок і 593 дії, нуль помилок. Той самий рушій записує відеопрезентації екранів з озвученням, а FFmpeg збирає їх у ролик.
ТЗ, яке збирається з того самого опису
Технічне завдання для погодження з клієнтом теж генерується: стек, модель даних за модулями з ER-діаграмами, вимоги з ідентифікаторами та критеріями приймання, екрани, API, нефункціональні вимоги, приймання та оцінка трудомісткості. Документ копіюється в Google Docs з таблицями й схемами або завантажується у DOCX.
Що це дає замовникові і де межа
- Швидкість на старті. Робочий прототип з базою, API та екранами з’являється ще до того, як написано перший рядок бізнес-логіки, і на ньому сперечаються про продукт, а не про картинки.
- Документація, яка не бреше. ТЗ, API і код збираються з одного опису.
- Інтеграції без окремого проєкту. Усе, що бачить користувач, доступне через описаний API.
- Звичайний код на виході. Це Yii 2 і React, які прочитає будь-який PHP- і React-розробник.
Чесна межа: генератор закриває типову частину системи. Правила, заради яких бізнес замовляє систему (розрахунок кошторису з матеріалів, планування завантаження цехів, складні статуси оплат), проєктуються разом із замовником і пишуться людьми або КодГеном під контролем перевірок. Як це розкладається на етапи й бюджети, описано в стратегії розробки застосунку, а прототип на Fractal відповідає етапу прототипування. Перше покоління генератора описане в кейсі Fractal.
На безкоштовній консультації архітектор Ingello розбере Ваше завдання і покаже, яка частина системи збереться з опису, а яка потребуватиме ручної роботи. Після неї Ви отримаєте розрахунок ціни та термінів за етапами. Записатися на консультацію.
