Claude Code + n8n: Refactoring a 30+ Node Workflow Into 5 Subflows

This is one of the clearest examples where Claude Code did not only give me advice. I gave it access through n8n API and MCP, and it helped clean up a real company blog automation workflow that had become too big, too duplicated, and too hard to manage.

Short version: I had a company n8n blog automation workflow with more than 30 nodes. It started to feel like spaghetti because I kept duplicating logic. Claude Code helped refactor it into a main publisher workflow plus 5 smaller subflows, each with fewer than 10 nodes, with better names, easier error handling, and less server RAM pressure.

The biggest lesson for me: Claude Code can be more than a code assistant. For n8n, it can act like a workflow architect.

This post continues my Claude Code CLI server management story. That first post explained the bigger shift from copy-pasting YAML into chatbots to letting Claude work closer to real files, tools, and server workflows. This post focuses on one specific example: my n8n blog workflow refactor.

Jump to

• Before: one big 30+ node workflow
• How Claude Code worked with n8n API and MCP
• The refactor: 5 smaller subflows
• The English and Chinese blog workflow surprise
• Why this helped server RAM
• What I learned

Before: one big 30+ node workflow

The original workflow was for company blog automation. Over time, it grew to more than 30 nodes.

At first, it worked. But the bigger it became, the harder it was to maintain.

• I kept duplicating similar logic.
• Error handling became harder to trace.
• Changes were risky because one edit could affect many later steps.
• The workflow was difficult to understand when I came back later.
• Running many heavy steps together could spike server RAM.

The workflow was not broken in a simple way. It was more like a structure problem. It had become a spaghetti workflow.

Before:
One big n8n workflow
30+ nodes
Repeated logic
Harder debugging
Image + blog + Google Doc + posting steps running together

How Claude Code worked with n8n API and MCP

The important part is that I did not only paste screenshots or JSON into a chatbot. I gave Claude Code access to work with the workflow through both:

• n8n API
• n8n MCP

That made the workflow different from a normal chat conversation. Claude could inspect, edit, and monitor the workflow more directly.

Instead of me manually explaining every node, Claude could work with the actual n8n workflow structure.

This is why it felt very different from my old way of using AI. I was no longer only asking, “What should I do?” I was asking Claude to check the real workflow, suggest a better structure, and validate the result.

The refactor: 5 smaller subflows

Claude suggested that the workflow should be broken down into one main publisher workflow plus 5 subflows. This made a lot of sense because each part had a different job.

The result felt much easier to manage:

• each subflow has fewer than 10 nodes,
• each subflow has a clearer purpose,
• error handling is easier to locate,
• changes are safer because they happen in smaller parts,
• the workflow names are easier to search and understand.

One thing I really liked was the naming style. The flows were named clearly, something like:

BLOG-00 Blog Publisher Main
BLOG-01 Docx to HTML
BLOG-02 Translate to Chinese
BLOG-03 Feature Image
BLOG-04 Post to Wix
BLOG-05 Post to WordPress

This naming style is simple, but it helps a lot. I can immediately see the order: main workflow first, then document conversion, Chinese translation, feature image, and the two publishing targets.

With names like this, I can quickly understand the workflow order. BLOG-00 is the main publisher workflow, and BLOG-01 to BLOG-05 are the smaller parts for conversion, translation, feature image, and posting. When something fails, I can quickly find the correct workflow instead of searching inside one big 30+ node flow.

Why smaller subflows feel better

For me, smaller subflows are easier to trust. I do not need to understand 30+ nodes at once. I only need to understand the part I am changing.

After:
BLOG-00 main publisher workflow
BLOG-01 to BLOG-05 as smaller subflows
Each mostly under 10 nodes
Cleaner names
Easier error handling
Lower chance of one change breaking everything

The English and Chinese blog workflow surprise

The most surprising part was the language blog workflow.

I thought I needed a more complicated setup. In my mind, I needed different AI steps, then write the draft to Google Docs first, then only post the blog later.

But Claude built it in a cleaner way. It could run the process directly and handle English and Chinese blog output without the extra manual structure I thought was required.

Another surprise was that it could push 2 blog posts at the same time. I initially thought it was only posting one. When I mentioned that to Claude, it corrected my understanding clearly and explained what was really happening.

That moment was important because Claude did not just build the workflow. It also corrected my mental model of how the workflow worked.

This is one reason I like using Claude Code for this type of work. It can do the task, but it can also teach me the structure behind the task.

Why this helped server RAM

My company workflow runs on a real server, so RAM matters. A big workflow can spike memory because many heavy steps may run together: feature image generation, blog writing, Google Doc handling, and posting logic.

When everything is inside one large workflow, the server has to handle more at the same time. Breaking the workflow into smaller subflows makes the structure easier to control and reason about.

For me, this was not only about making n8n look cleaner. It was also about making the workflow feel safer to run on the server.

Error handling became easier

The biggest practical improvement is error handling.

Before, if something failed, I had to search inside a large workflow and guess which part caused the issue. Now, each subflow has a clearer name and a smaller purpose.

• If the blog content step has an issue, I know where to look.
• If the label or posting step has an issue, I know which subflow to check.
• If I need a change, I can prompt Claude to fix one specific flow.

Another useful thing is that Claude validates the workflow before reporting back. It checks that the change works, then tells me what was done.

What I learned from this refactor

This n8n refactor taught me a few things:

• Big workflows are not always better. They can become hard to maintain.
• Subflows make debugging easier. Smaller parts are easier to understand.
• Good names matter. A name like 00-blog post is easier to find than a random workflow name.
• Claude Code can help with architecture. It did not only fix a node. It improved the workflow structure.
• AI can correct my understanding. The 2-blog posting behavior was something I misunderstood until Claude explained it.

Related automation and server posts

This post connects with my other n8n, self-hosting, and AI-assisted server management posts:

• From Copy-Pasting YAML to Managing Servers with Claude Code CLI
• What I Automated With n8n on Server (2 Real Examples)
• The $0 Automation Engine: Hosting n8n on an Old Laptop with Cloudflare Tunnels
• What Is an AI Agent? A Simple Explanation of Model + Harness + Tools

Frequently Asked Questions

Can Claude Code edit n8n workflows?

In my setup, Claude Code worked with n8n through both the n8n API and MCP. This allowed it to inspect, edit, and monitor the workflow more directly than a normal chatbot conversation.

Why split a large n8n workflow into subflows?

Subflows make the workflow easier to manage, debug, and update. In my case, a 30+ node blog automation workflow became a BLOG-00 main publisher workflow plus 5 smaller subflows, with each subflow mostly under 10 nodes.

Did the refactor help server performance?

It helped reduce the feeling of one big workflow running everything together. Since image generation, blog writing, Google Doc handling, and posting can be heavy, smaller subflows make the system easier to control and troubleshoot.

Was this for personal or company use?

This was a company workflow, so I am keeping the private details general. The important part is the workflow structure and how Claude Code helped refactor it.

Final note

This refactor made me trust Claude Code more for real workflow management. It did not just answer questions. It helped clean up a messy n8n automation, reduce duplication, improve naming, and make the whole system easier to understand.

For me, that is the real value: Claude Code can be a teacher, a doer, and sometimes even the person who explains my own workflow back to me better than I understood it before.