Genuine question, because I keep going back and forth on this. My current take: - n8n when the client (or their team) needs to see and edit the workflow, when it's mostly connecting apps, and when they'll maintain it after I leave. - Claude Code when the logic is complicated, when it needs real code (parsing messy documents, custom APIs), or when it's something I'll maintain for them. Where it gets blurry: a lot of people here are now using Claude Code to build n8n workflows, which is a mix of both. What I'm least sure about is handover. A visual workflow is easier for a non-technical client to understand. Code is easier to test and version properly. How do you decide which one to use for a client project?

One habit I'd recommend to anyone selling automations: never quote from a description alone. Ask for 10 real examples of whatever the workflow will handle, like emails, invoices, form submissions or call notes, with private details removed. A client says "we get order emails and need them in the spreadsheet." Then you see the examples: - three are forwarded threads with the order buried halfway down - one is a PDF attachment, one is a photo of a handwritten note - two are the same order sent twice That's a completely different project from the one described, and a different price. Asking for examples also tells you how organized the client is. If they can't find 10 examples in a week, the automation probably isn't their biggest problem yet. And it gives you real test data for day one. What do you ask a client for before you give them a price?

For a few of my apps, a scheduled Claude Code task runs every morning. It looks at unresolved Sentry issues, writes a fix with a test, runs an end-to-end test locally, opens a PR, merges it and ships a release. That sounds risky, and it would be without one rule: the agent only marks an issue as resolved after the release is verified. Not when the code is written, not when the PR merges. Before that rule, "resolved" just meant "the agent thinks it fixed it". With it, an issue stays open until there's evidence the fix is actually live. A few other things that help: - each task does one product and one job - every run writes a short report I can read with my coffee - anything it isn't sure about gets left for me instead of guessed The agent does the boring part. I review what it couldn't confirm. If you run agents on a schedule, what's the rule that stops them from fooling you?

When evaluating Hermes Agent, a fictional instruction says 'must disconnect power'; a draft translation says 'should'. The decision I would test: review obligation and prohibition words before judging fluency. Which wording change could make a fluent translation unsafe?

For a proposed Hermes Agent workflow, which identifiers do you explicitly protect in translation work? A sample manual refers to component AB-120 next to ordinary descriptive words. Keep the code exact and translate the explanation around it.