How my non-engineering team at Sentry learned to ship

SubscribeSign in

How my non-engineering team at Sentry learned to ship<br>We moved 2,500 pages out of our CMS with Claude Code and Git. 4 months ago, most of us hadn't written code.

Matt Henderson<br>Jun 04, 2026

Share

A few months ago, I opened Claude Code and pointed it at our marketing site. The task was unglamorous: scan the site, find pages where internal linking was weak, and open pull requests with fixes.<br>Within minutes, the agent was crawling the repository and shipping pull requests across multiple pages at once. Then it hit a wall.

For the parts of our site that lived in GitHub as code, the agent ran wild:<br>18 pages updated in a single PR for a handful of AI tokens. But the pages that mattered most (like our blog), were locked behind a Content Management System (CMS) the agent couldn’t touch.<br>That moment kicked off a migration. Four months later, ~2500 pages of Sentry‘s marketing site live as Markdown and code in a Git repo, and we’re 100% out of our CMS. Here is what we learned.<br>Why we did it

Before the Claude Code session, we were actually expanding our CMS footprint. We wanted scalability for non-technical team members (me included at the time), guardrails to keep things on-brand, and a foundation for localization. Watching an agent do a month of SEO work in an afternoon and then stop dead at the CMS boundary changed the calculation.<br>Velocity was the real reason, not cost. We weren’t trying to escape a Contentful bill (though Cursor’s CMS had cost them nearly $57,000 in one year, which is non-trivial). We were trying to escape the situation where an agent could update half of our site instantly and the other half not at all. That asymmetry was getting more painful by the week as we built more workflows around Claude Code.<br>There’s been a small wave of teams writing about similar moves: Lee Robinson migrated cursor.com from a headless CMS back to Markdown in three days, spending $260 in AI tokens. Prefect rebuilt their entire site from scratch. Anita Kirkovska at Vellum took a different path, staying inside Sanity CMS but giving each marketer their own AI assistant with agent.md files that codify the team’s writing rules.<br>But it’s still early enough that best practices are still being written. What was clear, was that we wanted to work on the website w/ coding agents, and having pages gated behind a CMS was a blocker.<br>Technically makes practical sense of software + AI. Subscribe for more stories like this one.

Subscribe

How we actually did it

Our growth engineering team wrote up the full technical playbook here, which is the right reference if you want the deep dive on Astro, Vite, the Vercel Blob cache we built for our marketing automation forms, and the schema-to-frontmatter mapping work.<br>The highlights:<br>~2500 pages migrated by a team of 2.5 developers in a two-month window. Most of the actual code was written by Claude Code; the engineers spent most of their time planning, reviewing, and directing the agent.

One directory at a time. Docs and marketing pages migrated first (easiest to template), then blog content, then the most complex interactive pages. We kept the CMS on a free tier for legacy content during the transition, which gave us a soft cutover instead of a hard one.

We changed frameworks at the same time, from Gatsby to Astro. Build times went from 14 minutes to under 6 in the migration itself, and after we shipped a Marketo form cache (the forms had been hitting an external API on every build), we got down to under 4. That works out to about 15.8 build hours saved daily across our ~95 builds/day.

We consolidated ~200 bespoke pages into 3 templates during the migration. This made the codebase dramatically simpler, which makes it easier to use by coding agents. The agent doesn’t have to learn the quirks of 200 one-off pages; it learns three templates.

Claude Code wrote most of the migration scripts that pulled content from Contentful’s API into our new Markdown files. We also experimented with Claude running Playwright visual regression tests against the old Gatsby site to catch unintended shifts.

Broken staging builds are down ~95% and our Web Vitals score went from 89 to 97. Most of the broken-build reduction came from cutting external API dependencies out of the build process.

What it unlocked

Things that used to require a Jira ticket, a project request, or a Looker dashboard now happen in a Claude Code session.<br>In the last four months, our growth team has shipped a lot more than previously possible:<br>147 pages edited across 2 PRs to fix link issues surfaced by our Screaming Frog crawler.

50 legacy blog redirects cleaned up in about 5 minutes. This used to be a backlog ticket that nobody got to.

116 internal-link improvement PRs opened by a hub-and-spoke tool I built that prioritizes pages by SEO value. It runs as a Claude Code skill and pulls authority data from Ahrefs via MCP.

10 pages updated or built same-day...