A growing number of organizations are betting that AI will write their systems for them. It’s easy to see why. Describe an application, and minutes later something runs: screens, a database, even a sign-in page.

The organizations that have worked this way the longest tell a more nuanced story. The first AI-built application is impressive. The tenth, two years in, is where the conversation changes: who understands it, who can change it safely, and who answers for what it does.

Our view is simple. It isn’t low-code or AI. It’s low-code and AI. AI is changing how fast software gets written. A platform is what keeps that software governable as it grows. Here’s why it takes both.

Writing the code was never the hard part

Most of what a system costs comes after it goes live. Requirements change, regulations change, the people change. Over ten years, an important system is changed hundreds of times, and every change has to leave it working, secure, and understood.

AI makes code cheap to produce. That’s real progress, but it also means more code to own. A generated application still has to be upgraded, patched, secured, tested, and changed for as long as it’s in use. A fast start doesn’t shrink that work. Often, it grows it.

Complexity grows faster than the code

A small application generated from a description is easy to follow. A system with dozens of entities, years of rules and exceptions, and integrations with five other systems isn’t. Each new piece of generated code has to fit everything already there, and the chance that one change breaks something unexpected rises with every addition.

Regenerating doesn’t solve it. Ask for the same change again, and the structure may come back different from last time, with the same behavior in some places and not in others. For a prototype, that’s fine. For the system that issues permits or pays benefits, it isn’t.

Every generated system is built differently

Ask AI for twenty applications, and you get twenty ways of storing data, signing people in, running a process, and recording what happened. Each one has to be learned, secured, and maintained on its own terms.

On a platform, the twentieth application uses the same data model, sign-in, permissions, workflow engine, and audit trail as the first. That’s what lets a remarkably small team own a remarkably important system, and then the next one, instead of looking after a growing collection of codebases.

Governance is structure, not a review afterward

In government and other regulated work, it isn’t enough that a system works. You have to show how it works: how its data is structured, who can see what, how a decision was reached, and what changed since last year.

A platform proven in that kind of work makes the structure part of how you build:

  • Data is modeled with its relationships and rules in one place, not scattered across generated code.
  • Processes run as diagrams in standard BPMN, which the process owner can read and an auditor can follow.
  • Access is set by role, down to individual fields, and connected to your identity provider.
  • Every change is recorded with who made it and when, versioned in your own Git repository, and reversible.

Generated code can do each of these too, but only if someone asks for it every time, and someone checks that it was done right. Nobody reviews eight thousand lines of generated code with the care an important system needs. People can review a data model, a form, and a process diagram.

Knowledge has to outlive the people

When the developer who prompted an application leaves, the organization keeps code that nobody actually wrote, and that nobody fully knows. The reasoning behind it sits in a chat history, if it’s anywhere at all.

On a platform, the system’s logic lives in models the next person can open and read: the data, the forms, the processes, and the rules. A new team member, a partner, or an auditor starts from the same picture.

Some decisions must come out the same every time

AI is probabilistic. Ask it the same thing twice, and you may get two different answers. That’s what makes it good at reading, summarizing, and drafting, and it’s also why it can’t be the whole system.

Whether someone is eligible, whether an application is complete, how much a payment is: those decisions have to come out the same way every time, and be explainable afterward. They belong in rules and workflows. AI does its best work in the steps around them: reading the documents, extracting the fields, sorting the cases, and handing the result to the rules and the people who decide.

AI works better on a platform

Asked to generate a whole system, AI produces something too big to check. Asked for one piece inside a known structure, such as a query, a form, or a workflow step, it produces something small, specific, and easy to review. And because it knows the data model it’s working in, what it suggests fits your actual tables and fields, not a generic example.

That’s how AI works in Plant an App, in three jobs:

  • In the builder, builders describe what they need, and AI drafts the SQL query or the first version of a form for them to review. What AI drafts, the team owns: it’s versioned and changed like everything else.
  • In the process, AI takes on a step in a workflow, such as pre-checking the documents attached to an application, and returns fields the next rule or reviewer can use.
  • In the conversation, assistants answer from your own content and act through the same workflows as the rest of the application, so there’s no second automation to govern.

You choose the AI provider and use your own keys, and moving to a better model doesn’t mean rebuilding the workflow around it. We cover all three jobs on the AI page.

Where AI on its own is enough

Not every piece of software needs a platform. A prototype to test an idea, a one-off script to move data, a small tool with one owner and a short life: AI on its own is often the fastest way there.

The line is the one that applies to any software: how long it will live, how many people depend on it, and what happens when it’s wrong. When the answers are years, many, and a lot, it needs structure underneath.

Both, in the same system

The organizations getting the most from AI aren’t the ones generating the most code. They’re the ones that give AI a clear job inside a system they can govern, run by a small team that understands all of it.

Use AI for the work that repeats. Use the platform for the system that has to last.