Built a claude code plugin for non-technical people called Techie
By default, cc assumes you're technical and there to code. Techie assumes you're *non-technical* (but smart) and want to get more from AI
One command installs everything, plain English after that. Same compound memory without the jargon and complexity
I had them both introduce themselves ↓
(left = default, right = with Techie)
Model, effort, context, time – people treat AI setup like four dials to tune. It's really one question and two levers.
The question: how much *reasoning* does the task need? That sets the two levers: model and effort
Context should always be the minimum that's fully sufficient, nothing more. And if *time* ever feels like a factor, that's a sign your context needs work
Every rule I'd added to stop Claude's 'customer context' notes turning into a mess already had a name in data engineering. I just didn't notice until I went back over them:
- One file owns each fact → primary key + source of truth
- Don't repeat a fact, link to it → normalisation
- Phrases it's not allowed to write → validation constraints
- 300-line cap, old detail ages out → lifecycle management
- Context starts lean, grows into its own files → schema evolution
- Read it back cold, does it still help? → data quality check
I didn't think "primary key" when I wrote the rule. Just "this keeps contradicting itself". Same instinct one layer up
Context engineering is data engineering basically
Claude code: if you've been using /simplify (I use all the time), it's now /code-review
And you can now pass an effort argument e.g. `/code-review high`
(You can even pass --comment to post findings as inline github pr comments)
The strongest agent setups don't run one big agent. They hand off through documents
A reference doc holds the stable contract (components, constraints, what good looks like). A spec is the per-task goal. Two narrow agents read both – one writes the spec, the next builds it
One agent holding everything in its head bloats context and makes worse calls. Scope down and let documents carry the state
Claude code: when to background a session, when to stay interactive
Heuristic that's working for me: would you trust a colleague to do this from a Slack message alone? No follow-up questions, no shared whiteboard
If no → don't background. Plan interactively first, hand off the result
Three patterns fall out of it:
- Background from start: well-specified ticket + mechanical done
- Interactive then background: plan needs collaboration, execution is mechanical once decided
- Interactive throughout: the conversation *is* the work (strategy, exploration)
Background agents are like colleagues working async. Interactive sessions are sitting next to you
Someone called my AI agent setup "amazing but quite daunting"
It's not complexity that makes a setup look impossible, it's maturity. Mine is a folder of markdown files an agent reads like anyone else. It's just had 10 months of catching contradictions and gaps
The structure is what you arrive at, not what you design. Start simple and don't abandon it when it gets messy
Claude code: /btw <question> asks something without it entering the conversation history
Took me a second to see the use case – it's the clean replacement for ask-then-/rewind
A clarifying aside normally costs context: the question and the answer sit in the transcript until you rewind them back out. Whereas /btw never records the turn so nothing to roll back
Mature AI setups look complicated from the outside. Conceptually they're the same as anyone's – folders, markdown files and an AI that reads them
The actual dimension is maturity: of your context, of your workflows. When you start there are inaccuracies, contradictions and gaps everywhere
Catching and fixing them is the discipline. Just start
Most second-brain setups drift over time. Smarter folder structures don't fix it
What does: a governing doc per domain. Mine for account management defines: hub-and-spoke layout (current-state hub + foundational spokes, all linked, not duplicated), target sizes per file, migration triggers when sections bloat
Code projects get a different one (memory bank framework). Strategy docs don't need an extra layer
Drift = two files quietly disagreeing 6 months later. The right governing doc catches it
Every 'new' AI agent problem is an old data engineering problem with new branding
Speaker attribution = identity stitching
Context bloat = schema design
Agents losing track between sessions = stateless systems
Each one was solved decades ago. Each one is being re-solved from scratch by AI vendors who haven't read the back catalogue
Build Notes issue #6 out
5 discoveries this week:
- Opus 4.7 less forgiving than 4.6 (yesterday's tweet)
- The map is lean, the terrain is dense
- Don't codify workarounds for temp tool issues
- Replaced Granola in 2 hours
- The audit that went sideways
+ 3 things on my radar