AI that builds your application without writing code
Writing code has become cheap. Maintaining it has not.
An AI can now write in minutes the code that used to take a week. We use it every day and would not go back. But a business application is not written once: it is changed for ten or fifteen years, by people who were not there when it was written. Every line generated for a new feature is a line somebody will have to understand before they can safely touch it. And when every feature is solved a little differently, programs drift apart, and each change costs more than the one before.
The speed of writing was never the real cost of business software. The real cost is what it takes to change it safely later.
A management system for applications
Nobody would keep a company's accounts by hand, each entry written a little differently by whoever happened to be at the desk. Accounts live in a system that knows what an entry is, checks it against rules, and can tell you what a change affects.
The definition of an application is not so different from accounting data. It is rules, and the application of rules: what data a page shows and who may see it, what a button does and under which conditions, which figures a report prints. In most software those rules are scattered through the code. In GTmeta they are data, and the Suite keeps them the way a management system keeps accounts: it records them, checks them, and tells you what depends on what. The Suite is, in effect, the management system of your applications.
One engine draws every application
Pages, forms and grids, the SQL they run, the actions behind every button, the menus and the reports: all of it is a description, and one engine reads that description and draws the application. The engine is the same for every project; what changes from one application to the next is only the description.
This is also why an AI can build a GTmeta application without writing code. It writes the same description a person writes in the Designer, with the same building blocks. A page built by the AI is opened, read and changed in the Designer exactly like a page built by hand.
Technical note: the vocabulary is closed. The AI composes pages from the building blocks the platform already has; it does not add new mechanisms to the engine. That boundary is what keeps its work reviewable.
Three places where business software usually hurts
Most of the changes a business application receives during its life land in the same three places. GTmeta keeps each of them in one place, in plain view.
The link between programs and data
Every SQL statement of an application lives in a single repository, with an identifier, the connection it runs on and its declared parameters. Pages and reports do not write SQL inline: they point to a statement by its identifier. When a table changes, the question "what does this affect?" is answered by looking up which statements use it and which pages and reports point to them, not by searching through code.
The repository is also where access to data is enforced. A parameter that restricts what a user may see is filled in by the server from that user's profile, never by the page, so no screen can ask for more than its user is allowed to read.
Reports and the data behind them
Reports take their data from statements in the same repository, and the parameters a report receives are the ones declared on those statements. Changing what a report shows, or what the page that prints it must pass, is a change to definitions anyone can read. The same user restrictions apply to a report's queries as to the page.
What happens when you click a button
Behind every button there is an ordered list of actions: load this data, check these conditions, save, call this procedure, open that page. Each step has a type, and conditions decide whether it runs. To know what a button does, you read its list in the Designer from top to bottom. Nothing is hidden in an event handler written years ago by somebody else.
Where the AI fits
This is the principle behind the AI-assisted design we are building for the Designer (see the roadmap). You describe a page; the assistant builds it in a staging area of the Designer, and a validator checks that every reference resolves: every dataset points to a statement that exists, every button to actions that exist. You review the result and commit it, or discard it. The AI never touches your project until you do, and what it leaves behind is a description your team can read, not code somebody has to decipher.
What we hold ourselves to
- One engine for every application. A change to the engine is exercised by every page of every project.
- A small vocabulary. Every new mechanism has to earn its place, because everyone who maintains an application has to learn it.
- Description first, code last. When something can be done with the building blocks the platform already has, it is done that way, whether a person or an AI is doing it.
- Every change readable by the next person. An application should be understandable by somebody who was not there when it was built.