Anyone who knows me knows this: I love automation that simply works. To illustrate a principle that has been on my mind, I built a small thought experiment in n8n. It is a fictional scenario, but one that gets to the heart of a real problem in modern workflows. I constructed two parallel paths to generate useful data.
On one side: a simple code node – my "rock in the storm". It does exactly what it is supposed to do, the same way every time, at virtually no cost. On the other side: an AI agent, powered by OpenRouter. The "creative chaos" that finds solutions you cannot hard-code, but also introduces a degree of unpredictability.
The terms Stable at the top in green and Volatile at the bottom in yellow then came to mind.
Two fictional paths in an n8n workflow
This is not a value judgment. It is a categorization. And that is exactly what this post is about: when do I reach for which tool – and why?
What "stable" means
Traditional automation – meaning rule-based systems, scripts, code nodes, regex – works deterministically. Same input, same result. Always. That sounds boring, but in many contexts it is exactly what I need.
Take a specific example from research: when extracting BI-RADS scores from radiological reports (X-ray images), regex was compared directly with LLMs [1]. The accuracy? Almost identical. The difference: regex was 28,120 times faster. Not a little faster. 28,000 times. That is not an academic detail – it is an architectural argument.
Stable automation is also attractive from an operating-cost perspective. A code node in n8n costs me nothing extra. An LLM call does. And again on every cycle. If you run high-throughput workflows, you notice that at the end of the month.
What traditional automation needs: clean, structured data and clearly defined rules. If I know what goes in and what should come out, a code node is the superior choice. No surprises, no hallucinations, no token consumption.
What "volatile" means – and why that is not a flaw
AI is not unstable. AI is, in a certain sense, creative (AI in the sense of generative AI). That is an important distinction.
When I give an AI agent a task, I do not necessarily get an identical result for an identical input. That sounds like a disadvantage – but it is often exactly what I need. Specifically, when:
- the input data is unstructured (free text, emails, PDFs without a schema)
- I cannot define a complete set of rules because the variation is too great
- I need to understand context and intent, not just match patterns
An example: I want to automatically categorize and prioritize incoming support requests. No regex in the world can cope when customers describe their shop login not working in twelve different ways. An LLM understands that – even in awkward German, with spelling mistakes and no clear structure.
That is the strength of the volatile side. No rulebook needed. In return: runtime costs, potentially varying results and – importantly – higher resource consumption.
The democratization problem
This is where things get interesting – and, honestly, a little delicate.
AI tools have democratized automation. Someone who previously needed a developer to build a workflow can now drop an AI agent into n8n, write a prompt and get going. That is great. In principle.
In practice, however, I increasingly see non-technical people – and unfortunately some service providers too – using AI agents where a simple code node would be the better solution. Not out of malice, but because:
- The AI agent "just works" – at least in the first test
- The costs and consequences only become visible later
- There is a lack of understanding of what happens under the hood
Specifically: anyone sending an order confirmation by email and making an LLM call for it because "AI can do that" is paying pointless token costs for a task that a template with three variables solves in milliseconds. Admittedly, it is not necessarily expensive – but it scales poorly. And it is more error-prone: what if the model gets creative one day and slightly varies the email's content?
It becomes even more critical in security-relevant processes. AI-generated output is not deterministic output. If you build that into permission checks without understanding it, you are creating a problem waiting to happen.
As far back as 2020, colleagues of mine identified major shortcomings in expertise in AI, process optimization and automation in a study in Germany [2]. Are we in a much better position now, in 2026?
Resources, costs, speed
A few figures I keep in mind:
- A simple code node: virtually no runtime costs, execution in milliseconds
- An LLM call via API: token costs that add up at high throughput – and not linearly, but cumulatively, because multi-turn conversations charge for the entire history too
- Reasoning models (those with explicit "thinking"): up to 50 times the CO₂ emissions of compact models – often for marginal accuracy gains [3]
That does not mean avoiding AI. It means making a conscious choice. Do I really need a reasoning model to tag blog posts? No. Is a smaller, fast model sufficient for sentiment classification of customer reviews? Yes, in most cases.
In my personal n8n instance, I always keep an eye on the metrics.
Dashboard in Grafana
Most of my n8n processes are still traditional, without AI or with AI added only at certain points. But there are also workflows based entirely on AI.
When I have to turn to AI
There are tasks where traditional automation simply gets me no further:
- Understanding unstructured input – free text, OCR results, scanned documents
- Assessing content – Is this product description complete? Does this text sound professional?
- Context-dependent decisions – What is the right answer to this customer question, depending on order history and the current context?
- Creative tasks – generating, varying, translating and summarizing text
There is no regex for any of that. No if-else tree grows tall enough. Here, AI is not the convenient option – it is the only sensible one.
The hybrid approach: Determinism as a guardrail
My personal architectural preference looks like this: a deterministic framework, AI where needed [4].
In n8n, that specifically means: I first check whether I can solve a problem using rules. If so, a code node. If not, an AI agent – but with clear guardrails: defined input formats, validated outputs, and a deterministic downstream processing step afterward.
The diagram at the beginning of this post shows exactly that: both paths lead to the same output. I decide for each task which path makes more sense. This is not an either-or question. It is a design decision.
Where am I using AI everywhere?
I also think it is important to keep track of your AI processes. These need maintenance too, and have to be adjusted from time to time. Especially when new models come onto the market.
In my case, I created various dashboards in my Grafana instance. Among them is one that gives me an overview of the models and providers used in the n8n workflows.
Metrics in n8n
I implemented this through an n8n workflow that analyzes all my other workflows daily and then stores the metadata in my Postgres database.
Another important part is testing your AI models with test data. But I will surely write a separate blog post about that at some point.
Conclusion
AI is not a cure-all – and traditional automation is not a relic. Both have their place. The art lies in recognizing which tool is suitable for which task [5].
What concerns me about the current developments: more and more people are automating without understanding the implications. That is initially a good thing – automation is important. But choosing the wrong tool produces systems that are more expensive, slower, more error-prone and harder to maintain than necessary.
My rule of thumb: if I can describe the problem completely, I do not need AI. If I cannot – then I do.
Update October 5, 2026: System 1 models as an additional option
With System 1 decision models such as jev, kev or laya, there is now another way to make decisions more easily with the help of AI. They can be an option between traditional, fully rule-based processes and an LLM.
Before using an LLM for a decision-making task, I should therefore also check whether a System 1 model is sufficient for the specific use case. As always, the right choice depends on the inputs available and the requirements for result quality, costs and reliability.
References
[1] Lacoste et al. (2025): A Comparative Performance Analysis of Regular Expressions and an LLM-Based Approach to Extract the BI-RADS Score from Radiological Reports. medRxiv.
https://www.medrxiv.org/content/10.1101/2025.06.01.25328636v1.full-text
[2] valantic (2020): Exclusive valantic study: Major shortcomings in expertise in AI, process optimization and automation
https://www.valantic.com/de/presse/exklusive-valantic-studie-mit-luenendonk/
[3] ScienceDaily (2025): Thinking AI models emit 50x more CO2 — and often for nothing.
https://www.sciencedaily.com/releases/2025/06/250619035520.htm
[4] Elementum AI (2025): Deterministic vs. Probabilistic AI: Enterprise Workflow Guide.
https://www.elementum.ai/blog/deterministic-vs-probabilistic-ai
[5] ECI Software Solutions: AI vs. Automation: Why the Difference Matters for SMB Growth.
https://www.ecisolutions.com/blog/ai-vs-automation-smb-difference/