All posts Alle Artikel
Automation n8n Claude Codex AI Dev Workflow

Automation that actually ships: n8n + Claude Code + Codex in a real client workflow

7 min read 7 Min. Lesezeit

I used to think “automation” meant building some fragile Rube Goldberg machine that breaks the second an API hiccups. Then I started doing client work at scale: small sites, frequent edits, repetitive admin, a steady stream of “can we just quickly…” requests. That’s where automation stops being a hobby and becomes basic operational hygiene.

And here’s the slightly annoying truth: most automation fails because people try to automate the smart parts first. They plug an LLM into everything and hope vibes become reliability.

The way it actually works is the opposite: automate the boring parts with deterministic plumbing (n8n), and use LLMs (Claude Code / Codex) only where language and code understanding is real leverage. Not as the engine. As the turbocharger.

The “automation triangle” I keep coming back to

In client work, you’re always juggling three constraints: speed (because clients want it yesterday), control (because you’re accountable), and cost (because nobody wants a subscription stack that looks like a SaaS graveyard).

n8n + agentic coding tools hit that triangle nicely. n8n gives you orchestration, retries, scheduling, branching, logging, and integrations. Claude Code and Codex give you “do the annoying thinking” for code and content tasks. You keep the final decision.

That’s the core pattern: automation proposes, you approve.

Where n8n wins (and where people misuse it)

n8n is not “the AI.” It’s the nervous system.

It’s good at:

  • moving data between services,
  • normalizing inputs,
  • calling APIs,
  • handling failures without drama,
  • and leaving an audit trail.

It’s bad at:

  • deciding ambiguous business logic,
  • writing nuanced copy without context,
  • making sweeping codebase changes unsupervised.

So I use n8n to wrap the workflow in guardrails, and I only call Claude Code / Codex inside those guardrails. If you do it the other way around (LLM first, orchestration second), you get a workflow that looks impressive in a demo and behaves like a toddler in production.

Claude Code vs Codex: same category, different personalities

If you’re using both, it helps to be honest about what each is best at.

Claude Code is strong at careful refactors and reasoning across a codebase. When I need: “understand this project structure, apply a consistent change, and don’t miss edge cases,” it tends to feel steady. It’s especially good when the task is less about generating new code and more about modifying existing code safely.

Codex is strong at scaffolding and hands-on implementation. When I need: “generate the new route, wire the endpoint, follow the conventions,” it’s great for momentum and predictable execution.

If I had to summarize it in a sentence: Claude Code is my refactor brain, Codex is my implementation hands.

The workflow I use most: turning messy client requests into clean PRs

Here’s a pattern that pays rent.

A client message arrives. It’s usually vague. Sometimes it’s a voice note. Sometimes it’s a WhatsApp novel. The goal is to turn that chaos into a clean, reviewable change — without you becoming a human middleware layer for 45 minutes.

So the pipeline looks like this:

n8n ingests the request → normalizes it → enriches it with context → creates a “work packet” → sends it to an agent (Claude Code or Codex) → produces a pull request → you review → merge.

The magic isn’t the agent. The magic is the work packet.

A good work packet contains:

  • what the client wants (cleaned up),
  • constraints (don’t change layout, keep branding, don’t break SEO),
  • where in the repo this probably lives,
  • acceptance criteria (what “done” means),
  • and a hard stop rule: if uncertain, ask instead of guessing.

That last bit matters. If you don’t explicitly permit the agent to stop, it will confidently fill in blanks. That’s not “AI being stupid.” That’s you failing to define the contract.

Example: the “work packet” contract

This is the kind of prompt I feed into Claude Code or Codex from n8n (as JSON or a templated text block):

You are working in an existing repository. Do NOT invent files.
If you can't find something, stop and ask.

TASK:
- Implement the requested change described below.

REQUEST (normalized):
- Add a new section to the homepage: "Seasonal Offers"
- It should match existing typography and spacing.
- Content: headline + short paragraph + 3 cards (title, description, link)

CONSTRAINTS:
- No new UI libraries.
- Keep Lighthouse performance stable.
- Do not increase client-side JS unless necessary.
- Reuse existing components if present.

ACCEPTANCE CRITERIA:
- Section renders on homepage.
- Responsive on mobile.
- No console errors.
- Build passes.

OUTPUT:
- Provide a concise summary of changes.
- Provide the exact files changed.
- If tests exist, update or add them.

Then n8n enforces the boring parts: timeouts, retries, branch naming, PR creation, notifications, and logging.

What makes this production-safe (aka: not a toy)

LLMs fail in predictable ways. They hallucinate, they overreach, they miss context, they time out. So you build the workflow assuming failure is normal.

The reliability tactics that actually matter:

Time budgets
If the model hasn’t responded in X seconds, you don’t just “wait.” You fall back. Maybe you return a partial result. Maybe you queue it for later. But you don’t block the whole run.

Structured outputs
Don’t ask for “a summary.” Ask for a JSON object with keys you validate. If it can’t comply, treat it as an error: retry, downgrade, or route to manual review.

Diff-first behavior
For code changes, require the agent to list which files it intends to touch before it touches them. This reduces surprise edits across unrelated parts of the app.

Human approval gates
Anything that deploys should pass through you (or at least a PR review). Automation that deploys directly is fine for hobby projects; for client work it’s where regret is born.

Where n8n fits best in this stack

I like n8n in three places:

1) Intake
Forms, emails, Slack, Notion requests — whatever. n8n turns incoming mess into normalized fields.

2) Orchestration
Branching logic like: content-only → CMS workflow; code change → repo workflow; ambiguous → clarification workflow.

3) Output & accountability
Create the ticket, post the summary, attach the PR link, update Notion, notify the client, store logs. The stuff you forget when you’re busy.

If you’re self-hosting, this is also where you get to be honest about privacy. A lot of “EU tools” are just a UI over an American model endpoint anyway. The practical win is: n8n can run on your own infra, and you choose where model calls go (or keep some tasks local).

So… should you automate with LLMs at all?

Yes — but only if you stop treating them like a magic brain and start treating them like a fallible collaborator.

The pro is obvious: leverage. You compress repetitive work. You ship faster.

The con is equally obvious: if you don’t build guardrails, you’ll produce silent errors at scale. Automation doesn’t just amplify productivity — it amplifies mistakes.

My rule is simple: automate anything that is repeatable, measurable, and reversible. If it’s not reversible (billing, deletion, publishing legal text), keep a human in the loop.

The part nobody says out loud

This stack isn’t about replacing developers. It’s about replacing context switching.

Because the real cost in freelance/agency life isn’t “writing code.” It’s switching between tools, copying things around, reformatting, summarizing, documenting, notifying — and doing the same ceremony again tomorrow.

n8n deletes the ceremony. Claude Code and Codex delete the grunt thinking. You keep the taste, the responsibility, and the final call.

That’s a pretty good deal.

Most important points (so you can stop scrolling)

  • n8n should be the reliable nervous system; LLMs should be contained inside guardrails.
  • Claude Code is excellent for careful refactors; Codex is excellent for practical scaffolding and implementation.
  • Use “work packets” with constraints + acceptance criteria, enforce timeouts/structured outputs, and keep human approval for anything that deploys.