The online whiteboard of Kristofer Palmvik
In the right context, the icon's meaning is clear. However, the AI Sparkle icon doesn’t always convey granular meaning. Users don't always know what kind of AI they're interacting with in a Google product (ML, LLM, image generator, etc.) or the precise action they'll receive — whether it's newly generated text, AI-powered analysis, or image editing suggestions.
By forcing developers to talk early, you make it harder for technically oriented silos to appear. Instead, it helps discover the natural service boundaries and API contracts in the business domain. Instead of silos based on technology, you can form cross-functional teams that align with distinct parts of the product.
This post contains my notes and highlights from the Shape Up from 37signals. It contains practical and actionable advice on project management, planning, and actually shipping meaningful work. I found it a great alternative to traditional practices like Agile. Give it a try on your next project!
If faster code generation alone doesn’t deliver value, the answer is not more acceleration, but smarter constraints. For me, that’s why XP resonates now more than ever: it teaches us to slow down just enough to learn, align, and build with intent.
The sparkles icon has become increasingly prevalent in user interfaces, particularly in association with AI-driven features, but it suffers from ambiguity and lacks a standardized meaning.
Most teams using AI tools responsibly aren’t vibe coding at all—they’re operating in entirely different regions of what I see as the AI development matrix. Understanding where you sit on this matrix determines whether AI becomes a superpower or a disaster.
Right now, most of our tests are “public”. The AI can see them, learn from them, and optimize for them. This works for basic functionality. But it creates a risk. The AI might generate code that passes all your tests but doesn’t actually solve the problem. Like writing an if statement for every number between 1 and 2000 instead of using a proper algorithm.
If you’re still building your site as an SPA for the sake of “smoothness,” you’re solving a problem the browser already fixed – and you’re paying for it in complexity, performance, and maintainability.
Kent Beck’s timeless advice, “Make the change easy, and then make the easy change,” is a guiding principle for software craftsmanship. It’s a simple yet profound idea that should resonate with both developers writing code and leaders shaping technical strategy. At its core, this philosophy advocates for intentional preparation to ensure changes to a codebase are smooth, predictable, and sustainable. But what does “easy” really mean, and how can we apply this principle across different dimensions of software development?
Despite the rush to integrate powerful new models, about 5% of AI pilot programs achieve rapid revenue acceleration; the vast majority stall, delivering little to no measurable impact on P&L. The research—based on 150 interviews with leaders, a survey of 350 employees, and an analysis of 300 public AI deployments—paints a clear divide between success stories and stalled projects.
5091 links collected between and