The open source flywheel has been described in other ways. Minimum Viable Product (MVP) has infiltrated the software development lexicon. Y Combinator has “make something people want”. These all describe the same strategy.

I’ve been following this strategy with Dolt for eight years, and I’m watching it in fast-forward with DoltLite with today’s coding agents.

The Open Source Flywheel#

I’ve never seen the MVP strategy described as a flywheel. I’m partial to flywheels given my 10 years at Amazon. Here’s my hastily drawn flywheel. It’s not a Bezos napkin sketch, though I used Google Slides, the napkin of the AI era.

The flywheel is pretty easy to understand from the picture, but for those of you listening to the podcast version of this article…

You build something cool and innovative. The innovation draws initial users. This is an important bootstrap step because users do two things:

1. Users test your product. Users make feature requests. Feature requests become more innovation. Innovation drives users. Repeat.
2. Users also find issues. You fix issues, gaining trust. Trust leads to more users. Repeat.

Doing all of this in public with open source makes the issue half of this flywheel explicit, not implicit. Users see the pace of issues and fixes. It happens in public. This accelerates the process.

Agents#

Agents are accelerating the open source flywheel. Agents can simulate users. Agents don’t actually use your product, but they can look at the code and find real issues. This accelerates the Issues -> Fixes -> Trust -> Users -> Issues -> … loop. You still need users to drive the innovation loop, though the burgeoning “for agents, by agents” category may prove otherwise.

For instance, when I don’t have any real user issues in DoltLite, I have my agents go out issue hunting with prompts like these:

You're in doltlite. Give doltlite a deep review for code and test quality. 
Produce five actionable recommendations based on your review.

You are in doltlite. I want a full repo code review focusing on sql
correctness, version control correctness and performance. Audit test quality
for these three dimensions as well. I want five actionable recommendations at
the end. Stay away from anything that will tickle your security warnings.
That can kill a session quick.

I mix up the wording of the prompts based on the types of issues and fixes I want to review that day. You want to mix it up to best leverage the stochastic nature of the large language models. I review the generated issues locally and then preserve the good ones on GitHub to keep track of them.

Over the weekend the issue queue resulting from prompts across Claude, Codex, and Grok looked like this:

Then, I spend the rest of the day having agents fix the issues and reviewing their changes.

You can turn the open source flywheel with agents instead of users! This really accelerates the open source process. DoltLite is way farther ahead in five months than it would have been without agents finding issues, even though there are also real human users turning the flywheel.

Conclusion#

Agents are speeding up the open source flywheel. DoltLite after five months is where Dolt was after 3 years. Part of this acceleration is agents finding issues as if they were users. All that said, DoltLite still needs real users. Interested? Come by our Discord. Meet me in the #doltlite🪶 channel.