This case is about how our AI developer actually works. Spoiler: it does not write a whole project from scratch after hearing "build me a CRM". It writes a description of the system in three small, strict languages, and the code, database, API and admin panel are built from that description by Fractal, our generator. It builds them the same way on every run, with no inspiration and no hallucinations.
Right now the market looks a bit like a noisy bazaar. On one side everyone shouts that artificial intelligence is about to replace programmers. On the other side businesses keep losing money on clumsy integrations, manual work, frozen spreadsheets and systems that break at the worst possible moment. Dictating "build me a CRM, an ERP and a client portal" to a chat sounds lovely, but in a real business such tricks work exactly until the first normal complication.
In the video I show it on a live example: a simple CRM prototype with a client, a card, a table, filters, statuses and events. Below we look under the hood: how the ISFL, SFL and IFL languages work, what exactly Fractal generates, where AI sits in this chain and where it is deliberately absent.
Why vibe coding is only good for small things
Let's skip the holy wars. Vibe coding, no-code and low-code are not evil. A small screen, a form, a filter, a table, a landing page with some logic: modern tools really do speed this up, and arguing with that is silly.
But a complex system is no longer a stool made of three boards. It is a city with roads, crossroads, utilities and traffic rules. It is home to the business rules the company actually runs on, to integrations where one system has to talk to another properly instead of exchanging tantrums, and to state scenarios where a screen behaves differently depending on the role, status, date and a dozen details that surface after the client's first phone call.
AI can quickly draw a beautiful shop window, but it does not always understand where the load-bearing walls are. And oddly enough, the business cares about the walls more. So we split the work: the walls are described formally and built by the generator, and AI helps where it is genuinely strong.
Fractal in two paragraphs
Fractal is an automated development technology we have been building for more than eight years. You do not type a system in it, you describe it: which entities and relations exist, which screens, which components on those screens and where links lead. The generator takes the description, checks it with a validator and produces the MySQL schema, migrations, models, a CRUD admin panel, a REST API with documentation, interface screens, fake data and tests. The project base (Yii2, Docker setup, authentication, files, translations) comes from a prototype that is copied for every new system.
Roughly speaking, it is a constructor that builds constructors. The history, architecture and valuation of the platform are covered in a separate case, FRACTAL: automation of programming and software development. Here we look at the mechanics.
How it works: description, generation, system
- Requirements. A spec, a brief or just a conversation with the client.
- ISFL. Requirements are laid out as a map of screens: which screens exist, which pattern each one uses, which models take part and where you can go from it.
- SFL and IFL. Two models are derived from the map: a data model in SFL and an interface model in IFL.
- Validation. The generator checks both descriptions against strict rules: names, types, relations, whether linked screens exist. An error is highlighted right in the editor.
- Generation. SQL, migrations, models, CRUD, API, screens, menus and fake data are built from the validated description. Running it again with the same description gives the same result.
- Manual work. Whatever makes the client's business special is written by hand or with CodeGen in dedicated places.
The three Fractal languages
The languages are small and boring on purpose. A boring language is easy for a person to read, easy for a model to write and impossible to read two ways.
ISFL: a map of screens and the flow
ISFL describes the application from above. One screen is a block of exactly seven lines: technical name, title, pattern, description, events, links to other screens and models. Blocks are separated by an empty line.
orders_param
Заказы
list-table
Список заказов пользователя
Просмотр, фильтрация
order_param,profile_param
order,userThe pattern comes from a closed list: crud, list-table, form, model-profile, calendar, chat, google-map and about fifteen more. A link to a screen that does not exist is a validation error, not a surprise during the demo. Five system screens (layout, home, login, registration, profile) are added automatically, so nobody can forget them, even with real effort.
SFL: the data schema
SFL describes the database. The first line of a block is the table, the rest are fields. A human-readable label goes before the vertical bar, the technical name after it. An exclamation mark makes a field required. A field ending in _id becomes a foreign key. Here is a real fragment of a CRM schema from our registry (the labels are in Russian, as in the original):
Проект|project
Название|name !
Описание|description ? text
Клиент|client_id !
Дата_начала|start_date date
Статус|status !
Задача|task
Название|name !
Проект|project_id !
Ответственный|user_id !
Дата_создания|created_atThe generator infers half of the types from the field name: *_at becomes a timestamp, description and *_text become text, *_price and *_cost become money, is_* becomes a boolean. You do not write the id field or the user table, they always exist. Labels before the bar go into UI captions and SQL column comments. Standard names such as email, phone_number or latitude are recognised by the fake data generator and filled plausibly, so the prototype looks alive from the first run instead of being a pile of "test1, test2".
The article cover shows the same mechanics at scale: a bus transport schema with 25 business objects, trips, route segments, bookings, promo codes and recalculations. Our transport systems grew on this base.
IFL: screens on top of models
IFL describes the interface and relies on SFL. A screen is a block, and the grid is set with lines: a dash opens a new row, a number from 1 to 12 sets the column width. A component is a single line of three parts: the model, the component type and the fields separated by slashes.
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_idThere are three meaningful lines here: a full-width title, a list of clients as cards in two columns taking 9 of 12 columns on the left, and a form for the same model taking 3 columns on the right. screen_client_detail_param_id turns into a link to the client card, and dot notation such as project.client.city pulls a field through a relation. There are about twenty component types: forms, filters, tables, sliders, cards, media, hero blocks and custom components when the standard ones are not enough.
A special point of pride is business logic directives. Lines such as event:order:before_update, action:order:recalculate or method:order:build_pdf written right in the screen description are registered in the documentation and become method stubs in the model's service. Logic does not get lost between the screen and the code, it is written down where it was invented.
What Fractal generates
- SQL and migrations. Tables, types, required fields, foreign keys, column comments.
- Models and a CRUD admin panel. Admin sections for every entity, menus, filters, sorting, pagination.
- REST API with documentation. List, view, create, update and delete endpoints for every model, plus Swagger that lets a frontend or a mobile app connect without oral tradition.
- Interface screens. Pages and components from IFL, layout, menus, links between screens.
- Fake data. Based on field names, and where a name says nothing, a model picks values that make sense for the domain. The demo looks like a working system, not an empty database.
- Tests. Checks of the generator itself against reference schemas and generation of Playwright E2E scenarios for the generated screens.
- Draft documents. The "Generate spec" button and its neighbours assemble a draft specification and a system description from the schema for discussion with the client.
Where the AI developer fits in
Put simply, AI is good wherever an engineer used to work as a very expensive photocopier. In Fractal it got exactly that kind of work, and here is how it is organised.
- AI writes descriptions, not code. ISFL Builder sends the spec to a model and gets back a map of screens in a strict format. In the next step the model writes SFL and IFL from the requirements and the ISFL. Everything it writes goes through the same validators as a human's code. A wrong type or a link to a missing screen, and the description is rejected.
- The generator is deterministic. The code is built by Fractal, not by the model. The same description always gives the same SQL, the same models and the same screens. This is the main safety net: the model may fantasise in a draft, but not in production code.
- CodeGen for targeted work. When a screen needs non-standard logic, the CodeGen button builds a separate prompt for Codex for each screen: the screen's IFL block, the SFL schema, the directives and a short list of files it is allowed to touch. Custom components carry a marker, and without it the model does not write to the file. Every run, its tokens and errors go to a log.
- A person owns the idea. The architect reads the description, not thousands of lines of generated code. The CRM description above fits on one screen, and you can argue about it with the client on substance.
This is the very approach I talk about in the video: first a person builds the skeleton and the nervous system, and only then AI helps grow the muscles and skin quickly. You can do it the other way round, but then you first inflate a beautiful rubber mannequin and then try to work out how to attach a spine to it.
Limitations we mention up front
- The stack is fixed. The output is PHP, Yii2, MySQL, Docker. If a project needs a different stack, Fractal helps design the data and screens but will not generate the code.
- Unique business logic is written by hand. Fractal builds the database, API and admin panel, while whatever makes transport transport and a clinic a clinic (seat calculation by route segment, money, roles, integrations) is written by engineers. The generator saves routine, it does not think for us.
- IFL is meant for typical screens. Forms, lists, cards, tables, filters. Non-standard design goes into custom components, and IFL has a separate type for them.
- Discipline is mandatory. One SFL line is one column, the IFL field list has no spaces, and hand-written code lives in services and components, not in generated files. Otherwise the next regeneration will erase it neatly and without malice.
- The generator is a working tool, not a product. Its interface is engineering-grade, there is no onboarding, and we show it on a call rather than sell it by subscription.
What came out of it
Fractal does not live apart from projects, it lives inside them. A few systems that grew on this base and have detailed cases:
- Bus Ticket: an admin system for selling bus tickets. The data schema, the API with documentation and the base admin panel were generated, routes, seats, prices and bookings were written by hand.
- Bus booking: a system for a carrier, from the website to the owner's panel, built on the Fractal bus transport schema.
- Svit BUS: an app, a website and a ticket booking back office.
- NorthWest: a CRM for a logistics consulting company, where SFL and deterministic generation made it possible to fit noticeably more into the budget than usually fits into an MVP.
- Corporate software for a German holding: SFL was used to describe entities, the database, the API and part of the documentation.
Why the architect matters more now, not less
The faster you can produce something, the more dangerous a mistake in the idea becomes. A wrong idea used to be implemented slowly and expensively, and the business had a chance to spot trouble early. Now a bad idea can be implemented surprisingly fast. In other words, poor decisions scale faster too. Progress, you have to admit =)
Waiting for everything to start writing itself is like buying a jet engine and hoping it will build the plane on its own. First you need aerodynamics, a structure, calculations and a person who understands why the plane is flying there in the first place. A strong architect today does not sit on a throne of UML diagrams forbidding everyone to live. They turn the chaos of requirements into a description from which a system can be assembled quickly and predictably. Fractal is exactly that for us: small things really can be done faster now, and big things can be done faster without losing your head.
Where to see it
The Fractal generator lives on our stand and is shown on a call: we open the editor together, write a piece of SFL for your task and see what comes out. There is no public link: the generator holds the schemas of live projects.
Need a system, not another digital attraction?
If you need a complex web system, a CRM with integrations, a quick SaaS prototype or a gradual replacement of a zoo of programs with a coherent platform, come to Ingello Systems. We start with a free consultation: we go through the process and the data, show which part of the system fits the generator and which needs manual work, and only after that we name a price.
A similar solution: An AI agent that sells by itself.
