The online whiteboard of Kristofer Palmvik
I’ve come to the conclusion though that what people call “pairing” with an LLM is more the illusion of pairing than the real thing. Ultimately, it’s more of a siren than an active collaborator. It’s nothing but your thoughts, reflected back off of a bazillion vectors. That’s not to say it’s necessarily a bad thing, but it’s not the same thing.
Over time, the flywheel produces something that's hard to replicate: structured organisational context. Not a wiki that nobody reads. Not documentation that's perpetually out of date. Living, tested, versioned context that coding agents actively consume and that humans actively maintain. Knowledge that shows up directly in the quality and consistency of every line of code your agents produce.
My personal conclusion can however not end up with anything else than that the big hype around this model so far was primarily marketing. I see no evidence that this setup finds issues to any particular higher or more advanced degree than the other tools have done before Mythos. Maybe this model is a little bit better, but even if it is, it is not better to a degree that seems to make a significant dent in code analyzing.
Standards were supposed to eliminate browser-specific code. We dug ourselves out of the IE era, celebrated, and then built exactly the same hole again around a different browser. Only now the browser-specific code lives in the browsers that aren’t dominant, patching over a web built for the one that is. Sites I’ve worked on are in these files. Yours might be too. And the lists are getting longer.
Google Chrome is reaching into users' machines and writing a 4 GB on-device AI model file to disk without asking. The file is named weights.bin. It lives in OptGuideOnDeviceModel. It is the weights for Gemini Nano, Google's on-device LLM. Chrome did not ask. Chrome does not surface it. If the user deletes it, Chrome re-downloads it.
I’ve now seen dozens of companies struggling to put AI to work writing code, and each one has moved through five clear tiers of automation. That felt familiar, and I realized that the federal government had been there first – but for cars. In 2013, the NHTSA created the five levels of driving automation1. This was helpful, because while the highest level at the time was only level 22, it let everyone have a common language for both where things were, and where things were going.
Remote work doesn’t kill belonging. Indifferent leadership does. The office never created belonging on its own, it just made it easier to do the things that create belonging: casual conversations, shared meals, visible recognition, the spontaneous moments of human contact that accumulate into trust. If you move to remote or hybrid and don’t deliberately recreate those conditions, you haven’t gained flexibility. You’ve just moved the loneliness into people’s homes.
Although we started our MVP exploration with large generative prompts, that’s obviously not a sustainable solution in this type of context, which demands very high standards of accuracy and clear reasoning grounded in data. The solution instead became an orchestrated multi-agent pipeline with 23 specialized agents collaborating in a strictly linear chain, with built-in QA loops, access to AI tools (so-called “tools”), and rigorous data integrity and formatting rules.
The valuable part of an open source contribution was never the code. It was the understanding. Someone found a problem, understood it well enough to describe it, maybe understood the codebase well enough to propose a fix. The code was a vehicle for that understanding. Now the code is free and the understanding is what's scarce. A detailed bug report with reproduction steps and a clear description of expected versus actual behavior is worth more than ten agent-generated PRs. It always was. The gap has just gotten enormous.
The productivity gains from these models are real, and so is the friction and understanding that come from engaging with the work on a tangible and frequent basis. Despite the countless failed attempts at trying to democratize coding while not understanding coding, we're faced with the reality that you cannot understand code without engaging with it. And it's become clear that if you don't keep engaging and writing it, you can lose touch with that understanding, which will in turn make you a less capable orchestrator in the first place, rendering this phase of AI coding a strange and needlessly stressful interlude.
The PocketOS boss puts greater blame on Railway’s architecture than on the deranged AI agent for the database’s irretrievable destruction. Briefly, the cloud provider's API allows for destructive action without confirmation, it stores backups on the same volume as the source data, and “wiping a volume deletes all backups.” Crane also points out that CLI tokens have blanket permissions across environments.
Example Mapping helps you zoom in and focus on the smallest pieces of behaviour inside your story. By mapping it out you can tease apart the rules, find the core of the behaviour you want, and defer the rest until later. With this level of scrutiny, example mapping acts like a filter, preventing big fat stories from getting into your sprint and exploding with last-minute surprises three days before demo-day.
I keep asking myself: What happened to the principles that were professed a decade ago? To address climate change? To reduce racial, gender, and economic inequality? To “don’t be evil”? Were these principles abandoned, or were they merely born of convenience? Has tech always been like this? Was I just blind to it before?
Every elaborate scaffold you build to compensate for a current limitation is a bet that the limitation stays. Usually it doesn’t. By the time your workaround is battle-tested, the reason it existed is gone. Build for the model in three months, not the one today. Software engineering taught me to build abstractions that last. AI engineering is teaching me to build abstractions I can afford to lose.
Here's some rad CSS that just hit baseline between October 2025 - April 2026. At this point with the following features, the "I can't use it" vibe can shed away.
Moving to a European tech stack is a lot of work. Some of it is really fun - like testing new tools, reaching out to people to ask for advice - but it's also time consuming. How long do you invest in a tool before testing another one? What conveniences are you willing to give up to feel more comfortable about the way your data is used? You have to make that choice over and over again.
AI cannot bear responsibility. AI is not a responsible person, and it would be meaningless to speak of a tool that operates in “good faith.” Therefore, it cannot provide a responsible service, nor can responsibility be delegated to it.
Yet I don’t see the focus on people that I saw with XP and other flavors of “agile” development. It’s all about Claude, Cursor, Copilot, and other tools. True, the DORA AI Capabilities Model touches on things like psychological safety and user needs. But I don’t see the clear emphasis on people that I saw in the early days of XP.
The Swedish UX hiring market is failing both sides at the same time. The infrastructure between them was built for a different era. Nobody has rebuilt it. AI has accelerated the breakdown without fixing the underlying problem. Candidates send hundreds of applications into the void. Recruiters drown in noise they cannot convert into signal. Both sides end up performing for a system that serves neither.
Product expert John Cutler delivers a thought-provoking talk on one of the most underexamined risks of the AI boom: that the same tools promising to supercharge teams are quietly pushing people into single player mode. Using a sci-fi movie framing and cognitive science concepts like the four E’s of cognition (embodied, embedded, extended, and enactive), John makes the case that real understanding isn't something individuals bring to a room — it's something teams produce through interaction. He introduces three forms of metacognition teams need to develop in an AI-saturated environment, and offers a practical framework for knowing when to work alone versus when multiplayer sense-making is essential. A grounding counterpoint to the productivity hype, and a challenge to use AI as a catalyst for collaboration rather than a substitute for it.
Feeling productive is somewhat addictive. Listening to sped-up podcasts, getting summaries of books, letting the AI build projects for you while you are sleeping. But what is “productive” in this sense? If it didn’t need to be done from the beginning, does doing it anyway still count? Another way of thinking about this newly found efficiency is going in the opposite direction. What can you do, that the AI can’t? How you can shape a point of view that a large language model never could?
It’s not that ideas three through seven are bad, per se, but more so that they take valuable time and space away from the best ideas. Applied to story, the word ‘ideas’ could be replaced with many things. Fewer plots, but better. Fewer characters, but better. Fewer themes, but better. Fewer scenes, but better. My stories get in trouble when I try to do too much.
There are really two questions that matter when it comes to the Wait Calculation for AI: How good? And how fast? In other words, how good can this particular run of AI technology (either LLMs or their immediate successors) get in terms of human achievement; and how fast will this happen?
Imagine a world without version control. A world where there is only one version of the software. This is the latest version, and the version that runs in production. Imagine not having to struggle with merge conflicts, getting rid of your git cheat sheet and always knowing exactly what code runs in production.
Create a shareable link for your prompt and open it instantly in ChatGPT, Claude, Gemini, Grok, or Perplexity — one click, and the prompt is ready to run.
We don't know where AI is taking us. Big US tech firms want to rush into that unknown future without guardrails; the Communist Party of China wants the state to oversee that research. One version promises a hyper version of consumer capitalism; the other, a world in which the state determines what you can or can't do with this technology.
We as an industry right now, have got an amazing tool that will forever change how we develop products (and do many other things too). But we are viewing it with the same focus at productivity, cost-reduction and efficiency gain that we did before this paradigm shift. This leads us wrong; instead lets think about how we can optimize the entire value chain and create real value. Who knows, maybe the bottleneck in our process cannot be solved with faster output?
The real multiplier today is the engineer who knows how to wield agents effectively and coordinate their output toward a result the company actually cares about. That means decomposing complex problems into tasks agents can execute reliably, reviewing and directing that output with enough judgment to catch what went wrong, and owning the integration into a real system that holds up in production. It also means communicating what was built, to whom, and why it matters. Working well with others, not just technically but in the full human sense: understanding what stakeholders need, translating across the technical and non-technical divide, making your work legible to the people who depend on it. These were always important skills. They are now non-negotiable ones.
LLM-API och AI-tjänster på egen GPU-hårdvara i Sverige. Bortom Cloud Act och Schrems II — all inferens stannar hos oss.
A semantic constraint engine for Claude Code & Codex. Forces agentic communication into minimal-token lithic structures. Retain 100% technical accuracy while destroying up to 87% of output latency.
We are discovering better ways of building software and operating organizations in the age of artificial intelligence by preserving, governing, and evolving the provenance of decisions that shape our systems.
My hope (once the dust settles) is that we come out the other side with more collaboration. Instead of competing for leverage, I'm hoping individual contributors find new ways to work together. For example, what if Product Managers and Engineers did more AI-driven pair programming? The PM could focus on customer behavior and product goals. The engineer could evaluate architecture, security, and maintainability. They would iterate together in real time, using LLMs.
This rule, in its most up-to-date form is as follows: “When a meeting, or part thereof, is held under the Chatham House Rule, participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, may be revealed.” Essentially, the rule tells us that it’s ok to share information and stories from the session when we leave, but not to share who said what.
The more time I spend with coding agents, the more I become convinced that they are damn-near incompatible with working in teams. I've suggested this before, but I really think more people should be chewing on this. The bottleneck for software teams—the thing that's always made them less than the sum of their parts—is the handshake problem. It's the one thing from The Mythical Man-Month everyone remembers: "Adding manpower to a late software project makes it later."
Element utilises the decentralised Matrix open standard to create a resilient, zero trust, communications network. With no central point of failure, Element protects against global outages and ensures high availability through the use of redundant servers. Element also supports air-gapped and low bandwidth communications, including Mesh and satellite connectivity.
5268 links collected between and