Cursor for Everything

Source: DoltHub Blog
Author: DoltHub team
Date: 2025-11-19
Ingested: 2026-06-03

Summary

DoltHub argues that Cursor's success in the IDE market — combining a familiar UI with an LLM chat window and version control — can be replicated across any application. The key insight: LLMs make mistakes, and version control (diff + rollback) is the safety net that makes agentic writes trustworthy. They propose Dolt (a version-controlled SQL database) as the backend that enables this pattern for any database-backed application.

Key Ideas

1. Cursor's Victory Formula

Cursor succeeded not by inventing a new UI, but by forking VS Code (familiar) and adding a chat window on the right. Developers didn't need to learn anything new. The chat panel connects to an LLM with tool access to the codebase. Version control (Git) provides the safety net — you can see what the LLM changed and roll back if needed.

Agent mode extends this: instead of prompt/response, the LLM loops on output until a goal is achieved, performing multiple steps autonomously.

2. "Chat on the Side" as Universal UI Pattern

The "chat on the side" interface is becoming the default for adding LLMs to applications:

  • App Builders (Vercel v0, Replit, Lovable): chat on left, built app on right
  • Google Apps: suggesting actions in a side panel
  • Gauntlet AI / Marin Software: performance marketing app with LLM chat on right
  • Any service-oriented application: existing UI on left, chat panel on right

3. The 5-Step Recipe

To build "Cursor for Everything":

  1. Add a chat panel to your UI — can even use vibe coding tools like Cursor itself
  2. Connect the chat panel to an LLM — use OpenAI/Anthropic APIs, include app context for better responses
  3. Expose your application's API to the LLM as tools — use MCP (Model Context Protocol) standard
  4. Migrate your backend database to Dolt — MySQL or Postgres compatible, drop-in replacement
  5. Use Dolt primitives to expose version control functionality — branches, commits, diffs, merges as SQL procedures

4. The Problem: LLMs Make Mistakes

Google Sheets + Gemini example:
- Asked Gemini to create a sheet of US Presidents → worked
- Asked Gemini to remove "Thomas Jefferson" → it deleted ALL data
- No diff view to see what changed
- Cmd+Z (undo) didn't work — Gemini's interface isn't hooked into the undo system
- Had to ask the LLM to put the data back

Root cause: No version control underneath. Without diff and rollback, LLM writes are untrustworthy.

5. Dolt as the Agentic Database

Dolt provides Git-like version control for SQL databases:

  • Branches — work in isolation
  • Commits — permanent markers in version history
  • Diffs — queryable like tables (full SQL power for bespoke diff UIs)
  • Merges — with sophisticated conflict detection
  • All exposed as SQL procedures and functions — no new APIs to learn

6. Branch-Aware Writes

The critical design pattern for agentic applications:

  • LLMs should only write on branches, never on main
  • User reviews the diff before merging
  • If user likes changes → merge to main
  • If user doesn't like changes → delete branch, show main
  • Conflict detection prevents LLM from stomping real user changes

7. MCP (Model Context Protocol)

The standard for exposing application APIs as LLM tools. Similar to REST/GraphQL/gRPC but designed for LLM consumption. Enables the LLM to take actions on the user's behalf within the application.

Relevance to Dark Factory

This article provides the architectural blueprint for version-controlled agentic writes in any application. Key parallels to factory operations:

  • Branch-aware writes = agents work on branches, humans review before merge (same as factory gates)
  • Diff + rollback = safety net for LLM mistakes (same as RALPH retry protocol)
  • MCP tools = standardized way to expose application capabilities to LLMs
  • Familiar UI + chat = the "chat on the side" pattern mirrors the factory's human-in-the-loop design

The Dolt-as-database pattern is directly applicable to any factory pipeline where agents write to databases and humans need to review changes before they go live.