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.
Top comments (0)