git worktree uses one repo to laid out multiple branches in separate directories.

git worktree add new/path/for/worktree branchname

I now refuse to use git checkout to switch branches, always keep my main branch checked out and updated and always use worktrees to work on features. Love this workflow!

Great article! I have similar observations and techniques and Claude Code is exceptionally good - most of the days I'm working on multiple things at once (thanks to git worktrees) and each going faster than ever - that's really crazy.

For the "sub agents"thing, I must admit, that Claude Code calling o3 via sigoden/aichat saved me countless of times!

There are just issues that o3 excells at (race conditions, bug hunting - anything that requires lot of context and really high reasoning abilities).

But I'm using it less since Opus 4 came out. And of course its none of the sub-agent thing at all.

I use this prompt @included in the main CLAUDE.md: https://github.com/pgflow-dev/pgflow/blob/main/.claude/advan...

sigoden/aichat: https://github.com/sigoden/aichat

Come here to write this - perfect analogy!

I’m tinkering on pgflow – an open-source, DAG-based workflow engine that uses Postgres to orchestrate workers on top of PGMQ queues. It seamlessly integrates with Supabase (no new infra needed!) and executes code on Edge Functions using custom, serverless task queue worker. All the current and past state of all executions is stored in Postgres and can be queries with simple SELECTs and flows can be started from within the db (think: pg_cron, triggers).

I have strong focus on db consistency and Type safety between steps.

### Built so far – core SQL orchestration (state machine, retries, observability, queue management) – strictly typed TypeScript DSL + compiler that turns flow definitions into migrations – a minimal Edge Function worker that polls, executes and reports back

### Current focus I’m heads-down on a dedicated client library. It leverages Supabase Realtime to stream events and progress of each flow run back to the browser, while having strict compile-time safety for flows defined with the TypeScript DSL.

### Next on the roadmap - Fanouts for processing arrays of data in parallel, with per-item retry logic. - SQL-based conditionals/branching that leverages JSONB containment operator and step outputs

Docs: https://www.pgflow.dev/concepts/how-pgflow-works/ Repo: https://github.com/pgflow-dev/pgflow

pgflow can be used with any language/runtime, I just started with TypeScript and Supabase, as that's what I'm using.

The worker is stateless and "dumb" by design (currently it runs on serverless functions) - it just calls SQL functions: "poll_for_tasks" to get some tasks from the queue and then either "complete_task" or "fail_task" after executing user code - that's it, nothing more, so it should be relatively easy to adopt it to other runtimes.

I have written a small architecture primer on pgflow if anyone is interested in its simple but flexible design https://www.pgflow.dev/concepts/how-pgflow-works/