What self-healing code generation is, how it works, and where it stops

What is self-healing code generation?

Self-healing code generation means the system that writes the code is also the system that detects and fixes its own errors, before a human sees them. The distinction that matters is timing. Most AI coding tools generate, stop, and hand you whatever came out; if a dependency is missing or a type does not line up, finding that out is your job, and your next move is to paste the error back into the chat. A self-healing system closes that loop itself: it compiles what it just wrote, reads the compiler output the way a developer would, applies a targeted fix, and compiles again.

That changes what the output is, not just how pleasant it is to get. A tool that hands over code with the errors still in it is handing over a draft. A system that only ever hands over states that build is handing over something you can run. The difference shows up most clearly in what you do next: review the result, or debug it first.

How does the healing loop actually work?

In Airbuild the loop runs inside a single generation, not as a cleanup pass afterwards. Each generation step builds the project, so an error surfaces at the moment it is introduced rather than at the end, when it is harder to attribute. The agent reads the real build output — the same text a developer would see in a terminal — and applies a fix aimed at that error instead of regenerating the file and hoping. Then it builds again. The cycle repeats until the build is clean.

Runtime errors get a second, narrower path. A build can succeed and the application can still break when it actually runs, which no compiler catches. In the live preview, an error hands itself to the AI in one click, with the stack trace and the surrounding code as context, and the fix comes back in the same session.

At publish time the same mechanism runs once more with a hard limit: if the production build fails, Airbuild attempts an AI repair and rebuilds, up to two retries. If it still fails after that, you get the error text and the loop ends rather than grinding on. That limit is deliberate — an unbounded repair loop burns your budget on a problem it cannot see.

What does Airbuild check before a release goes live?

Airbuild runs three areas of checks on every project by default — tests, security and code quality — and all three are on from the first build without anyone configuring them. Security scanning uses Semgrep for code patterns and Trivy for dependency vulnerabilities and committed secrets. Code quality uses Ruff for Python and Biome for the JavaScript and TypeScript side. Tests are generated alongside the code and run in the test cockpit.

The checks do not run against your working copy. At publish, Airbuild freezes a snapshot of exactly the code that is going out and checks that, which closes the gap between "the version I scanned" and "the version that shipped" — a gap that, in a normal CI setup, is where most surprises live.

All three can be switched off per project. That is a deliberate decision rather than an oversight: a throwaway prototype does not need a release gate, and a gate nobody can turn off gets worked around instead of used. What matters is that the default is on, so the project that needs the checks has them without anyone remembering to ask.

What actually blocks a release?

In Airbuild a release is blocked by high-severity findings from the security and code-quality checks, and by nothing else unless you ask for it. A finding at that severity stops the publish until it is resolved; lower-severity findings are listed in the Problems panel and do not hold anything up. The findings carry a one-click fix that hands the problem to the same AI that generated the code, which is usually faster than reading the rule.

Failing tests are the exception people get wrong. A failing test does not block a publish on its own. It blocks only when the team switches on the pre-publish test gate for that project — then a red suite stops the release. Leaving that off by default is a defensible call: an early project full of half-written tests would otherwise be unable to ship at all.

One more rule is worth knowing because it is counter-intuitive: if a check that is switched on crashes or fails server-side, the publish is blocked rather than waved through. A gate that silently disappears when its scanner breaks is not a gate.

What can you switch on when you need more?

Three further checks exist in Airbuild and stay off until you enable them: SonarQube deep quality analysis, OpenAPI linting, and a dynamic security scan. They are opt-in because each one costs time on every publish and earns that time only for some projects — a marketing site has no API to lint.

The dynamic scan is the one worth understanding, because it works differently from the others. Everything described so far reads your source code. The dynamic scan probes the running application over HTTP, the way an attacker would, which catches a class of problem that no amount of source reading finds: a route that is reachable without authentication, a misconfigured header, an endpoint that leaks more than it should.

SonarQube deep quality, once enabled, carries the same authority as the default checks — its high-severity findings block a release too. That is worth knowing before switching it on mid-project: you are not adding a report, you are adding a gate.

How is this different from self-healing CI?

Self-healing CI and self-healing code generation fix different things at different moments. A self-healing CI pipeline reacts after the code is written and the build has already failed: it retries a flaky job, pins a dependency, reruns a step. The code that broke it is already committed, already in the repository, already somebody's problem to review.

Self-healing code generation acts earlier, at the moment the code comes into existence. The broken intermediate state never becomes a commit, never reaches the pipeline, and never needs a pipeline to be clever about it. By the time any CI system sees the project, the errors the generator could fix are already gone.

The two are not alternatives and a serious setup has both. The point of the distinction is where you should expect the time saving: a self-healing pipeline saves the minutes after a failed build, while self-healing generation removes the failed build from the sequence.

Where does self-healing stop?

Self-healing stops at the boundary between errors and intent. It repairs things that are demonstrably wrong — code that does not compile, a dependency with a known vulnerability, a pattern a rule flags — because those have a definition of "fixed" that a machine can verify. It cannot tell you that the invoice logic calculates the wrong total, because nothing in the build output says so. Correct software that does the wrong thing passes every check described on this page.

There are three further limits worth stating plainly. The repair loop at publish is bounded at two retries, then it hands back to you rather than looping. The review runs on the code Airbuild generates, so it is not a review tool you point at an arbitrary existing repository. And every gate here can be switched off per project — which means the guarantee is "on by default", not "always on".

None of that is an argument against the mechanism. It is an argument for knowing which of your problems it removes: the mechanical ones, reliably and without you asking. The ones that need judgement stay yours.

Does self-healing mean nobody reviews the code?

No — self-healing changes what reaches review, not whether review happens. What the loop removes from your plate is the class of problem with an objectively right answer: compile errors, known vulnerabilities, dependency advisories, lint violations. Those are exactly the findings a human reviewer is worst at catching reliably and most bored by. What arrives at review instead is code that builds, passes its tests, and carries no unresolved high-severity finding.

The code also stays yours to read. Airbuild generates standard React, TypeScript and Python — no proprietary runtime, no generated format you need Airbuild to open. From the Website Builder Pro plan upward you connect your own GitHub repository, and every change the AI makes is committed and pushed there, so the review can happen wherever your team already reviews code, with the full history in Git.