Elezea — link posts

Is Hip-Hop in Decline? A Statistical Analysis

Rian van der Merwe — Sat, 18 Apr 2026 00:59:06 GMT

I love this blog and try not to link to it too much, but this one about how fewer people listen to hip hop was especially great.

So, what’s filled the space hip-hop once dominated? A blend of new arrivals and familiar mainstays. Latin music—led by Bad Bunny—and Asian pop, powered by K-pop acts like BTS, have expanded their global footprint. At the same time, legacy formats are resurging: country is booming, driven in large part by Morgan Wallen, while the loosely defined “alternative” category continues to gain share across the charts.

I particularly love how he tries to avoid causation/correlation errors in his hypotheses. Like this one I hadn’t thought about:

Streaming adoption laggards: Hip-hop uniquely benefited from early streaming adopters in the 2010s. Younger listeners—who were predisposed to the genre—were among the first to embrace platforms like Spotify, giving hip-hop an outsized digital footprint. More recently, late adopters—like country fans, older cohorts, and global audiences—have rebalanced the charts, lifting genres like country and K-pop.

Thanks for still believing in RSS! Feel free to get in touch.

Evals Are the New PRD

Rian van der Merwe — Wed, 15 Apr 2026 17:31:37 GMT

Braintrust makes a good case (apologies for the X.com link...) for rethinking how PMs work on AI products: the eval replaces the PRD.

An eval is a structured, repeatable test that answers one question. Does my AI system do the right thing? You define a set of inputs along with expected outputs, run them through your AI system, and score the results using algorithms or AI judges.

The eval becomes both the spec and the acceptance criteria. The directive to engineering:

"Here is the eval. Make this number go up."

That's very different to how most teams work today, but I can definitely see the industry moving this way. Product usage generates signals, observability captures them, and evals turn them into improvement targets. The PM's job is to define what "good" looks like in code and curate the data that reveals what "bad" looks like.

The PM skills that transfer are the same ones that always mattered — discovering needs and opportunities, and making judgment calls about what to build for business value. The difference is that instead of a document that describes the intent, you have a test suite that encodes it.

Thanks for still believing in RSS! Feel free to get in touch.

No One Else Can Speak the Words on Your Lips

Rian van der Merwe — Tue, 14 Apr 2026 02:17:00 GMT

Ben Roy explains why prompting an LLM to write an essay misunderstands what writing actually is:

People fundamentally can't prompt good essays into existence because writing is not a top-down exercise of applying knowledge you have upfront and asking an LLM to create something. AI agents also can't create good essays for the same reason. Even though their step-by-step reasoning is more complex and iterative than human prompting, a chain of thought is still trying to accomplish a predefined goal. By contrast, real writing is bottom up. You don't know what you want to say in advance. It's a process of discovery where you start with a set of half-baked ideas and work with them in non-linear ways to find out what you really think.

I will continue to argue that for general business writing LLMs are fantastic if they are given the right context and guidance, and that it can save hours of work (with high quality results). But all my experiments with using LLMs for creative writing has so far fallen flat. Maybe—likely?—that will change within the next few months. But for now, the brain work this kind of writing requires remains. Not a bad thing imo.

Thanks for still believing in RSS! Feel free to get in touch.

Zombie Flow

Rian van der Merwe — Sun, 12 Apr 2026 14:54:13 GMT

Derek Thompson goes into the history of the "flow" concept, and how tech and entertainment companies learned to simulate it without any of the substance psychologist Mihaly Csikszentmihalyi originally had in mind:

Algorithmic flow is flow without achievement, flow without challenge, flow without even volition... To be lost in the lazy river of algorithmic media is to be lost the current of life without a mind. Zombie flow.

Ten years ago the question was how to get into flow more often. Now it might be how to get out of the fake version fast enough to remember what the real one felt like.

Thanks for still believing in RSS! Feel free to get in touch.

AI might actually need more PMs

Rian van der Merwe — Fri, 10 Apr 2026 20:51:22 GMT

Amol Avasare, Anthropic's Head of Growth, said on Lenny's Podcast that maybe PM jobs are not going to shrink as much as we may have thought...

Rather than immediately replacing PMs, AI is currently increasing engineering leverage the fastest, which creates new pressure on PMs and designers. In larger organizations, that may actually increase the value of PMs who can guide priorities, manage alignment, and sharpen decision-making—especially as engineers take on more "mini-PM" responsibilities.

Thanks for still believing in RSS! Feel free to get in touch.

Eight years of wanting, three months of building with AI

Rian van der Merwe — Fri, 10 Apr 2026 20:41:58 GMT

Lalit Maganti writes about building a SQLite parser with AI — a project he'd been putting off for eight years, finished in three months. His comparison of AI coding to slot machines is uncomfortably familiar:

I found myself up late at night wanting to do "just one more prompt," constantly trying AI just to see what would happen even when I knew it probably wouldn't work. The sunk cost fallacy kicked in too: I'd keep at it even in tasks it was clearly ill-suited for, telling myself "maybe if I phrase it differently this time."

Also, I agree that this is still true today, but I'm not convinced it will remain true beyond 2026:

AI is an incredible force multiplier for implementation, but it's a dangerous substitute for design.

Thanks for still believing in RSS! Feel free to get in touch.

Endgame for the open web

Rian van der Merwe — Sun, 29 Mar 2026 17:57:15 GMT

Anil Dash has a long essay on the state of the open web and not all of it rings true for me, but buried in the opening is a wonderful definition of what the open web actually is:

The open web is something extraordinary: anybody can use whatever tools they have, to create content following publicly documented specifications, published using completely free and open platforms, and then share that work with anyone, anywhere in the world, without asking for permission from anyone. Think about how radical that is.

It does feel like if the web got invented in 2026, it would not have been left as an open technology for long (see also AI and how much open source models are lagging).

Thanks for still believing in RSS! Feel free to get in touch.

Negative space in writing

Rian van der Merwe — Tue, 24 Mar 2026 00:14:41 GMT

Tracy Durnell explores non-visual negative space—what happens when writing leaves room for the reader to think:

The current design trend of business and self-help style books is to use tons of subheadings and callout boxes and always, a list of the key points at the end of the chapter. While this is a highly skimmable format and often nice visual design, it essentially sucks the negative space out of the text — the places in which the reader might step back and consider their own examples or anticipate what point the author is trying to make. There's no time for hunches here.

And:

The negative space of the text helps build the aesthetic experience. Small details flavor the text with a sense of reality. Drawing out events — leaving questions unresolved and conflicts unsettled — can build tension. And textual space creates a gap for the reader to make the personal decodings of the text that build meaning.

Not everything has to get to the point immediately. Sometimes the best thing a writer can do is leave room for the reader to get there on their own. I'm thinking about this because I'm currently reading The Will of the Many. It is slow, and long, and one of the best books I've read in ages. The negative space is probably a big reason why I love it so much.

Thanks for still believing in RSS! Feel free to get in touch.

Agentic manual testing

Rian van der Merwe — Mon, 23 Mar 2026 23:53:30 GMT

Simon Willison has a practical guide on manual testing with coding agents. Two tips I've already started using:

It's still quick for an agent to write out a demo file and then compile and run it. I sometimes encourage it to use /tmp purely to avoid those files being accidentally committed to the repository later on.

And:

If an agent finds something that doesn't work through their manual testing, I like to tell them to fix it with red/green TDD. This ensures the new case ends up covered by the permanent automated tests.

Thanks for still believing in RSS! Feel free to get in touch.

When Using AI Leads to “Brain Fry"

Rian van der Merwe — Sat, 14 Mar 2026 13:58:45 GMT

I am definitely feeling the "brain fry" right now:

We found that the phenomenon described in these posts—cognitive exhaustion from intensive oversight of AI agents—is both real and significant. We call it “AI brain fry,” which we define as mental fatigue from excessive use or oversight of AI tools beyond one’s cognitive capacity. Participants described a “buzzing” feeling or a mental fog with difficulty focusing, slower decision-making, and headaches.

The research is fascinating and worth reading, with super interesting findings like this:

As employees go from using one AI tool to two simultaneously, they experience a significant increase in productivity. As they incorporate a third tool, productivity again increases, but at a lower rate. After three tools, though, productivity scores dipped. Multitasking is notoriously unproductive, and yet we fall for its allure time and again.

Earlier this week I had this thought: "Oh no, I think I've blown out my context window. I wish I could add some more tokens to my brain. Until then I might just have to respond to new requests with 401 Unauthorized."

And that's when I realized I probably need to go touch grass or something.

Thanks for still believing in RSS! Feel free to get in touch.

AI should help us produce better code

Rian van der Merwe — Sat, 14 Mar 2026 13:43:35 GMT

As usual, Simon Willison hits the nail on the head here:

If adopting coding agents demonstrably reduces the quality of the code and features you are producing, you should address that problem directly: figure out which aspects of your process are hurting the quality of your output and fix them. Shipping worse code with agents is a choice. We can choose to ship code that is better instead.

Also see Mitchell Hashimoto’s idea of “harness engineering”:

It is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.

Thanks for still believing in RSS! Feel free to get in touch.

On Meeting Your Child Again, and Again

Rian van der Merwe — Sat, 07 Mar 2026 22:11:52 GMT

Derek Thompson wrote a wonderful essay on what happens when you become a parent:

The baby you bring home from the hospital is not the baby you rock to sleep at two weeks, and the baby at three months is a complete stranger to both. In a phenomenological sense, parenting a newborn is not at all like parenting "a" singular newborn, but rather like parenting hundreds of babies, each one replacing the previous week's child, yet retaining her basic facial structure. "Parenthood abruptly catapults us into a permanent relationship with a stranger," Andrew Solomon wrote in Far From the Tree. Almost. Parenthood catapults us into a permanent relationship with strangers, plural to the extreme.

Thanks for still believing in RSS! Feel free to get in touch.

Why It's Still Valuable To Learn To Code

Rian van der Merwe — Fri, 06 Mar 2026 22:47:32 GMT

Carson Gross has a good essay on whether junior programmers should still learn to code given how capable AI has become. His core warning to students:

Yes, AI can generate the code for this assignment. Don't let it. You have to write the code. I explain that, if they don't write the code, they will not be able to effectively read the code. The ability to read code is certainly going to be valuable, maybe more valuable, in an AI-based coding future. If you can't read the code you are going to fall into The Sorcerer's Apprentice Trap, creating systems you don't understand and can't control.

And on what separates senior engineers who can use AI well from those who can't:

Senior programmers who already have a lot of experience from the pre-AI era are in a good spot to use LLMs effectively: they know what 'good' code looks like, they have experience with building larger systems and know what matters and what doesn't. The danger with senior programmers is that they stop programming entirely and start suffering from brain rot.

This maps directly onto what I've been writing about with AI for product work and the second brain setup I've built. The system works because I spent years writing and reading PRDs, strategy docs, and OKRs—enough to develop actual opinions about what good looks like. You have to do the work first, then the second brain is worth building.

Thanks for still believing in RSS! Feel free to get in touch.

An AI Wake-Up Call

Rian van der Merwe — Sun, 01 Mar 2026 22:05:04 GMT

Matt Shumer's Something Big Is Happening has made the rounds over the last couple of weeks, but just in case you haven't seen it, I think it's very much worth reading. He's an AI startup founder writing for the non-technical people in his life:

AI isn't replacing one specific skill. It's a general substitute for cognitive work. It gets better at everything simultaneously. When factories automated, a displaced worker could retrain as an office worker. When the internet disrupted retail, workers moved into logistics or services. But AI doesn't leave a convenient gap to move into. Whatever you retrain for, it's improving at that too.

Previous waves of automation always left somewhere to go. The uncomfortable implication here is that the escape routes are closing as fast as they open.

There are too many quotes worth commenting on, but this observation about what we tell our kids feels important:

The people most likely to thrive are the ones who are deeply curious, adaptable, and effective at using AI to do things they actually care about. Teach your kids to be builders and learners, not to optimize for a career path that might not exist by the time they graduate.

Predictions about the pace of change tend to be simultaneously too aggressive and too conservative in ways that are hard to anticipate. But the direction feels right, and the practical advice is sound: use the tools seriously, don't assume they can't do something just because it seems too hard, and spend your energy adapting rather than debating whether this is real.

Thanks for still believing in RSS! Feel free to get in touch.

Toolshed, blueprints, and why good agents need good DevEx

Rian van der Merwe — Sun, 01 Mar 2026 18:36:16 GMT

Alistair Gray published part two of Stripe’s “Minions” series, going deeper on how they built their internal coding agents. It’s a great read throughout, but three ideas really stood out to me.

First, blueprints. These are workflows that mix deterministic steps with agentic ones:

Blueprints are workflows defined in code that direct a minion run. Blueprints combine the determinism of workflows with agents’ flexibility in dealing with the unknown: a given node can run either deterministic code or an agent loop focused on a task. In essence, a blueprint is like a collection of agent skills interwoven with deterministic code so that particular subtasks can be handled most appropriately.

If you know a step should always happen the same way, don’t let an LLM decide how to do it. Let the agent handle the ambiguous parts, and hardcode the rest (this can also dramatically reduce token cost).

Second, their centralized MCP server:

We built a centralized internal MCP server called Toolshed, which makes it easy for Stripe engineers to author new tools and make them automatically discoverable to our agentic systems. All our agentic systems are able to use Toolshed as a shared capability layer; adding a tool to Toolshed immediately grants capabilities to our whole fleet of hundreds of different agents.

A shared tool layer that all agents can use… 500 tools, one server, hundreds of agents. Very cool idea.

And third, what they call “shifting feedback left”:

We have pre-push hooks to fix the most common lint issues. A background daemon precomputes lint rule heuristics that apply to a change and caches the results of running those lints, so developers can usually get lint fixes in well under a second on a push.

If you can catch a problem before it hits CI, do it there. A sub-second lint fix on push is better than a 10-minute CI failure, whether you’re a person or an LLM burning tokens.

So much of Stripe’s agent success is built on top of investments they made for human developer productivity. Good dev environments, fast feedback loops, shared tooling. The agents benefit from all of it, and developers remain in control.

Thanks for still believing in RSS! Feel free to get in touch.

The A.I. Disruption Has Arrived, and It Sure Is Fun

Rian van der Merwe — Sat, 21 Feb 2026 17:09:08 GMT

Paul Ford writes about vibe coding for the NYT (gift link) and what happens when software suddenly becomes cheap and fast to ship:

There are many arguments against vibe coding through A.I. It is an ecological disaster, with data centers consuming billions of gallons of water for cooling each year; it can generate bad, insecure code; it creates cookie-cutter apps instead of real, thoughtful solutions; the real value is in people, not software. All of these are true and valid. But I’ve been around too long. The web wasn’t “real” software until it was. Blogging wasn’t publishing. Big, serious companies weren’t going to migrate to the cloud, and then one day they did.

And then he brings it home in a way that continues to make him one of my favorite web writers:

The simple truth is that I am less valuable than I used to be. It stings to be made obsolete, but it’s fun to code on the train, too. And if this technology keeps improving, then everyone who tells me how hard it is to make a report, place an order, upgrade an app or update a record — they could get the software they deserve, too. That might be a good trade, long term.

We can grieve what we lost, while also being optimistic about the future AI is unlocking for all of us. It’s uncomfortable, but that’s ok, all technological shifts are.

Thanks for still believing in RSS! Feel free to get in touch.

The Father-Daughter Divide

Rian van der Merwe — Sat, 21 Feb 2026 16:56:23 GMT

Isabel Woodford has a research-heavy essay in The Atlantic about why dads and daughters crave closeness but struggle to find it. 28% of American women are estranged from their father, and even where relationships are intact, they tend to be thinner—more transactional, less emotionally honest—than daughters want.

At the root of the modern father-daughter divide seems to be a mismatch in expectations. Fathers, generally speaking, have for generations been less involved than mothers in their kids’ (and especially their daughters‘) lives. But lots of children today expect more: more emotional support and more egalitarian treatment. Many fathers, though, appear to have struggled to adjust to their daughters’ expectations. The result isn’t a relationship that has suddenly ruptured so much as one that has failed to fully adapt.

And the psychological explanation that cuts deepest:

“What generates closeness is another person’s vulnerability,” Coleman explained, and dads may not be ready for that.

Daughters aren’t asking for grand gestures or dramatic change—they’re asking for their fathers to show up emotionally. Which turns out to be hard for a lot of men who were raised to see that kind of openness as weakness.

Thanks for still believing in RSS! Feel free to get in touch.

The AI baseline has moved

Rian van der Merwe — Sat, 21 Feb 2026 16:53:14 GMT

Geoffrey Huntley wrote about what happens when people finally “get” AI:

If you’re having trouble sleeping because of all the things that you want to create, congratulations. You’ve made it through to the other side of the chasm, and you are developing skills that employers in 2026 are expecting as a bare minimum.

The only question that remains is whether you are going to be a consumer of these tools or someone who understands them deeply and automates your job function? Trust me, you want to be in the latter camp because consumption is now the baseline for employment.

Knowing how to use these tools is no longer a differentiator. The gap is between people who consume AI outputs and people who understand the systems well enough to build on top of them.

For product managers, this means that prompting ChatGPT for a first draft doesn’t count as an AI skill anymore. The question is whether you can wire together agents, automate your own workflows, and spot opportunities others miss because they’re still thinking in manual processes.

Thanks for still believing in RSS! Feel free to get in touch.

The Jevons Paradox and the Future of Knowledge Work

Rian van der Merwe — Tue, 03 Feb 2026 01:54:08 GMT

I keep thinking about this essay by Mike Fisher about what happens when automation makes work easier. His central argument challenges the assumption that’s baked into most AI-and-jobs discourse:

In every domain where automation becomes powerful, the pattern remains consistent. Human expertise becomes more valuable because the total volume of meaningful work increases. Early fears of automation nearly always assume a fixed amount of work being redistributed. But work is not fixed. Work expands when constraints are removed.

He anchors this on the Jevons Paradox—the 19th century observation that improved steam engine efficiency led to more coal consumption, not less. And then he traces the pattern through radiology, where the number of US radiologists grew from 30,723 in 2014 to 36,024 in 2023, despite Hinton’s 2016 prediction that deep learning would make them obsolete within five years.

He concludes:

AI will reshape the profession, but only in the sense that cars reshaped transportation or spreadsheets reshaped finance. Not by eliminating the field, but by expanding its scope. Not by reducing labor, but by elevating it. Not by shrinking opportunity, but by multiplying it. The world does not need fewer people who understand systems. It needs far more of them.

I find this framing useful because it shifts the question from “will AI take my job?” to “how will the work change as the volume increases?” That’s a much more interesting thing to figure out (which is also why I have been so focused on expanding my Product Second Brain).

Thanks for still believing in RSS! Feel free to get in touch.

Why "Correction of Error" Gets Incidents (and Product Failures) Wrong

Rian van der Merwe — Mon, 26 Jan 2026 02:20:20 GMT

I’ve covered “root cause” thinking in incident reviews before, and Lorin Hochstein takes aim at a related issue: AWS’s “Correction of Error” terminology:

I hate the term “Correction of Error” because it implies that incidents occur as a result of errors. As a consequence, it suggests that the function of a post-incident review process is to identify the errors that occurred and to fix them. I think this view of incidents is wrong, and dangerously so: It limits the benefits we can get out of an incident review process.

What makes his critique compelling is the observation that production systems are full of defects that never cause outages:

If your system is currently up (which I bet it is), and if your system currently has multiple undetected defects in it (which I also bet it does), then it cannot be the case that defects are a sufficient condition for incidents to occur. In other words, defects alone can’t explain incidents.

This applies to product work too. When users report problems, our instinct is to find “the bug” and fix it. But often the bug has been there for months—what changed is the context around it. A new user flow, a spike in traffic, a feature interaction we didn’t anticipate. If we stop at “fixed the bug,” we miss the chance to understand why the system let that failure through in the first place.

Thanks for still believing in RSS! Feel free to get in touch.