More
than three decades ago, GeneXus made a bet that today sounds strangely current: you don’t write the system, you model it; and from that model, code is generated deterministically. When the business changes, the model changes, and the system is regenerated.
The emergence of LLMs puts that bet in a new light. AI-assisted development is advancing at a rapid pace, but it keeps stumbling over an old problem that GeneXus has been solving for years: how do you trust what was built, understand it, and be accountable for it?
This article describes how we are rethinking GeneXus for this era – what we preserve from its core, what we open up, and what we incorporate from LLMs – to develop and maintain critical systems with AI in a safe and auditable way.
The idea in one sentence: in the new GeneXus, the conversation does not directly produce code. It produces a formal, versioned model; code is one of its projections.
Two common approaches in LLM-based development
The first is to go with the flow: ask the model for what we want and trust that it will handle it well, betting that each new version will be a little better than the last. It is fast and gets you far, until you need to understand, maintain, or be accountable for what was built.
The second is to add scaffolding: a specification that declares intent, accompanied by hooks and controls that monitor the model while it works. It is a disciplined, serious approach. But it retains a fundamental limitation: the specification is prose.
It can be reviewed, but it is difficult to deterministically verify that it is complete, that it does not contradict itself, and that every part of the implementation corresponds to an explicit intent. The correspondence between what was requested and what was built ends up relying on reviewing the code, the tests, and the final behavior – precisely what is increasingly costly to examine in depth.
Both approaches are legitimate and solve real problems. The difference we propose is not one of speed, but of what kind of guarantee remains at the end of the process.
The third way: modeling intent
Instead of leaving intent written only in prose, GeneXus converts the conversation with the user into a formal model, guided by an ontology that knows what concerns a system must address and what questions must be answered for it to be considered complete.
It is worth being precise about what that ontology is, because that is where the key lies – and also the limit of the approach.
It is not a neutral oracle: it is opinionated knowledge, the codification of what GeneXus learned over thirty years of building business systems. That opinion is its value: you do not reinvent from scratch in every project what it takes for a system to be complete. And, like everything else in GeneXus, it is inspectable and versionable.
On top of that model, verification is no longer just a reading. And here it is worth saying precisely what it guarantees and what it does not.
What is verified deterministically is that the model complies with the rules of the ontology: that all mandatory concerns have been addressed, that every reference points to something that exists, that constraints are met, and that the model does not contradict itself.
What cannot be proven by machine is that the model says what the business actually needs. That leap – from real intent to typed facts – is still made through a conversation.
The difference from prose is not that we have eliminated that conversation, but that we have moved it to a verifiable ground. Before, interpretation was scattered across a document that someone read and considered good enough. Now it is typed, recorded, and contrastable against an explicit ontology.
The risk does not disappear: it is concentrated, made visible, and becomes auditable. The process cannot declare complete, with respect to the ontology, what is not yet complete.
An example, end to end
Let’s take something as common as permissions.
The agent does not ask about authorization models, policies, or roles. It asks whether anyone can enter the system, whether everyone sees the same options, and who can do each thing.
Each answer is stored as a typed fact in the model.
And this is where the difference becomes clear: if the system declares, for example, an operation to delete an invoice but the question of who can execute it was never answered, verification catches it. That concern was left open and the system cannot move forward as if it were resolved.
There is no need to trust that a reviewer will discover it by reading code: there is a declared operation and the knowledge needed to govern it is missing. That gap is visible to a machine.
When the permissions model is complete and verified, the repeatable structures, validations, and access controls can be generated deterministically.
And if there were a unique permissions rule that no generator covers yet – for example, “only the regional manager who approved the transaction can reopen it” – that part is handled differently, as we will see later, but it is also recorded and must present evidence.
The same principle becomes even more important when the business changes.
Suppose an invoice that could previously be closed directly now requires prior approval. The change does not start by searching for which files need to be touched. It starts by modifying the model: a new rule appears, a new operation or state, and the relationships needed to represent it.
From there, the system can calculate which parts depend on that knowledge and which projections were affected by the change. Those that apply are regenerated; those that do not depend on it remain intact.
This way, the question shifts from “did we remember to update all the affected places?” to “what does the graph say depends on this change?”
That thread – conversation in business language, typed facts, verification that exposes what is missing, explicit impact analysis, generation of what is repeatable, and a different treatment for what is unique – is the one that runs through the nine principles.
How intent is captured
1. Conversation in business language, not technical jargon
Everything happens inside an agentic development environment – an ADE – with a chat through which the user converses with the agent about the system they want to build.
The user does not need to know the terms of the ontology: they talk about the business and the agent translates.
This is how we incorporate one of the great advantages of LLMs – a fluid conversation in natural language – without transferring the technical vocabulary of the model to the user.
2. Level of rigor declared at the start; the ontology adapts what is mandatory
At the beginning, the project’s level of rigor is declared: a proof of concept, an internal tool, or a mission-critical system.
Based on that profile, the ontology determines which concerns must be covered as mandatory and which can be resolved with decisions already established by GeneXus.
From there, the agent explores what is missing. It does not improvise questions in each conversation, but works from the knowledge GeneXus has codified about what it takes to build quality systems.
This is especially important for Mission-Critical Systems. The user does not need to know all the technical dimensions required to build one: security, access, integration, accessibility, operability, internationalization, governance, and other system concerns.
GeneXus takes a position on that. Its ontology codifies what must be considered for each type of system and requires that those concerns be addressed or explicitly declared as not applicable. The agent brings those decisions into a conversation in business language.
The user explains what they need. GeneXus contributes the knowledge about what needs to be considered to build it at the declared level of rigor.
How it is verified
3. Formal model with typed facts, not interpretable prose
In specification-driven development, the agent follows instructions written in prose.
Here, answers are represented as typed facts within a formal model.
That is why what the system must comply with can be verified deterministically. It is not a specification that someone reads and considers good enough: it is a model that a machine can accept or reject.
4. The model lives in Git, not in a proprietary database
The model consists of text files in a Git repository.
You can diff it. You can review it in a pull request. You can work with branches. Git blame can tell you who declared each fact, when, and in which change it appeared.
A pre-commit hook validates the model against the ontology and rejects the commit if it does not conform.
The source of truth is not locked inside the ADE or a proprietary database. It is in open files, versionable and processable with the same tools any development team already uses.
If tomorrow the user wants to build another tool on top of that knowledge, the model is still there. If they want to audit it, so is it.
5. Nothing happens in a black box
The ADE offers views to understand the model, know what is missing for the system to be ready, explore its relationships, and anticipate what artifacts will be produced.
And the model does not simply return “valid” or “invalid.”
It can show which concern remains open, what was resolved by a profile decision, what was declared as not applicable, and what still needs a human answer.
At any point you can see the real state of the system and the reasons why it cannot yet move forward.
The gate blocks; the ADE explains why.
How it becomes code
Before talking about generation, it is worth defining an expression we will use from here on.
We call compiled regime the cases in which the knowledge needed is represented in the model and a generator exists that can transform it into an artifact without asking an LLM to interpret intent again.
In that regime, generating is no longer a new decision. It is a compilation of knowledge already captured.
6. Deterministic generation for what is repeatable
When the model is complete and verified, generation begins.
What repeats – data structures, operations, policies, contracts, and recurring patterns of business systems – can be produced through deterministic generators.
When a generator exists for that knowledge within the compiled regime, given the same model and the same generator, the same output is always produced. There is nothing to reinterpret or guess: the generator transforms into code the knowledge that was already captured.
7. Code is a projection of the model, not a standalone artifact
As we saw in the invoice example, when the business changes the model changes, and the dependencies in the graph make it possible to determine which projections were affected and must be regenerated.
In the compiled regime, code is not the place where intent is preserved: it is a consequence of the model.
Discipline for what is unique
Not everything is repeatable.
For what is truly new – which is often the most critical and differentiating logic of a business – a generator is not enough.
The answer is not to pretend otherwise, but to offer a different, explicit guarantee.
8. Generic objects with provenance and evidence
When something will occur only once and no generator yet covers it, it is represented as a generic object.
There the LLM can build it, but not from a conversation that is then lost.
The input it used, the specification, and the context material are saved and versioned. The result must declare how it was produced and present evidence that it works.
It is not held to the same guarantee as a compiled artifact. It is held to a different one, explicitly: provenance and evidence.
This is deliberately the point where the approach coexists with uncertainty rather than denying it, and manages it by keeping it traceable.
9. The second-instance rule: what is repeatable becomes a generator
There is a fundamental rule: if a second instance of the same type of input appears, the system no longer allows it to be treated as a unique case.
And this is not a methodological recommendation that a developer has to remember. Cardinality is part of the model and validation rejects a second instance being declared as a unique case.
At that point, that knowledge must become a generator.
The LLM can help write it, but from then on it no longer invents each result from scratch.
The first occurrence may require authorship and evidence. The second reveals that a pattern exists. The pattern is formalized and moves into compiled territory.
This way, the territory of the uncertain does not grow indefinitely with the system: it narrows as knowledge hardens.
The product we are designing
We are designing a new GeneXus: an agent you talk to about your business, and that transforms that conversation into a formal, verifiable model.
You do not need to know what is technically required to build a Mission-Critical System. GeneXus has an opinion on that: its ontology incorporates that knowledge and ensures that important concerns are not silently forgotten.
The bet is not just to build faster. It is to be able to trust what is built: to know that what was necessary was considered, that what is missing is visible, and that what we already know how to solve is produced in a repeatable way.
That trust rests on a single line of knowledge, verifiable end to end, where each link states what it guarantees and what its limit is.
We are not designing an agent that writes more code.
We are designing a GeneXus that converts conversations into verifiable knowledge, and verifiable knowledge into software we can trust.
You may also be interested in reading:
GeneXus and Neuro-Symbolic Architecture
The Problem with Prompt-Based Development
GeneXus for Agents: 15 key questions answered