Is AI The End of the CMS Systems?

Skills Killed MCP Servers, Kind Of

<h2>Video Killed The Radio Star</h2>
For years, the CMS was treated as essential web infrastructure.
If a business wanted to update website copy, publish blog posts, manage landing pages, or give non-developers control over content, the default answer was usually the same: use a content management system. That led to massive adoption of platforms like WordPress, Drupal, and Contentful.
But AI is changing the assumptions that made CMS platforms so valuable in the first place.
The old reason for using a CMS was simple: most people could not safely edit a website in code. Now they increasingly can, through AI agents. And once that happens, much of the CMS starts to look less like infrastructure and more like overhead.
<h2>What is a CMS?</h2>
A CMS, or content management system, is software that allows people to create, edit, organize, and publish website content without directly modifying the site’s codebase.
Common examples include WordPress, Drupal, and Contentful. Some CMS platforms are traditional all-in-one systems. Others are headless and API-driven. That architectural difference matters in implementation, but not much in the broader argument here.
At a high level, all CMS platforms exist to solve the same problem: separating content editing from the code that renders the website.
That used to be extremely useful. Now, in many cases, it is just another layer to maintain.
<h2>AI is replacing the “change the copy” use case</h2>
A large percentage of CMS usage comes down to one basic job: changing content.
A team wants to update a homepage headline, revise product page copy, swap a CTA, edit metadata, publish a case study, or tweak an about page without asking a developer to make the change manually. Historically, that is exactly what a CMS was for. But AI agents are now capable of handling this workflow directly.
A marketer or founder can tell an AI system:
<ul><li>“Rewrite the hero section to focus on speed and implementation clarity.”</li></ul>
Or:
<ul><li>“Update the pricing page to sound more premium and reduce vague agency language.”</li></ul>
The AI can make the change in the actual codebase, often with enough context to preserve tone, layout, and structure.
That is the real disruption.
The CMS was not just a content tool. It was an access tool. It existed because non-programmers needed a safe interface for editing sites. AI is quickly becoming that interface. Once non-technical users can direct changes through AI instead of through a CMS dashboard, a lot of CMS-related complexity stops making sense.
<h2>Website content no longer needs a CMS to be editable</h2>
The strongest historical argument for a CMS was that code was inaccessible. That argument weakens significantly once AI can operate as an intermediary between the user and the codebase.
Instead of training team members on a CMS, configuring fields, maintaining integrations, and dealing with preview limitations, many teams can now work from intent:
<ul><li>“Add a testimonial section under the hero.”</li><li>“Change the homepage language to target B2B SaaS founders.”</li><li>“Update all service pages to align with the new positioning.”</li></ul>
That does not eliminate the need for review. It does eliminate much of the need for a CMS to serve as the editing surface.
This is the uncomfortable truth for many content platforms: AI agents are becoming better at translating business intent into site changes than CMS interfaces are.
<h2>Blog posts can live directly in the codebase</h2>
Blog publishing is another area where the CMS is losing its advantage. Many companies still use a CMS mostly because they have a blog. But blog content is one of the easiest things to move out of a CMS entirely.
Markdown works. MDX works. Static site generators work. Frontmatter works. Flat files in a repository work. For many modern websites, blog posts do not need a database-backed publishing platform. They just need structured content files and a build pipeline.
This approach is often faster, cheaper, easier to version, and much more AI-friendly.
An AI agent can draft a post, revise it for tone, optimize headings, add metadata, structure internal links, and save it directly as Markdown in the repo. The entire workflow becomes simpler because the content lives closer to the rendering logic.
If your CMS is mainly acting as a blog editor, that is increasingly hard to justify.
<h2>CMS platforms are often standing in for a database and admin dashboard</h2>
Not all CMS usage is just about copy or blog posts.
Many companies also use CMS platforms to manage structured objects, reusable content blocks, complex page layouts, directories, resource libraries, location pages, product-like entries, or other semi-structured business data.
In practice, the CMS often becomes a substitute for two things:
<ul><li>a database</li></ul>
and
<ul><li>an admin dashboard</li></ul>
That was historically a practical shortcut. Building internal tools used to require enough engineering effort that teams tolerated the awkward fit of a CMS instead.
AI changes that tradeoff.
AI is now extremely fast at generating custom admin dashboards, CRUD interfaces, validation flows, internal tooling, and business-specific management systems. What once required a dedicated internal tools effort can now be scaffolded and implemented much more quickly.
That weakens another major reason to use a CMS.
If a CMS is mostly functioning as a generic object editor with some publishing features, AI makes it much easier to replace that system with something purpose-built.
<h2>AI works better with code-first websites than CMS-powered websites</h2>
This is one of the most important points, and one many teams miss.
AI performs better when it has context.
Code-first websites give AI exactly that.
When content, components, data structures, and rendering logic are all visible inside the codebase, AI can inspect the system more holistically. It can see how content is used, how components are structured, how pages are assembled, and what effect a change is likely to have.
CMS-powered sites often split that context apart.
The content model may live in one platform. The frontend components live somewhere else. The rendering logic is detached from the editing interface. Relationships are often implicit rather than obvious. Preview environments may be partial or unreliable.
That fragmentation makes AI-assisted editing harder.
The AI may see the frontend but not the actual content driving it. Or it may see the CMS schema without enough UI context to understand what the resulting page should look like.
This is where code-first architecture wins.
When the source of truth is close to the implementation, AI can reason better, edit faster, and make more reliable changes.
If you want AI to be genuinely useful in website iteration, design changes, content updates, and structural edits, reducing architectural indirection matters.
CMS platforms often increase that indirection.
<h2>Why code-first web development fits the AI era better</h2>
Code-first websites are not automatically better in every situation. But they are often a better fit for how modern teams will actually work with AI.
A code-first setup makes it easier to:
<ul><li>update content directly</li><li>keep rendering logic and content close together</li><li>version everything cleanly in Git</li><li>let AI agents understand page structure</li><li>generate or modify admin tooling as needed</li><li>reduce vendor dependency and integration overhead</li><li>move faster on design, content, and experimentation</li></ul>
The CMS was designed for a world where editing content without touching code was the main bottleneck.
Now the bottleneck is shifting.
The question is no longer, “How do we keep non-technical users out of the codebase?” It is increasingly, “How do we give AI enough context to make high-quality changes quickly?”
Those are not the same problem.
<h2>Will AI completely replace CMS platforms?</h2>
Not immediately.
Many organizations will continue using CMS platforms for years. Large teams still care about permissions, workflows, governance, localization, editorial approval chains, legal review, and the comfort of established systems. There are absolutely environments where a CMS will remain the preferred choice.
But that should not obscure the broader trend.
For smaller teams, startups, design-forward agencies, and fast-moving companies, the default assumption that every website needs a CMS is becoming much harder to defend. In many cases, the CMS is no longer solving a core problem. It is preserving an old workflow that AI has started to dissolve.
<h2>Final thoughts: AI will not kill every CMS, but it will kill the default</h2>
AI will not wipe out WordPress, Drupal, Contentful, or every other CMS overnight. But AI is attacking the reasons these platforms became standard.
<ul><li>If copy can be changed by AI agents, you need less editorial overhead.</li><li>If blog posts can live in Markdown, you need less publishing infrastructure.</li><li>If admin dashboards can be generated quickly, you need less CMS-driven object management.</li><li>If AI edits code-first sites more effectively, you need less architectural separation between content and implementation.</li></ul>
That does not mean no one will use a CMS. It means the burden of proof is shifting. In the age of AI, the real question is no longer whether you can use a CMS. It is whether the CMS is actually helping you move faster.
For a growing number of teams, it is not.

Image showing a CMS representation going into the shredder

AI is changing website content management. Learn why AI agents, Markdown, code-first websites, and custom admin dashboards are making traditional CMS platforms less necessary.

Alec Dibble

Advisor

<h2>Skills vs MCP Servers: Why the Default Architecture Is Changing</h2>
For a while, MCP servers looked like the obvious future of AI tool use.
The pitch was compelling: expose tools through a standard interface, keep them available to the model, and let the agent decide what to call. In theory, that creates a clean, extensible architecture.
In practice, it often creates a context problem.
Many MCP server setups assume that tool definitions, schemas, and related instructions should stay available in the model’s context at all times. That works in some environments, but in many real-world agent systems it is inefficient. You end up paying a constant context cost for capabilities that are only used occasionally.
That is where skills are changing the design pattern.
Skills let you keep capability definitions lightweight by default and load deeper logic only when needed. In many cases, that makes them a better packaging unit than an always-present MCP interface.
So no, skills did not literally kill MCP servers. But they did weaken the case for keeping every tool surface mounted all the time.
<h2>What Is the Problem With Always-On MCP Servers?</h2>
The core issue is not MCP itself. The issue is always-on availability inside the active prompt or working context.
When a model has to carry a large tool surface at all times, several problems show up:
<ul><li>More tokens are spent on tool descriptions instead of the actual task</li></ul>
<ul><li>The model has more options to evaluate, even when most are irrelevant</li></ul>
<ul><li>Tool selection gets noisier</li></ul>
<ul><li>Prompt focus degrades</li></ul>
<ul><li>Context windows get consumed by infrastructure instead of reasoning</li></ul>
This becomes especially noticeable when one MCP server exposes many functions, resources, or conventions but only a small subset is relevant in any given interaction.
That is bad context economics.
If a capability is only needed in 5% of cases, keeping its full interface always present is usually the wrong default.
<h2>Why Skills Are Often Better Than Full MCP Context</h2>
A skill is a lighter abstraction at the point where it matters most: the default context.
Instead of loading a full server interface up front, a skill can contain:
<ul><li>a compact description of what it does</li></ul>
<ul><li>metadata about when it should be used</li></ul>
<ul><li>a script, workflow, or invocation template</li></ul>
<ul><li>optional MCP instructions or server-specific context</li></ul>
<ul><li>logic for loading deeper resources only when activated</li></ul>
That means the model only carries the small routing layer most of the time. The heavier instructions, schemas, or tool surfaces only appear when the system decides they are relevant.
For many AI agent workflows, that is the better tradeoff.
You usually do not need a full CRM tool interface loaded during a generic planning conversation. You do not need a data migration tool mounted in context during brainstorming. You do not need invoice reconciliation capabilities sitting inside the active prompt unless the task clearly points there.
In those cases, skills are simply the cleaner abstraction.
<h2>MCP Servers Solved a Real Problem</h2>
It would be a mistake to overcorrect and pretend MCP servers were a bad idea.
They solved important problems:
<ul><li>standardized tool access</li></ul>
<ul><li>cleaner external system integration</li></ul>
<ul><li>a structured interface for agents to interact with capabilities</li></ul>
<ul><li>a better alternative to ad hoc wrappers and prompt hacks</li></ul>
Those benefits still matter.
But many teams blurred two separate concerns: tool connectivity and prompt residency.
MCP is a transport and interface pattern. It does not automatically follow that every exposed capability should remain permanently loaded in the model’s context.
That distinction is where skills start to win.
A skill can sit above the tooling layer and act as a compact trigger. The MCP server can still exist underneath, but it no longer has to live in the model’s face all the time.
<h2>How Skills Reduce Context Bloat in AI Agents</h2>
The strongest case for skills is simple: they let you compress the long tail of rarely used capabilities.
Most agent systems do not use all tools evenly. A few tools are used constantly. Many others are situational.
That means the right architecture is not “keep everything equally available.” It is closer to:
<ol><li>Keep the default context lean</li></ol>
<ol><li>Expose a registry of lightweight skills</li></ol>
<ol><li>Activate the right skill when the task warrants it</li></ol>
<ol><li>Load deeper MCP-backed instructions only on demand</li></ol>
This design reduces context bloat while preserving access to powerful external systems.
That is why skills feel increasingly like the right default for production agents.
<h2>Why On-Demand Skill Loading Works Better</h2>
There are three practical reasons this model tends to perform better.
<h3>1\. Most tool usage is sparse</h3>
Many agent tools are episodic, not continuous. They matter only for specific task patterns. Loading them only when needed is more efficient than treating them as always-active prompt residents.
<h3>2\. Skill routing is improving</h3>
Agent frameworks are getting better at deciding which capability to use. Some use planners, classifiers, retrieval layers, or compact registries. Others rely on model-driven routing over small metadata summaries.
As routing improves, the need for always-loaded tool context gets weaker.
<h3>3\. Smaller active context usually produces cleaner behavior</h3>
Less irrelevant prompt material usually means better focus. The model sees fewer distracting options, the relevant instructions are more legible, and tool calls become more intentional.
That often leads to:
<ul><li>fewer unnecessary tool invocations</li></ul>
<ul><li>better skill selection</li></ul>
<ul><li>better workflow adherence</li></ul>
<ul><li>more usable room in context for actual reasoning</li></ul>
<h2>Skills vs MCP Servers: A Better Mental Model</h2>
A useful way to think about this is:
<ul><li>MCP servers are infrastructure</li></ul>
<ul><li>Skills are activation interfaces</li></ul>
The MCP server gives the system capability. The skill determines when that capability should become active.
That distinction matters.
Many teams originally treated direct tool exposure as both the plumbing and the UX layer for the model. But those are different design problems. Backend connectivity should not automatically dictate what sits in the prompt at all times.
Skills separate those layers more cleanly.
<h2>When MCP Servers Still Make Sense</h2>
There are still real cases where direct MCP exposure remains the right choice.
For example:
<ul><li>IDE-style environments with constant file, diff, and code operations</li></ul>
<ul><li>highly interactive systems where many tools are used repeatedly</li></ul>
<ul><li>environments where dynamic discovery matters</li></ul>
<ul><li>workflows where chaining across tools is continuous rather than occasional</li></ul>
<ul><li>systems where on-demand loading would introduce more friction than value</li></ul>
In those cases, keeping tools closer to the model may still be worth the context cost.
But that set of use cases is narrower than people first assumed.
A lot of early agent systems adopted the maximal pattern by default. That made sense when the ecosystem was still exploring tool standards. It makes less sense once you recognize how much waste comes from permanently loading rarely used capabilities.
<h2>Are Skills Replacing MCP Servers?</h2>
Not exactly.
Skills are not replacing MCP servers so much as reframing their role.
Instead of being the thing the model constantly stares at, MCP increasingly becomes the implementation layer behind a smarter routing system. The skill becomes the lighter-weight abstraction the model sees first.
That is the real shift.
The architecture is moving away from “everything mounted all the time” and toward “load the right capability at the right moment.”
<h2>The Future of AI Agent Tooling Is Probably Layered</h2>
The most practical architecture for many agent systems now looks something like this:
<ul><li>a lean default prompt</li></ul>
<ul><li>a lightweight skill registry</li></ul>
<ul><li>a routing layer that decides what to activate</li></ul>
<ul><li>deeper tool or MCP-backed capability loaded on demand</li></ul>
That structure is usually easier to reason about, cheaper in context, and often more robust in practice.
It also matches how real work happens. Most tasks do not require every tool at once. They require the right tool when the problem becomes specific enough.
<h2>Conclusion: Skills Didn’t Kill MCP Servers, But They Did Change the Default</h2>
Skills did not make MCP obsolete.
What they did do is expose a design mistake: many systems were treating full tool availability as the default, even when the task pattern did not justify it.
For a large class of AI agent applications, skills are the better packaging unit. They reduce context overhead, improve focus, and let you defer heavy tool instructions until they are actually relevant.
MCP servers still matter. But in many systems, they increasingly look like plumbing rather than the main abstraction.
That is why the title is only half joking.
Skills killed MCP servers, kind of.
<h2>FAQ</h2>
<h3>What is the difference between a skill and an MCP server?</h3>
An MCP server exposes capabilities through a structured interface. A skill is a lighter activation layer that tells the system when and how to use a capability, often loading deeper MCP context only when needed.
<h3>Why are always-on MCP servers a problem?</h3>
They can consume too much context, introduce noise, and make tool selection less efficient when many capabilities are only used occasionally.
<h3>Are MCP servers still useful?</h3>
Yes. They are still useful for highly interactive or tool-dense environments where many capabilities are used continuously.
<h3>Why are skills becoming more important?</h3>
Because they let agent systems keep default context lean while still accessing powerful tools on demand. As routing improves, this becomes a stronger default pattern.

Image showing an agent skills folder and an X through MCP

MCP servers are still useful, but always-on tool context is often wasteful. Here’s why skills, on-demand loading, and better routing are becoming the better default for many AI agent architectures.

Jordan Sullivan

Co-Founder

Some of the smartest engineers I know remain convinced that large-language-model (LLM) tools are a passing craze. I sympathize: tech hype cycles are exhausting. Yet after months of building real software with agents such as Cursor, Devin-style workflows, and Claude Code, I’m convinced these systems are already the second-most consequential advance of my career—behind only the Internet itself.
<h2>What “Modern” LLM Development Looks Like</h2>
If your only experience is pasting prompts into ChatGPT and copying fragile snippets, you’re missing the point. Today’s serious practitioners let agents
<ul><li>crawl entire repositories,</li><li>open PRs, run tests, and iterate automatically, and</li><li>call arbitrary CLI tools you wire up.</li></ul>
In practice an agent behaves like a tireless junior engineer who never forgets a command-line flag and never stops at 6 p.m.
<h2>The Upside in Plain Terms</h2>
<ol><li>Tedious code writes itself. Dependency scaffolding, rote boilerplate, and test refactors disappear, freeing you to focus on architecture and product thinking.</li><li>Google once, not twenty times. An LLM looks up obscure API calls faster than you can type “Stack Overflow.”</li><li>Momentum on tap. Agents hand you a project in the “it almost runs” state—exactly where the fun starts.</li></ol>
You still review every diff, but the floor now starts at “competent” rather than “blank file.”
<h2>Constructive Answers to Common Objections</h2>
<ul><li>“I won’t understand the generated code.” You own the merge button. Spend five minutes massaging style, just as you would with a human PR.</li><li>“Hallucinations make this dangerous.” Agents compile, test, and loop until the build passes. Errors feed back into the prompt; nonsense rarely survives.</li><li>“It’s still mediocre.” Mediocre is fine for glue code. Raising the minimum quality bar while you polish the critical paths is a net win.</li><li>“This ruins the craft.” Buy the dining table, hand-carve the heirloom workbench. Professional software is about solving problems, not perfect dovetails everywhere.</li><li>“Jobs will vanish.” Automation has always shifted roles—from databases to CI pipelines. The best defense is embracing the new leverage early.</li></ul>
<h2>A Better Framing</h2>
Think of LLM tools as pouring concrete for you: they lay a flat, fast foundation so you can design the building. They do not replace judgment, taste, or accountability, and they certainly do not grant production access on their own. But they do remove friction that historically killed side projects and slowed features.
Just as open-source libraries eliminated weeks of plumbing code, AI assistants wipe out another layer of drudgery. The ceiling for brilliance might not rise overnight, but the floor—where most of our time is spent—jumps dramatically.
<h2>Where to Go from Here</h2>
<ul><li>Wire up an agent to your real repo. Give it strict tests and linters, then ask for a small feature.</li><li>Treat it like an intern. Review, coach, and iterate. Measure the delta in shipped value, not line count.</li><li>Stay pragmatic. Skip the AGI debates and focus on whether today’s tools save you an hour you can reinvest elsewhere.</li></ul>
Something real is happening. Having a career in tech is all about staying relevant and it&#39;s worth your future to take AI seriously.

Why AI Coding Deserves Your Attention

AI sometimes seems all hype but agent advances in the last six months can put you behind the pack if you don't start caring soon.

Practical AI notes from teams shipping real systems

Is AI The End of the CMS Systems?

Skills Killed MCP Servers, Kind Of

Why AI Coding Deserves Your Attention

AI delivery for teams moving
across markets and time zones

Practical AI notes from teams shipping real systems

Is AI The End of the CMS Systems?

Skills Killed MCP Servers, Kind Of

Why AI Coding Deserves Your Attention

AI delivery for teams movingacross markets and time zones

AI delivery for teams moving
across markets and time zones