An AI Programmer Who Writes According to Architecture and With Sense

Be sure to watch the video; it is embedded directly in this article: in it, I show with a live example how we develop complex web systems using AI, why ordinary vibe coding is suitable only for small things, and what a mature approach looks like, where architecture, business logic, screens, and integrations are designed first, and only then AI accelerates development, making prototypes, charts, CRM modules, and events cheaper and faster =)

How we develop complex web systems with AI, but without the cult of vibe coding =)

Right now the market looks a bit like a noisy bazaar: on one side everyone is shouting that artificial intelligence is about to replace programmers any moment now, while on the other side businesses are still losing money on crooked integrations, manual work, frozen spreadsheets, and systems that break at the worst possible moment. The idea of simply dictating to a chat a phrase like make me a CRM, ERP, and client portal sounds beautiful. But in real business, such tricks work exactly until the first normal complication.

As long as we are talking about a small screen, a simple form, a filter, and a table — yes, modern tools really do speed up production. But as soon as you have a large subject area, roles, events, telephony, calculations, analytics, queues, statuses, change history, dozens of screens, and integrations, it is no longer magic, but mature engineering. And this is where it becomes clear where AI is useful and where it just very energetically generates chaos.

Why ordinary vibe coding is good only for small tasks

Let’s do without religious wars. Vibe coding, no-code, low-code, and other fast builders are not evil. For some tasks, they are excellent. If you need to quickly sketch an MVP, an inquiry interface, a small CRM table, a landing page with logic, or an administrative form, this can be very profitable.

But a complex system is no longer a stool made of three boards. It is a city with roads, intersections, utility networks, and traffic rules. This is where business rules live — that is, the formal conditions by which the company actually operates. This is where integrations live — when one system must correctly talk to another, not exchange hysterics. This is where state scenarios live — when a screen behaves differently depending on the user’s role, entity status, date, event, previous actions, and a dozen other little things that usually surface after the client’s first call.

And this is where the naive approach starts to crack. Because AI can quickly draw a beautiful facade, but it does not always understand where the building’s load-bearing walls are. And for business, oddly enough, the walls are what matter most.

Where AI really makes development cheaper

Development really has become cheaper. It would be stupid to hide this. But it became cheaper not because architects, analysts, and engineers suddenly became unnecessary. Quite the opposite. It became cheaper where people used to spend hours and days on repetitive mechanical work: repeated forms, screen bundles, standard handlers, standard components, routine interface templates, auxiliary modules, and wrapping around already understood logic.

To put it in human terms, AI is good where an engineer used to work like a very expensive copier. And this part of the routine can now genuinely be automated. But key decisions must still be made by a human, preferably one who is not tired and does not have the imagination of a goldfish.

We use LLM (large language model, meaning a large language model — roughly a smart auto-completer of text and code) as a production accelerator, not as a shaman to whom the entire project is randomly handed over. This is an important difference. A very important one.

Our approach: architecture first, generation afterward

Instead of simply dictating chaotic wishes to the system, we build the project step by step. First, a human describes the high-level logic. What entities exist in the system. What relationships they have. What roles exist. What events affect product behavior. Which integrations are mandatory. Where the module boundaries are. Where the risks are. Where future growth points are. Where the potential swamps are, into which contractors without systems thinking usually jump quite happily.

Then we use a declarative approach. Declarative means that we describe what must exist, instead of manually moving every nut. For example: there is a client entity, there is a client form, there is a client table, there is an event card, there is an activity chart, there are transitions, filters, restrictions, actions. We describe not button chaos, but the screen model.

Then generation is connected. But not instead of architecture, inside an already meaningful framework. That is, first a human builds the skeleton and nervous system, and only then AI helps quickly grow the muscles and skin. And this is much more useful than the other way around, when first a beautiful rubber mannequin is inflated, and then everyone tries to figure out how to attach a spine to it.

What layers such development consists of

To avoid turning the product into a digital shed, we divide it into understandable levels:

• domain model — this is a description of the main business entities, roughly who here is friends with whom, argues, pays, and changes statuses
• contracts — rules of communication between parts of the system, so modules do not read each other’s minds but work according to agreements
• event model — a list of exactly what happens in the system and how it affects other parts of the product
• integration layer — gateways to telephony, API, external platforms, analytics, payment systems, and other useful grown-up things
• visual screen schema — forms, tables, cards, charts, filters, routes, interface states
• generation of standard code — where expensive manual work is no longer needed, but a fast and disciplined result is needed

That is why the idea close to us is not let AI figure it out itself, but the idea of engineering acceleration. When the machine helps where it is profitable, and the human is responsible for the intent, architecture, and consequences.

If you are interested specifically in this approach to accelerating production, also see our material about FRACTAL — automation of programming and software development. It is precisely about that transition from manual tinkering to a higher level of design.

What this gives business besides beautiful words

A manager cares not about technical romance, but about the result. Preferably one that can be measured in timelines, budget, transparency, and the number of nerve cells that did not die on the project.

Architecture-driven generation provides several very practical effects:

• faster prototyping — you can quickly show a working interface instead of discussing air for a week
• faster approval — the customer sees not an abstract 200-page technical specification, but a live scenario
• less manual routine — standard parts of the product are assembled faster
• higher manageability — the system is easier to extend instead of rewriting every six months
• lower risk of a random dump — because the logic is built top-down, not by the method of random patches

This is especially important for companies that are already tired of living in Excel, in messengers, in manual calls, in separate telephony, in a separate sales spreadsheet, in a separate folder with documents, and in a separate person who for some reason is the only one who knows how everything really works. Such a business is usually very heroic, but already exhausting.

A practical example: CRM, events, charts, telephony

The video shows a very simple, almost ascetic CRM prototype. There is a client, a card, a table, filters, statuses, and events. At first glance, nothing dramatic. But it is precisely in such examples that you can clearly see where the boundary begins between a child’s craft and a normal system.

As long as you just have a list of leads, the task looks almost innocent. But then you want to see interaction history, status dynamics, client events, an activity chart, filtering by dates, automatic updates after calls, a funnel, analytics by managers, segmentation, and other completely normal wishes of any living business.

And then appears webhook (a mechanism where one system itself notifies another that an event has occurred). For example, telephony transmits the fact of a call, and the CRM already records it in the client’s history, updates the funnel, builds an activity chart, and gives the manager not feelings, but data.

That is, the product stops being a beautiful box with a table and turns into an accounting and management system. And that is already a different class of tasks.

Why complex screens must not just be drawn, but thought through

One of the main problems of weak development is that the interface is perceived as a picture. Like, there is a form, a button, and a little table — what is there to think about. But a screen in a serious system is not decoration. It is a decision-making point, a business process node, and the surface through which the user interacts with the company’s logic.

In a good project, the screen is connected to the data model, access rights, validation, the event log, queues, integrations, analytics, reporting, and sometimes even legally significant actions. That is why, for us, a screen is not just frontend. It is part of the architecture.

That, in fact, is why we separately develop both the CRM direction for sales and client processes, and solutions for BPM design and process management, and broader corporate platforms such as platFORMA. Because companies rarely suffer from a lack of screens. Usually, they suffer from a lack of a system.

Why you should not wait another six months until everything starts writing itself

There is a favorite illusion of recent years: let's wait a little, and soon systems will write themselves completely. But reality is more stubborn. Even if generative technologies become ten times stronger, business still has to be ready. There must be a data structure. There must be a process map. There must be module boundaries. There must be clear roles, rules, and priorities.

Without this, waiting for a miracle is like buying a jet engine and hoping it will build the airplane itself. No, first you still need aerodynamics, structure, calculations, and a person who understands why the airplane is flying there specifically, and not into the neighboring hangar.

That is why the right strategy is not to wait for magic, but to move development to a more modern engineering level now. Then every next AI improvement will not be scary news from the internet, but your working tool.

Who this approach suits

Startups. Especially those that have an idea, ambition, and a desire to launch quickly, but no desire to turn development into an endless expense funnel. Here it is important to prototype quickly, align quickly, correct course quickly, but at the same time not build the foundation out of cardboard.

Systemic companies. Those that already have departments, real processes, accumulated mistakes, scattered services, telephony, documents, reports, logistics, sales, operations, and a historical zoo of programs. In such a situation, what is needed is not a toy, but mature architecture that gradually brings order.

If corporate logic is closer to what you need, also look at the cases on the platform for a management holding and materials on eHealth documentation analysis for medical systems. They show very clearly how domain complexity quickly turns random development into too expensive an amusement.

Why a classic architect is now more important, not less needed

The faster something can be produced, the more dangerous an error in the concept becomes. Previously, at least a wrong idea was implemented slowly and expensively, and the business had a chance to notice the trouble in advance. Now a bad idea can be implemented surprisingly quickly. That is, a low-quality solution has also started scaling faster. Progress, nothing to say =)

That is exactly why the value of systems analysis (analyzing how the business actually works), architectural design (organizing a resilient system structure) and contract thinking (when parts of a product interact according to clear rules, not telepathically).

Today, a strong architect is no longer a person sitting on a throne of UML diagrams and forbidding everyone to live. It is a person who can turn the chaos of requirements into a clear digital structure suitable for accelerated development. That is where the real value is.

What is the result

The future is not about simply talking to a little chat and hoping for a miracle. The future is about connecting architecture, systems analysis and generative technologies into one working pipeline. Then the project becomes not a set of beautiful screens, but a machine that can serve the business, calculate, integrate, grow, and not fall apart at the first non-standard task.

And if very briefly: small things can now really be done faster. And big things can now be done faster without losing your head. And that is no longer hype. That is already economics, manageability, and a quite tangible competitive advantage.

Need a system, not another digital attraction?

If you need development of a complex web system, corporate application architecture, rapid SaaS prototyping, CRM with integrations or a gradual replacement of an old zoo of programs with a clear platform, go to Ingello Systems.

There you can view reviews, working principles, cooperation stages, and leave a request for a free consultation. Because good software is not when AI has cheerfully generated something. Good software is when your business stops living in constant fire mode.