Engineering · October 8, 2026
Every change, checked: how we keep AI edits from breaking your site
This week a test edit broke a website while reporting success. Here's what went wrong, what we changed — and the checks every change in Firelent now has to pass.

A website builder that uses AI has one job it can't get wrong: when you ask for a change, you get that change — and nothing else breaks. This week, in testing, we found a way that promise could fail. This post is about what happened, and what we built so it can't happen again.
A chat assistant that wasn't there
We were testing an edit on a demo website for a barbershop: “Add a chat assistant to every page.” The model did good work. It wrote a new component for the assistant, added it to the homepage and both legal pages, and summed up what it had done. The build finished. The status said done.
The site was broken.
The new component had been written into a folder our safety rules didn't expect. Those rules protect the files Firelent manages for you — the building blocks every site shares — so that a model can't overwrite them by accident. Faced with a file in an unfamiliar place, the rules did exactly what they were told: they quietly left it out. The pages that used the assistant were saved. The assistant itself was not.
Every single step had worked as designed. The result was still wrong.
Two rules that disagreed
When we traced it, the cause was almost boring. Two parts of Firelent decided which files belong to your project — one when the model writes, one when your project is saved and loaded — and each kept its own list. Over time, the lists had drifted apart.
So we replaced both with a single rule. There is now exactly one place that decides whether a file is yours or Firelent's, and everything asks it: writing, saving and loading. New files that you or the model create are yours, wherever they sensibly live. The files Firelent manages for every site stay managed — so the improvements we make to them still reach your site automatically.
Checking the result, not the instructions
The tempting fix would have been to tell the model more firmly where new files should go. We don't fix problems that way. The instruction was already there, and a model that ignored it once can ignore it again.
Instead, every change now has to pass a new check before it's saved: does every file it uses actually exist? If a page imports a component that isn't there, that isn't a finished change. It goes back for repair — automatically, before you ever see it. If it can't be repaired, the change fails, and you don't pay for it.
We'd rather catch a broken change ourselves than have you find it on your live site.
Everything a change goes through
That check joined the ones every edit already passes:
- Small changes stay small. For a typo or a new phone number, Firelent edits the exact lines involved instead of rewriting whole files. Less rewritten code means less that can go wrong.
- Every file has to make sense. Code that wouldn't load is caught and repaired before it's saved.
- Every file has to be there. The new check: nothing may point at something that doesn't exist.
- Every version is kept. If a change isn't what you wanted, go back to any earlier version — for free.
- Our failures are on us. If a build fails on our side, your credits come back.
What this means for you
Mostly: nothing you'll notice, which is the point. Ask for a new section, a booking form or a chat assistant — and when Firelent says it's done, it's done.
We'll keep writing about how Firelent works under the hood, including the parts that went wrong first. If an AI tool has ever told you everything was fine while it wasn't, you'll know why that matters.