ИИ-программист, пишущий по архитектуре с умом

Этот кейс про то, как у нас на самом деле работает AI-разработчик. Спойлер: он не пишет весь проект с нуля по фразе «сделай мне CRM». Он пишет описание системы на трёх маленьких строгих языках, а код, базу, API и админку из этого описания строит Fractal, наш генератор. Строит одинаково при каждом запуске, без вдохновения и без галлюцинаций.

Сейчас рынок немного похож на шумный базар. С одной стороны все кричат, что искусственный интеллект вот-вот заменит программистов. С другой стороны бизнес по-прежнему теряет деньги на кривых интеграциях, ручной работе, зависающих таблицах и системах, которые ломаются в самый неподходящий момент. Идея надиктовать чату «сделай мне CRM, ERP и клиентский кабинет» звучит красиво, но в реальном бизнесе такие трюки работают ровно до первого нормального усложнения.

В видео я показываю это на живом примере: простой прототип CRM с клиентом, карточкой, таблицей, фильтрами, статусами и событиями. А ниже разбираем, что происходит под капотом: как устроены языки ISFL, SFL и IFL, что именно генерирует Fractal, где в этой цепочке AI и где его сознательно нет.

Почему вайб-кодинг хорош только для мелочей

Давайте без религиозных войн. Вайб-кодинг, no-code и low-code не зло. Маленький экран, форма, фильтр, табличка, лендинг с логикой: современные инструменты реально ускоряют такую работу, и спорить с этим глупо.

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

AI может быстро нарисовать красивую витрину, но не всегда понимает, где у здания несущие стены. А бизнесу, как ни странно, важнее именно стены. Поэтому мы разделили работу: стены описываются формально и строятся генератором, а AI помогает там, где он действительно силён.

Что такое Fractal в двух абзацах

Fractal это технология автоматизированной разработки, которую мы развиваем больше восьми лет. Систему в нём не набирают руками, а описывают: какие есть сущности и связи, какие экраны, какие компоненты на экранах и куда ведут ссылки. Генератор берёт описание, проверяет его валидатором и порождает схему MySQL, миграции, модели, CRUD-админку, REST API с документацией, экраны интерфейса, фейковые данные и тесты. Основа проекта (Yii2, Docker-окружение, авторизация, файлы, переводы) берётся из прототипа, который копируется для каждой новой системы.

Грубо говоря, это конструктор, который создаёт конструкторы. Подробнее про историю, архитектуру и оценку платформы рассказываем в отдельном кейсе FRACTAL: автоматизация программирования и разработки ПО. Здесь же смотрим на механику.

Как это работает: описание, генерация, система

1. Требования. ТЗ, бриф или просто разговор с клиентом.
2. ISFL. Требования раскладываются в карту экранов: какие экраны есть, какой у каждого шаблон, какие модели на нём участвуют и куда с него можно перейти.
3. SFL и IFL. Из карты выводятся две модели: модель данных на SFL и модель интерфейса на IFL.
4. Валидация. Генератор проверяет оба описания по строгим правилам: имена, типы, связи, существование экранов, на которые ведут ссылки. Ошибка подсвечивается прямо в редакторе.
5. Генерация. Из проверенного описания строятся SQL, миграции, модели, CRUD, API, экраны, меню и фейковые данные. Повторный запуск с тем же описанием даёт тот же результат.
6. Ручная работа. То, что делает бизнес клиента особенным, дописывается руками или с помощью КодГена в специально отведённых местах.

Три языка Fractal

Языки маленькие и нарочно скучные. Скучный язык легко читать человеку, легко писать модели и невозможно понять двумя способами.

ISFL: карта экранов и сценария

ISFL описывает приложение сверху. Один экран это блок ровно из семи строк: техническое имя, название, шаблон, описание, события, ссылки на другие экраны и модели. Блоки разделяются пустой строкой.

orders_param
Заказы
list-table
Список заказов пользователя
Просмотр, фильтрация
order_param,profile_param
order,user

Шаблон выбирается из закрытого списка: crud, list-table, form, model-profile, calendar, chat, google-map и ещё полтора десятка. Ссылка на несуществующий экран это ошибка валидации, а не сюрприз на демо. Пять системных экранов (каркас, главная, вход, регистрация, профиль) подставляются автоматически, их никто не забудет, даже если очень постарается.

SFL: схема данных

SFL описывает базу. Первая строка блока это таблица, остальные строки это поля. Перед вертикальной чертой пишется человеческое название, после неё техническое имя. Восклицательный знак делает поле обязательным. Поле, которое заканчивается на _id, становится внешним ключом. Вот настоящий фрагмент схемы CRM из нашего реестра:

Проект|project
Название|name !
Описание|description ? text
Клиент|client_id !
Дата_начала|start_date date
Статус|status !

Задача|task
Название|name !
Проект|project_id !
Ответственный|user_id !
Дата_создания|created_at

Половину типов генератор выводит сам по имени поля: *_at становится отметкой времени, description и *_text текстом, *_price и *_cost деньгами, is_* булевым полем. Поле id и таблицу user писать не нужно, они есть всегда. Переводы до черты попадают в подписи интерфейса и в комментарии колонок SQL. А стандартные имена вроде email, phone_number или latitude генератор фейковых данных узнаёт и заполняет правдоподобно, поэтому прототип с первого запуска выглядит живым, а не набором «test1, test2».

На обложке статьи та же механика в масштабе: схема автобусных перевозок, 25 бизнес-объектов, рейсы, отрезки, брони, промокоды и пересчёты. На этой основе выросли наши транспортные системы.

IFL: экраны поверх моделей

IFL описывает интерфейс и опирается на SFL. Экран это блок, сетка задаётся строками: дефис открывает новый ряд, число от 1 до 12 задаёт ширину колонки. Компонент пишется одной строкой из трёх частей: модель, тип компонента и поля через косую черту.

client_management_param
-
12
Мои_объекты title 1
9
client list:2 company_name/contact_person/email/city/
    screen_client_detail_param_id
3
client form company_name/contact_person/email/city/
    screen_save_id

Здесь три строки смысла: заголовок на всю ширину, слева на 9 колонок из 12 список клиентов карточками в две колонки, справа на 3 колонки форма той же модели. screen_client_detail_param_id превращается в переход на карточку клиента, точечная нотация вроде project.client.city вытаскивает поле через связь. Типов компонентов около двадцати: формы, фильтры, таблицы, слайдеры, карточки, медиа, обложки и свои компоненты, если типовых не хватило.

Отдельная гордость это директивы бизнес-логики. Строки event:order:before_update, action:order:recalculate или method:order:build_pdf прямо в описании экрана регистрируются в документации и превращаются в заготовки методов сервиса модели. Логика не теряется между экраном и кодом, она записана там же, где её придумали.

Что генерирует Fractal

• SQL и миграции. Таблицы, типы, обязательность, внешние ключи, комментарии колонок.
• Модели и CRUD-админку. Разделы администрирования для каждой сущности, меню, фильтры, сортировка, пагинация.
• REST API с документацией. Для каждой модели эндпоинты списка, просмотра, создания, изменения и удаления, плюс Swagger, по которому фронтенд или мобильное приложение подключается без устных преданий.
• Экраны интерфейса. Страницы и компоненты по IFL, каркас, меню, переходы между экранами.
• Фейковые данные. По именам полей, а там, где имя ничего не говорит, значения по смыслу предметной области подбирает модель. Демо выглядит как работающая система, а не как пустая база.
• Тесты. Проверка самого генератора на эталонных схемах и генерация E2E-сценариев Playwright по сгенерированным экранам.
• Черновики документов. Кнопки «Генерировать ТЗ» и соседние собирают из схемы черновик технического задания и описание системы для обсуждения с клиентом.

Где здесь AI-разработчик

Если по-человечески, AI хорош там, где раньше инженер работал как очень дорогой копировальный аппарат. Во Fractal ему досталась ровно такая работа, и вот как она устроена.

• AI пишет описания, а не код. ISFL Builder отправляет ТЗ модели и получает карту экранов в строгом формате. Следующим шагом модель по требованиям и ISFL пишет SFL и IFL. Всё, что она написала, проходит те же валидаторы, что и код человека. Ошибся в типе или сослался на экран, которого нет: описание не примут.
• Генератор детерминирован. Код строит не модель, а Fractal. Одно и то же описание всегда даёт один и тот же SQL, те же модели и те же экраны. Это главная страховка: модель может фантазировать в черновике, но не в production-коде.
• КодГен для точечных доработок. Когда экран требует нетиповой логики, кнопка КодГен собирает для Codex отдельный prompt на каждый экран: IFL-блок экрана, SFL-схему, директивы и короткий список файлов, которые разрешено трогать. Свои компоненты помечены маркером, без которого модель в файл не пишет. Каждый запуск, токены и ошибки уходят в журнал.
• Человек отвечает за замысел. Архитектор читает описание, а не тысячи строк сгенерированного кода. Описание CRM выше помещается на один экран, и спорить о нём с клиентом можно по существу.

Получается та самая схема, о которой я говорю в видео: сначала человек строит скелет и нервную систему, а уже потом AI помогает быстро нарастить мышцы и кожу. Наоборот тоже можно, но тогда сначала надувают красивый резиновый манекен, а потом пытаются понять, как бы ему приделать позвоночник.

Ограничения, о которых мы говорим заранее

• Стек фиксированный. На выходе PHP, Yii2, MySQL, Docker. Если проекту нужен другой стек, Fractal поможет спроектировать данные и экраны, но код не сгенерирует.
• Уникальная бизнес-логика пишется руками. Fractal строит базу, API и админку, а то, что делает перевозку перевозкой, а клинику клиникой (расчёт мест по отрезкам пути, деньги, роли, интеграции), пишут инженеры. Генератор экономит рутину, а не думает за нас.
• IFL рассчитан на типовые экраны. Формы, списки, карточки, таблицы, фильтры. Нестандартный дизайн уходит в свои компоненты, для них в IFL есть отдельный тип.
• Дисциплина обязательна. Одна строка SFL это одна колонка, в списке полей IFL нет пробелов, ручной код живёт в сервисах и компонентах, а не в сгенерированных файлах. Иначе следующая регенерация его аккуратно и без злого умысла сотрёт.
• Генератор это рабочий инструмент, а не продукт. Интерфейс у него инженерный, онбординга нет, и показываем мы его на созвоне, а не продаём по подписке.

Что получилось на выходе

Fractal не живёт отдельно от проектов, он внутри них. Несколько систем, которые выросли на этой основе и о которых есть подробные кейсы:

• Bus Ticket: административная система продажи автобусных билетов. Схема данных, API с документацией и базовая админка сгенерированы, маршруты, места, цены и брони дописаны руками.
• Автобусный букинг: система для перевозчика от сайта до панели собственника на Fractal-схеме автобусных перевозок.
• Svit BUS: приложение, сайт и учётная система бронирования билетов.
• NorthWest: CRM для логистической консалтинговой компании, где SFL и детерминированная генерация позволили уместить в бюджет заметно больше, чем обычно влезает в MVP.
• Корпоративный софт для немецкого холдинга: SFL использовался для описания сущностей, базы, API и части документации.

Почему архитектор сейчас важнее, а не менее нужен

Чем быстрее можно что-то произвести, тем опаснее ошибка в замысле. Раньше неправильную идею реализовывали долго и дорого, и у бизнеса был шанс заметить беду заранее. Теперь плохую идею можно реализовать удивительно быстро. То есть некачественное решение тоже стало масштабироваться быстрее. Прогресс, ничего не скажешь =)

Ждать, пока всё начнёт писаться само, всё равно что купить реактивный двигатель и надеяться, что он сам построит самолёт. Сначала нужны аэродинамика, конструкция, расчёты и человек, который понимает, зачем самолёт летит именно туда. Сильный архитектор сегодня не сидит на троне из UML-диаграмм и не запрещает всем жить. Он превращает хаос требований в описание, из которого систему можно собрать быстро и предсказуемо. Fractal для нас ровно такой способ: маленькие вещи теперь и правда можно делать быстрее, а большие вещи можно делать быстрее без потери головы.

Где посмотреть

Генератор Fractal живёт на нашем стенде и показывается на созвоне: вместе открываем редактор, пишем кусок SFL под вашу задачу и смотрим, что из него получается. Публичной ссылки нет: в генераторе лежат схемы живых проектов.

Нужна система, а не очередной цифровой аттракцион?

Если вам нужна сложная веб-система, CRM с интеграциями, быстрый прототип SaaS или постепенная замена зоопарка программ внятной платформой, приходите на Ingello Systems. Начинаем с бесплатной консультации: разбираем процесс и данные, показываем, какая часть системы ложится на генератор, а какая потребует ручной работы, и только после этого называем цену.

Похожее решение: ИИ-агент, который сам продёт.