The boring 20% that made it stick
- Why LLMKIT: sharing what works across five stacks
- Context is the hard part
- The fourth and fifth stack
- The boring 20% that made it stick
- One view across Claude Code, Codex and Copilot
- Copy, never move
- Normalize once, at the end
- Windows 11, and an honest scorecard
- Shippable, with findings
- Mirror, don't ask
- A name isn't enough
- A footer means it finished
Getting LLMKIT actually adopted — not just built — taught me that the unglamorous parts matter as much as the core system.
Three examples
A Teams notification system. The whole team hears about kit installs, updates and releases as they happen, without me manually pinging anyone. Nobody has to wonder whether they’re on the current version or what changed.
A simple, editable config for what gets announced. Changing what the notifications say, or which events trigger them, doesn’t require touching code. That keeps the announcements current, because updating them is cheap.
Real thought about the day-to-day developer experience — beyond “does it install.” What it feels like to pick up an update, how visible changes are, and whether anything in the engineer’s normal workflow gets disrupted.
Why none of this shows up in a demo
A demo shows the core system working once. None of the parts above make a demo more impressive. All of them are why LLMKIT is something people keep using, rather than something they used once.
The lesson
If there’s one lesson from this stretch, it’s that developer tooling lives or dies on the boring 20%:
- Visibility — people know what changed and when.
- Ease of updates — staying current costs nothing.
- Trust — it won’t break your workflow on a day you can’t afford it.