This Kickstart series walked you through building a simple Xperience website by hand: modeling content types, creating a channel, building pages, and writing the presentation layer that renders them.
With KentiCopilot tools, you can use an AI assistant to build the same site: you write a specification of what you want, and the agent handles the mechanical work. Watch the demo below, then read what it takes to run a session like this yourself.
New to this series? Start with the fundamentals.
Before using an AI assistant to build with Xperience, complete the Developer kickstart series, building the project by hand. This will help you understand how the content model, channel, pages, and underlying Xperience APIs work together. That foundation is essential when working with AI-generated code. It enables you to review the proposed solution, identify any incorrect assumptions, troubleshoot issues, and adapt the code only when you are 100% sure. Once you understand the manual build, return to this page to explore how an AI assistant can help you complete the same work faster.
Tools we used
The model split above matches the work: the heavier reasoning job, sharpening ambiguous requirements into a specification, got the more capable model, while a well-specified implementation and a checklist-driven audit ran reliably on a faster one. See Choose a model that fits the task for making that call on your own project.
To have a good starting point, ensure you have:
Let your assistant handle the installation for you. Ask it to add the KentiCopilot plugins and configure both MCP servers. If something fails for a reason specific to your machine, ask it to help diagnose that issue as well, rather than troubleshooting by hand.
Things to watch out for
Installing the KentiCopilot plugins doesn't configure any MCP server. Add both the Documentation and the Management MCP server to your workspace yourself, then open your assistant's MCP servers list and confirm exactly one entry for each is running.
If you started from the Xperience project boilerplate, note that it ships with AddAuthorization() and UseAuthorization() commented out in Program.cs. The management API returns HTTP 500 until you enable them.
Before you hand the assistant any real work, make sure the project itself is ready for it.
Ask your assistant to run the agentify skill from the KentiCopilot web development plugin against your project. It audits three things: agent instructions, design and coding standards guidance, and whether the Documentation and Management MCP servers are configured. It reports what it finds and waits for your approval before making any changes.
Run the audit before you start. A project that passes it gives every new session the same starting context, instead of one that depends on what happened to be in a previous conversation.
Without instructions, the agent makes its own structural decisions: content retrieval calls land wherever they're used, files sit in flat directories, and naming follows whatever the agent defaults to. That's fine for a quick prototype, but on a real project, you want your own conventions – feature folders, a shared retrieval service, consistent naming – and the skills are built to be shaped this way, not to assume one.
The fastest way there is to point the agent at a well-structured Xperience by Kentico project and have it derive your instructions from that project's patterns. In order of preference:
Review the structure and patterns in [reference project]. Generate instruction files covering: project and solution structure, feature organization, content retrieval, naming conventions, and the documentation I should check against.For a project this size, the result can be a single instruction file. A larger project might split it into several, one per concern. Either way, a project-structure file might spell out the layout you want the agent to follow – for example, something close to how this demo's own project ended up organized:
src/
├── Kickstart.Entities/ # Generated content type classes -- never hand-edited
├── Kickstart.Web/ # ASP.NET Core app: UI + infrastructure, organized by feature
└── Kickstart.Web.Tests/ # Tests mirroring the Features/ tree
Web/Features/LandingPages/
├── LandingPageController.cs # Thin: retrieves the page, returns a view
├── LandingPageViewModel.cs
└── LandingPagePageTemplate.cshtmlWhatever comes out of it, one file or several, aim to cover:
The assistant still needs to know what to build. In the demo, that material is the Developer kickstart guides themselves, sitting in the workspace as markdown, but the format isn't the point. Pasted documentation URLs, a static HTML design, or a requirements document work just as well. What matters is that the requirements come from something real, not from a well-worded prompt.
The single biggest factor in the result is what you hand the assistant before it writes anything.
Have the assistant write a specification before it builds anything, and review it properly. In the demo, the first draft models the site's slogan as a text field on the page; several pages share the same slogan, so it belongs in the Content hub as reusable content instead. That's a content modeling decision, and no assistant can make it for you – but correcting it in a specification costs two sentences, where correcting it in a half-built site costs a rebuild.
The demo uses a third-party, open-source skill by Matt Pocock, shared on his AI Hero (opens in a new tab) site: /grill-with-docs (opens in a new tab). It interviews the developer before writing the specification. It's one example of a good habit, rather than a requirement. Other equivalents work too, including writing the skill yourself or simply instructing the agent to ask. A skill makes more sense here, since it's something you'll reuse throughout your Xperience by Kentico development. For a much more formal and structured framework, which may be helpful in enterprise projects, take a look at GitHub's spec-kit (opens in a new tab).
A specification with acceptance criteria also gives the assistant somewhere to stop. It has a definition of done to check its own work against, so it stops when the criteria are met instead of continuing to make changes.
The demo builds the whole site in a single implementation run. That works here because the site is small – four content types, two pages, one navigation menu – but the example is small; treat it as such, not as a recommendation.
On a real project, divide the work first and run the same loop for each slice: specify, review, implement, verify. Slice by page, by content type, or by feature, whatever matches how the work is already broken down. Size each slice so that one cycle stays reviewable in one sitting: if you can't read the resulting changes carefully, you're not really verifying anything.
Before you move on to the next slice, check that it's stable: the solution builds, the generated classes exist for anything new, the page renders, and the objects show up in the administration interface. If something doesn't build or render correctly, ask the agent to find the root cause and fix it; if you're not sure what to do next, ask it to propose the next step based on where the project actually stands.
The specification is what makes this work across iterations. It stays in the repository as the current agreement, so each new session, and each new slice, starts from the same record rather than from a conversation someone has to remember.
Iterating also gives you a place to correct course. A specification you've already reviewed once is easier to extend for the next slice than to write from scratch, and each verified slice narrows what can go wrong in the next one.
dotnet run --kxp-codegen command – the same one you'd run yourself – and confirmed the solution still built.The agent logs each tool call as it happens, so you can see exactly which one it reached for at every step, and audit the session afterward.
Read Work effectively with KentiCopilot for the habits that make sessions like this one reliable: exploring before planning, delegating investigation to subagents, and keeping your project's context durable.
For the rest of the KentiCopilot tooling – the MCP servers, the plugins, and the skills they contain – see KentiCopilot. For more resources and community examples, visit the Kentico AI development hub (opens in a new tab).
For more on why the environment you set up matters more than the prompt you write, read I thought AI coding was about prompts. I was wrong. (opens in a new tab).
When you're ready, move on to the next page: Next steps.