Somewhat recently we changed our slogan.

Our old slogan:

Our new slogan:

As a result of this change, we sometimes get people asking us questions like:

• Is DoltHub an AI company now?
• Is Dolt an AI application?
• Does Dolt primarily exist for AI?
• Is Dolt “vibe-coded”?

In order to put any confusion to rest, we want to be transparent about the ways we use AI and the ways we don’t.

Where We Started#

We first released Dolt, the first version-controlled SQL database, all the way back in 2019. This was long before the modern LLM trend, and long before agentic coding came onto the scene. That alone should make it pretty clear that Dolt is not itself AI, was not created for AI, and had no AI involved in its design. Dolt came about because Tim and Aaron discovered Noms and realized the potential of a version-controlled database with structural sharing. We believe Dolt provides value in a wide variety of software domains.

The first time we acknowledged LLMs was in April of 2023, when we added a hidden command to let ChatGPT write your SQL queries. It was a real feature, but it wasn’t very reliable and we knew that. We added this feature mostly because we thought it was amusing, but also as an excuse to try and understand the at-the-time capabilities of LLMs.

That was only three years ago, and the software dev space has radically transformed since. We want to meet users where they’re at, and recently many of our users have use cases related to Agentic AI. It turns out that Dolt branches provide an elegant solution for isolating, reviewing, and merging or rolling back changes, something that AI agents struggle with. So we made our slogans and marketing reflect that shift. But we still believe that Dolt has wide applicability. It isn’t “an AI tool” as much as “a tool useful for AI (but not limited to AI)”.

Our AI Policy#

Given that many of our users are explicitly interested in using Dolt in conjunction with Agentic AI, we consider it important to understand the strengths and limitations of AI so that we can provide useful guidance about the ways that Dolt can help them. In order to gain this understanding, we sometimes experiment with the same AI coding agents as our users.

We believe that transparency is important, so we’ve outlined our policy below to explain how each of our projects is (or isn’t) affected by AI, and our different projects have different policies.

Our Blog Posts#

We don’t use LLMs for our blog posts. We may use generative AI for link preview images, but the written content of our articles always comes from us.

The reason why is simple: We don’t believe in wasting your time with blog spam.

We write a lot of blogs because we want to get ourselves out there. But everything we write is something that someone at DoltHub wanted to write because they believed was worth writing.

Blog posts are also one the main ways we communicate with users. If we replaced that with a machine, then there wouldn’t actually be any communication. Using an LLM to write a blog post would mean that we were publishing a post for the sake of publishing a post, writing empty words to meet a quota. Frankly, blogs like that don’t need to exist, we don’t want to write them, and you shouldn’t have to read them. It’s a huge waste of everyone’s time.

Last year, we tried an experiment. The goal was to document an attempt to produce an LLM-generated article about Dolt. The plan was to publish a post about that process, including the clearly-labeled generated text alongside human commentary. It never materialized because everything we generated was completely unusable.

It’s possible that at some point in the future, we attempt this experiment again in order to see how the technology has evolved. If we do, the approach will be the same: anything created by an LLM will be clearly labeled, with commentary, framed in context of our attempts to understand the state of the technology. We think that unfiltered human perspective is critical.

Our Traditional Code Projects (Dolt, DoltLab, Doltgres)#

We’ve learned a lot from the last 7 years of working on Dolt and Doltgres. We spend a lot of effort ensuring that these projects are human-readable, human-maintainable, and reflective of our deliberate designs. We have no intention of ever jeopardizing that.

Currently, we accept LLM-assisted PRs for these projects, although we understand why other project maintainers don’t. And as stated above, we occasionally use agentic AI to draft our own PRs, in order to better understand their real-world benefits and limitations. But every PR, regardless of whether or not it used AI, is manually reviewed by the same team of DoltHub developers that have been developing Dolt for years, and we hold all PRs to the same standard:

• All PRs must pass our comprehensive suite of integration tests.
• PRs must have intentional descriptions that match our release notes style.
• Any new features must have comprehensive testing and these tests must be human-readable.
• We require authors to be able to explain and justify design decisions made in their code. This ensures that every PR is a conversation between two real people who understand the systems being modified.

If a PR doesn’t meet those standards, we don’t merge it. Basically, PRs should reflect the best efforts of the author. This keeps our code readable, maintainable, and high-quality, regardless of its source.

Our Write-Only Projects (DoltLite, Dumbo)#

“Write-only code” is a term coined by Heavybit investor Joe Ruscio and Waldemar Hummer of Localstack, and it’s exactly what it sounds like: code that is not intended to be reviewed, maintained, or even read by a human being. It just needs to work. Write-only code can heavily leverage LLMs because the bar for code style or quality is much lower.

Our two newer projects, DoltLite and Dumbo, are both projects that rely on the pre-existing corpus of Dolt code. Much of DoltLite’s functionality is a port of code from Dolt, and Dumbo uses Dolt as a library dependency. Since LLMs would be able to leverage our existing code as context, we expected that both projects would be uniquely amenable to the write-only code approach and decided to try it as an experiment.

This means that code in these projects doesn’t have the same maintainability requirements as traditional projects. Instead we made the deliberate decision to prioritize correctness and developer velocity over anything else.

These projects still have stringent testing requirements. If anything, comprehensive test coverage is more important here. Write-only projects are test-driven development in its purest form: you define the requirements, and when it finishes, you get something that satisfies those requirements. If it has holes, it’s probably because your requirements have holes.

Fortunately, the fact that DoltLite and Dumbo rely on our existing code also means that we get to start with lots of comprehensive parity tests. Dolt and its tests are oracles that DoltLite and Dumbo can be compared against.

In order to do write-only coding well, you still need to understand the domain you’re working in inside and out. Given that SQLite support was one of our most requested large features, we knew that if we didn’t do it ourselves soon, someone else would. And if anyone was going to try to vibe-code DoltLite, it should be us.

The downsides of this approach are obvious. Code that cannot feasibly be maintained by humans has an inherent shelf-life. Our CEO Tim openly admitted that at some point, we’re probably going to have to rewrite DoltLite as a traditional:

At some point, I’m probably going to have to read the Vibe Code and understand it. At that point, I’m back in Trad Code, working off a possibly shaky foundation. […] Potentially, I’ll have to throw away the Vibe Code and make a better solution with Trad Code from scratch. My guess is the Vibe Code to Trad Code hand off will come on the order of months, maybe a year, if DoltLite becomes popular.

But there’s also an undeniable temptation to write-only coding, because developer velocity for a fresh write-only project is kind of obscene. Our engineer co-founder Aaron assessed that to reproduce the first week of DoltLite’s development with traditional code, he would need a dedicated team working for 3-6 months.

We’ve been very impressed with how quickly we’ve been able to iterate on DoltLite, but we also know that code of its caliber should never touch the original Dolt repo with a ten-foot pole. There must be a barrier between the two.

From our vantage point, there’s no point in blending these approaches. If you start blindly committing LLM-generated code to a trad-coded project without proper human review, you stomp all over your carefully crafted design decisions. And if you start manually reviewing a vibe-coded project, you go mad.

Conclusion#

We’re always experimenting to better understand new tools and new approaches to software development. But we’re also committed to being pragmatic and levelheaded. We don’t give in to hype. If we think something is overblown, we don’t hold back, like when we wrote about the state of agentic coding a year ago.

It’s also true that our newer blogs have, on average, been less critical than that one. That’s because the technology is evolving at a pace that can be honestly scary. And that fear and the hype make it all the more important for us to understand what we’re dealing with. And why it’s important for us to share that understanding with our audience.

If you have any questions about our AI policy or our philosophy toward AI in general, you should always feel free to join our Discord and ask us directly.