Creating A Safe Space for Editors to Be Wrong

I spend most of my time these days working on Umbraco AI, bringing AI into the hands of content editors. So I think a lot about what actually makes AI useful to someone, and I keep coming back to my own experience as a developer.

Looking back, a couple of things gave me real freedom working with AI. And working on tools for editors, I’ve been wondering what the equivalent could be for them.

The Two Things

The first was isolation. Git worktrees gave me a safe place to be wrong. Every session gets its own branch, its own sandbox, its own throwaway environment. If the AI goes down a bad path, I delete it and nothing is lost. Nothing that matters is at risk until I explicitly decide to merge. Because mistakes are contained, I can let the AI work without watching every step, and I can try bolder things knowing I can walk them back.

The second was self-validation. Linters, tests, type checks, coding standards. These give the AI an objective, machine-checkable definition of “good.” It doesn’t just generate something plausible and stop — it generates, checks its own work against the rules, and iterates until it passes, before I ever look at it. I’m no longer the first line of quality control; the tooling handles that.

One gives me a safe space to work in. The other gives a clear target to work towards. Together they let me hand things over and trust what comes back, and that’s really what changed how much I can get done.

Editors in Umbraco don’t have obvious equivalents for either. So what would give them the same freedom?

A Safe Space to Be Wrong

Think about what we ask a content editor to do today. They open the one draft of a page shared with everyone, and they start changing things. There’s no branch and no sandbox. Every edit happens against the live working copy of the real site.

Now picture an editor who wants to try a bold rework of a whole section. A seasonal campaign, a rebrand, a restructure that touches thirty pages and the shared blocks they all pull from. Today that’s an all-or-nothing job done out in the open, one page at a time, with no way to see the finished result before committing to it and no clean way to undo it.

Isolation for an editor might look like being able to branch content the way I branch code. A named unit of work you can make sweeping changes inside, knowing none of it touches the live site, or what your colleagues are doing, until you decide it should. Being able to preview the whole site as it would look if those changes went live, before any of them actually do. And being able to discard the lot, at no cost, if it turns out to be the wrong direction.

The branching isn’t really the point. Making it low-stakes to be wrong is. An editor who knows they can’t break anything is free to try the ambitious thing. And a space like that is also somewhere you could let AI work, not against the live site, and not needing someone to approve every individual change, but safely, until there’s something worth reviewing.

A Definition of Good

Ask any team what “good content” looks like for a given section and you’ll get real answers. It needs a main image. The SEO fields have to be filled in with the right keywords. Hero blocks use the approved layout, not the other one. The tone matches the brand. It’s actually worth reading.

Every one of those is a real rule, and almost none of them are written down anywhere a machine could check. They live in onboarding docs, style guides, and the heads of whoever’s been there longest. The definition of good exists, it just isn’t legible.

Code was in the same place before we had linters. “Good code” was tribal knowledge until someone made it executable, and once the standard was something a tool could check, people stopped arguing about it in reviews and machines could enforce it automatically.

A version of that for content might be a way to capture “what good looks like here” as something you can run against a page and get a straight answer back, pass, or fail with specifics. Some of those checks are mechanical: is the image there, are the fields filled, is the layout approved. Others are judgement calls, tone, quality, whether it’s any good, the sort of thing that used to need a person, but that a model can increasingly help with if you give it the right prompt.

Once good is checkable, the loop opens up. Content gets generated, checked against the standard, and revised and checked again until it passes, before anyone sees it. The editor’s job moves from fixing to approving.

The Questions I Keep Coming Back To

Neither of these is far-fetched, and neither is really about AI. A safe place to be wrong and a legible definition of good would help editors even if AI weren’t in the picture, they’d be freer to experiment, and content would come out more consistent. But they’re also the two things that gave me the freedom to work with AI the way I do now, and I suspect they’d do the same for editors.

So those are the questions I find myself sitting with while I work on this. What does a safe place to be wrong look like for someone who edits content instead of code? And what would it mean to give them a definition of good they can actually run?

Until next time 👋