Cuts both ways. If supply chain attacks continue recursive self improvement, everyone’s going to be working in air-gapped facilities. Departments also need to be air-gapped from one another. And each team air-gapped. And so on.

There’s a speed limit, because the faster you go the less room for error you have. It’s the same as being heavily leveraged with debt. If you have a cash investment and it drops by 50% you can just wait. If you’re leveraged 100-to-1, a 1% drop forced liquidation and wipes you out.

I mean that in the sense that they had the idea way before the wave of rapid linux 0days and supply chain attacks were common. The design they picked has only become more relevant.

> I have a co-worker who's basically not a programmer, but got multiple implementations of applications working sooner than our dev teams

Deployed to production, right?

Right??

(I’m just kidding, of course it’s only on their machine, no different than Excel 5 years ago)

> architect and orchestrate the coding, but 'language' isn't a barrier anymore.

Never was the barrier.

Here's the kicker: The devs spent nearly 5 months on a solution, and it ended up being so crap it was abandoned. The multiple vibe-coded solutions were all better.

Of course language was the barrier, that's part of why it was always hard to hire people. It takes years to get good at a particular language, and most people are idiots from bootcamps who learned a single framework.

The main risk-of-regret is: How will you feel when/if the $20/month plan costs $2000/month?

May never happen. But be clear with yourself if you’re relying on it not happening.

It’s a hell of a nice risk mitigator to understand the code, in a language you know, if you have to print-debug it yourself at some point.

You need at least 3 for this. People go on vacation, turnover, can’t risk losing that critical institutional knowledge.

Agree with other response, look at Dagster for this.

If you want to roll your own, you build a dependency graph (a dict) of the functions you want to call, Python already has graphlib.TopologicalSorter built in that can do this for you. Throw in logging and the tenacity library for retries and you’re set.

Temporal and DBOS are more around the durability guarantees. If you have tasks that are expensive to restart from scratch, or if you have human-in-the-loop approvals, or you have months between steps (e.g. 90-day warranty inspection after installation), you want that durability.

> better to use a real programming language that compiles into a DAG

Fun fact: a DAG, after topological sorting, is a list

Many people need the efficiency of running things in parallel. But if you don’t (like if you’re running reporting/ETL stuff overnight), you can skip a lot of the complexity and just run a list of tasks in the right order.

Or put another way, before you adopt a DAG orchestrator (and all the time evaluating your options), remember you can just run the same steps as a list and get something shipped, and the DAG stuff is an optimization you can tackle in phase 2.

The entire state is (mainly) two tables in Postgres. Maybe 10 tables total if you’re using all the features.

There’s something about seeing the ground truth, in full, in one place, when you’re trying to understand it, or troubleshoot it.

0 open issues. That means it’s production ready, right?

Right??