DEV Community: Mike Isaacs

Opticon London 2026 - I wasn't the audience, which is why it was useful

Mike Isaacs — Thu, 22 Oct 2026 14:42:22 +0000

I spent 13 October at the Barbican for Opticon London, Optimizely's annual conference. Two things were obvious pretty quickly. Almost everyone there was a marketer, and almost every session was about AI.

As a Head of Development, I wasn't really the audience. But the idea I kept turning over on the way home was for developers, and it fits in a sentence: AI is a new hire, not a new tool.

A new hire, not a new tool

Optimizely leans into that framing in its own product. Its Virtual Teammates are agents scoped to a role, with their own permissions and context that carries between projects. Teams pick them from a directory, which makes for a slightly unusual hiring round.

The framing matters because of what it implies. A tool gets installed and is expected to work. A new hire gets onboarded, given a remit, checked on, and trusted with more over time.

It also explains a point that stuck with me: the culture a team already has shapes how it gets on with AI. Teams that write things down, review each other's work and treat mistakes as something to learn from tend to absorb it well. Teams where knowledge lives in a couple of people's heads (and onboarding means "here's your laptop, good luck") struggle with people and AI alike. How a team's last few new starters got on is a pretty good predictor of how it'll get on with AI.

For developers, that turns productivity into a memory problem. A capable .NET developer can write C# on day one. What they don't know yet is how we structure an Umbraco solution, how we handle uSync, which front-end patterns we've settled on, and what a good pull request looks like here. A person picks that up over a few weeks and keeps it. An agent forgets all of it when the session ends.

So that's where I've been putting our effort. Not into picking the cleverest model, but into writing down how we work: reusable skills for things like our uSync conventions and front-end standards, plus repository-level instructions every agent reads. Optimizely's version for marketers is Mark-IQ, a data layer that saves people re-explaining their brand in every prompt. Ours is a folder of markdown files. Less glamorous, same job, and it turns out to be the onboarding documentation our human new starters always deserved.

The layer matters more than the tool

The second takeaway follows on neatly. If the knowledge and the guardrails live in a consistent coordination layer above the tools, the tools themselves become interchangeable.

That matters because there's no best tool, only the current one. The leaderboard changes most weeks, and waiting for a clear winner is a reliable way to still be waiting next year.

Open conventions make this realistic for development teams. AGENTS.md is read by most of the major coding agents, and Agent Skills, which Anthropic released as an open standard in December 2025, is supported by tools including GitHub Copilot and OpenCode. Put the knowledge there, apply the same code-quality guardrails whatever wrote the code, and swapping an agent stops being a migration. Routing planning to a high-capability model and small edits to a lightweight one keeps the costs sensible too.

It's the same with people. Nobody redesigns the org chart every time someone joins.

The complexity is in the ask, not the code

The idea I've thought about most since came from the marketing sessions: an empathy map, a sliding scale of which tasks can go to AI and which should stay with people, based on how much human judgement each one needs.

Development needs one too, but I think the axis is different. It's a complexity map, and the complexity that counts is in the requirement, not the implementation.

That's easy to get backwards. Patching an Umbraco site to the latest minor release (or even major version) and bringing its companion packages up in lockstep can be fiddly, but nobody's unclear on what "done" looks like. That's a good agent task, with a developer reviewing it. A support ticket that says "the form's broken for some users" might come down to ten lines of code, but working out what's actually wrong needs someone who can talk to the client and weigh up the context.

Sort the work by how well the ask is understood rather than how hard the code looks, and the sliding scale more or less draws itself. Clear requirements go to the agent with a reviewer. Fuzzy ones stay with a developer, who might well hand the implementation over once the requirement's pinned down.

Opticon didn't set out to say anything about development (I suspect there weren't many in the room wondering how PR process can improve AI oversight). Strip away the marketing context, though, and the lessons travel well. Write down what the team knows. Keep the structure stable so tools can come and go. Decide what to hand over by how well the ask is understood.

None of that depends on which model tops the benchmarks next quarter. That's rather the point, and if you're writing the onboarding pack for your own AI teammates, I'd like to compare notes.

Codegarden 2026 - a little late, because it gave me something to build

Mike Isaacs — Wed, 01 Jul 2026 15:53:03 +0000

A few weeks ago I was in Copenhagen for my first Codegarden, and one quiet thought has stuck with me since. It didn't come from a keynote. It came from the bit the keynote leaves out.

I've worked with Umbraco for years, but I'd never been to Codegarden, and I turned up without much of a fixed idea of what the two days would be. I kept that open on purpose. I wanted to take it in rather than measure it against something I'd decided in advance. What struck me most was that the value came from two places at once. The sessions were a fantastic source of inspiration; everything from keynotes to guest speakers all seemed to resonate in some way or another. The conversations in between the sessions - drifting around the event space and finding common ground with anyone and everyone - proved just as valuable. I came home more energised than I've been in a while, with a notebook full of half-formed ideas and a better feel for the community I'm part of.

But the thing I kept turning over afterwards was that bit the keynote leaves out. That's what I want to write about.

The easy half and the hard half

Every major Umbraco release gets the same treatment. A polished keynote, a clean demo, a feature that looks effortless on stage. There's plenty in 18, and which part matters most depends on what you're building. For me it's Elements: a new Library section where you manage reusable content and reference it through a new element picker. Create once, use everywhere. It's a genuinely good direction. Reusable content has lived awkwardly in the content tree for years, and Library finally gives it a proper home.

What the demos don't show you is the part I've been playing around with for the past few weeks. Taking a real Umbraco 17 site, with content pickers threaded through block lists, block grids, rich text blocks and base document properties, and getting all of it to point at the new Library without an editor ever noticing anything moved underneath them.

The feature is the easy half. The migration is the half that decides whether anyone actually uses it.

Why migration is where adoption lives

A new way of modelling content only matters if existing sites can get to it. New projects will use Library because it's there and it's the obvious choice. The much bigger pile of work is the sites already in production, built the old way, where reusable content was faked with content pickers pointing at hidden nodes because that was the best tool on offer at the time.

Upgrade conversations with clients are increasingly turning into "end of life is on the way, you need to upgrade!" but Umbraco have given us some genuinely useful new features that can turn those conversations from scaring clients away from security woes to improving their content management and supercharging their marketing activities.

There's a timing thing here. The migration path has to exist when the feature does, not three months later when the upgrade conversation has gone cold. A site that wants Library is at its most willing in the window right after release, while the appetite is fresh and the project is being planned anyway. Miss that window and you're asking someone to reopen a decision they've already made, which almost never happens.

That's the question I bring to every shiny thing on a keynote slide. Not "is this exciting", but "what's the real path from a live production site to it, and how much of that path can be made painless". The exciting idea is the easy part. The route onto it is the work.

What the package actually does

This is the problem the Library Migrator package is built to solve, and the job is less glamorous than it sounds. It moves documents from Content into Library, so the things that were always meant to be reusable end up where they belong. It swaps every content picker on the relevant types for an element picker pointed at Library, so editors keep the same workflow and have nothing new to learn. And it rewrites the stored values, which is the part that earns its keep: every value held in an old content picker is updated to reference the new elements, across block lists, block grids, rich text blocks and base document properties. One reference left behind is a broken link an editor finds at the worst possible moment.

None of that shows up in a demo, using a brand new, tailored project designed to show the feature off at its best. Yet content is the centrepiece of all CMS solutions and the value in existing content is always at the forefront of our clients' minds. Whether it's a same-platform upgrade or a complete rebuild, the question of migration always gets raised.

The Library Migrator is out now. If you're looking at an Umbraco 17 site and wondering how on earth it's going to reach 18's (or 21 if you're LTS-conscious) Library, that's exactly what it's for.

Library Migrator on Umbraco Marketplace

Library Migrator repository

An introduction

Mike Isaacs — Fri, 26 Jun 2026 14:54:32 +0000

I should be upfront about something. I don't really enjoy writing blogs. I'm a developer by instinct, the kind of person who would rather solve the problem than write three hundred words about having solved it. So starting one feels a little against the grain.

But that's sort of the point. I'm Head of Development at Growcreate, which means I look after the work across support, maintenance, devops, and our projects. A lot of my day isn't spent in the code anymore. It's spent in the gap between two worlds. On one side there's the C-suite, with the big ideas and the direction. On the other there's the development team, who need something concrete to actually build with on a Tuesday morning. My job, more often than not, is to stand in that gap and translate. Turn the direction into tactics. Turn the strategy into something a team can pick up and run with.

That translation work is messy, and it rarely makes it into the things we ship. You see the finished site, not the brainstorm sessions, the false starts, or the decision we argued about for a week. This blog is my attempt to share some of that. The why and the how behind the work, not just the what.

I still code when I can get away with it. For me it was never really about the code as such. It's about problem-solving, and code just happens to be the means to an end I reach for most. That mindset, the idea that the tools are servants to the problem and not the other way round, is probably the closest thing I have to a philosophy. Expect it to turn up here a lot.

So this is the start. I can't promise I'll suddenly love writing. But I think there's something worth saying about how a development team actually thinks, enhances, and evolves, and I'd like to try to say it. Come along for the ride.