There is a particular kind of fatigue that sets in around the twentieth node of a Zapier zap. You know the one. The connecting lines start to cross. The error-handling branch you added last week now has its own error-handling branch. Someone on the team named a step "Step 7 (FINAL) (USE THIS ONE)." You open it on a Monday morning, stare at the canvas for forty seconds, and quietly close the tab.
We've spent the past eighteen months instrumenting that moment. What we found surprised us: the canvas isn't failing because the workflows got more complex. The workflows got more complex because the canvas required them to be.
The canvas tax
Every drag-and-drop builder shares an unspoken bargain: in exchange for a visual representation of your logic, you agree to express that logic in nodes. One node, one action. Two actions, two nodes and a line. A branch becomes a diamond and three lines. A retry becomes a node that points back at itself in a way that looks vaguely alarming.
The canvas didn't help us think clearly about workflows. It forced us to think about nodes.
The cost shows up in our data. Across the 12,000 teams we studied, median Zapier zaps grew 31% in node count year over year, but the work they accomplished grew by only 9%. The rest was scaffolding: wrapper nodes, formatter steps, lookup nodes, glue. The canvas was eating itself.
The natural-language alternative
What happens if you stop drawing the workflow and start describing it? We thought we knew. We assumed natural language would be a thin layer over the same model, a different input method for the same canvas. It is not.
Here is a workflow our customer Anika at Resend wrote on a Tuesday afternoon, in plain prose, in our editor:
# trigger
When a new customer signs up on our website
# steps
1. Look up their company info using Clearbit
2. Score the lead with AI: company size, industry, role
3. If score > 80, create a Salesforce deal + assign rep
4. Send a welcome email via Gmail with their name
5. Log to Google Sheets and post to Slack #signupsWhat the compiler produced from this prose was an 8-node playbook with one branch, five API integrations, and, critically, an error shield Anika never asked for, because the AI knew Clearbit sometimes times out and Salesforce sometimes rate-limits.
In a drag-and-drop tool, Anika would have spent the next two hours adding retry logic, formatter steps, and conditional fallbacks. In ours, she spent six minutes describing what the workflow should do, and the compiler handled what it should be.
The compiler is the product
The interesting work, it turns out, isn't the editor. It's the compiler. Translating "if the score is high" into a branching condition is the easy part; what's hard is knowing that the score might be missing, that the field might be a string instead of a number, that the Salesforce API will occasionally return a duplicate-key error and you should treat that as success.
That kind of knowledge isn't visible in the editor. It lives in the compiler. And once you accept that the compiler is doing the real work, the editor stops needing to look like a canvas. It can look like writing.
Three predictions
We think the next three years of workflow automation will be shaped by three forces:
- Workflows will be read more than written. The unit of authorship becomes the prose, not the diagram. Reviewing a teammate's workflow becomes reading a paragraph instead of tracing arrows.
- Error handling moves below the line. Retries, fallbacks, and rate-limit logic will be invisible unless you ask to see them. The compiler will assume you want them; you'll opt out, not opt in.
- Integrations stop being a menu. "Send to Slack" is enough. "Update the CRM" is enough. The resolver picks the tool. You don't browse a directory of 4,000 apps; you mention what you need.
None of this means the canvas disappears overnight. There are workflows where a diagram is genuinely the right representation: complex state machines, multi-week orchestrations, anything with significant parallel branches. But those are a minority. For the long tail of "when X happens, do Y and Z," prose is better. It always was. We just didn't have the compiler.
We'll keep writing as the data accumulates. If you're building
workflows, in any tool, and you want to share what you're
seeing, the inbox is open: field-notes@dugong.live.