I rebuilt our content review pipeline in Claude Code. Here is the reason.

Semrush has thousands of blog posts, and many of them are pieces of information that readers rely on to learn about topics related to SEO, AI visibility, and content. Keeping those titles current and at the quality bar Semrush is known for is an important and ongoing task.

For a while, I tried to resolve to store our information content with the n8n workflow. It works for research but breaks down in writing.

So, I rebuilt the pipeline in Claude Code. This one handles both research and writing.

That’s why I called to talk about moving from n8n to Cloud Code, how the new system works, and what has changed in our team.

What keeps breaking n8n

Revising an existing article is two jobs in one: checking and surgical rewriting.

You have to find out what’s creating, where the competitors have moved, what the AI ​​search landscape is waiting for now, what new product capabilities can be woven into it, and how to update the piece without touching what still works. Multiplying that by hundreds of backlogs means the workflow has to be fast, accurate, and consistent.

My first attempt at directing this work was the n8n workflow.

Part of the research has worked. In each article, grouped together:

• Comprehensive SERP keyword data
• Top competitor titles
• Embedded domain intelligence (EDI) scanning that compares our article to our competitors
• An overview of Google’s AI for query
• Related searches on Google sites
• Communication opportunities are embedded in all of our content

But writing didn’t work.

The draft is also somewhat close to what I wanted, but never close enough to publish.

The voice was closed. The layout ignored the style guide. The language was soft and verbose. And worst of all, there were hallucinations – the AI ​​sometimes described Semrush’s missing features, and in convincing detail.

I tried everything I could think of to improve the output. Using different AI models. Strengthening instructions. Break the draft into small steps. It provides a style guide. Giving more drafts of the past as examples.

None of them produced consistent, high-quality results. I’ll get an acceptable draft once, and then the next run will be wrong in a new way.

I finally gave up trying to fix the content I was getting on n8n. Half of the research still gave us a brief for the team to write about, so we went ahead with that and put the draft aside.

But I couldn’t stop thinking about why the draft kept failing.

It turns out that the failure was structural all along. n8n is great for compiling API calls – download this, convert that, and send it forward.

Writing an article, however, requires editorial thinking – judgment about tone, structure, and what to change. That kind of thinking requires considering the entire article at once, as well as reference materials such as style guides and past examples available as decisions are made.

Workflow tools are not designed for that.

Why I switched to Claude Code

I needed something that would do the actual editing work, like read the original article, understand the intent of the question, and make calls about what to change and what to leave alone.

I looked at a few options and kept coming back to Claude Code.

Here’s what made it fit:

Claude Code is an agent that runs inside a folder on your computer. Pipe is that folder. A style guide, previous drafts, research output, and an essay under review are all files within it.

Claude Code reads what it needs when it needs it, and the work it does becomes another file that the next step can use.

The structural difference from n8n is in how AI fits into the workflow. In n8n, you build workflows in advance, and AI performs one specific step, such as writing a paragraph or summarizing data.

In Claude Code, the AI ​​runs the workflow itself, reads the files, decides what to do, and writes the results. Combined with skill guides that tell it what to do at each step, the Claude Code has both content framework requirements and constraints that keep it from going off the rails.

That’s what makes the difference.

The AI ​​had access to what it needed when it wanted it, with a defined task at each step. The function it produced was a file that the next skill could take and the author could open later for testing.

I rebuilt the entire pipeline in Claude Code, including the API calls that used to work fine on n8n. With everything in one folder, the writing process can read the research output, original article, previous draft, and style guide whenever we need it.

And it worked.

The pipeline produces drafts that our writers can edit and publish, and a trail of files that they can check if something is off.

Nine skills, end to end

The pipeline I built in Claude Code is nine skills, tied together by a main script that runs sequentially.

I give it the URL of the article I want to review and a target keyword, and I return a draft. Drafts go through our normal editorial workflow just like any other article: revision, revision, editing, and photos. Our team makes all the calls to schedule.

Here are nine skills:

1. Download live article
2. Research SERP and competitors
3. Perform an EDI semantic similarity check against our existing patch
4. Put together a review plan
5. Find outdated content
6. Analyze what the product says
7. Schedule updates
8. Generate side-by-side comparisons of the original and the new draft, with changes highlighted
9. Format the result for publication

I kept it to nine skills on purpose. It was the smallest number that gave me a unique ability to make all the decisions the pipeline had to make.

And one design choice proved to be very important. Each skill saves its work in a file before starting the next one.

I call those files pipeline artifacts. They include research, plan, outline, and comparisons for each side. Saving each step as a file means that any single skill can be run again without starting over, and anyone can open the files for testing when the draft is closed.

What changed when the Claude Code pipeline was implemented

Two things changed when the Claude Code pipeline started working:

1. The hallucinations the AI ​​produced from time to time became easier to grasp
2. The draft began to read as we wrote it

Any step in the generation of AI can be subjective at times. The pipe is designed to catch them quickly.

Dana – one of our contributors – was reviewing the draft and came across some great suggestions for a missing feature. The kind of error that, in the old version of n8n, would have passed or cost twenty minutes of testing.

He opened the diff side-by-side, looked at the same section in the first article, saw that the first one didn’t talk about workflow, and replaced it with artificial. The whole thing took about a minute.

Here is what the diff artifact looks like:

That’s what artifacts do. AI will still make mistakes. The pipeline is designed so that the reviewer can catch up and check in one minute instead of 20 minutes.

The big story is what happens in every run.

For months, I’ve been trying to figure out a script to produce something that reads like Semrush. Which means the right way of voice, tone, structure, and how we describe our products. In n8n, I’ll get a draft that might nail one of those things and miss the other three. And on the next run, I’ll get a different combination.

But for Claude Code, three runs with little changes between them got me there. Third, the draft was always strong.

The word is the same as the present article. The layout followed our style guide. The voice was Semrush. The brand positioning was right. The AI ​​got the product descriptions correct. The same type of errors did not always appear in different places.

This was the part I didn’t expect. Months of maintenance on the n8n hadn’t gotten me here. Three runs off Claude Code did it.

Dana is still holding things, but they were minor edits to edit any draft needs, like sharpening the opening, rearranging a section, or smoothing out a rough transition. The draft no longer comes with the major problems that n8n gave us, such as the wrong voice, ignoring the style guide, or Semrush’s established features.

Dana’s response after several runs was that the writing was much better than what we had previously produced. And the collective vision was really helpful.

What ultimately matters

There are three main things in every game.

1. Writing requires full context. Treating the LLM as one step in the workflow gives you inconsistent writing. The writing task should see the article, the style guide, and the research at the same time.
2. The file path is system. Each ability saves its activity before the next one starts. That clue is how our team handles problems, and how I can rerun any single step without starting over.
3. Fewer skills, more refinement. Nine combine the work. Every time I’ve been tempted to add a tenth skill, the right step would have been to hone one of the nine available.

The pipeline is working, the team is using it, contributors are saving a lot of time, and the feedback has been better than anything we’ve had with AI-generated content.

If you’re hitting a quality ceiling with AI content, start by asking where your AI makes its writing decisions. If it happens within a workflow step, that’s where the ceiling appears.

Move the writing task somewhere where the AI ​​can read your files directly. That could be an agent like Claude Code or any tool that gives the AI ​​continuous access to reference objects. It was that move that broke the ceiling for us.