Somewhere in your organization, someone manages your website. Maybe it's a marketing coordinator. Maybe it's an outside agency. Maybe it's a developer who also does twelve other things.
Here's what their Tuesday morning looks like: Open the CMS. Find the page. Click through the editor. Make the change. Hit save. Check the preview. Notice something broke. Fix the thing that broke. Save again. Preview again.
That was a 12-word text change on a service page.
Nobody talks about how much friction is baked into that workflow. Your team has absorbed it as the cost of maintaining a web presence. They've stopped noticing the overhead because it's invisible. And because they've stopped noticing it, they've stopped questioning whether it has to work this way.
Here's what I know now: it doesn't. The overhead was never necessary. We just had no other option.
Until recently.
What the Old Workflow Actually Costs You
Think about what's really happening when your team logs into a CMS to make a change.
They're not just editing content. They're operating a piece of software designed to give non-technical people technical control. Which means menus and editors and settings and permissions. Which means navigating all of that just to get to the thing they actually want to change.
Code changes are worse. Open the IDE. Find the file. Make the edit. Run a build. Push to GitHub. Wait for the deployment. Maybe something breaks in production that didn't break locally and someone spends 45 minutes figuring out why.
None of this is hard. But it's all overhead. Every tool is a place where someone can get distracted, make a mistake, or spend five minutes doing something that should take thirty seconds.
I've coached a lot of business leaders over the years. One thing I keep seeing is that organizations systematically undercount the cost of operational overhead. They know it exists, but they've made peace with it. It's just the way things work, so why add it up?
When you start adding it up — across every content update, every layout tweak, every page that needed to exist last week — the number surprises you. And it's not just time. It's the cognitive cost of managing the tools, the agencies, the handoffs. It's the gap between “we need this change” and “the change is live.”
That gap is about to get a lot smaller for the organizations paying attention.
What Actually Happened When I Built a New Page
Here's a real story. Not a hypothetical.
I'm working on the new version of my site. New design, new stack: Payload CMS on the content side, Astro as the front end, everything living on GitHub. I needed to build a new page for my upcoming book — something that would normally take an afternoon of tool-switching and back-and-forth.
The normal move would be: open Payload, navigate to the content collections, create a new entry, fill out the fields, save, then open the IDE to wire up the template, write some CSS, push to GitHub, wait for deployment, check the browser, realize something looks off, go back to the IDE, fix it, push again.
I didn't do any of that.
Instead, I opened Claude. I have an MCP — a Model Context Protocol connection — that links directly to Payload CMS. So instead of navigating the Payload interface, I described the page I wanted to create. Claude pushed the content straight into Payload through the MCP. No logging into the CMS. No clicking through admin screens.
Then it got more interesting. Claude Code was integrated with the Astro site on GitHub. So I could push design and layout changes from the same conversation. When I needed to get a photo on the page, we dropped it in place and wired it up. Not through an asset manager. Not by dragging files around. Through the conversation.
Here's the part that still gets me: I didn't open my IDE once. I didn't write a single line of CSS.
What I did was open a browser to see what the page looked like. Gave my feedback to Claude. It made the code changes, built the site, deployed it. I looked at it again. Two more rounds of that. And then it was live.
A complete new page. With a photo. With a design I hadn't drawn a wireframe for. Built, deployed, and live — without touching a CMS UI, an IDE, or a stylesheet.
For leaders reading this: what I just described isn't a party trick. It's a preview of how your team's workflow is about to change, whether you plan for it or not.
Watch how this article comes together and gets deployed to this site without logging into the CMS.
What's Actually Happening Under the Hood
Let me be clear about the mechanics, because it sounds like magic and it isn't.
The MCP connection to Payload means the AI can read from and write to the content layer directly. It knows what collections exist, what fields they have, and what's already in them. When I say “create a book page with this title and this description,” it's not guessing. It's making structured API calls to the CMS the same way a developer would — just without the developer spending an hour on it.
The Claude Code integration with GitHub means changes to the site can be proposed, written, committed, and pushed from inside the conversation. The site builds automatically when the push happens. Deployment follows.
So the loop becomes: describe what you want, watch it happen, open a browser to review, describe what needs to change, watch it happen again.
The technical details matter here, because they explain what's actually changing and what isn't. The underlying systems — the CMS, the codebase, the deployment pipeline — are all still there. Nothing got replaced. What changed is the interface for operating them. Instead of logging in, navigating menus, and learning where buttons are, you describe what you want in plain language.
This is why the conversation about AI in your business shouldn't start with “what tool should we buy.” It should start with “what are people on my team spending time doing that could now work differently.”
What This Changes for How You Staff and Operate
I want to be direct about what I've observed, because the implications run deeper than one person's website workflow.
Most of what I was doing in my CMS and IDE was operational. Maintenance. Content updates. Layout tweaks. The kind of work where the actual change is small and the overhead is most of the time. That overhead is now collapsing — not for every task, but for enough of them that the math on how you staff your team changes.
There are still situations where deep technical work requires an expert operating traditional tools. Major architectural decisions. Complex integrations. Anything where you need granular control and tight feedback loops. That work isn't going away.
But here's what I keep seeing: organizations that assume AI is only relevant for the “fancy” work are missing where most of the hours actually go. The hours go to the operational layer. The maintenance. The changes that need to happen quickly and usually get queued behind something else because someone has to log in, find the thing, make the change, and make sure they didn't break anything in the process.
When that layer collapses, a few things change simultaneously. The gap between “we need this” and “it's live” shrinks. The dependency on specialists for routine work decreases. And the people on your team who understand how to work this way — who can describe what they want and review what comes back — become significantly more valuable than the people who are only skilled at operating the legacy tools.
The Shift That's Actually Happening
We've spent decades building specialized tools for every category of work. A CMS for content. An IDE for code. A CRM for customers. A project management tool for tasks. Each one is an abstraction layer sitting between your people and the underlying data. Each one has a UI. Each one has a learning curve. Each one requires someone to log in, navigate, and operate it.
What AI with MCP connections creates is a different kind of abstraction. One where the interface is language. Where instead of learning where the button is, you describe what you want. Where the complexity of the underlying system becomes the AI's problem, not your team's.
The CMS was already an abstraction — it sat between your people and raw database tables. The AI with MCP connections is a new abstraction sitting between your people and the CMS. Or between your people and the code. Or between your people and whatever tool was previously the interface.
Think about that for a second. The tool is no longer the interface. The conversation is.
I built a new page for a new book on a new version of my site. I didn't write any CSS. I didn't open my IDE. I described what I wanted, reviewed it in a browser, and made a few adjustments out loud.
Your competitors are figuring this out right now. The ones who recognize what's actually shifting — not AI as a feature, but AI as the new interface layer for every tool your team already uses — are going to have a structural advantage that compounds over time.
That's not a small thing. That's a different way of working.
And it's already happening.