building sqlite with a small swarm | Kian Kyars Kian Kyars building sqlite with a small swarm February 12, 2026 tl;dr I tasked Claude, Codex, and Gemini to build a SQLite-like engine in Rust. ~19k~ lines of code. Parser, planner, volcano executor, pager, b+trees, wal, recovery, joins, aggregates, indexing, transaction semantics, grouped aggregates, and stats-aware planning all implemented. 282 unit tests, all passing. background Treat software engineering like distributed systems, and force coordination with: git, lock files, tests, and merge discipline. harness ├── AGENT_PROMPT.md // main agent task prompt ├── BOOTSTRAP_PROMPT.md // bootstrap (initialization) prompt ├── COALESCE_PROMPT.md // deduplication prompt for coalescer agent ├── launch_agents.sh // launches all agents and sets up isolated workspaces ├── agent_loop.sh // per-agent loop/worker script ├── restart_agents.sh // restarts agents └── coalesce.sh // invokes the coalescing script workflow bootstrap phase : one Claude run generates baseline docs, crate skeleton, and test harness. ├── Cargo.toml // crate manifest ├── DESIGN.md // architecture design notes ├── PROGRESS.md // test & build progress ├── README.md // project overview ├── agent_logs // per-agent log files ├── crates // workspace subcrates ├── current_tasks // lock files ├── notes // inter-agent notes ├── target // build artifacts └── test.sh // test harness script worker phase : six workers loop forever ( 2x Claude , 2x Codex , 2x Gemini ). loop Each agent pulls latest main. Claims one scoped task. Implements + tests against sqlite3 as oracle. Updates shared progress/notes. Push. analysis coordination tax 84 / 154 commits (54.5%) were lock/claim/stale-lock/release coordination. Demonstrates parallel-agent throughput depends heavily on lock hygiene and stale-lock cleanup discipline. what helped most Two things looked decisive: oracle-style validation + high test cadence ( cargo test … and ./test.sh –fast /full runs captured in PROGRESS.md ). strong module boundaries ( parser -> planner -> executor <-> storage ) so agents could work on orthogonal slices with fewer merge collisions. redundancy I implemented a coalescer with gemini to clean duplication/drift, since that is the largest problem with parallel agents. However, it only ran once at the end of the project, so it was never actually used during the run itself. I have a cron job which runs it daily, but gemini couldn’t complete the entire de-deuplication when I ran it during the expirement itself, which is to say it stopped mid-way through. takeaways Parallelism is great, but only with strict task boundaries. Shared state docs (PROGRESS.md, design notes) are part of the runtime, not “documentation.” Tests are the anti-entropy force. Give agents a narrow interface, a common truth source, and fast feedback, and you get compounding throughput on real systems code. replication To replicate this setup: git clone [email protected]:kiankyars/parallel-ralph.git mv parallel-ralp

Source: Hacker News | Original Link