I've been building Tribal, a memory system that stores tacit engineering knowledge as you work and makes it queryable across your team.
My taste for hyper-configurable systems comes from a previous job, where bank operators configured the system in Python themselves.
I brought that instinct to my own project; when sketching the first config schema, I reflexively made the embedding model as configurable as the inference model. In a config file, they look like the same kind of setting.
They are not the same thing.
Swap your inference model and nothing you've already stored notices. Swap your embedding model and none of it can be searched until every last record is rebuilt.
The new post is about that gap: how a small promise about a system's behaviour can cost far more to keep than it did to make.
Keeping this one meant implementing zero-downtime migration - rebuilding everything underneath a live system without anyone feeling it shift
Follow for more articles like this one
@DanielSmidstrup The doorman fallacy - AI replaces tasks not jobs
Hiring juniors is a great way to mold seniors who deeply understand the problems that matter to your organisation
@0xV0LYX@omarsar0 I wonder about this; eventually it'll be useful to share or consolidate memories - if they all create their own schema on the fly, it would be difficult to share learnings
I'd lean toward a standard, however loose
@omarsar0 Absolutely; was thinking about this the other day; how would one decide which memories are worth keeping over time?
Parsing a transcript, or instance, a financial system may focus on financial data, ignoring other details - same wouldn't be said about a lead qualification system
Since then, comments have been far leaner and the review loops go on far longer without my intervention, all whilst maintaining my personal code quality bar.
That's it; that's the post 🥂
Anyone do anything similar?
It occurred to me I could lean on good old code quality techniques here, so eventually I added this:
"The urge to write or lengthen a comment is a signal to try the code first: rename the value so the meaning rides the name, extract the block into a function whose name carries the why, lift the invariant into a type or an assertion.
"Prose is the fallback for what code structurally cannot say: the outside constraint, the non-obvious why, never a patch over a name that failed to say it.
"A comment that grows under review is the sharpest case: each round's added explanation is a fact looking for a home in the code, and the comment should shrink as the code absorbs it, never lengthen to defend it."