The flow is the program
Design software with AI
without
going blind to it.
Typed, supervised dataflow on the BEAM. You describe a system as a small typed graph, an AI writes or edits that graph, and a compiler checks every wire — the data contracts and what each part is allowed to touch — before any of it runs.
Apache-2.0 · {:bloccs, "~> 0.9"}
· built on OTP & Broadway
Why now
AI writes more code than any team can read closely.
Nobody should ship software they don't understand. The missing piece isn't a faster model — it's a shared surface where a human and an AI design the same system, small enough to hold in your head and precise enough for a compiler to check.
Thousands of lines to review by reading. Mis-wired calls and surprise side effects surface in production, if at all.
A small graph to review by glancing. The compiler rejects mis-wired stages and undeclared effects before anything runs.
The unit
A node is a declaration, not a class.
Each node declares its typed ports, the effects it's allowed to perform, and the two functions that implement it: a pure core and an effect shell. The compiler checks the contract — undeclared effects don't compile. Wire nodes into a network and bloccs emits a Broadway supervision tree you can read, review, and run.
- TOML manifests are the source of truth — any canvas is just a view.
-
Generated source lands in
_build/— debuggable and reviewable. -
Schemas are versioned
(
Order@1) and edges must match.
# validate.bloccs — one node
[node]
id = "validate"
kind = "transform"
[ports.in]
order = { schema = "Order@1" }
[ports.out]
valid = { schema = "Order@1" }
[effects] # none declared -> none allowed
[contract]
pure_core = "MyApp.Orders.Validate.transform/2"
effect_shell = "MyApp.Orders.Validate.execute/2"
Open source
Two pieces, both open.
The library defines and runs your networks. The dashboard lets you watch them. A hosted Pro tier is on the roadmap — everything you need to build and observe is free today.
bloccs
Apache-2.0The library. Declarative TOML manifests compile to a Broadway supervision tree.
- Typed ports & edges
- Effects as capabilities
- Pure core / effect shell
bloccs_web
Apache-2.0The dashboard. Mount one router macro and watch your networks run, live.
- Topology & metrics
- Message inspector
- Real coverage
Why bloccs
Visibility and code, without the tradeoff.
The space is polarized: visual tools sacrifice the code, code tools sacrifice the view. bloccs refuses to pick.
The graph is the source of truth
Not a diagram of the program — the program itself. Code lives in typed blocks; the connections between them are explicit and checked.
A compiler checks the wiring
Ports are declared, edges schema-match, effects are declared capabilities. Mis-wired stages and undeclared effects fail at compile time, not at 3am in production.
A surface you and an AI share
A manifest is small enough to hold in your head and precise enough for a model to edit. Review a graph and trust a compiler — not thousands of generated lines.
Real Elixir, not click-to-configure
Every block holds a pure core and an effect shell — ordinary functions with ordinary typespecs. No widget ceiling, no "available integrations" wall.
Compiles to OTP
A manifest becomes a Broadway supervision tree: real fault tolerance and back-pressure, on a runtime hardened behind Discord, WhatsApp, and Pinterest.
Observable by default
Every run is traced, timed, and inspectable. Mount the dashboard and watch the live topology, message flow, and real coverage of what executed.
Use cases
Built for real backends.
Concurrent, stateful systems where you need to understand and control what's running.
Webhook & event processing
Ingest, validate, route, fan out to effects. Dead-letter the unknowns. Every hop typed and traced.
View the buildRAG & agent pipelines
Retrieve, rank, call a model, gate the action. Capability boundaries and simulation mode are built in.
View the buildPayments & stateful flows
Branch on state, enforce idempotency, recover under supervision. The graph makes the money path legible.
View the buildQuestions
What bloccs is, and isn't.
Where it fits, where it doesn't, and how it relates to letting a model write the code.
- Isn't this just Bubble / no-code?
- They aim at opposite outcomes. No-code platforms like Bubble abstract code away so non-engineers can ship, and the result only runs inside the vendor's closed runtime. bloccs is built for engineers: the diagram is a typed spec that compiles to plain Elixir you own, review in a normal PR, and run anywhere. Its job is to make AI-written code reviewable at the speed AI produces it, not to hide the code from you.
- Why not just let Claude write the code directly?
- Claude writes bloccs — it isn't the alternative to it. Freeform generation means reviewing thousands of lines and trusting the model. A manifest means reviewing a small graph and trusting a compiler that catches mis-wired stages and undeclared effects before anything runs.
- What stops an agent from touching things it shouldn't?
- Effects are declared capabilities, not loose function calls. A block that doesn't declare HTTP or database access can't reach for it — the compiler fails the build. That boundary is what makes an AI-written change safe to accept without reading every line.
- What does it compile to?
- A Broadway supervision tree on the BEAM. Generated source lands in _build/ so you can read, review, and debug it like any other Elixir — no hidden runtime.
- Do I need to know Elixir?
- Yes. bloccs is Elixir/OTP and runs on the BEAM — blocks are real Elixir functions and it compiles to a Broadway supervision tree. If your backend already lives on Erlang/Elixir it drops in; if it doesn't, this isn't a way to skip learning the platform.
- How is this different from n8n, LangGraph, or Temporal?
- n8n and Zapier are closed SaaS automation — your flow runs on their runtime, untyped. LangGraph orchestrates agents in freeform Python. Temporal gives durable execution but you still hand-write every line. bloccs is the one where a typed graph compiles to plain code you own, with the compiler checking wiring and declared effects before it runs.
- Is it production-ready?
- Within its lane, yes. The runtime is supervised, back-pressured, and capability-checked, with retry, timeout, idempotency, and telemetry wired into every node, on the same BEAM substrate (Broadway/OTP) hardened behind Discord and WhatsApp. What's pre-1.0 is the surface: the public API and manifest format can shift between minor releases, so pin a version. The one thing bloccs leaves out by design is durability — in-flight messages live in memory, so put Oban or a broker at the edges for work that must survive a restart.
- When should I not use bloccs?
- When the work isn't a graph of typed stages. A single ingest → process → batch pipeline is Broadway's job, and bloccs would only add a layer. Work that must survive restarts, run exactly-once, or be scheduled is a durable job — that belongs in Oban, at the edges of a network. "Component A must be incapable of calling component B" is a module-dependency rule that boundary enforces at compile time, which bloccs doesn't replace. Ad-hoc state or one-off concurrency is a plain GenServer or Task. And it isn't a web page or content-block builder. bloccs earns its keep once you have a graph of effectful stages you want declared, checked, and reviewable.
- What's free and what costs money?
- The core is open source and free under Apache-2.0: the library plus a dashboard to watch systems run. A commercial Pro tier (bloccs.pro) is for teams in production — governance and audit, guarantees, support, and a hosted option. Free earns adoption; Pro is what a company needs once this is load-bearing.
Build backends you can see, trace, and trust.
Add bloccs to your deps, write a manifest, and mount the dashboard. Approval gates and capability boundaries are there when your agents are.
{:bloccs, "~> 0.9"}