Writing
What Codegarden Inspired Me to Build Next
How a Codegarden talk inspired a constrained AI workflow for rebuilding existing sites into a structured Umbraco component framework.
I couldn’t get out to Denmark for Codegarden this year, but I was still lucky enough to experience the talks with a virtual ticket. Not quite the same as being there in person - I missed the catch-ups and side chats, the community feel, and the craziness that makes Codegarden what it is. But being able to watch the talks still filled me with plenty of inspiration for the next 12 months of Umbraco’ing.
Carole Logan has summarised the best bits of her in-person experience this year. We ‘attended’ most of the same talks, so I don’t want to repeat what she’s already covered. But CG26 was very exciting! I might have been watching from home, but Carole and I were still messaging during the talks like excited children whispering at the back of the (virtual, hybrid?) classroom.
Elements, Umbraco Automate, Umbraco.AI, the new Search work, MCP, agent skills. There was so much to get excited about. The main thing I came away with was not an opinion on all of it (yet), but more of a backlog. Things to read. Things to try. Things to understand properly before deciding how useful they really are.
One talk in particular pushed me into a proof of concept almost immediately.
What Shannon’s talk made me wonder
Shannon Deminick’s talk on building and evolving Umbraco sites with AI agents was the one that stayed with me.
His public UmbracoAI demo explores prompting, rules, MCP, reusable skills, agents and workflows for working with Umbraco. The bit that interested me was not just “AI builds an Umbraco site”, although that is obviously a good demo. It was the way the workflow and tasks were structured.
The demo was not one massive prompt asking a model to make a website from scratch and hoping it did something sensible. It used skills, instructions, rules and a workflow. The model still had room to make decisions, but it was not being given unlimited freedom.
For me, that feels much closer to where AI becomes useful in real development work.
If AI can build a generic Umbraco site from skills and a workflow, could the same idea help rebuild an existing site on top of a structured Umbraco component framework?
The problem I pointed it at
Re-platforming an existing site involves understanding what is already there, deciding what should carry forward, rebuilding it in Umbraco, and migrating the content.
Before work on the new site can begin, someone has to understand the old one. What pages are there? Which sections repeat? Which bits are global? Which content patterns are deliberate and which ones are just the result of years of small changes?
That discovery and migration work takes time, and it is easy to underestimate. If you misunderstand the current site, you risk carrying old problems into the new platform or missing patterns that should have been modelled properly.
That gave me a more specific question for the proof of concept: could an AI-assisted workflow inspect an existing site, identify its broad content and design patterns, map those patterns onto an Umbraco component framework, and migrate enough of the content to give a developer a structured starting point?
What I built
Inspired by Shannon’s talk, I built a pipeline for re-platforming an existing site onto a structured Umbraco component framework.
I kept the control flow deterministic. The workflow decided what happened next. The AI was used inside specific steps where judgement was needed.
Roughly, the pipeline looked like this:
- Scrape the source site
- Classify content, links and design tokens
- Propose a sitemap
- Spin up a fresh Umbraco site
- Create theme configuration
- Download and import media
- Map page sections onto existing block-grid components
- Generate supporting pages
- Build navigation and footer content
I used Microsoft’s open-source Conductor tool to orchestrate the stages, so that the LLM did not control the whole process.
I was happy for the model to make judgement calls inside a stage. It could decide that a section looked like a hero, suggest which colours formed the main brand palette, or choose the nearest matching block-grid component. But I wanted to draw the line at authoring the load-bearing Umbraco output. The model proposed structured decisions; deterministic scripts validated them against the framework, transformed them, and wrote the configuration.
The control pattern looked like this:
The first test
For the first test, I pointed the workflow at a familiar site and asked it to rebuild the homepage using the component framework.
The workflow rebuilt the homepage into dozens of content blocks across nine themed sections. It recreated the broad palette and typography. It imported media. It created navigation and footer content. It generated supporting pages so that the main links were not dead ends.
It was not a pixel-perfect recreation of every detail, but it was close. You could immediately tell that it had been generated from the source site, and from a distance it looked like a considered recreation of it. More importantly, it had produced something much more useful than a visual copy: real Umbraco content and configuration that could be inspected, diffed, imported and improved, rather than a static mock-up or a folder of throwaway generated HTML.
Then I dropped the database and ran the workflow again from nothing. That exposed a few readiness and idempotency bugs that incremental development had hidden. Once they were fixed, the pipeline could rebuild the site cleanly from an empty state and safely rerun stages without creating duplicate content.
That felt like the point where it stopped being a one-off demo and became a reusable delivery workflow. The screenshot proved it could produce something; idempotency gave me confidence that it could do it again.
Trying it on less familiar sites
A site you know well is the easier test. Next, I pointed the same workflow at a live site with a different brand, typography, content shape and navigation structure. There was no useful XML sitemap, so it also had to reconstruct the broad information architecture from the navigation.
The generic discovery still worked. It identified the homepage sections, reconstructed a sitemap, imported imagery, created a theme, mapped the page into block-grid content, and produced a recognisable rebuild using the same underlying component framework.
It was not pixel perfect. Some parts mapped well while others looked clearly off, a bit like a 2024 AI had designed them. But it was recognisably the same site.
What mattered was that the workflow held up on a site it had never seen before, without being hand-tuned to that example. That was more than I expected from the first version of the proof of concept.
What I learned
The tests showed that the generic discovery work was more reusable than I expected. Scraping, sitemap extraction, media handling, site setup and import can all be made fairly repeatable. Theme interpretation and content mapping are different: they require judgement.
Which colour is the accent colour? Is this section a hero, a promo band or something more bespoke? Which existing component is the closest match? That was where the AI was most useful, and where it needed the strongest boundaries.
Without a precise catalogue of the available components and fields, the model hallucinates options that do not exist. The guardrail is simple: every proposed mapping is validated against the catalogue, and the workflow stops rather than writing invalid content when a decision falls outside it.
A fixed component framework gives you consistency, reuse and maintainability, but it also puts a ceiling on fidelity. A source site may contain overlapping sections, unusual background treatments or brand-specific patterns that the destination framework cannot express. The AI can find the nearest match, but when there is no clean equivalent, the useful response is to record the gap and suggest a framework enhancement rather than pretend the mapping is exact.
The exciting result is not simply that one site got 60-70% of the way there. It is that the workflow is generic, reusable and idempotent. Point it at a site it can access and it can create a themed Umbraco site, import the media, and map the content into real block-grid components. It is not a finished build, but it turns a blank project into a structured implementation that a developer can review, correct and extend.
The need for guardrails also changed how I thought about the framework. If agents are going to work inside structured systems, those systems need to be legible to them. I built a machine-readable catalogue of every available block, field, variant and constraint, including which source to trust when documentation and the underlying definitions disagree. That catalogue helps the agent stay in bounds, but clearer component contracts and explicit constraints help developers too.
Back to Codegarden
What excited me was not that AI could produce a convincing demo. It was that a constrained workflow could do useful delivery work: understand an existing site, map it into real Umbraco components, migrate the content, and expose where the framework did not quite fit.
It does not remove the developer from the process. It gives them a structured starting point and a useful set of decisions to review. The AI handles judgement where it helps, deterministic scripts keep the output valid, and a human decides what to accept, change or build next.
That is what Codegarden connected for me this year. Reusable content, automation, AI, MCP and agent skills suddenly felt relevant to a problem I already recognised from real Umbraco delivery work. This proof of concept is only the first of the ideas I want to explore off the back of it.
I missed being in Denmark, but Codegarden still did what a good conference should: it left me inspired, full of ideas to test, questions to answer, and impatient to start building.