DEV Community: SteamPixel

I'm done. Flow editors are broken. And you all know it.

SteamPixel — Mon, 18 May 2026 12:42:58 +0000

I spent the last years trying to make flow editors work. For chatbots. For forms. For LLM orchestration. Every single time I end up in the same place: buried in nested menus, drowning in node configurations, writing inline code in a tool that promised me "no-code."

I'm done making excuses for these tools. They are broken. Not the UI. Not the docs. The foundation.

So you open Botpress. Or Voiceflow. Or n8n. And within five minutes you're staring at a canvas full of nodes, nested menus, inline code editors, and condition builders that feel like they need their own documentation. You wanted to build a chatbot. Now you're studying a tool.

And it's not just chatbots. Complex form flows, onboarding wizards, LLM orchestration. Every single flow builder out there follows the same pattern: drag a node, click on it, get buried in configuration. Add a condition? Another menu. Need an API call? Another node, another config panel. Want to change something? Good luck finding where that logic actually lives.

This is not normal. And we should stop pretending it is.

The code editor test

Let me ask you something. Have you ever clicked on a variable name in your code editor and suddenly 10 nested submenus popped open? With configuration options, conditions, and inline logic attached to that single variable?

No? Of course not. That would be insane. No developer would accept that. You'd close the editor and never look back.

So why do we accept exactly this in flow builders? Every node is a little universe of hidden complexity. Click on it, and you're three menus deep before you even understand what it does. That's not a powerful tool. That's a broken abstraction.

If a flow editor requires a course before you can use it, it's not a tool. It's a problem.

The real issue is deeper than UI

The frustrating thing is: most people blame the UI. "It just needs a better interface." "A cleaner design." "Fewer options."

No. The UI is a symptom. The actual problem is the underlying architecture.

Think about it. An edge between two nodes is already a condition. It says: if this, then that. That's temporal logic. That's a rule. It's right there, visible on the canvas.

So why does every flow builder then bury another layer of conditions inside the nodes? You connect two nodes with an edge, and then you click on the node and configure more conditions in a nested menu. Conditions hidden inside a box. Invisible from the outside. Black boxes everywhere.

And it gets worse. Most flow builders love super-nodes. Take a typical "Choice Node" or "Question Node." It contains the question, the answer options, the branching logic, sometimes even validation. All packed into one node. That's a conceptual breach. The answer options are not part of the graph. They are buried inside a single node, invisible to the structure, unreachable by edge logic.

What if each answer option was its own node? Connected by edges that already carry the logic? Then your entire decision tree would be visible on the canvas. No hidden menus. No black boxes. The graph is the logic. This applies to every complex node type out there. The moment a node contains structure that should live in the graph, you've lost the point of having a graph in the first place.

And there is another problem: Most flow builders are event-driven at their core. Something happens, a trigger fires, a sequence runs top to bottom, done. That model has no real concept of state. It doesn't know where you are. It doesn't adapt when things change. So every edge case, every branch, every "what if the user goes back" scenario has to be manually wired and configured inside the nodes. The architecture can't handle the logic on a structural level, so it dumps it on you, hidden behind click after click after click.

What if the graph could think for itself?

Imagine a different foundation. Instead of "event happens, sequence runs," the graph itself holds the state. Every node knows if it's alive or dead. Every connection between nodes has a clear semantic meaning: this path must be taken, this path may be taken, this path must not be taken.

Three edge types. Must. May. Not. That's it. And that's enough. These three types can express every logical gate visually on the canvas. AND, OR, NOT, XOR. No configuration panels. No inline code. Just edges you can see.

When state changes, the graph re-sequences itself. You don't manually wire fallback paths. You don't write inline conditions. The structure is the logic. Change a decision and entire branches die while others come alive. No custom code. No nested menus. The graph adapts because it was designed to.

And before someone asks: no, re-sequencing doesn't mean the entire graph is traversed every time. At the start, only the entry node is active. As the user progresses, the active portion grows, but it stabilizes at a fraction of the total graph. When a user backtracks, the old branch dies and a new one activates. The traversal shifts, it doesn't accumulate. The more complex your graph, the more branches are dead at any given moment. Complexity makes it more efficient, not less.

This concept is called Reactive Graph Sequencing. And I built a flow editor based on it.

Wanderer

Wanderer is an open source flow editor built on RGS. No nested menus. No inline code. No configuration hell. The graph structure itself defines the logic.

If you want to understand the technical foundation in detail, I wrote about it here: Reactive Graph Sequencing: The Technology Behind Wanderer

Want to see demos? Check this out

I'm not saying this is the only way. But I am saying that the current generation of flow builders is built on a broken foundation. And we should stop blaming ourselves for struggling with tools that were never designed to be intuitive.

What do you think? Is the architecture the real problem, or am I just bad at reading nested menus?

Title image: https://pixabay.com/de/illustrations/ai-generiert-scrapyard-wagen-8241457/

Your Chatbot Ignores 2 Out of 3 Requests. Here's a Structural Fix.

SteamPixel — Wed, 13 May 2026 07:55:24 +0000

You know the drill. You type something like:

"I want to buy moisturizer, check the status of my last order, and I need your address."

The chatbot picks one of those (usually the first) and the rest just vanish. You're stuck repeating yourself, clicking through menus again, or giving up entirely.

This isn't a prompting problem. It's an architectural one.

Why most chatbot builders fail at this

Most builders (Dialogflow, Voiceflow, Botpress, you name it) route conversations through tree-like or linear flow structures. One input → one intent → one path. That model breaks the moment a user has more than one thing to say.

Some builders try to work around this by looping back after each task, but that leads to fragile state management and spaghetti flows. The fundamental structure doesn't support it.

I've written more about why conversations don't fit into trees here and why they also don't belong in relational databases here, if you want the deeper reasoning.

The fix: serialize intents before routing

The approach I built into Wanderer works like this:

User sends a message with multiple requests
A GPT call extracts and splits the intents into a structured list
Each intent gets queued as a separate task
The graph executes them one by one, each in its own context
Each task knows the full picture — it can say "Let me handle the first of your 3 requests" and "All done — that was the last one"

This is possible because Wanderer uses a reactive graph architecture instead of rigid trees. I call it Reactive Graph Sequencing — nodes react to state changes in the graph rather than following a fixed path. That means dynamically queuing 1, 3, or 7 tasks at runtime isn't a hack, it's how the system naturally works.

Before & after

Without multi-intent serialization:

User: "I want to buy moisturizer, check the status of my last order, and I need your address."
Bot: "Sure, I can help with the moisturizer! Here is a selection.
"
(The other two requests? Gone.)

With serialization:

User: "I want to buy moisturizer, check the status of my last order, and I need your address."
Bot: "Got it — 3 things! Let's start with the address..."
(Then moves on to order status, then moisturizer — automatically.)

Try it yourself

I built a working example you can test right now — no signup, no account needed:

👉 Open the Multi-Intent Demo

There's a chat embedded on the page. Try throwing multiple requests at it and see what happens.

Why this matters

This isn't just a nice-to-have. If your chatbot handles support or e-commerce, users constantly send multi-intent messages. Dropping those silently means more repeated messages, more frustration, more drop-offs, and ultimately more tickets landing on a human agent's desk.

I'm building Wanderer as a new kind of chatbot builder based on reactive graphs. If the architecture angle interests you, I've written a whole series on the underlying concepts on the Wanderer blog.

Visual Logic Without Code - Can This Change the Way We Build Flow-Based Systems?

SteamPixel — Mon, 07 Jul 2025 12:08:44 +0000

What if logic wasn’t hidden behind blocks – but was the blocks?

With Wanderer, I’ve built a free visual flow builder where the logic is the structure.

No function bodies. No hidden scripts. Just nodes and edges - and a graph that executes itself in real time, right in your browser.

You can build things like AND, OR, XOR, and NOT gates - all 100% no-code.

🧠 The twist?
Edges are the logic. They define behavior, and the whole system reacts live.

🎯 Try the interactive logic gate demos

It’s for builders, educators, and anyone curious about what visual programming can become when it’s truly visual.

Let me know what you think – and what you'd build with it.

— Chris

I built a reactive no-code flow engine that runs entirely in your browser, no login, no backend

SteamPixel — Sat, 05 Jul 2025 11:20:25 +0000

Hey Dev.to 👋

I’ve been working on a side project that started from a simple frustration:

I just wanted to build a chatbot

but every tool forced me to write complex code, bury logic inside nodes, or sign up for yet another cloud service.

So I built my own.

Introducing Wanderer Flow – a reactive, visual, and open flow engine that runs 100% in the browser.
No backend. No login. Just open a tab and start building.

What makes it different?

Flow-based: You build logic by connecting nodes and edges, not writing scripts.
Reactive: The flow is constantly traversed, like a living system.
No server: It’s fully client-side. Nothing gets uploaded. You own your data and logic.
Fork & share: Every flow can be exported as JSON or shared via URL.
GPT support: You can add GPT nodes, define your own prompts, and react to responses in the graph.
Instant preview: The flow runs while you’re building. You see your changes live.

Example use cases

Chatbots that adapt to changing context (like weather or inputs)
Interactive decision trees
Lightweight, offline-ready AI agents
Guided flows for websites or tools — without backend dependencies

Tech stack

Nuxt3 / Vue / Tailwind/ Vanilla JS / TypeScript
Open source (soon on Codeberg)
Designed to run on the edge, Raspberry Pi, or inside any CMS

Try it now

Go to: wanderer-flow.de

No signup required. Try the builder or fork one of the included examples.

I’d love your feedback

What’s clear or confusing?
What would make it more useful for you?
Would you use this for anything?

Thanks for reading!

Chris