How do we know when we have crossed the line?

When somebody in the team cannot change the flow without help. That is the practical boundary rather than any amount of code, and it arrives the first time a step contains logic that reads as programming to the person who owns the process. Naming a maintainer at that moment is the cheapest thing you will ever do about it.

Should we avoid the code steps entirely?

Not usually, because the alternative is contorting the visual parts into something worse. A short transformation in one step is far more legible than five boxes arranged to fake it. What deserves resistance is the reach outward: a step that calls other systems has quietly become an application, and it should be reviewed like one.

Does this change which platform we pick?

It changes what you compare. Feature tables converge because all of these connect applications and run on a schedule, so the useful question is where each puts its escape hatch and who on your team can reach it. A platform whose code step needs an engineer is a different purchase for a team without one.

Glossary

Low code

Low code is mostly visual building with the option to write real code where the visual parts run out, which is where most working flows end up once they meet an awkward case.

In plain terms

Building it by dragging pieces around, with the option to write a few lines where dragging will not do. Almost everything real ends up here, because there is always one step that needs a date reformatted or a rule that no menu offers. The few lines are easy to write and they change who can maintain the thing.

Why it matters

Because the moment those few lines exist, the automation has a different owner. Everything up to that point could be read and changed by whoever understood the process; afterwards there is a fragment only some people can safely touch, sitting in the middle of something the rest of the team depends on. That is a staffing consequence arriving through a tooling decision.

How it works

The code appears at the awkward edges rather than in the main flow. A date arrives in the wrong format, two systems disagree about what an empty field means, or a rule has three exceptions no menu anticipated, and a short block handles it while everything around it stays visual. Those edges are where the effort concentrates and where the fragility lives.

It is the honest end state of most visual building, not a separate category of product. Platforms that market themselves as needing no code nearly all provide a step that accepts real logic, because their customers reached the edges and asked, so the practical difference between the labels is which one the marketing leads with. Buying on that label rather than on where the escape hatch sits is the mistake.

The maintenance profile changes the moment a fragment exists. Visual steps can be read by whoever understands the process, and a block of code cannot, so a flow that was owned by an operations lead becomes something that needs a second person for part of it. That person is rarely assigned, which is how these become quietly unowned.

Where the code runs decides how much trouble it can cause. A short transformation inside a step is contained and easy to reason about, while the same platform letting you reach outward to other systems has produced something closer to a small application, with the failure modes and the review obligations that implies. The two are sold under one word.

Where the flow stops being readable by its owner

The reason to draw this as a line about readability rather than about capability is that capability is never the thing that hurts. Every platform on this page can do what a team needs; what varies is how many people can still understand the result a year later, after the person who built it has changed roles. Automations do not usually fail by breaking. They fail by becoming unowned: something changes upstream, the flow starts producing slightly wrong output, and the only person who could have diagnosed it has moved on, so it is switched off and the work returns to being done by hand. Each step rightwards on this line shortens the list of people who could have caught that. None of the steps is wrong, and taking one without naming who now owns the result is what turns a good automation into a temporary one.

Seen in the wild

An engineer-oriented platform whose visual nodes accept real code when the logic demands it, self-hosted so the operational effort is yours as well.
n8n
A visual canvas with branching, loops and data transformation as first-class steps, which is what keeps most of the flow out of code at all.
Make
A database and workflow platform where the AI works against structured operational data already in the workspace rather than against a blank sheet.
Airtable AI

Common misconceptions

People assume

It is a compromise between two real categories.

In fact

It is where nearly everything lands, because the edges arrive in every non-trivial flow. Platforms marketed as requiring no code almost all provide a step that takes real logic, so the labels describe emphasis rather than capability and the honest comparison is where each one puts that step.

People assume

A few lines of code is a small commitment.

In fact

It is small to write and lasting to own. The moment a fragment exists, part of the flow can no longer be read or safely changed by the person who understands the process, and somebody has to be responsible for it. That person is rarely named at the time, which is how these become orphaned.

Telling them apart

Low code vs No code

Low code

Visual, with a real escape hatch you will use.

No code

Visual, with the promise that you will not need one.

The same platform is frequently sold as both, so the label tells you about the marketing and the location of the escape hatch tells you about the product.

Questions

How do we know when we have crossed the line?: When somebody in the team cannot change the flow without help. That is the practical boundary rather than any amount of code, and it arrives the first time a step contains logic that reads as programming to the person who owns the process. Naming a maintainer at that moment is the cheapest thing you will ever do about it.
Should we avoid the code steps entirely?: Not usually, because the alternative is contorting the visual parts into something worse. A short transformation in one step is far more legible than five boxes arranged to fake it. What deserves resistance is the reach outward: a step that calls other systems has quietly become an application, and it should be reviewed like one.
Does this change which platform we pick?: It changes what you compare. Feature tables converge because all of these connect applications and run on a schedule, so the useful question is where each puts its escape hatch and who on your team can reach it. A platform whose code step needs an engineer is a different purchase for a team without one.