I'm using Claude to write about using Claude to write about using Claude to build features in Xperience by Kentico. If your head just tilted slightly, you're tracking correctly.

Here's what happened: I built AI-powered content and coding features into the CMS. Then I asked an AI to help me write about that work. The post resonated—readers loved it, executives forwarded it around. Success tastes sweet until you realize the weirdest part isn't what you built, but who wrote the story.

Now I'm back in the editor, one layer deeper into the recursion, asking the same AI to help me write about asking that AI to write about...you get it. We've created a documentation ouroboros, and honestly? It feels like glimpsing the future through a funhouse mirror.

The technical work is straightforward enough: machine learning models personalizing content delivery, natural language processing improving search, automated testing validating component outputs. Standard 2025 web development, really. But somewhere between implementing the features and explaining them to stakeholders, I crossed a threshold. The tools I use to build became the tools I use to document became the tools I use to reflect on documentation itself.

This is where it gets genuinely strange. Every prompt I write teaches the AI about my project. Every response shapes how I think about the work. The boundary between "doing development" and "explaining development" has dissolved into something like a collaborative improvisation where neither participant is entirely sure who's leading.

I keep wondering: when the AI helps me articulate what I built with AI, is the resulting clarity genuine insight or just really convincing recursion? Does it matter? The executives greenlit more budget. The developers on my team actually read the documentation. The features ship on schedule.

Maybe this is just what technical writing becomes when the tools achieve a certain capability threshold. Your documentation toolchain doesn't just record the work—it participates in how you understand the work. It's less "AI replacing writers" and more "writing becoming a real-time negotiation between human intention and machine articulation."

The recursive loop tightens. Next week I'll probably use this post as context for the AI to help plan the next feature sprint. The snake continues eating its tail, and somewhere in that spiral, we're building the future of content management and digital experience.

I just can't tell anymore who's holding the pen.

There's a peculiar moment that happens when you're knee-deep in Azure KeyVault certificate configurations at 3 PM on a Tuesday, managing authentication schemes for four separate websites running through a single ASP.NET Core application, when you realize: this is exactly the kind of complexity AI was built to help us navigate.

Modern enterprise CMS development isn't the "install WordPress and pick a theme" experience many imagine. Real-world platforms like Kentico Xperience power ecosystems—multiple brands, intricate authentication flows, Dynamics 365 integrations, WS-Federation SSO schemes that need perfect orchestration. The cognitive load is immense. You're not just building websites; you're architecting digital experiences that span organizational boundaries while maintaining security, performance, and developer sanity.

This is where AI tooling is fundamentally changing the game, not through flashy automation, but through something more subtle: context management at human scale.

Consider a scenario I encountered recently: troubleshooting a 500.30 error in a multi-site configuration while implementing Azure Identity Provider integration. Twenty years ago, this meant hours of documentation diving, Stack Overflow archaeology, and tribal knowledge phone calls. Ten years ago, it meant better documentation and more targeted searches. Today? AI-assisted development tools can hold the entire context—your authentication schemes, certificate deployment strategies, CQRS patterns with MediatR, Lucene search configurations—and help you reason through the problem space in natural language.

The transformation isn't that AI writes your code (though it can). It's that AI reduces the context-switching tax that makes complex architectures so mentally expensive.

When you're working with embedded Razor class libraries, managing four separate WS-Federation callbacks, coordinating Dynamics 365 marketing lists, and implementing sophisticated cache invalidation strategies—the traditional "figure it out" approach means holding an impossible amount of architectural knowledge in your head simultaneously. AI becomes a thought partner that remembers the details while you focus on the decisions.

But here's what genuinely intrigues me: platforms like Xperience by Kentico are themselves evolving to incorporate AI capabilities—content recommendations, personalization engines, intelligent search. We're approaching an inflection point where AI assists both the creation of the platform and the experience it delivers. The developer uses AI to navigate CQRS query handlers and cache dependency management, while the end user experiences AI-powered content discovery they never consciously notice.

The irony? The more sophisticated our CMS architectures become—multi-tenant, headless, composable—the more we need AI assistance just to maintain them effectively. We've built systems whose complexity exceeds comfortable human cognition. AI isn't replacing developers in this equation; it's making it possible for developers to keep building increasingly ambitious systems without drowning in their own technical debt.

Is this progress? Unquestionably. But it raises an interesting question: are we building complex systems because AI can help us manage them, or is AI emerging because our systems demanded it?

I suspect the answer is yes.

If you’ve ever worked with traditional CMS platforms or earlier versions of Kentico, you might expect a lengthy, click-heavy setup process. But with Xperience by Kentico, things have changed—dramatically.

Now, it takes just 3 simple .NET CLI commands to get a fully functioning MVC-based application up and running. Whether you’re a .NET Core developer trying XbK for the first time, or a seasoned Kentico dev exploring the new architecture, this streamlined process gets you building faster than ever.

---

1. Install the Project Templates

dotnet new install kentico.xperience.templates

This command installs the official Xperience by Kentico templates into your environment, allowing you to scaffold an entire solution with a single command.

---

2. Scaffold the MVC Project

dotnet new kentico-xperience-mvc -n NameOfProject

Replace NameOfProject with whatever you'd like your solution folder and project to be named. This command generates:

• A ready-to-run ASP.NET Core 8 MVC site
• Pre-configured XbK integration
• Default routing, configuration, and content retrieval

No need to piece together startup logic or wire up services manually—Xperience takes care of that.

---

3. Configure the Database

dotnet kentico-xperience-dbmanager -- -s “ServerName” -d “DatabaseName -a “KenticoAdministrationPassword” --license-file “\location\of\license.txt”

This command:

• Creates the database schema
• Seeds initial data
• Applies the license file
• Sets up the CMS admin account

If your SQL Server is running locally, "ServerName" might be localhost or localhost\SQLEXPRESS.

---

Why This Matters

Xperience by Kentico was rebuilt from the ground up to embrace .NET Core fully. That means:

• No more Web Forms
• No more admin UI in the same project as your frontend
• Clean separation of concerns
• Real developer freedom

This new installation workflow reflects that philosophy: clean, quick, and powerful.

---

What's Next?

After installation, open your solution, run the application, and log into the Xperience Admin UI using the credentials you configured.

From there, you can start building:

• Page types
• Page templates
• Widgets
• Components
• Content modeling strategies

All within a modern, headless-ready DXP that feels native to ASP.NET Core developers.