BrainDrive Updates — How We’re Designing the Update System
Today’s dev call (Dave W, Dave J, Nav) included a deep design conversation about how BrainDrive will handle updates for users. This is one of those features where the AI-first architecture makes a huge difference compared to traditional software — so we wanted to share the thinking.
Watch the Discussion
The Problem
BrainDrive is iterating fast. Users install via Docker and have no way to know a new version exists. Worse, many of our new features ship as file updates (to-do lists, digest, new AGENT.md templates) — not just code. Without a migration system, existing users miss new features entirely.
The Core Insight: Two Types of Updates
We landed on separating updates into two categories:
- Code updates (Docker image, backend, frontend) — these just push through. No user customization to conflict with.
- File/onboarding updates (library files, instructions, starter pack content) — these go through an AI-mediated review. The AI compares what you have now vs. what’s new, identifies conflicts with your customizations, and walks you through the options.
This matters because BrainDrive’s files are self-evolving — the AI and the owner both modify them over time. Blindly overwriting would destroy customizations people have made.
How It Works
When there’s an update, a small indicator appears in the sidebar. Click it, and you’re talking to BrainDrive Plus One (your AI) about the update. The AI reads a migration manifest that ships with each new version and does an impact analysis against your current setup:
- “The to-do update is clean — no conflicts.”
- “The AGENT.md change adds one line. Your other customizations are unaffected.”
- “The interview prompt has been rewritten, but you’ve modified yours — here’s what’s different.”
You can accept all (most people will do this), go piece by piece, or skip everything. Declined updates are remembered — you won’t be nagged.
The Design Principle That Simplifies Everything
The key insight from the call: the AI only needs current state vs. new state. No change history. No tracking 80 intermediate diffs. Just: what exists in your BrainDrive now, and what’s the update bringing? The AI does a fresh comparison every time.
Dave W put it simply: “If I told you to update my BrainDrive, you wouldn’t go look through 80 changes. You’d look at what I have now, look at what’s new, and make the update.”
This is what makes the system tractable. We’re not building a version control system — we’re leveraging the AI’s ability to understand context and resolve conflicts intelligently.
Smart Re-surfacing
One nuance: if you decline the to-do feature today, and six months later you’re trying to use something that depends on it, the AI should say: “I know you passed on to-dos, but the calendar feature you’re interested in builds on it. Want to revisit?” Not nagging — context-aware guidance.
What’s Next
Dave W is finalizing the spec and UX design. Dave J implements. The update system is launch priority #2 (after BrainDrive Models), but since texting is nearly done, Dave J will finish that first.
This is part of our building-in-public series. We review every dev call transcript against our specs to catch gaps and keep docs in sync — this session found 5 improvements to apply.
