I wanted an AI assistant that understands my taste, not just my prompt.
Generic assistants are useful, but they start cold. They do not know how I review code, how I write technical posts, what I consider risky, or which tradeoffs I usually make. So I built a local-first "brain" that learns from my own work history and turns that into reusable guidance for coding, writing, reviews, and project memory.
The goal is simple: better defaults.
Not automation for automation's sake. Not a replacement for judgment. Just a way to make the assistant start closer to how I already think.
The system harvests signals from my own work:
- GitHub PRs, issues, and review comments
- Technical blog posts
- Sent emails
- Work chat messages
- Project tickets and notes
- Internal project learnings
- Code review discussions
Each signal is stored with source, type, timestamp, context, and optionally an embedding for search.
The raw data stays local. The useful part is not the raw archive. The useful part is the distilled layer built on top of it.
The current local brain has roughly:
- 15k raw persona signals
- 3.5k distilled traits and review patterns
- 2.2k knowledge entries
- 20k+ evidence instances behind the distilled traits
- 4.8k code review and PR discussion signals from a private work corpus
- 1.8k distilled code review patterns
- 57 technical blog posts analyzed for writing style
Signal sources are roughly:
- 7.1k GitHub signals
- 6.3k work chat signals
- 1.2k sent email signals
- 300 project ticket signals
- 57 blog post signals
The code review corpus is categorized roughly as:
- 590 correctness patterns
- 565 simplicity patterns
- 314 process patterns
- 168 performance patterns
- 127 framework idiom patterns
- 33 style-nit patterns
The review patterns are split across:
- patterns from reviews I gave
- patterns from reviews I received
- peer discussion patterns
- resolved tradeoff discussions
I keep private company names, repo names, reviewer names, raw comments, internal paths, server details, and credentials out of public summaries like this.
The system does not just store messages. It distills them.
Signals are batched and analyzed into traits:
- tone
- writing style
- technical expertise
- recurring topics
- opinions
- working relationships
For example, repeated evidence might turn into traits like:
- direct and pragmatic communication
- concise technical explanations
- preference for minimal dependencies
- strong verification discipline
- risk-aware delivery
- bias toward boring, maintainable code
- practical Rails and API design judgment
Each trait keeps an evidence count and confidence. That matters because a one-off comment should not become a "personality trait." Repetition is the signal.
The most useful part so far is the code review brain.
Past PR comments are converted into reusable review patterns. The patterns are grouped into review axes:
- correctness
- simplicity
- performance
- process
- framework idioms
- style nits
That lets an assistant review a new diff with my review habits in mind.
Instead of only saying "this could be cleaner," it can look for things I repeatedly care about:
- Does the code match the domain semantics?
- Are authorization and multi-tenant boundaries preserved?
- Is there a risky migration or deploy path?
- Did the change add behavior without focused tests?
- Is an abstraction paying rent?
- Is a dependency avoidable?
- Is a hot path doing unnecessary work?
- Is the PR description missing risk or verification context?
The point is not to enforce every preference as a hard rule. Some things are correctness issues. Some are process gaps. Some are just nits. The review brain keeps that distinction.
That makes the output more useful than a generic lint pass.
The writing side learns from my technical posts.
It looks at structure, pacing, examples, and repeated patterns. For technical blogs, the guide it produces prefers:
- opening with the concrete problem or feature
- naming the exact API, version, or behavior
- showing the old way first
- showing the new way with copy-pasteable code
- using short paragraphs
- ending with a useful reference link
This is especially helpful for framework posts.
Bad generic draft:
In today's fast-paced development landscape, developers need robust solutions...
Better draft:
Rails now supports X, which removes the need for Y.
Then show the old code. Show the new code. Explain the tradeoff. Link to the PR or docs.
That shape is much closer to how I prefer technical writing to work.
Commit history is useful, but raw commit messages are not always the strongest source.
The stronger signals usually come from the context around commits:
- PR descriptions
- review comments
- issue discussions
- shipped change notes
- verification records
- follow-up fixes
Those show not just what changed, but why it changed and what risks mattered.
Direct commit-message ingestion can be added, but I would still weight PRs, reviews, and resolved discussions more heavily. They contain more judgment.
The brain supports semantic and keyword search across local knowledge.
That means I can ask questions like:
What are my strongest coding opinions?
or:
How do I usually explain Rails upgrade work?
or:
What patterns should I check before shipping this PR?
The assistant can then answer from prior signals instead of guessing from a blank context window.
This setup helps in a few concrete ways.
For code review:
- catches recurring risks earlier
- keeps feedback closer to my standards
- separates blockers from nits
- reminds me to ask for verification evidence
For coding:
- prefers small, practical changes
- avoids unnecessary dependencies
- follows existing framework conventions
- pushes for focused tests before broad test runs
For writing:
- avoids generic AI phrasing
- keeps technical posts concrete
- uses examples instead of abstractions
- preserves my usual direct tone
For project memory:
- remembers decisions across sessions
- stores useful patterns once
- makes previous lessons searchable
- gives future assistants better context
I do not want the assistant to become overconfident.
The rules are:
- Do not fake verification.
- Do not claim a test passed unless it actually ran.
- Do not invent persona traits without evidence.
- Do not expose private raw data.
- Do not turn style preferences into fake correctness issues.
The brain improves defaults. It does not remove responsibility.
Local-first is important for this kind of system.
The source material includes private work communication, PR comments, and project context. That should not be casually sent around or pasted into prompts.
The public-safe version is the distilled idea:
- harvest my own signals
- store them locally
- distill repeated patterns
- retrieve relevant guidance when needed
- keep private data private
That is enough to make the assistant much more useful without turning private history into public training data.
The best AI assistant is not the one with the biggest prompt.
It is the one with the best defaults.
For me, that means an assistant that knows:
- I care about correctness first
- I prefer boring, maintainable code
- I want verification before confidence
- I like direct writing
- I value concrete examples
- I would rather remove a dependency than add one casually
That is what this local brain gives me.
Not magic. Just memory, evidence, and better starting points.