Ask an LLM to write a database connector today, and you get one version. Ask again tomorrow, and you get a slightly different one. Neither is wrong. Both work. But now your codebase has two subtly different patterns for the same thing, and your team has to hold that inconsistency in their heads.
This compounds. A small team building with AI assistance ends up with a codebase that feels authored by five different people with five different opinions on how to structure an HTTP client, a retry loop, a logging call. The code is correct. The system is incoherent.
The standard advice is to write better prompts, enforce code review, maintain a style guide. These help at the margins. They don't address the root cause: LLMs are stateless, context-limited, and have no memory of the patterns your team has already agreed on. Every generation starts from scratch.
Most software, even sophisticated backend systems, is mostly structure. Connection handling, retry logic, event routing, error boundaries, logging hooks — the scaffolding around the thing that actually matters: the business logic.
The business logic is small. It's the part that's genuinely different between projects. It's also the part where an LLM, given a clear problem and no distractions, does its best work.
Rigolo's thesis is simple: lock down the structure, free up the logic. Give teams a library of pre-built, pre-agreed blocks — connectors, transformers, routers, triggers — and let them wire those blocks together visually. The LLM's job becomes writing the function inside a block, not deciding how blocks connect.
Rigolo is a VSCode extension. The node graph lives where the code lives. Developers drag connections between typed ports, configure blocks inline, and see the resulting Python — not a JSON workflow definition, not a YAML file, but actual readable Python that goes into version control like anything else.
Blocks are just Python classes with a defined interface. Teams write their own. A block for your internal auth service, your message broker, your database layer. Once written, a block is reusable across every flow in every project. The interface is consistent because the block is the same code, not a regenerated approximation of it.
Deployment is a single command. The runtime is event-driven: flows execute when triggered, pass typed data between nodes, and fail loudly when something breaks — not silently with a subtly wrong result.
n8n, Zapier, and Make are good at connecting external services for operational workflows. Rigolo is not trying to replace them. If you need to trigger a Slack message when a form is submitted, use n8n.
Rigolo is for the layer below that — the backend systems those tools call into. The processing pipelines, the domain logic, the services your product is actually built on. It lives in your repo, runs on your infrastructure, and is owned entirely by your team.
Rigolo is at the vision stage. The ideas here are clear. The implementation is being worked out.
If this resonates — if you've felt the inconsistency described in section one — we'd like to hear from you. The early design should be shaped by the teams who will actually use it.
Follow along on GitHub, or reach out directly.