AI-програміст, який пише за архітектурою з розумом

Цей кейс про те, як у нас насправді працює 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. Починаємо з безкоштовної консультації: розбираємо процес і дані, показуємо, яка частина системи лягає на генератор, а яка потребуватиме ручної роботи, і лише після цього називаємо ціну.

Схоже рішення: ШІ-агент, який сам продає.