What makes Basic Memory unique isn’t just its technical architecture - it emerged from and enables a new kind of development process. While many use AI for code generation or problem-solving, we’ve discovered something more powerful: real collaborative development between humans and AI.
The Basic Memory project itself demonstrates this collaborative approach. Nearly entire codebase was written via pair programming between a human and LLM, Claude, primily using MCP tools via the Claude Desktop app. The flow goes something like this:
- Have some conversation about a problem to solve or feature to implement. Exchnage ideas, sketch up an initial approach
- AI (Claude) writes initial implementations and tests
- Human (me) reviews, runs, tests, and commits code
- Knowledge persists across conversations via writing notes about design, code artifacts (We use Basic Memory to write Basic Memory)
- Development continues seamlessly even across different AI instances
- Results improve through iterative collaboration
This isn’t just a theoretical process - it’s how we actually built the system. The codebase wasn’t created by an AI generating code at my request, nor was it built by me using AI as a reference tool. It wasn’t vibe coding. Instead, it emerged through genuine collaboration where both sides contributed their strengths to the project.
The process is really very similar to how I would work as a lead or principal engineer with other software engineers:
- We chat, write some loose designs (I jokingly call these “napkin drawings”) to convey ideas.
- Then the developer submits a PR, which the team reviews asynchronously.
- Even though “I” didn’t write the code, I’m still responsible for reading it, reviewing it and understanding it thoroughly.
- If I see a problem or have a question, I give feedback
- Eventually people pick up on shared styles, patterns and a common set of patterns and “domain language” emerges within the system.
Notably the process follows the same tried and true software engineering practices used throughout my career:
- Start small, change one thing at a time
- Test early, test often. We aim for 100% test coverage
- Use feature branches for new code, merge the branch when the feature is complete
- Document designs via design documents. We have a large “specs” folder with past and future feature designs
- Use CI/CD to automate all flows, build, test, release
- Practice TDD (Test Driven Design). This, in particular, is much easier with AI because it can do the chore work of writing tests.
- Don’t be afraid of refactoring and removing code. If code isn’t useful, it’s in the way.
This approach differs fundamentally from “shallow” AI-assisted development. It’s not about:
- Using AI to generate standalone code snippets
- Asking for solutions to isolated problems
- Treating AI as a search engine or reference library
- Giving vague instructions and prompting the LLM to fix any problems via copy/paste
- Shipping throwaway code
Instead, it’s about:
- True collaborative development with shared context
- Persistent knowledge across multiple sessions
- Seamless context switching between AI instances
- Iterative improvement through shared understanding
- Building complex systems through sustained collaboration
Having an AI collaborator who:
- Remembers all technical discussions
- Can reference any previous decision
- Writes consistent, well-documented code
- Maintains context across sessions
- Works at human speed but with machine precision
It creates something different than traditional development. It’s like having a team of senior developers who:
- Never forget project details
- Always write clear documentation
- Maintain perfect consistency
- Are available 24/7
- Learn and adapt from every interaction
The breakthrough is turning automated assistance into true collaboration:
- AI isn’t just a tool, it can be a development partner
- Knowledge builds naturally through use
- Context persists across all interactions
- Work continues seamlessly across sessions
- Development becomes genuinely collaborative
The result is that as a solo developer, I’m able to take on entire categories of projects and problems I would not have even contemplated before.
Here’s what a typical interaction looks like:
Me: Let's implement the knowledge graph synchronization
Claude: Based on our previous discussions about bidirectional sync, I think we should start with the file scanner component. Here's a proposed implementation:
[Code implementation]
This follows the pattern we established with the entity repository, but adds the checksumming functionality we discussed last week.
Me: Looks good, but I'm concerned about the atomic file operations.
Claude: Good point. Looking at our existing codebase, we're handling atomic operations in the repository layer. Let me revise...
[Updated implementation]
Me: Perfect. I'll run the tests and commit this version.
Claude: Great. For the next piece, we should consider implementing the relation synchronization. Would you like me to sketch out that component?
This approach has implications far beyond just our project - it’s a new model for how humans and AI can work together to build complex systems.
This collaborative model transforms the experience of development:
- From Solo to Collaborative
- Traditional: Developer alone with problems
- New: Continuous collaborative problem-solving
- From Linear to Exploratory
- Traditional: Constrained by individual knowledge
- New: Free to explore broader solution spaces
- From Draining to Energizing
- Traditional: High cognitive load
- New: Shared intellectual adventure
The real potential isn’t in AI replacing developers or merely assisting them - it’s in creating a fundamentally new kind of development partnership where each party brings their unique strengths to the table.
In the next part of this series, we’ll dive into the specific technical patterns and processes that make this collaborative approach work in practice.
Want to explore Basic Memory for yourself? Check out our GitHub repository to get started.