rqlite development: the Agents are here

rqlite  is a lightweight, open-source, distributed relational database written in Go. It uses SQLite as its storage engine and Raft for consensus.

I’ve been developing rqlite for about ten years, and until recently, the workflow hadn’t changed much. I write the code. Others contribute here and there. GitHub issues are filed, triaged, and resolved. The usual.

Then language models showed up, and things started to shift.

A Brief History of the Last 30 Months

It all started in late 2022. I typed in a prompt, asked for some Python, and got a working function. It was basic, but it worked. The syntax was right. The logic was fine. What surprised me most was that I was suddenly programming a computer using natural language. I was impressed, and I saw hints of what was coming.

By April 2023, I was feeding rqlite code into GPT 4 for feedback on style, structure and possible bugs. My workflow was primitive — copy from the IDE, paste it into the UI. But the results were impressive, GPT found real issues, proposed changes, and was actually fun to use. But it was frustrating at times — what I really wanted was to be able to point an LLM at my entire repo.

But this pattern held for a while. I was copying snippets into rqlite. Not whole features—just helpers or boilerplate. It saved time, and that was enough.

Then, in early 2024, I started using models for design work. I’d describe the goals, I’d ask for implementation options or trade-offs, and it would lay them out, clearly and completely. It was like having a second opinion, on demand. And it was good.

By the mid-2024, I tried something different. I gave GPT 4o the entire rqlite CHANGELOG and asked what I should build next. It gave me a roadmap, an opinion on what rqlite was missing. rqlite now had its own dedicated Product Manager.  It advised me to build Change-Data-Capture next, and I agreed. It has always been a long-requested feature.

By March 2025 I was using GPT as a transpiler. How far could this go? I’m not a Java programmer, but within a few hours I could supply the rqlite community with a fully-featured Java client.

In May 2025, I assigned the first real GitHub issue to an agent – a bug in the SQL parser used by rqlite. A few minutes later, there was a pull request. I reviewed it, tweaked it, and then merged it. It was as straightforward as working with a junior engineer. Maybe more so.

That’s when things accelerated. Now, two weeks later I am writing issues specifically for agents. I am changing how I write descriptions—clearer scope, more direct language. I was organizing work assuming agents will pick it up.

What’s Different Now

It doesn’t feel pity, remorse, or fear. And it absolutely will not stop until….you merge the PR.

Yes, I could have done the work myself. Probably faster. But that’s not the point. I can only do one thing at a time. With agents, I can do ten. Or a hundred. They don’t ask for days off. They just take the input and return output. It changes how I think about coordination – and engineering management.

There are still limits, however. The LLMs don’t push back on bad ideas. They don’t ask, “Is this the right problem?” If you give them the wrong question, they’ll answer it anyway.

Even so, something’s changed. I’ve interacted with many contributors to rqlite over the years. Some of them were human. Some weren’t. And lately, just based on code, I can’t always tell the difference.

The agents are here. And I’m building rqlite with them.