I have, mostly, long running autonomous tasks, so it doesn't matter how slow inference is. If I optimize for latency it means I'm turning into the limiting factor.
How would you prevent a junior engineer doing this mistake? Presumably, you would setup a lint rule. Do the same for LLMs. Run the linter after each edit through a hook, give feedback to the LLM. Write your lint rules with clear explanations of why the behavior is a problem, and nudges to the good behavior.
That's not a hack, if you operate the entity from Germany, it must be registered in Germany. It's often touted as a tax loophole, but it's not. Tax authorities do not care about you unless you actually make money, then they will come after you.
You don't need business plans and all that stuff. The problem in Germany for instance is that a GmbH needs 25k of capital + expensive notarization. These are the only two things that need improvement.
I use the same motion to iterate on linter config and hooks (both claude code hooks and git hooks). So guardrails are actually enforced and iterated upon and do not clutter the context.
> But if it's so obvious, why aren't other developers rolling out their own PKMS? Perhaps I'm the first to discover this or perhaps developers aren't writing about their custom PKMS. My guess is that commercial note-taking apps have larger, more vocal communities that drown out the murmurings of other DIY solutions.