When AI codes in low-code, code stops being the central problem

The first wave of AI coding left us with a seductive image: an agent takes an issue, writes files, runs tests and opens a pull request. It works. Sometimes it works very well.

But it also leaves an uncomfortable question for any serious team: if AI can write code faster than humans can responsibly review it, what is the new bottleneck?

In a traditional language, the answer is often a large diff. Hundreds or thousands of lines in Java, C#, JavaScript or SQL. An agent can produce them in minutes; the team then has to understand, review, test, integrate and maintain them for years.

In a mission-critical application, that is not a detail. It is the center of the problem.

AI does not remove review: it moves it

Google’s internal code review practices are clear: small changes are reviewed faster and more thoroughly; 100 lines is usually reasonable, while 1,000 lines is usually too large. GitHub published a recommendation this year specifically for agents: do not let them produce one giant pull request; split the work into a stack of small, reviewable PRs.

That recommendation is right. It also shows the limit of the traditional approach: when the primary artifact is general-purpose code, human supervision still happens over a large amount of accidental detail.

It is not enough for the code to compile. A reviewer has to understand whether it respects the business model, breaks a historical convention, touches a regulated flow, duplicates logic, opens a security edge, or changes something nobody wanted changed in production.

AI accelerates writing. Understanding remains a human responsibility.

The value of low-code is not “writing less”: it is reviewing closer to intent

In serious model-driven and low-code platforms, the point is not to avoid code for aesthetic reasons. The point is that the important artifact is closer to intent: entities, relationships, rules, transactions, processes, screens and integrations.

Model-Driven Engineering literature says this directly: models raise the level of abstraction and hide implementation detail. A Software and Systems Modeling article explains that domain models include less “accidental detail” than code written in general-purpose languages and can therefore be easier to create, verify and maintain.

That becomes central with AI coding.

If an agent changes a business rule in a model, the team reviews the rule. If an agent generates 3,000 lines to indirectly implement the same rule, the team reviews the rule and also the technical path the agent chose.

The difference is not philosophical. It is operational.

GeneXus already starts from an advantage: the Knowledge Base

GeneXus was not born as “one more language.” It was built around a stronger idea: capture business knowledge in a Knowledge Base and generate from there.

The official documentation says a KB stores users’ views of the business reality being modeled; that knowledge is structured, pure and platform-independent, and GeneXus can infer more knowledge and generate the database and application programs for different platforms.

That changes the AI conversation.

In a traditional stack, the agent usually works on the final byproduct: source files. In GeneXus, the natural place to reason is not the generated code. It is the KB: objects, rules, properties, Patterns, transactions, procedures, APIs and relationships.

So when AI codes on a platform like GeneXus, the best outcome is not “more code.” It is proposed changes on modeled knowledge, in smaller, readable, governable units.

“Orders of magnitude less” matters in production

A mission-critical system is not protected by hope. It is protected by reducing the surface that must be audited and putting validation in the right place.

A low-code change can represent a large amount of generated code later. But the team does not necessarily need to review that generated code line by line as if it were handwritten authorship. It can review the higher-level change: the object, property, rule, screen, Procedure or transaction. Then the deterministic generator does its job.

Carnegie Mellon SEI makes a relevant point for Model-Driven Engineering: in these systems, models are the primary artifacts; when an organization keeps only the generated code, evolution becomes harder because generated code is not necessarily structured for human comprehension.

In GeneXus terms: if the knowledge is in the KB, review has to come back to the KB. Generated code matters, but it is not the best place to understand business intent.

The honest warning: low-code without engineering can fail too

None of this means “magic low-code.” Poorly governed low-code can become shadow IT, duplication, unclear ownership and applications that are hard to maintain. Microsoft, Gartner and other analysts keep repeating the same point: in enterprise, low-code needs governance, security, access control, lifecycle management, monitoring and clear development practices.

NASA uses and studies model-based software engineering for mission- and safety-critical contexts, but its guide is explicit: auto-generated code must be handled carefully, verification and validation still exist, and models and generated code must remain synchronized.

That is the right line: not less discipline. Discipline applied to the right artifact.

Where KBbridge fits

KBbridge complements GeneXus at exactly that point.

KB Sync externalizes the Knowledge Base to plain text, keeps it synchronized and lets AI work on a readable representation. KB Editor gives the agent real GeneXus context: syntax, navigation, local documentation through MCP, language rules, synchronization state and validation before returning to the KB.

The result is not AI throwing code over the wall. The target workflow is different:

• the agent reads the KB as text;
• it proposes changes in units of knowledge;
• the team reviews smaller, more semantic diffs;
• Git leaves evidence;
• GeneXus remains the authority that validates and generates;
• KB Sync validates before writing back.

That workflow is far more reasonable for an application running a bank, a pharmaceutical operation or a regulated system than accepting thousands of new lines because “AI wrote them and the tests passed.”

The right question

The question is not whether AI should code. It already does.

The question is: which artifact do you let it code against?

If it operates over thousands of lines of traditional code, your bottleneck will be reviewing thousands of lines. If you bring it closer to a modeled, versioned, readable and validated Knowledge Base, human supervision can focus where it adds value: intent, rules, impact and consistency.

That is the advantage of a serious low-code platform in the age of agents: not producing less software, but producing it from a level where humans and machines can understand each other better.

---

Sources

• Springer — Low-code development and model-driven engineering: Two sides of the same coin?: link.springer.com
• Carnegie Mellon SEI — Model Driven Engineering: Automatic Code Generation and Beyond: sei.cmu.edu
• Google Engineering Practices — Small CLs: google.github.io
• GitHub Engineering — Turn one giant AI-generated pull request to a reviewable stack: github.blog
• ACM CCS / arXiv — Do Users Write More Insecure Code with AI Assistants?: arxiv.org
• DORA / Google Cloud — Accelerate State of DevOps Report 2024: dora.dev
• NASA — Guidebook on Model-Based Software Engineering and Auto-Generated Code: ntrs.nasa.gov
• Gartner Peer Insights — Enterprise Low-Code Application Platforms: gartner.com
• GeneXus Docs — Knowledge Base: docs.genexus.com
• GeneXus Blog — Executable Specifications and Four Decades of GeneXus Vision: genexus.blog

How you try it

If you want to see how a GeneXus Knowledge Base becomes readable to agents, with text in Git, local documentation and validation before returning to the KB, start with Getting Started. There is a 15-day free trial, no card required, at kbbridge.com.