theory extension and construction is what knowledge work will become.
we see the shift towards specification construction with AI bots. This is something they are *not* good at. They're great at boilerplate english and work fantastically well when given a proper theory to work from. but novelty, not so much!
software engineering will become *harder*. code is easy so engineering discipline matters more. know the lanugage specs, know the corner cases, know your domain. know how to speak 1-1 with real people in your domain
practice will be necessary to keep your skills sharp
i deeply trust my sister, but she may not be competent at a job i need done. trust / competence misalignment. hard to solve
open ledger helps. we can see pre-existing economic interactions. on-going interactions between trusted entities provide little signal. but strangers interacting and yielding economic returns (or not) is a strong signal about the relationship.
neomutt if you wante email in the terminal. no recos for mp3s, but ncspot is useful if you have spotify. the 'm' key for recommendations is fantabulous.
Claude wrote some code to unfreeze a 'teacher' NN feeding into an LLM. It added an auxiliary loss instead of relying on the gradient signal directly from the LLM. I though "that's interesting" and kept it. Now 3 days of training and compute got flushed. All because I vibed. There is something about being principled when working with code that is consequential. Maybe all code.
Then again. I learned something didn't work. That's a plus!
It's an older paper, but it checks out. I wanted to use this to force a 'poor mans' contrastive loss over tokens in an LLM's output. But I'm not sure if it's even worth investigating.
I meant this paper: https://arxiv.org/abs/2504.13837 instead. Though that other paper is very relevant as it talks about improving the sampling efficiency.