The multiplayer challenge for no-code tools

Thanks for reading! Let me know if there’s a topic you’d like me to cover.

The promise of no-code and low-code tools is compelling. We want to democratize software development and make it accessible to non-technical users.

These tools face a critical challenge when moving from simple automation to production-grade workflows. How do you support effective collaboration and change management?

What is the multiplayer challenge?

When we think about “multiplayer” in the context of no-code tools, we talk about more than multiple people working together. It’s about creating an environment where:

1. Changes are visible and traceable: When a workflow changes, all stakeholders should know what changed, who changed it, and why.

2. Security and compliance are maintained: IT and InfoSec teams need visibility into production workflows and their changes.

3. Recovery is possible: Teams need a clear path to roll back or fix issues.

Here’s a scenario I’ve seen: Your coworker is on a plane and makes changes to a Zapier workflow. Nothing is technically broken when you review the flow and the world has changed.

How do you learn what happened? In a perfect world, the tool would tell you who made the change, what happened, and whether it’s material. Today, you often need to look at every single node in your workflow to understand the scope of the change.

What if you knew which nodes in your workflow changed and how they differ from the previous version? Good news! That’s a well-solved problem when you support source control.

Source control is the missing link

The most glaring omission in most no-code tools is GitHub (or equivalent) integration.

Source control isn’t just for developers – it’s a fundamental tool for managing change in any software system. It provides:

• A clear audit trail of changes

• The ability to review changes before they go live

• Simple rollback capabilities when things go wrong

• A shared understanding of the system’s state

One of the best paradigms for maintaining state today is a source control system like GitHub. You may hate the implementation, but don’t hate the state management.

Source control gives you:

• A clear idea of what happened and when

• Who changed it and (perhaps) what they were trying to do

• An easy way to roll back the changes when things go wrong

What source control doesn’t give you… yet is an executive summary of the change. The auto-generated PR for no-code is a feature waiting to happen, and is possible (and relatively easy) today with LLM support.

Why multiplayer support matters

Without these capabilities, no-code tools face significant limitations:

1. Collaboration becomes risky: Changes made by one team member can silently break workflows for others

2. Production support is difficult: Without change tracking, debugging issues becomes a nightmare

3. Scaling becomes problematic: As workflows grow more complex, managing changes without proper tooling becomes untenable

This is an ongoing and key problem in “just-in-time” no-code development. When a change happens, the team maintaining (and using) the workflow needs an update on what happened, why, and whether they need to change other processes.

The path forward for multiplayer access

For no-code tools to truly scale, they need to embrace DevOps practices:

1. Version control integration: Every change should be tracked and reviewable

2. Change notification systems: Teams should be automatically informed of relevant changes

3. Rollback capabilities: When things go wrong, recovery should be straightforward

4. Testing environments: Changes should be testable before hitting production

In a perfect world, you would create an agent — perhaps a GitHub action — that could run whenever a Pull Request (PR) gets committed to your repo from a no-code platform. Part of this action would be a webhook to retrieve the metadata of the steps.

Once you know the structure of your code, you could feed that information to an API to explain the inputs and outputs for each step, the summary of what happens, and a general overview of the flow. Another idea is to create a quick flow chart of data as it moves through the system.

But you can’t do this in many tools today. The main reason is that they don’t make the metadata of their steps available for review via API or JSON download. Why not?

My best guess is that they either have older code that they don’t want to expose to an API or some product person feels there is a strategic advantage to not letting people see the data structures they use to put their apps together. It could also be true that they want to lock customers in by not sharing too much detail.

The integration that teams like Pipedream are doing with GitHub makes much more sense. Why not enable teams to see who changed what at any point? Why not make it easy to roll back a failed release when things don’t go as planned?

Use AI to document no-code workflow

One of the most promising developments in managing no-code workflows is that Large Language Models (LLMs) can analyze and understand the code. LLMs can provide several powerful capabilities:

1. Code Summarization and Documentation

• Automatically generate human-readable summaries of workflow changes

• Create detailed documentation of data flows and dependencies

• Generate flowcharts and diagrams showing how information moves through the system

2. Risk Assessment and Change Impact Analysis

• Identify which parts of the workflow are most vulnerable to changes

• Highlight potential points of failure or data loss

• Suggest safer alternatives for risky modifications

• Provide recommendations for testing specific components

3. Automated Code Review

• Compare changes against best practices

• Identify potential security or performance issues

• Suggest improvements to the workflow structure

• Flag potential compatibility issues with other systems

For example, when a change is made to a workflow, an LLM could:

• Generate a Mermaid diagram showing the data flow

• Create a risk assessment report highlighting vulnerable points

• Suggest specific tests to run before deploying

• Provide a plain-language explanation of what changed and why it matters

This AI-assisted approach to change management makes it easier for both technical and non-technical team members to understand the implications of changes, while also helping to maintain system stability and reliability.

Key developments coming soon(ish)

Looking ahead, I see a few key developments that could make this even better:

• Standardized Metadata Formats: As more tools adopt source control integration, we’ll likely see standardized formats for workflow metadata emerge.

• AI-Powered Change Management: LLMs will get better at understanding workflow changes and suggesting improvements.

• Integrated Testing Environments: More tools will build testing capabilities directly into their platforms.

• Cross-Platform Compatibility: Tools will get better at working together, easing change management across different platforms.

The “easy to use” promise of no-code tools shouldn’t come at the expense of proper change management. By adopting DevOps practices, these tools can maintain accessibility while becoming more robust and production-ready. The future of no-code isn’t just about making development easier – it’s about making collaboration and change management easier too.

What’s the takeaway? No-code tools excel at making development accessible, but their true test comes when teams need to collaborate. Without proper change management and source control, what starts as a simple workflow can quickly become an unmaintainable mess.