Alexander Arvidsson

You can delete a post. You can unpublish an article. You can invoke GDPR and demand erasure. What you cannot do is remove something from an LLM. Once data dissolves into billions of model weights, there’s no row to delete, no file to erase. And it gets worse: the models now training on AI-generated outputs are degrading with each generation, narrowing toward a statistical echo of themselves. The right to be forgotten has no technical implementation path. None.

Goodhart’s Law - when a measure becomes a target, it ceases to be a good measure - is quietly undermining data strategies everywhere. Support tickets get closed without being solved. Active users log in and leave. Velocity numbers climb while codebases rot. The problem isn’t bad metrics; it’s the assumption that better metrics fix the underlying issue. The real question to ask before deploying any KPI: if we optimize for this, what will break?

AI tools force knowledge workers into constant task-switching that neuroscience proves is cognitively expensive. Only 2.5% of people can effectively multitask, yet we’re asking everyone to perform like fighter pilots without selection or training. Berkeley researchers found workers experienced burnout as managers consumed efficiency gains with increased assignments—repeating the Jevons Paradox from the telegraph and typewriter eras. Organizations measure output volume while ignoring cognitive sustainability, creating hidden supervisory labor that extracts maximum throughput regardless of cost.

I’m in Redmond this week for the Microsoft MVP Summit - 4000 MVPs, 83 buildings across 500 acres, and not a single roadmap leak to share. The summit is NDA-covered, but that was never the point anyway. The most valuable thing you can do here isn’t sit in a preview session. It’s finding the engineer whose documentation you’ve been reading for years, buy them a terrible American coffee, and ask the question that doesn’t fit in a support ticket.

Non-determinism in LLMs isn’t a bug to fix - it’s a parameter to control. But most teams are tuning the wrong things: obsessing over temperature settings while ignoring the architectural choices that actually matter. Structured outputs, deterministic skills for calculations, plan-then-execute agent patterns, retrieval logging - these are what separate systems you can trust from ones that roll dice in production. The goal was never a deterministic LLM. It was knowing exactly where randomness is allowed to live.

Power BI User Days in Utrecht has something most events don’t - soul. But beyond the atmosphere, something more interesting is happening: attendees are no longer asking how to build things. They’re asking why, and when, and whether. A maturing community, combined with LLMs absorbing the basic how-to questions, is shifting the conversation toward applied thinking. It’s the shift I’ve been waiting for. Utrecht suggests the appetite is finally there.

For every hour on stage, a hundred hours of preparation. That ratio stopped feeling like a personal failing when the blog became part of the process — not as a publishing platform, but as a thinking tool. A post forces the argument into shape before the slides exist. If the logic holds on the page, it’ll hold on the stage. If it doesn’t, better to find out now than in front of a sold-out room in Utrecht.

Non-determinism in LLMs creates real operational problems: flaky tests, irreproducible bugs, compliance nightmares, and unreliable agents. Most people only know about token sampling, but randomness creeps in across six distinct layers—from floating-point variance to hidden system prompts. Temperature=0 and random seeds help less than you’d hope because they constrain token selection, not reasoning paths. The solution requires structural constraints, not parameter tuning. Until then, you’re rolling dice in production.