Here's a thing that's true of almost every marketing website I’ve ever worked on: it's slightly behind.

Not catastrophically, but behind in a way that builds up a weird “marketing-tech-debt” slowly and quietly. 

The product page that still uses an old naming convention, the homepage footer pitches a use case you deprioritized, landing pages were written before you had six months of customer calls telling you what people actually want and never revisited.

At AssemblyAI, we had a specific version of this challenge. Our marketing team was busy keeping up with our product team. Feature launches, new content workflows to tackle entirely new verticals, getting the next new feature page out in line with the release. The surface of the website kept growing, and the content kept slowly creeping towards stale. The translation process from "customer said this" to "site reflects this" was too slow and too dependent on whoever had bandwidth. Product changes, like renames, pricing updates, new positioning, triggered manual sweeps that happened in untimely chunks, if at all. 

The thing is though—we build Voice AI infrastructure. Generating and processing voice data from customer conversations, internal meetings, the example voice agents on our website, is literally what we do. Our product team has gotten pretty good at translating that data into improvements. Our marketing team hadn't, yet.

But armed with coding agents, a new brand-design system, and access to all of our customer, product, and internal data, we built an entire new website from the ground up: deeply in sync with customer feedback and without a visual web builder in sight.

‍

What was actually breaking 

Things kept breaking for us in a few specific shapes. Both of them were happening pretty predictably, but without much bandwidth to solve them.

1. Product decisions with site-wide implications.

When we made a naming change, launched a new feature, or changed the price on something, we needed to propagate across an unknown number of instances across the website. Everywhere that thing was mentioned, ideally. But that is broad sweeping and difficult to find with a sprawling site. Product names live in page copy, meta descriptions, nav labels, comparison tables, FAQ sections, CTAs. 

The process was supposed to be: someone flags the change, a marketer schedules time to sweep the files, someone else reviews. In reality, that process reliably missed things, because an entire website is a lot to audit manually, and our team had launch commitments that seemed like a better use of time than doing so.

‍

2. Customer intelligence sitting unused.

We were accumulating real signal about how customers described their problems, what use cases they cared about, what language they used to search for solutions. It lived in support tickets, in Granola meeting notes, in call transcripts. It almost never made it to the website—not because anyone decided it shouldn't, but because there was no efficient path from "customer insight" to "published page." The loop was broken.

Both of these are solvable problems. 

But changing how the site was built, not just how it was managed, unlocks velocity and accuracy previously unavailable to us.

‍

In March 2026, our CEO Dylan posted in our internal marketing channel:

It wasn't exactly met with unanimous enthusiasm.

One member of the marketing team had a GitHub account. No one else had ever composed, approved, or merged a pull request, let alone knew how to articulate how the process worked. The idea of a no-code team suddenly operating out of a repository felt like an operational risk on top of an uncertain technical bet. We weren't sure where to start asking questions, because we didn't really understand the shape of the concept. Not to mention we had legitimate questions about SEO performance, brand consistency, and what would happen to the workflows our team depended on.

What followed was six weeks of questions, careful decisions, and then actual execution. Our technical lead had been exploring a code-first approach and was ready to move. He selected the stack for us: Claude Code writing all the code, Astro as the web framework, Vercel for deployment, with GitHub as the home for everything. From there, it became a genuinely cross-functional effort.

‍

The process that followed was this:

• Our product marketing team audited the entire website and defined what we needed: what pages stayed, which went, which were highest priority, and what they needed to communicate. 
• Then, product marketing worked with our creative director to build brand-aligned UI templates that became the building blocks for every page Claude built.
• Our technical lead composed an internal design system from these components that the team can pull from to generate new pages. This way, we could audit the component "building block" once and know that every page downstream follows the design rules we've set out.
• Our security & product engineering  teams helped us stand up the new infrastructure end-to-end—access controls, secrets management, deployment permissions—and signed off before anything went live.
• Our data and analytics team audited the migration for tracking continuity, making sure nothing broke in the transition and that we'd have clean data on the other side.
• Our content lead already had a host of brand content skills, so we plugged them into the new repo so that any generated copy reflected our actual voice.
• Then, we started building. Our technical lead and I spent about two weeks prompting Claude to build and QA each page across the site—from concept to animation to mobile responsiveness, all of it "vibe coded," as the kids are saying.

What we spent the last six-ish weeks creating is the foundation for an AI-driven content and website development system. This foundation has made it possible for a single content owner to spin up fourteen new use-case pages in about four days, and 99+ language-specific pages in about a week. And it made it possible for me to rename two product lines across hundreds of instances in under ten minutes and a single PR.

In just 37 days since "the build" began, I alone have made 176 contributions across three different AssemblyAI repos. That works out to more than four contributions per day.

‍

Our vision for the site is paying off

We're building the feedback loop that we always wanted but couldn't practically operate. Of course, some updates to the site are still purely manual: someone on the team sees something that needs to change, drops a note in our #marketing-website-updates Slack channel, tags Claude, and a PR gets opened. No ticket, no handoff, no waiting for a sprint. If you can describe the change, you can request it.

But the more interesting piece is what happens without anyone having to notice anything, that is genuinely leveling-up the quality of our site. Every Thursday, an agent runs a structured audit—pulling from recorded customer calls in Granola, conversations in Slack, internal product discussions—and returns a citation list: here's what's being said about our product, here's where our site is out of sync with it, here's what should change. The output isn't a deck or a summary that lives in a folder. It's a set of actionable updates with sources attached and clear recommendations for where to incorporate it into the website. All that’s left to do is review by a human and merge.

On the GEO side, we're wiring this into our content workflows too. We have an automated process for flagging when AI systems are surfacing outdated or incomplete positioning about us and generating updated page content and FAQs to correct it. The idea is that as the conversations about us change, the site changes with them, instead of drifting further from reality.

What all of this adds up to is a team that doesn't have to choose between moving fast and staying accurate. 

‍

My honest assessment as someone who opened my first PR on April 21, 2026

I'll be honest: I had real doubts going in. Learning a new system takes time. Not necessarily the concepts themselves, but the actual muscle memory of how to make updates. Cloning a repo, branching, composing a PR, resolving a merge conflict. That's a real ask of a non-technical team already stretched thin, carrying the ambient pressure of feeling like you should always be doing more, faster, and better, than you actually can.

What changed my mind wasn't the technology. I knew Claude Code was good, I knew it probably could do what we were asking it to. What changed my mind was realizing that our team’s backlog isn't necessarily a resource problem—it's a structural one. 

There will always be more to do than any team can execute. As we continue walking into the unknown world of the AI-industrial revolution, the resounding question continues to be: what do you automate, what do you delegate, and what do you protect your time for? Every hour that our team is not manually auditing files for outdated copy or chasing renamed products across the site is an hour pointed at something that actually requires judgment.

That's the real shift. AI hasn't taken jobs on our team—it's made the backlog feel, for the first time, like something other than a permanent condition: a pit so deep you can't see the bottom. It lets us actually do the things we've always known we need to do, and then ask the better question: what would I build if I had the time to build it? 

When he pitched the idea to the marketing team, Dylan talked about 100x-ing website velocity. Solving this structural problem has made that very literal for us: run a full content audit and ship every change in one pass. Build a landing page for every language we support in thirty minutes. Spin up competitor comparisons the same day the opportunity surfaces in Slack. 

What used to live in the "someday" column is now a prompt away.

The question every team should be sitting with isn't "how do we use AI?" It is more like, "what is actually in our infinite backlog and what parts would be suddenly reachable if we could automate more of them?"