What they did
Ukjin Choi, a data engineer and former DBA, set out to build a relational database around one constraint: a tuple's key can never change. He worked in the Claude Code CLI, first switching between Opus and Fable and later using Opus 5.5 and Sonnet. Before any code he gave the model a target (most features of commercial databases at similar speed), development rules and about 20 invariants. Work was split into milestones, stages and tasks, one milestone per session, with a review agent and a performance agent run at the end of each stage before asking him to approve a push. All context lived in Markdown folders for rules, specs, dated rule changes, per-milestone instructions and open bugs.
How it went
KDBS reached roughly 300,000 lines with indexes, foreign keys, transactions, MVCC, WAL, backup and most SQL, but no triggers or stored procedures. He reports 10 to 40 percent faster single-row reads and updates than general databases. Past about 200,000 lines, builds and tests slowed and the end-of-stage check grew from under a minute to over an hour, so he moved testing to once per milestone. Most cases where the agent got stuck traced back to contradictions in his own requirements.
Worth knowing
He read the work between stages and picked among the model's proposed fixes himself rather than automating it fully. He wrote milestone documents only on his own request. The speed figures are his own and the post gives no benchmark setup. His one regret was not moving to the Max 20 plan sooner.
Postgresql
GitHub