Change, validate, roll back: staying in control of an AI-assembled application

1

The first version is a starting point

When AI assembles an application from your description, the first version arrives quickly. It is often close to what you wanted, rarely exact. A field is missing, a label is confusing, a rule applies one day too early. That is not a failure. It is the normal starting point of a phase of adjustment.

The real risk lies elsewhere. A first mistake is visible and gets corrected. What costs money is a change that silently breaks something that was working: a screen nobody opens anymore, a calculation that changes without anyone noticing, an access right widened by accident. Staying in control means organising things so that these side effects do not happen, or are seen before they reach your team.

2

Ask for targeted changes

After a first version, the temptation is to describe everything again. That is the best way to get a second version that is different, not better. AI works best when you point to the exact element: this field, this screen, this rule. Everything else stays put.

Three habits make a change request effective. Name the precise place. Ask for one thing at a time. Say what you saw and what you expected instead. They are the same habits described in Describing your need to AI, applied to an application that already exists.

• Good request: “On the Quotes screen, the Discount field accepts negative values. It should refuse any amount below zero.” Vague request: “The quotes module does not work well.”
• Good request: “In the list of interventions, add a Technician column right after the Customer column.” Vague request: “Information is missing in the lists.”
• Good request: “The rule that blocks an invoice without a purchase order must also apply to credit notes.” Vague request: “Review all the invoicing rules.”
• Good request: “When I click Validate, the record closes without a message. I expected a confirmation.” Vague request: “It crashes when we validate.”

A precise request has another advantage: it can be verified. You know exactly what to look at in the next version, and you immediately see whether anything else has moved.

3

When something goes wrong

A change sometimes produces an unexpected result. The useful reaction is not to ask for another correction straight away. It is to describe what happened, as you would to a colleague: which screen, which action, which result. “On the customer record, when I click Save, the VAT number disappears.”

Then let the AI explain the cause before it corrects anything. A clear explanation tells you whether the problem comes from the change you asked for, from an older rule, or from a misunderstanding about the need. Correcting without understanding means piling up patches: each correction calls for another, and soon nobody knows what the application does.

One correction at a time, checked before the next. If two problems appear, deal with the more important one, check, then move on to the second. The apparent slowness is a real saving.

4

Versions and rollback

An application assembled by AI must keep every version. Not only the latest: all the ones that came before it. That memory is what makes changes safe. You can compare two states, preview the new one before adopting it, and return to the previous one if the result does not suit you.

The principle is simple: a change that does not convince you is not kept. It broke nothing, it left nothing behind. You get the previous state back, exactly.

1. 01
   Preview

   Open the new version in a test space, with the screens and the demonstration data your team uses. Nothing has changed yet for users.

2. 02
   Compare

   Put the previous version and the new one side by side. Look first at the element that changed, then at the neighbouring screens: that is where side effects hide.

3. 03
   Decide

   Does the result match the request, with nothing else moved? You approve. Is there still a doubt? You ask for an explanation or a correction before going further.

4. 04
   Publish or roll back

   You publish the approved version, or you return to the previous one in a single action. Either way, the history keeps a record of what was tried and of the decision taken.

That reversibility changes the way you work. You dare to try, because trying costs nothing definitive.

5

Validate before production

Between the version you approved and your team’s daily work, one step remains: validation. It takes place in a dedicated environment, separate from production, where the people who will use the application actually test it. Normal cases first: create a quote, schedule an intervention, close a file. Then the exceptions: a customer without an address, a cancelled invoice, a date in the past.

It is also the moment to re-check permissions. A change can, without intending to, open a screen to a role that should not see it, or remove an access that is needed. Before each publication, the question is asked explicitly: who sees what, who can modify what. The answer must be the same as before, unless you asked for a change.

Nothing goes to production without your team’s agreement. And that agreement leaves a record: who approved which version, when, and on what basis. It is the same logic as the one described in Automate without removing human judgment for automations: a threshold, an approval, a record. An application evolves by the same rules as an automated action.

A version is not finished when the AI is done. It is finished when your team has approved it.

6

In Neoo: every evolution keeps a clear contract

In Neoo, this work is done with Neoo Forge, the workshop that assembles your applications with AI. You describe your business, Forge assembles the screens, rules and automations, connected to your existing data. Above all, Forge checks every evolution before publishing it.

That check covers five points: the dependencies between the application and the rest of your system, access rights, security, tests, and the ability to roll back. Forge’s compiler is a control gate, not a formality. A change that does not pass these checks is not published, and you know why.

Each capability assembled by Forge has an owner, a version, permissions and tests. That is what lets evolutions keep a clear contract: you know what each element does, who answers for it, and what changes from one version to the next. The starting point remains the one described in Create a business application without coding: your description, your words, your approval.

You can see how Forge works on the Neoo Forge page, or talk it through with us during a demonstration.