What I Took Away From Codegarden 2026

There was a lot on AI at Codegarden 2026. That was not really surprising given how much it is changing the industry, and how much of an impact it is already having globally. All at a rapid pace.

But what I liked was that most of the talks were not just “AI will solve everything”. A lot of it was more practical than that.

The main thing I took away was that AI can be really useful, but only if you give it proper context, review what it gives you, and still take responsibility for the output.

AI needs context

One of the talks I found most useful was Vibe Coder to AI Engineer by Matthew Wise.

The big takeaway for me was that there is a difference between just asking AI to do something and actually setting it up to work well with your project.

Some of the practical points were:

• Use MCP servers where they make sense
• Tailor your Claude or agents markdown files
• Split instructions at folder level so they are more specific
• Use planning and questions to reduce drift
• Use tool-specific skills rather than expecting one generic setup to do everything

It is easy to blame AI when it gives a bad answer, but a lot of the time it has not been given enough information. It is similar to onboarding a new developer. You would not expect someone new to understand your project, standards and weird edge cases without giving them context.

That theme came up again in AI as your sidekick. by Barbara Forbes

Use plan mode. Make the AI explain itself. Start a new context if the current one is going in the wrong direction. Treat AI like a new hire and give it the information it needs to do a good job.

That feels like a much better way to use AI than just hoping the prompt is good enough.

You still own the work

Another AI talk that stuck with me was Is AI making us bird brained? by James Hobbs.

The question that stood out was:

How do you defend work you did not do?

That is probably the uncomfortable bit with AI.

If AI writes the code, summary, copy or recommendation, you still need to understand it. You still need to know whether it is right. You still need to be able to explain it.

The other point was thinking about the consequences if AI is wrong.

For some things, the risk is low. For others, it could cause real life altering problems. So we need to be careful where we use it and how much we trust the output.

That linked nicely with the AI in Umbraco by Matt Brailsford talk.

What I liked about that session was that it moved away from AI as a vague feature and into how it could actually work inside the CMS.

Things like transcribing audio, generating notes, creating summaries and helping editors all sound useful. But the more important bit is how those tasks are handled behind the scenes.

Longer AI tasks should probably run in the background. Different models should be used for different jobs. Outputs should still be reviewed. And if AI needs to do more than write text, it needs tools that are designed for that specific action.

That last point stood out to me.

LLMs are good at writing text, but tools are what let them do something useful with it. In an Umbraco site, that could be working with content, using custom context, triggering workflows, or notifying other systems when something has happened.

So the real value is not just “add AI”. It is designing the right workflow around it.

That feels like the difference between a feature that looks impressive in a demo, and one that would actually be useful in a real project.

Reusing content properly

It’s Elemental; reuse your content! by Kenn Jacobsen was a good look at where reusable content is going in Umbraco 18 and 19.

The session covered the initial elements library, block editor elements, and how blocks can be disconnected from the library for page-specific changes.

The part I liked was that there is no difference for rendering. It just works.

Reusable content is one of those things that sounds simple, but on bigger sites it can make a big difference. CTAs, promo blocks, contact details, opening hours, disclaimers and repeated content can all drift over time if they are copied everywhere.

Having a better way to create and reuse that content should help keep things more consistent.

Look forward to implementing it on IglooTheme

Performance still needs thought

The Hybrid Cache changes everything by Markus Johansson was a good reminder that performance issues are often caused by small decisions that build up over time.

One point that stood out was around content traversal.

In Umbraco it can be easy to loop through content, walk the tree, filter in code and only think about performance when the site starts to slow down. That might be fine on a small site, but it can become expensive as the amount of content grows.

A better approach is to think about the type of data you are trying to get.

If you are searching or filtering across lots of content, Examine might be a better option than traversing everything from the content tree. If the output does not change often, runtime cache or output cache might make more sense. If the same expensive work is happening on every request, that is usually a sign it should be cached or moved somewhere else.

The useful takeaway for me was not just “use Hybrid Cache”. It was to be more intentional about where the work happens.

Before adding more code, it is worth asking:

• Does this need to run on every request?
• Could this be searched instead of traversed?
• Could this be cached safely?
• What actually causes this content to change?

That feels like a better way to approach performance. Not just adding cache at the end, but designing the site so it does less unnecessary work in the first place.

Package development can be tested better

On day two, Accelerating Package Development with Umbraco 17 Automation by Paul Seal was one of the more practical sessions for me.

There were a lot of useful ideas around automating package development and testing.

Some of the points I noted were:

• uSync CommandLine setup
• Running Umbraco in GitHub Actions
• uSync first boot
• YAML actions pointing to PowerShell scripts
• Using local NuGet packages in actions
• Using Mermaid to explain code visually
• Using Playwright screenshots to verify output from actions

I liked this because it was not just about building a package. It was about proving it works.

Can it install? Can it boot? Does the config import? Does the expected page actually render?

That kind of automated check gives much more confidence, especially when building packages that other projects will depend on.

This will come in handy for IglooTheme

AI search changes how we think about content

A Website, an Email, and an AI Summary walk into a Bar… by Georgina Bidder and Matt Sutherland was about GEO, or generative engine optimisation.

The main point was that search is moving offsite.

People might not always visit your site directly. They might ask an AI tool a question and get a summary instead. So the question becomes: how do you make sure the AI uses the right information from your site?

That means correct data sources are really important.

The QABLES framework from the talk was a useful way to think about it:

• Q - Questions
  Answer real questions in your content early. Add FAQs, how-to content and anything that helps make the answer clear without forcing someone to dig through the page.
• A - Audit
  Audit your pages, stats and quotes. Make sure the information is accurate, up to date and backed up where needed. Add structured data so search engines and AI tools can understand the content properly.
• B - Brand authority
  Build trust around the brand. Focus on E-E-A-T, reviews, citations, reputation and making it clear why your site should be trusted as the source.
• L - Long term
  Think beyond quick SEO changes. Provide your own data, get mentioned on other sites, and monitor where your brand appears using tools like Semrush.
• E - Entity / expertise
  Make it clear who is behind the content. Link authors to their profiles using sameAs, show expertise where it matters, and help AI tools connect the content to real people or organisations.
• S - Schema
  Use schema properly. Include details like business type, opening hours, locations, reviews, citations and multi-location information where relevant.

The big shift is that SEO is not just about ranking and getting clicks anymore. Sometimes it is about being the source that gets cited.

And when your site is not cited, you still need to check whether the information being shown is correct.

Old decisions are not always bad decisions

This Made Sense at the Time by Anna Bastron was a good reminder not to judge old features too quickly.

Sometimes you look at a project and wonder why something was built in a certain way. But at the time, there might have been a good reason.

The client might have needed it. The business might have worked differently. There might have been a technical limitation. Or maybe it was just the best option with the time and budget available.

That does not mean old decisions should never be changed.

It is okay to revisit old features. Sometimes the reason for them no longer exists. Sometimes they are still needed. Sometimes they just need improving.

The important thing is to document the why.

Why did we keep it? Why did we change it? What context has changed?

That future context is really useful for the next person who comes along and asks the same question. And, inevitably, that person will probably be you.

Stay, upgrade or rewrite

The final talk that tied a lot of this together for me was Umbraco Decisions: Stay, Upgrade, Rewrite by Rachel Breeze.

The main point I took away was to own the decision you make.

Staying where you are is a decision. Upgrading is a decision. Rewriting is a decision.

None of them are automatically right.

Each upgrade should be a chance to re-evaluate what the site could do better. Not just “we need to upgrade because we have to”, but what could be improved?

Performance, usability, accessibility, SEO, GEO, legal requirements, content models and business needs should all be part of the discussion.

There were also some good practical reminders:

• Check breaking changes before upgrading
• Audit packages for vulnerabilities
• Older packages slowly stop being supported
• Building new features is harder on older systems
• Content migration gets harder as you skip versions
• Extended Long-term Support (XLTS) can buy time, but it only covers the CMS
• WAF and IP restrictions can reduce attack vectors, but they are not permanent fixes
• Theme builders and starter kits can become hard to update if you diverge too far from the standard

The phrase that stood out to me was that upgrades need to be understood as engineering work, not housework.

That is a really good way of putting it.

Upgrades take planning, time and budget. They are not just tidying up. They can reduce risk, improve performance, make hosting cheaper, improve developer experience and make future work easier.

Also, “keeping it because we paid for it” can increase future costs.

That is something worth remembering.

The evening programme

It was not all talks and takeaways though.

The Special Evening Program & Dinner Party was a really fun night. There was an AI called Cinnamon running the programme, which felt very on theme for the whole event. Mistakes and all.

There was also an attempt at the Guinness World Record for musical chairs, which is not something I expected to be part of a tech conference.

And then there was bingo.

That is probably the part I will not forget, mainly because I somehow ended up winning the full board prize. So along with all the AI, content, caching and upgrade notes, I also came home with a very large fake cheque and a Codegarden story I will probably be telling for a while.

Final thoughts

Codegarden 2026 gave me a lot to think about.

There were plenty of product updates and technical ideas, but the bigger theme for me was decision making.

How do we use AI without switching off our own judgement?

How do we make content easier to reuse and maintain?

How do we improve performance without just adding random caching?

How do we automate package development properly?

How do we decide whether to stay, upgrade or rewrite?

And how do we document decisions so the next person understands why something exists?

For me, the answer across a lot of the talks was the same: context matters.

Whether it is AI, content, caching, packages or legacy decisions, the best results come from understanding the why, not just following the latest trend.