I read Lee Robinson’s post about migrating Cursor.com’s CMS to Markdown at 4:21pm. It’s 4:55pm now.

In that time, I pasted his post into Claude, asked it to interview me about our migration, talked through the details, and had it write this piece. I’m dictating this with Superwhisper. I’m not even typing. Now I’m handing it to Claude Code to land on our website.

Thirty-four minutes from "I should write about this" to shipped. That’s the whole point of what follows. The bottleneck is having a system where agents can actually operate.

Everyone’s excited about the cars right now. Claude Code, Cursor, Devin. But highways made cars transformative. Without infrastructure designed for them, you just have an expensive vehicle stuck on roads built for horses.

The same thing is happening with AI agents. Teams are buying powerful tools and wondering why everything still feels slow. The answer is usually that they’re running agents on infrastructure designed for humans. Once you rebuild the infrastructure, everything becomes this fast.

The Setup

Lee’s post about migrating cursor.com from a CMS to raw Markdown resonated because I did something similar at Prefect. The scope was different. Lee migrated content. I essentially rebuilt our entire website from scratch while migrating it.

The numbers: roughly 25 million tokens (mostly Claude), 290 commits, and what I estimated would take 6 weeks took about a week. Context on that estimate: I’m Prefect’s VP of Product, not a software engineer. This is not a full-time thing. I worked on it part-time, and when you count it all out, it probably added up to a full week of actual work. That’s still a 6x compression on my original estimate, while doing my actual job.

The Problem: Bifurcated Context

We were on a headless CMS. A perfectly standard choice for a marketing site. The CMS worked fine on its own. Lee identified the real issue: when you’re trying to work with AI coding agents, a CMS creates a wall between the agent and the content it needs to modify.

The design of these websites requires you to keep all of the important context about how things render bifurcated between code and this remote content store. The remote content was tightly coupled to the components in the code. The code was tightly coupled back. Orchestrating changes between those two systems was hard in a way that compounded.

Change got slow. If somebody had an idea for something for the website, it ended up being kind of a big deal.

This is the hidden tax of the CMS abstraction in the agent era. Your AI assistant can see the code but not the content. It suggests component changes without knowing what those components actually render. Every change requires a human to bridge that gap.

The Approach: Multi-Model Orchestration

Rather than treating this as a simple migration, I treated it as a greenfield rebuild that happened to pull data from an existing source. The key insight was matching different models to different parts of the problem.

Claude Opus 4.5 for Planning. I would have Claude Code with Opus 4.5 write plans to a local /plans directory. I spent a lot of time doing the re-platforming and redesigning plan with Opus. It created a large DAG of plan dependencies.

The planning phase was about decomposition. Which pieces could be parallelized? What were the dependencies? I made sure that in its plans, it figured out what could reasonably be dispatched to different subagents. I would have Claude reflect on the outstanding work to be done and ask it: if you could hire any people to help with this, what would the job description be? Then I used that to actually build subagents.

I’ve found it important to have it design both its workforce and its work.

Cursor Composer 1 for Execution. Once the plans existed, Cursor Composer 1 handled the actual implementation. It was lightning fast and barely made mistakes when it had a well-structured plan in front of it. The greenfield advantage helped. With a new site, the agent could write idiomatic Next.js and Shadcn without fighting legacy patterns. It just spoke the modern stack fluently.

Gemini Pro 3 for Animation. This was the biggest unlock when it came to actual web animation design. A surprise finding. For motion and interaction design, Gemini Pro 3 outperformed the other models significantly. Different models have different strengths, and knowing which to reach for matters.

Eating Our Own Dog Food

Prefect maintains an open source workflow orchestration project with a commercial product built on top. This created an interesting opportunity during the rebuild.

I was able to hook up our docs MCP server. It was super helpful in catching where our marketing had deviated from our open source.

When your marketing site is written by humans over years, it drifts. Features get described slightly differently than the docs. Capabilities get overstated or understated. By connecting the agent to Prefect’s own documentation MCP server, it could flag inconsistencies automatically. A kind of quality assurance that would have been tedious to do manually.

The Migration Was Actually the Easy Part

Transitioning the blog was the simplest part. I gave the agent a read access token to our CMS and it migrated all the data out of it, wrote it in Markdown, pulled all the images. It wrote a solid open graph image generator along the way.

The blog went from the CMS to pure MDX. Same with legal and security pages. But the scope was much larger than content migration.

We used all these agents not just to migrate the blog, but to migrate every piece of information and completely redesign it along the way. Landing pages. Comparison pages built using deep research on competitors, with human verification of sources. The entire site.

On the competitor comparison pages specifically: our competitors make open source software too. We check their new releases, but it’s not something we obsess over constantly. Now we’re able to have an agent in the loop that monitors their repos. What are new issues? What new things are they putting out? Have they actually solved this problem? The pages stay current because the research is automated.

The Real Unlock: Agent-Native Content Operations

The migration was a means to an end: making the website agent-native. Fully operated by agents.

CI/CD for Content. Now all of our blog posts are part of our version control system, which means we can run CI/CD on them.

This solved a problem that had been nagging the team. One of the things we struggled with the most before was somebody wanting to write a blog post and contribute to marketing. People would rely on AI tools. We would get middle-quality first drafts that didn’t adhere to our brand voice or our tone. They were still excellent ideas, but people weren’t getting the immediate feedback they needed. Folks would put in a lot of time to write a piece and then we would have to shop it back and forth.

Now any new blog post gets feedback from Opus with our style guides, our voice guides, and our writing philosophy already baked in. Writers get automated feedback before human review. The agent knows the house style. First drafts arrive closer to shippable.

The Linear to Devin Loop. Since all the context is now in one space, making changes against our website can be done more or less autonomously. We use Linear quite a bit now. You can create an issue in our #website channel with a high-fidelity description of what you want. That sends it to Linear. Then we use Devin to do a first pass and triage. It’s been able to land pretty good changes out of the gate.

The website has been live for about a week. Devin has successfully landed a handful of changes autonomously. Human describes intent in Slack, Linear captures it, Devin attempts the implementation, human reviews.

The Payoff: 30 Minutes vs. 2 Weeks

The clearest proof point came in the first week after launch.

Earlier this week we saw a LinkedIn post from one of our competitors saying that Airflow 2 was going to end-of-life soon. Our sales team flagged it—people are going to face this migration constraint, we should be able to help them.

In the old world, that insight would become a ticket. Someone would research the migration pain points. Someone would write copy. Someone would build the page. Design review. Content review. Ship. Timeline: roughly two weeks.

Now I can take that, put it into a deep research pipeline to figure out problems people were having with that migration. Verify the base sources and where they came from. Then gave that to Claude Code to build a landing page.

Before, that would have taken us two weeks. Now we can go from idea to fully fledged, high-quality page on our site in about half an hour.

Idea to shipped page in roughly 30 minutes. A category change in what’s possible.

What This Means

Lee Robinson put it well: "The cost of abstractions with AI is very high."

If you’re going to pay the cost of removing those abstractions, don’t just migrate. Rebuild for the agent era. Build the highways.

Right now, most teams are buying cars and driving them on roads built for horses. They have Claude Code and Cursor and Devin, yet their content lives in a CMS the agent can’t touch. Their workflows assume a human in the loop for every handoff. Their infrastructure was designed when humans were the only operators.

The real question is how you’re rethinking infrastructure.

For us, that meant putting all context in one place. Code and content in the same repo, visible to the same agents. It meant CI/CD that includes content quality checks, so writers get automated feedback before human review. It meant workflows designed around agent capabilities. Linear to Devin works because we built for agents from the start.

If you’re building tools yourself, use them to validate your own claims. Hook up your docs MCP server and let the agent catch drift. Consistency becomes automatic rather than effortful.

The CMS abstraction made sense when humans were the only ones editing content. Agents turn that abstraction into a wall. The same infrastructure that made humans productive now keeps agents slow.

Tear it down. Build the highway.

---

~25M tokens (mostly Claude, started on Sonnet 4.5 before Opus 4.5 released), 290 commits, estimated 6 weeks → actual ~1 week of focused effort.