Большинство систем, которые мы делаем для бизнеса, не набираются руками с нуля, а описываются. Структуру данных, экраны и их связи мы задаём на трёх небольших языках, а генератор Fractal 2 превращает описание в базу данных, REST API с документацией, админку, интерфейс на React и техническое задание. Ниже о том, как это устроено: фронтенд, бэкенд, инфраструктура, место ИИ в процессе и проверки, без которых генерации нельзя доверять.
Все скриншоты сняты с рабочего стенда. Сквозной пример: мебельная фабрика «Дубрава», данные в нём тестовые.
Подход: описание вместо кода
Обычная разработка держит одну и ту же систему в нескольких местах сразу: в ТЗ, в схеме базы, в коде бэкенда, в типах фронтенда, в документации 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 разберёт Вашу задачу и покажет, какая часть системы соберётся из описания, а какая потребует ручной работы. После неё Вы получите расчёт цены и сроков по этапам. Записаться на консультацию.
