At Sitecore Symposium 2026, Christian Hahn demonstrated something impressive: a complete SitecoreAI website built by a team of AI agents, without writing the code himself or opening the Sitecore interface. The agents needed just four hours of execution time, while Christian spent only 42 minutes actively involved. However, the entire process took 40 hours.
These were relatively straightforward websites, with limited integrations and none of the complexity that accumulates in long-running customer projects. Christian also experimented with converting older Sitecore sites, although those were similarly limited in scope. It would be a mistake to conclude that a complex enterprise implementation can suddenly be rebuilt in a few days.
What interested me most was not the speed of implementation, but what happened around it. If building a website becomes significantly faster and cheaper, where does the remaining work go? And what should we invest in when writing code is no longer necessarily the most time-consuming activity?
Four hours of work, forty hours to deliver
Christian, a Technical Product Manager at Sitecore, shared figures from two projects built using his agentic development workflow. In the first project, the agents completed four hours of work, with Christian spending just 42 minutes actively involved. Yet the entire process took 40 hours from start to finish. His second, larger project required 34 hours of agent execution and two and a half hours of his own time, spread across four and a half days.
The difference between execution time and elapsed time tells a more interesting story than the four-hour figure alone. During the first project, agents repeatedly stopped to ask questions. Christian was not always at his desk to answer them, so the workflow remained idle until he returned. The implementation was relatively quick, but progress still depended on someone being available to make decisions.
Notifications that allow you to respond remotely would already help. A more interesting improvement would be teaching agents about your preferences, architectural principles and previous decisions, reducing the number of routine questions without removing the checkpoints where human judgement matters.
The second project exposed another limitation. Much of the 34 hours went into repeatedly refining a design that Christian was not satisfied with. The agents could generate alternatives quickly, but they could not independently determine which result matched his expectations.
AI can reduce implementation effort, but it does not eliminate the cost of uncertainty. When the desired outcome is unclear, faster generation can simply produce more iterations.
The harness matters more than the prompt
Christian's approach is built around a *harness*: a structured environment that coordinates agents, provides them with relevant knowledge and verifies their output.
He used Claude Code, but the underlying concepts are not tied to a particular AI product. His setup consists of five building blocks: agents, commands, skills, rules and context.
Agents have narrow responsibilities, commands define the tasks being executed, and skills provide domain knowledge about Sitecore and its development tools. Rules establish requirements that must be followed, while context determines which information each agent receives.
Most of these building blocks are simply text files. Christian used thirteen specialised agents rather than relying on one general-purpose assistant, keeping the agents relatively lightweight and placing the actual platform knowledge in reusable skills.
The workflow starts with two product-management agents that interview the user, prepare a specification and challenge it for missing information. Other agents inspect the Sitecore environment, define the architecture, produce a design and break the work into implementation tasks.
Development then follows an iterative process in which implementation, code review and QA continue until the work passes its checks. The pipeline also handles provisioning, content authoring through Sitecore's Marketer MCP and publishing.
What I particularly liked was how Christian handled human involvement. His pipeline contains configurable approval gates, including checkpoints around specifications, design and release. During his demonstration, he retained the design approval gate while allowing other stages to proceed autonomously, with safeguards around changes to the actual SitecoreAI environment.
He summarised the philosophy rather well: "You leave the IDE to decide. Never to operate."
Autonomy does not have to mean removing people from the process. It means deciding where their involvement adds value.
The flow is yours to build
One of Christian's strongest messages came towards the end of the session, when he explained which parts of his solution others should reuse.
Rules, skills and agents are relatively universal and can often be adopted directly. Commands are more opinionated because they reflect his choices about how work should be performed. The complete workflow is even more specific, because it represents his approach to delivering a project.
As he put it: "The pieces are copy and paste. The flow is not."
I think this distinction matters for development teams considering agentic workflows. Installing a collection of Sitecore skills is relatively straightforward, but that does not automatically provide a reliable delivery process. The harder part is defining how those capabilities work together, how quality is measured and when decisions require human involvement.
Christian suggested starting small: install the skills you need, introduce specialised agents and gradually develop your own workflow based on the friction you encounter. He has shared both a [reference implementation of his workflow](https://github.com/Chris1415/agentic.hahn-solo.content-sdk.greenfield.developer) and a [library of Sitecore skills](https://github.com/Chris1415/sitecore-skills-pocs) on GitHub. Both are personal proofs of concept rather than officially supported Sitecore products.
The published materials provide a useful starting point, but the workflow itself is something each team needs to develop and improve.
The cost of implementation is falling
Christian also shared what running these agents costs. His first project consumed approximately $2,000 in model usage. After optimisation, he reported that a comparable demonstration website could be created for less than $500, with a delivery time of around two days.
Two changes contributed significantly to that improvement. First, he restricted the context available to individual agents. In his initial implementation, one developer agent accumulated a context of 820,000 tokens. Providing only the information relevant to each task reduced unnecessary processing.
Second, he stopped using the most expensive model everywhere. Claude Opus remained responsible for orchestration and requirements analysis, while implementation tasks moved to the less expensive Sonnet model.
These figures are impressive, but token costs should not be confused with project costs. Requirements gathering, integrations, security, testing and ongoing maintenance still require substantial investment, particularly in enterprise environments.
Nevertheless, the direction is interesting. As implementation becomes more efficient, the activities surrounding it account for an increasingly significant part of project delivery.
Analysis and verification become more valuable
For me, the most important lesson is that faster implementation places greater demands on what happens before and after the build.
Christian's workflow starts by challenging the requirements rather than immediately generating code. That is important because agents are remarkably good at turning incomplete instructions into something that looks finished. When information is missing, they make assumptions that may seem reasonable but do not necessarily reflect what the customer expects.
This problem is hardly new. Poor requirements have caused expensive rework long before AI entered software development. The difference is that agents can now turn those assumptions into working software much faster.
Christian also had the advantage of being the customer, architect and final decision-maker. In a real project, requirements must often be reconciled between marketing, IT, security and other stakeholders. AI can help structure those conversations, but it cannot remove the need for people to agree on the outcome.
The same applies to quality. Christian discovered early on that his agents could produce visually convincing components without supporting inline editing in the Sitecore page editor. He turned that experience into a hard rule: fields that support inline editing must expose that capability; otherwise the implementation fails its checks.
He applied a similar principle to performance, using an agent to monitor Lighthouse scores and create GitHub issues when performance deteriorated.
This is exactly the kind of platform knowledge I would want to capture in a harness. Requirements around inline editing, accessibility, performance and security should become repeatable quality checks rather than depending entirely on manual reviews. Automated checks cannot replace every assessment, but they can remove a considerable amount of repetitive verification.
Design deserves similar attention. Christian's repeated design iterations illustrated the cost of working without a sufficiently clear visual reference. Connecting agents to an established design system through tools such as Figma and Storybook would provide a more reliable foundation than asking them to interpret written descriptions repeatedly.
The point is not to eliminate human judgement. It is to use that judgement where it matters most, while making everything else as repeatable and verifiable as possible.
Where I would invest
Christian's session demonstrated how much can already be achieved with a collection of specialised agents, reusable skills and a well-structured workflow. More importantly, it showed that the real value comes from the way those capabilities are brought together.
For development teams, I see several investments worth making: improving how we translate business requirements into testable specifications, capturing platform knowledge in reusable skills, providing reliable design systems and turning quality requirements into automated checks.
But perhaps the most important investment is learning to design the workflow itself. Which tasks can agents execute independently? What information do they need? Which checks provide sufficient confidence, and where should a person remain involved?
I would also want to measure the results beyond execution time and token consumption. Human intervention, rework, escaped defects, and the time required to reach production readiness tell us much more about whether a workflow actually improves delivery.
Christian suggested that he might never write code again, before acknowledging that this was perhaps a little too drastic. I understand the sentiment, although I do not believe writing code will disappear from our work entirely.
What I do expect is a shift in where our expertise creates the most value. Analysis, architecture, design and verification become increasingly important as implementation is automated. So does our ability to turn that expertise into a process that agents can execute reliably.
The four-hour website was an impressive demonstration, but the bigger lesson for me was not about generating code faster. It was about designing a better way to deliver software.
And that is a workflow worth owning.