n8n vs Custom Code for Engineering Automation: The Decision, and the Bug That Proved It Right

Why Code, Not a Canvas

Four reasons drove it, in order of how much they actually mattered:

• Review parity. Every change to how a post gets approved or published goes through the same PR review as the rest of the site. A workflow-canvas change doesn't get that by default.
• Headless operation. Claude Code drives the queue directly, no GUI dashboard sitting between the agent and the task.
• Existing infrastructure. A Telegram bot already handled approvals; there was no gap a workflow tool needed to fill.
• One fewer service. Every extra tool in the stack is something else to patch and keep secure. Skipping it was the cheap option, not just the principled one.

The Bug That Proved It

On July 20, 2026, a scheduled post silently failed. The Buffer API adapter treated an error response as a normal one, never checked the status, so the X post never actually went out while the pipeline marked it published. Nothing threw, nothing alerted, the queue just quietly lied about what had shipped.

I found it the way you'd expect: read buffer.py, saw exactly where the status check was missing, fixed one line. Cheap once you can see it.

That's the part I can't picture happening the same way in a workflow canvas. I genuinely don't have a mental model for debugging that failure mode there, a canvas doesn't hand you the same thing a stack trace and git blame hand you in code. You'd be reading node configuration and hoping the tool's own logging caught the edge case, instead of reading the exact line that skipped a check.

What This Is Actually About

It isn't code versus no-code as a philosophy. It's about legibility when automation is wrong in a way that doesn't throw an error. A silent-fail bug is the worst kind, because nothing tells you to go look.

The only thing that saved this one was that the fix path was a normal code review, on a normal file, in a language with a debugger and a blame command. That's a property of the tool, not of how careful I was that week.

If your automation stack can fail without telling you, the question worth asking isn't whether the tool is fast to build in. It's whether you'd actually be able to find the bug when it goes quiet.

If you're weighing a workflow tool against custom code for something that publishes or ships on your behalf, that's exactly the kind of tradeoff I help teams think through in a strategy session.

What's the automation in your own stack you'd have the hardest time debugging if it started failing silently?

Originally published at veheria.tech/blog/n8n-vs-custom-agents-engineering-ops.