使用小型集群构建 SQLite
Building SQLite with a small swarm

原始链接: https://kiankyars.github.io/machine_learning/2026/02/12/sqlite.html

## 使用AI代理构建SQLite:摘要 2026年2月,Kian Kyars成功地指示三个大型语言模型——Claude、Codex和Gemini——使用Rust构建一个类似SQLite的数据库引擎。该项目在大约三天和154次提交中完成了约19,000行代码,包括解析器、计划器、火山执行器、B+树、WAL、事务、索引和聚合等功能。重要的是,282个单元测试全部通过,验证了实现。 该过程模拟了分布式系统原理,强调通过Git、锁文件和严格测试进行协调。代理在一个循环中运行:声明任务、以SQLite作为预言机进行实现、更新共享文档并推送更改。协调开销(锁管理)占了超过一半的提交。 成功的关键在于预言机式验证、高测试频率和强大的模块边界,从而最大限度地减少了合并冲突。一个“合并器”代理(Gemini)旨在减少重复,但*在运行期间*未能有效利用。该实验强调了严格的任务边界、共享文档作为运行时组件以及测试作为利用并行AI代理时的重要反熵力量。该项目的仓库和脚本可公开获取以供复制。

黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录 使用小型集群构建 SQLite (kiankyars.github.io) 17 分,kyars 发表于 1 小时前 | 隐藏 | 过去 | 收藏 | 1 条评论 希望有人觉得这篇关于我并行编码代理经验的文章有趣。帮助 scirob 1 分钟前 | 下一个 [–] 他们最终通过了所有单元测试吗?回复 指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系 搜索:
相关文章

原文
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

  1. 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
    
  2. worker phase: six workers loop forever (2x Claude, 2x Codex, 2x Gemini).

loop

  1. Each agent pulls latest main.
  2. Claims one scoped task.
  3. Implements + tests against sqlite3 as oracle.
  4. Updates shared progress/notes.
  5. 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-ralph/sqlite .
chmod 700 sqlite/*.sh
./sqlite/launch_agents.sh

restart agents:

./sqlite/restart_agents.sh claude/codex/gemini

coalesce agent:

Assumes you have the relevant CLIs installed (claude, codex, gemini), plus screen, git, Rust toolchain, and sqlite3.


limitations

  • The documentation in the repo became enormous, PROGRESS.md became 490 lines and look at the sheer amount of notes; all this to say that the coalesce agent must be run as often as the other agents.
  • There isn’t a great way to record token usage since each platform uses a different format, so I don’t have a grasp on which agent pulled the most weight.

future work

  • Track “substantive run rate”, since many are rate-limited/nothing happened.
  • Only Claude adds itself as a co-author to each commit and I did not do that for Codex and Gemini, so I need to add a commit message for Gemini and Codex.
  • Adding more strict observability because probably a lot of errors were due to the rate limit being hit mid work and then just not being able to like put then essentially at that point there was like only half finished work pushed.

inspiration

  • https://cursor.com/blog/scaling-agents
  • https://www.anthropic.com/engineering/building-c-compiler

appendix

code size snapshot

Language Files Lines Non-blank/Non-comment
Rust 14 18,650 ~16,155
Shell 1 199 ~139
Total 15 18,849 ~16,294

154 commits between 2026-02-10 and 2026-02-12.

usage

Gemini does not offer a way to monitor usage with their CLI. It’s also not on a weekly usage basis, but rather a 24-hour usage basis. For codex, I used 100% of the Pro Plan weekly usage, which is currently on a 2x promotion. I used 70% of the Claude Pro weekly usage.

disclaimer

  • codex wrote the first draft for this post.

citation

@misc{kyars2026sqlite,
  author = {Kian Kyars},
  title = {Building SQLite With a Small Swarm},
  year = {2026},
  month = feb,
  day = {12},
  howpublished = {\url{https://kiankyars.github.io/machine_learning/2026/02/16/sqlite.html}},
  note = {Blog post}
}
联系我们 contact @ memedata.com