Traditional CMSs solved one problem: they let non-developers edit website content. But those people were still limited to fields somebody else had created.
AI agents remove that boundary. The person who spots a problem can ask for the complete change—copy, layout, links, images, or code—then review the result before it ships. That is the idea behind the new magebit.com.
Git is the source of truth; agents are the interface
“Git is the CMS” is a useful slogan, but it is incomplete.
Git is our source of truth. It stores the website, its content, and the history of every change. But git is not the interface we expect every person at Magebit to use. Claude Code, Cursor, and T3 Code are.
Across Magebit, people use all three systems: Claude Code, Cursor, and T3 Code. A few of us, myself included, prefer T3 Code backed by our Cursor, Claude, and Grok subscriptions. The choice of interface is personal; the workflow underneath is the same.
A marketer, copywriter, designer, or developer describes the outcome they want. The agent changes the files, follows the website’s rules, and opens a pull request. The person then reviews the diff and the cloud preview before deciding whether it should ship.
That can be a new landing page, a layout adjustment, an internal-linking pass, or a one-word typo. Small changes do not need a separate system. They simply move through the same path faster.
That is the important architectural decision. The agent is an interface, not an unaccountable publisher, and the repository remains the one place where the website is defined.
Why we dropped the visual CMS
We initially added Keystatic, an open-source visual CMS that edits content stored in GitHub. We assumed copywriters would prefer a familiar form-based editor.
It worked, but it added another schema, deployment, and authentication layer to maintain. More importantly, our team did not need it.
Our copywriter learned the agent workflow on her own in one day; a 30-minute call the next day confirmed that she had understood it correctly. Even a small typo was simpler through Claude Code, Cursor, or T3 Code. So we dropped Keystatic from the workflow and kept the simpler model: content in git, agents as the interface, and a preview before a human merges.
What changed for the business
This is easy to discuss as a technology choice. For me, the more interesting change is organizational.
The old workflow divided people by tool:
- marketing wrote a request;
- design prepared a visual;
- development interpreted both;
- somebody found time to deploy it;
- the original requester checked whether the result still matched the intent.
The cost was not only developer time. It was the delay between noticing a problem and fixing it. Small improvements were often too expensive to enter the queue at all.
Now the person closest to the problem can start the change.
A copywriter can ask Claude Code, Cursor, or T3 Code to publish a post. A designer can send the same systems a screenshot and ask them to match the spacing. A marketing specialist can request an internal-linking pass across related articles. A developer can change the component underneath all of them. The expertise still matters; the hand-offs shrink.
Our designers now work directly with agents too. They can turn an interaction idea into a working page, fine-tune it in the browser, and create beautiful, precisely timed micro-animations without a long design-to-development hand-off. The designer still owns the taste and timing; the agent makes implementation much faster and easier.
I also make smaller changes from my phone through T3 Code; on desktop, the same workflow runs through Claude Code, Cursor, or T3 Code. I can fix a line, move a section, review the result, and open a pull request. That is useful, but mobile editing is not the breakthrough. The breakthrough is that the same governed workflow is available wherever the person with the context happens to be.
An agent can work across the website, not only inside a field
Forms are good at constrained input. They are poor at goals.
Consider a request such as:
Review our five strongest competitors for this topic, audit our related pages, and propose the changes that would make our coverage more useful.
That is not one field. It may involve research, headings, examples, internal links, structured data, metadata, and a new supporting page. A traditional CMS can store the final edits, but it cannot perform or coordinate the work.
An agent can inspect the whole system: content, templates, links, design rules, image constraints, and build output. It can make a coherent proposal and present the result as a preview rather than a collection of disconnected field changes.
The same applies to smaller requests:
- find high-value pages with weak internal linking;
- update a fact everywhere it appears;
- compare a screenshot with the implementation and fix the differences;
- identify content that has not been reviewed in two years;
- add a case study, connect it to the relevant services, and verify every reference;
- improve a landing page without breaking its search metadata or performance budget.
This is why calling the agent “a better CMS editor” undersells it. The useful unit is no longer the field. It is the outcome.
This article started as a message from my phone
Grok Bot fits naturally into the same model. I have bots connected—with controlled access—to several systems I use for work. For this article, I simply sent a message from my phone explaining that I wanted to write about our new approach to the Magebit website.
The bot did not rely only on the few details I happened to remember in that moment. It researched the subject, studied my previous writing and feedback to match my tone of voice, and searched relevant context from the systems I had connected, including my email and Slack conversations. That gave it precise examples and details that made the article more useful than a first draft based only on memory would have been.
It then created a pull request. I opened the cloud preview link, reviewed the actual page, listed everything I wanted changed, and sent it back through another revision. Once the direction was right, I asked our designers for a few images.
The quality layer sits below every interface
More people and more agents making changes can create more mistakes, faster. Access without guardrails is not empowerment; it is a larger blast radius.
The safety of our model comes from separating who can propose a change from what the system considers valid.
Every content type has a defined shape. An article must reference a real author. An image must exist. Metadata has length limits. URLs have one canonical form. These rules are shared by the website build and the instructions used by Claude Code, Cursor, and T3 Code.
Then automated checks inspect every change:
| Check | What it protects |
|---|---|
| Content and type validation | Required fields, valid relationships, supported values, and content compatibility |
| Spelling and prose review | Misspellings, duplicated words, awkward phrasing, and sentences cut off mid-thought |
| Image budget | Page speed when somebody uploads an oversized or poorly encoded asset |
| Link and redirect checks | Visitor journeys, search equity, and paid campaign URLs |
| Full-site build | Every generated page, structured-data payload, asset reference, and search index |
| Performance budgets | Core Web Vitals and script weight on business-critical pages |
| Risk review | Changes with an unusually large SEO, security, infrastructure, or publishing impact |
| Browser preview | The thing no schema can prove: whether the result actually looks and behaves right |
We learned the need for these checks from real failures. The old site accepted multi-megabyte images. It carried spelling mistakes for years because nothing read the prose. A one-line SEO change can remove hundreds of pages from search while still producing a perfectly valid website.
The checks do not make mistakes impossible. They make quality repeatable and failures visible. That matters much more than hoping the person pressing “publish” remembers every rule.
Checks for every change, review when it matters
Every change runs through extensive automated checks covering content, spelling, links, images, SEO, performance, and the full site build. A simple text correction can be checked, merged, and sent to production immediately—without a ticket or release window.
For a new landing page or a larger change, the same pull request creates a private cloud preview we can share internally. Marketing, design, and development review the actual page, discuss it, and request changes before it goes live. The pipeline stays the same; only the amount of review changes.
What we actually built
The implementation is deliberately conventional:
- Astro renders a mostly static website;
- articles and other editorial content live in MDX and JSON;
- Zod schemas define each content type;
- GitHub stores and versions the source;
- Cloudflare Workers serves the production site and per-branch previews;
- automated checks validate content, links, images, accessibility, SEO, and performance;
- Claude Code, Cursor, and T3 Code give people agent interfaces over the same system.
The stack is not the lesson. Another company could use a different framework, agent, and hosting platform.
The transferable design is:
- Keep one portable source of truth.
- Give each role an interface suited to its work.
- Encode important rules so they do not depend on memory.
- Let agents propose broad changes, but require evidence before trust.
- Make every release observable and reversible.
It is better everywhere—after you learn to delegate
After using this workflow, I do not see an area where the traditional CMS model is better. The real cost is the adjustment period: people need time to learn how to delegate and to trust the system around the agent.
A CMS may look faster for fixing one typo: log in, find the page, edit the field, and save. If you sit and watch an agent change the same text and run every check, it may take longer. But watching the agent work misses the point.
You should be able to say, “Update X and push it to production,” then move on. The agent makes the change, runs the same safety checks, and ships it. The goal is not the fastest possible clicking; it is building a system you can delegate to and trust. Once that trust exists, the model is better for both tiny edits and large projects.
This is bigger than our website
At Magebit, we are betting big on AI—not as an extra tool, but as a way to remove friction from how people work. We want everyone to be able to act on what they know without waiting for the right hand-off, ticket, or specialist to become available.
If someone needs a typo fixed, a landing page built, research completed, or an interaction refined, the shortest path should be to describe the outcome and receive something safe and reviewable. Claude Code, Cursor, T3 Code, and Grok Bot shorten that path; our checks make it trustworthy.
This website is one example of treating AI as a baseline, not a tool. Our goal is straightforward: enable people across Magebit to move from need to result with as little friction as possible, while keeping human judgment and quality at the center.
That is how we intend to work—and increasingly, what we help our clients build. If you want to compare notes, let’s talk.
