Elezea - RSS Feed

Discrobble v1.2.0 — Synced scrobble history

Rian van der Merwe — Sun, 31 May 2026 20:45:54 GMT

Your Recently Scrobbled history now syncs across all your devices. Scrobble an album on your iPhone and it's there on your iPad — your recent plays follow you anywhere you're signed in with the same Last.fm account.

What's new

Recently Scrobbled now syncs across every device signed into the same Last.fm account. It's there on launch — no pull-to-refresh needed.
Clear your history on one device and it clears everywhere.

Fixes

Older scrobbles from before this update may show without cover art. They clear out on their own as you keep scrobbling, or you can tidy them up right away with Clear Recent History in Settings.

Thanks for still believing in RSS! If you'd like you can reply via email.

We Should Be More Tired Than the Model

Rian van der Merwe — Sat, 30 May 2026 16:26:17 GMT

In a post about slowing down our agent use deliberately to increase quality and understanding Vicki links to Nolan Lawson's Using AI to write better code more slowly:

If you're the kind of developer who uses agents to write multi-hundred-line PRs that you barely understand yourself, I'd invite you to slow down a bit and try this other, slower style of "vibe coding." Ask an agent how your PR works and how it might fail. Have it write Markdown docs with Mermaid charts if necessary. Use Matt Pocock's /grill-me skill until you understand the entire PR front-to-back.

You might not be more "productive" in terms of raw lines of code. You might burn a ton of tokens just to find out that your entire plan was wrongheaded from the start. But I find this style of coding to be a more super-powered version of the kind of programming I was already trying to do before LLMs: careful, methodical, quality-obsessed, focused on making things better for the next coder.

So take a deep breath, slow down, try this technique, and see if you don't enjoy writing better code more slowly.

Vicki concludes:

All of these negate the supposed speed up effects of LLM-generated code in the short-term by adding friction, and yet, in the longer term, make me better at using the tool, because they solidify my own foundation instead of the foundation models'.

We should be more tired than the model.

We should be more tired than the model. When I saw the post in my feed I thought I misread the title (or maybe it was a typo). But after reading it I realized that's already where I've been heading organically myself. I went through my "look how fast I can go weeeeee!" era pretty quickly. While it was fun (check out all these side projects!) it was not just exhausting, I also found myself understanding less and less of what I was doing (which sucks all the fun out of the work anyway).

So I've been slowing down as well. Reading and editing even more than before. Challenging the agent for longer. Taking the time to close loops to update skills/context documents before moving on to the next thing. Never skipping the "let's write a design doc and implementation plan together" step.

I do think I am more tired than the model these days. But I also understand and learn more, which not only improves the quality of the output now, but also makes it better tomorrow. I think the speed trade-off is worth it.

Thanks for still believing in RSS! If you'd like you can reply via email.

The Great AI Cost Panic of 2026

Rian van der Merwe — Sat, 30 May 2026 14:57:55 GMT

Derek Thompson digs into the current news cycle about out-of-control AI token spend, and makes the case that since we're literally only 5 months into the ✨agentic era✨, we need to look at it in the context of how technology cycles usually work:

Rather than see the agent backlash as a clear sign that AI is a scam, or that it is doomed, it might make more sense to see this development in the context of a normal technological adoption curve. [...]

As SemiAnalysis’s Doug O’Laughlin told me in an interview last week, every new technology requires an extended period of trial and error, as organizations toggle between (a) not enough experimentation or spending, followed by (b) too much experimentation and spending, followed by (c) too dramatic a pullback, followed by (d) the repetition of steps (a) through (c), until firms figure out a long-term balance between labor spending and tech spending. Whether AI skeptics like [cognitive scientist Gary] Marcus are right that the bubble is about to pop depends entirely on a question that, as of today, nobody can definitively answer: Is the bill worth it?

Thanks for still believing in RSS! If you'd like you can reply via email.

Discrobble v1.1.0 — Native iPad support

Rian van der Merwe — Tue, 26 May 2026 20:30:26 GMT

Discrobble now runs natively on iPad, with a denser collection grid and a side-by-side album view that puts the cover and tracklist together. This release also clears out a sticky onboarding bug, makes sync safer when it gets interrupted, and fully removes your data from the server when you delete your account.

What's new

Native iPad support. The collection grid adapts to the screen — more albums per row on iPad, same comfortable density on iPhone. The album screen shows the cover and the tracklist side by side in both portrait and landscape.
The onboarding and sync screens stay at a readable width on iPad instead of stretching edge to edge.

Fixes

The app could occasionally get stuck on the setup screen after you connected your accounts. Once you're signed in, you now move on.
Collection sync is safer. If a sync is interrupted partway through, it can no longer remove albums from your collection by mistake.
Deleting your account from Settings now fully removes your data from the server, not just from your device.

Under the hood

In-flight auth tokens are now encrypted at rest on the server (AES-256-GCM).
Added the Apple required-reason API privacy manifest.

Thanks for still believing in RSS! If you'd like you can reply via email.

Your AI Use Is Breaking My Brain

Rian van der Merwe — Sun, 24 May 2026 19:12:11 GMT

Well here’s a disturbing point I somehow hadn’t thought about before. Are we training AI, or is it training us?

When I sat down to write this article, in which, to be clear, I did not use AI, I found myself writing the following sentence: “It’s not just in places we’re conditioned to see AI—Google AI overviews, LinkedIn influencer posts, and Facebook feeds—I’ve started seeing AI…” I stopped typing, freaked out, and deleted the sentence. Have I always written this way? I honestly don’t know.

This negative parallelism—“it’s not just x, it’s y” is maybe the most infamous AI writing-ism there is. It is something that is regularly called out as being obviously AI, and is the formation in the sentence Mamdani wrote that Spero called out. But I didn’t use AI. Did I use that construction because I’ve been immersed on an internet full of generic AI writing on every platform all day everyday for years? Or did I just happen to think that was the best way to phrase it at the time?

Related, I like Kai’s take on why we feel so... duped when we see clearly AI-generated text:

I'm not categorically against using AI to help out with tedious work. But there's a difference between using a tool to say something you actually mean, and using a tool to manufacture the appearance of meaning something.

I know it's a bit naïve to appeal to common decency when the same technology is busy guiding weapons systems, but please don't outsource sincerity. Don't pretend to care about someone or something just to get their attention.

The damage isn't just annoyance. It's suspicion that gets attached to genuine messages. Emails I would have read warmly now carry an asterisk. Did a person write this? Does this person actually care about my work, or is this just another prompt in the dark?

Thanks for still believing in RSS! If you'd like you can reply via email.

LLMs and Buttondown

Rian van der Merwe — Sat, 23 May 2026 22:13:05 GMT

I say this sincerely because I am a big fan of Buttondown and how Justin runs the business—this couldn’t have happened to a nicer guy:

Our month-over-month growth rate in Q1 2026 was double our growth rate in Q4 2025. Buttondown has, roughly, grown a little less than 2x every year of its existence; this -- its eighth year — is poised to shatter that, if trends hold.

Almost all of that incremental growth, meaning the growth in addition to our historical trend, I attribute to LLMs. We ask people when they sign up what brought them here, and an answer that went from surprising to banal to overwhelming over the course of Q1 was: an LLM. Users of all stripes cite an LLM as the reason that they ended up at Buttondown's front door.

You should click through for the whole post because he explains why he thinks this happened:

People have asked why I think we have been the beneficiary of this genre of growth. There is one fairly interesting reason: we have accidentally built a very LLM-friendly business in this space.

I’ve always been a big believer in API-first design, and this feels like an almost accidental enormous additional benefit to that approach. Anyway, all that to say... my newsletter is on Buttondown, and yours should be too.

Thanks for still believing in RSS! If you'd like you can reply via email.

The Product Leader’s Influence on the World We All Will Live in

Rian van der Merwe — Thu, 21 May 2026 23:20:25 GMT

In a practical example of brain fry, Petra Wille recalls some of her personal experience during coaching:

The product leaders and CPOs I coach tell me their people are completely fried before lunch—after a morning of generating content and reviewing outputs in Claude, Gemini, and ChatGPT, they’re just done. Adapting to this new type of work doesn’t make them more productive because they’re out of energy and brainpower by noon.

So conversations about how we actually work—what a sustainable rhythm looks like for humans in this new setup—still needs to happen.

This has become a pretty common complaint/concern among people I talk to, and it gets me too. I’ve been sitting on posting this link because I wanted to include some kind of proposal but... I got nothing. Just agreement with Petra that we really really need to figure out how to work in this new world in a way that avoids mass burnout.

Thanks for still believing in RSS! If you'd like you can reply via email.

You're Worse at Your Job Because You Care Too Much

Rian van der Merwe — Fri, 15 May 2026 21:48:08 GMT

Yes, it’s a clickbaity title, but if you read this as an essay about what to care about at work, it has some good reminders like this:

“Care less” is directionally right, but let’s get more specific. The real shift is learning to place your care deliberately — to get good at telling the difference between what’s strategically important and what’s just noisy. A lot of what happens inside companies is frustrating without being important. Reacting to a messy call that you personally wouldn’t have made as if it’s a strategic risk is what drains you. So is holding on to every detail as if it’s existential. Not everything deserves to be treated with equal importance. A gut check that helps: Will this matter in a year? If not, it probably doesn’t deserve much energy now. What’s the worst-case scenario? Often, it’s not that bad.

Thanks for still believing in RSS! If you'd like you can reply via email.

Meet the Sad Wives of AI

Rian van der Merwe — Fri, 15 May 2026 00:28:25 GMT

I sent this essay to my wife because doing self-owns is kind of my brand. It’s about husbands who can’t stop talking about AI, and despite how uncomfortable it made me, it’s not wrong and also wonderful writing. This is so good:

I should also say I didn’t bother speaking to any of the actual husbands for this story. I’m sick of hearing from the men of AI. So many of us are. They have podcasts and Senate hearings and magazine profiles and probably a group chat with the president. They’ve been talked to—and I can’t stress this enough—enough.

Thanks for still believing in RSS! If you'd like you can reply via email.

I Left Port 22 Open for 54 Days: An SSH Honeypot Study

Rian van der Merwe — Sun, 10 May 2026 00:16:16 GMT

This post is a fascinating look at how botnets actually work. I don’t want to spoil the takeaways so I’ll just quote this (but you should read the whole thing):

Your server isn't special. Nobody is "targeting" it. Every IP address on the internet is being continuously probed by automated systems. Within seconds of exposing port 22, you will receive login attempts. This isn't a question of "if" but "when" — and the answer to "when" is "immediately."

Thanks for still believing in RSS! If you'd like you can reply via email.

Discrobble v1.0.2 — Free on the App Store

Rian van der Merwe — Sat, 09 May 2026 20:05:48 GMT

My first iPhone app is live! Discrobble is now on the App Store, free. It connects to your Discogs collection and your Last.fm account so you can track your physical music listening in two taps: pick an album, hit "Scrobble," and the tracks land in your Last.fm history. There's more on the product page about how it works.

Thanks for still believing in RSS! If you'd like you can reply via email.

Song of the Day: May 6, 2026

Rian van der Merwe — Thu, 07 May 2026 02:47:35 GMT

This song is all over my Instagram Reels for some reason and it is such a vibe I can't get enough of it.

▶ Listen on Spotify

Thanks for still believing in RSS! If you'd like you can reply via email.

discogs-mcp v3.3.0 — Background sync, instant search

Rian van der Merwe — Tue, 05 May 2026 01:13:29 GMT

The first search of the day is now instant. discogs-mcp pre-fetches your collection in the background every hour and keeps it in a snapshot, so search_collection doesn't have to paginate the Discogs API from cold any more.

The server also tells your LLM client how to navigate it — every tool response ends with a "Next steps" block listing the most likely follow-up calls and the exact arguments to use, so chained queries like "find me a mellow jazz album, then expand the top hit" don't make the model guess.

And if you've been putting off deploying your own copy, there's now a Deploy to Cloudflare button in the README — one click, three secrets, done.

What's new

Hourly background sync keeps your collection snapshot fresh. Add or remove a record on Discogs and it's visible to search within an hour, automatically.
New refresh_collection tool forces an immediate snapshot refresh — useful when you've just bought an album and want it visible to search right now.
Server-level instructions and per-tool "Next steps" breadcrumbs make the server self-navigating for any LLM client. The instructions name a recommended path (search_collection → get_release → mutations); each tool response ends with the most likely follow-up calls, with real values templated in (get_release(release_id=28861354), not release_id=<ID>). Inspired by Rui Carmo's MCP server post.
One-click self-hosting via the Deploy to Cloudflare button in the README. Cloudflare provisions the KV namespaces, Durable Object, cron, and prompts for the secrets — no wrangler kv namespace create needed, and pushes to your fork redeploy automatically via Workers Builds.

Fixes

First search_collection call after a cold cache no longer times out. Previously this could take 30 seconds to two minutes on a 1,500-item collection, often longer than the MCP request timeout. It's now sub-second.
Mood queries ("mellow Sunday morning", "road trip music") respond just as fast as keyword queries — they used to pay the same pagination cost as everything else.

Under the hood

New syncCollection module with per-page retry, resumable progress, and atomic snapshot swap so readers never see partial state.
Cron runs hourly with a probe path: one API call to compare count + page-1 instance IDs against the snapshot. Full repaginate only when something changed. Steady-state cron tick now costs 1 Discogs request instead of 16.
Self-healing across MCP request timeouts: if a sync stalls partway through, the next call resumes from where it left off rather than restarting.
Dropped the MCP_LOGS KV binding. Sync outcomes now structured-log to the Workers runtime so Cloudflare Observability ingests them — one fewer namespace for self-hosters to create.

Thanks for still believing in RSS! If you'd like you can reply via email.

Why Did Hollywood Stop Making Dramas?

Rian van der Merwe — Fri, 01 May 2026 22:21:18 GMT

I guess this shows just how old I am because I loved every single one of the “Oscar-bait” movies in this list (I do agree on TCM though)...

When I was a kid, I would watch Turner Classic Movies and try to appreciate films from the 1940s, only to find the exercise strangely difficult. I could admire them—in theory—but I struggled to experience these stories the way their original audiences did.

I feel similarly about many Oscar-bait dramas of the 1990s, including but not limited to: Chocolat, American Beauty, Shakespeare in Love, Scent of a Woman, The English Patient, and Life Is Beautiful. I simply don’t understand what contemporary audiences saw in these films.

That aside, as usual Daniel makes an interesting larger point, about why we don’t see as many dramas as we used to:

Action and horror, meanwhile, have visceral elements that translate across generations: big dinosaurs, jump scares, campy set pieces, and other straightforward pleasures. The first ten minutes of Raiders of the Lost Ark are timeless and feature almost no dialogue.

Thanks for still believing in RSS! If you'd like you can reply via email.

lastfm-mcp v2.4.0 — Top tracks and 8K fewer lines

Rian van der Merwe — Thu, 30 Apr 2026 20:09:55 GMT

The big shifts in this release: three new tools, a glassmorphism-redesigned landing page, timezone-aware day boundaries on get_recent_tracks, and a 8,300-line cull of the original session-based worker now that the OAuth path has been the only one in production for a while.

What's new

Three new tools. get_top_tracks fills the obvious symmetry gap with the existing get_top_artists and get_top_albums. get_artist_top_tracks and get_artist_top_albums surface an artist's globally most-played catalog — useful for "what's the canonical record by X" questions.
Date-aware get_recent_tracks. New date param accepts a YYYY-MM-DD calendar date plus a timezone (IANA name, e.g. America/New_York) and the server computes the correct UTC day boundaries. Way better than juggling from/to Unix timestamps for "what did I listen to yesterday" queries. The response also echoes the queried range back so an LLM can self-verify it asked the right question.
Redesigned landing page at lastfm-mcp.com — glassmorphism, animated waves, glow effects.

Fixes

get_album_info no longer renders [object Object] when Last.fm returns the album artist as an object instead of a string. Latent bug, fixed via a formatArtist helper that handles both shapes.

Under the hood

Deleted the legacy worker. Removed src/index.ts plus the homemade JSON-RPC dispatch layer in src/protocol/ and the SSE transport in src/transport/. The OAuth worker (src/index-oauth.ts) has been the only production deployment for months; the legacy [env.legacy] block in wrangler.toml was never deployed to Cloudflare. Net diff: −8,293 lines, 0 added. Test suite went from 376 tests / 5 failing → 167 tests / 0 failing.
Dropped dead deps: crypto-js, @types/crypto-js, oauth-1.0a — zero imports.
Removed dead throttle. LastfmClient.throttleRequest was per-request (clients are instantiated per-request in the OAuth worker), so it never observed a previous request — it did nothing while implying rate-limit safety. Existing 429-aware retry handles rate limits correctly.
Dynamic tool catalog. The lastfm_auth_status tool list lives in one place now (src/mcp/tools/catalog.ts) instead of being hardcoded in three.

Thanks for still believing in RSS! If you'd like you can reply via email.

Output isn’t design

Rian van der Merwe — Thu, 30 Apr 2026 18:14:58 GMT

The hard part of design is rarely generating the form. It is understanding the problem well enough to know what and how something should exist at all. There is use and place for these tools, but tools are not the design process.

Christopher Alexander came closer than anyone to naming this clearly. In Notes on the Synthesis of Form, he describes design as the search for a good fit between a form and its context. Context, in his sense, is not a background condition. It is the full set of forces that make a problem what it is: human needs, technical constraints, conflicting requirements, habits, edge cases, and relationships that are easy to miss until you spend time with them. Bad design appears where those forces remain unresolved. Good design appears where those misfits have been worked through carefully.

— Karri Saarinen, Output isn’t design

Thanks for still believing in RSS! If you'd like you can reply via email.

tldl v2.4.0 — Broadsheet redesign

Rian van der Merwe — Wed, 29 Apr 2026 21:25:26 GMT

TL;DL has a new look. Inspired by classic broadsheet newspapers, the redesigned site puts episode summaries in a layout that's calmer to read and easier to scan — with proper typography, a featured "lead" episode, and a cleaner detail page for every summary.

What's new

Broadsheet-style homepage. A featured lead episode at the top, then the rest of the week's episodes laid out as numbered index entries. Episode count grows? Pagination kicks in at 20 per page.
Redesigned episode pages. New typography (Fraunces + Inter Tight + JetBrains Mono), a generated deck and pull quote on every episode, links out to the podcast's website and Apple Podcasts, and a "More from this podcast" section.
Search and tag browsing. Search the homepage with ?q=..., click any tag to see every episode with that tag, or browse the full tag and podcast directories.
Polished mobile and tablet layouts. Episode rows stack their metadata neatly on smaller screens. Tags wrap onto their own row. Pull quotes tighten up.
Subscribe, preferences, and request flows live in the new design. No more jarring jump from the new site into the old forms.
Restored social previews. Favicon, Open Graph, and Twitter Card tags are back, so links shared on social and in chat apps look right again.

Fixes

iPad portrait layout no longer cuts off episode titles — the index now collapses to the simpler mobile-style row at tablet widths too.
Masthead date shows the correct day in Pacific time instead of drifting based on the reader's timezone.
Episode summaries no longer show a duplicate title at the top — the redundant first heading is now stripped automatically.
Editorial metadata (deck and pull quote) generation now retries cleanly on transient failures instead of giving up on the first error.

Thanks for still believing in RSS! If you'd like you can reply via email.

How to stay relevant when the PM role keeps rewriting itself

Rian van der Merwe — Wed, 29 Apr 2026 00:25:50 GMT

Melissa Perri chimes in on how AI is changing the product role, and makes the case for measuring PMs by decisions changed and outcomes shipped, not by tickets written and docs generated:

If you are a PM, stop measuring your productivity by how many tickets you wrote, how many pages of documentation you spun up, or how fast you closed the loop on the last sprint. That work is going to keep getting easier.

Measure your productivity by how often you changed a decision that mattered, how often you saw around a corner, how often a senior leader walked out of a room thinking differently because of something you said. How often your shipped features translate into real customer outcomes is what matters.

Everything I read is saying the same thing right now: judgment, customer understanding, and the ability to change a senior leader's mind in a room are the skills that AI can't touch. I'm not disagreeing necessarily, but I do think that narrative is missing a big new skill that is needed. I wrote about this in What actually changed about being a PM:

I was talking to my wife the other day about what I’m doing, and she asked the obvious question: “Why are you automating your job away?” My answer: the people who automate their own jobs away are the ones who become more valuable, because the craft is now in orchestration — setting up the layers so the AI does the right thing.

I also continue to think about this quote from Org Design in the Age of AI and how the focus is shifting from "information movers" to builders:

The old PM spent most of their energy making ideas legible to other people. The new PM validates directly — prototyping, running data analyses, generating first-pass implementations. [...] The managers who thrive will be the ones whose real contribution was always judgment, coaching, and navigating ambiguity — not routing information.

Thanks for still believing in RSS! If you'd like you can reply via email.

Product Roadmaps: How the Best Product Teams Plan for Uncertainty

Rian van der Merwe — Tue, 28 Apr 2026 22:32:05 GMT

I'm a big fan of Now/Next/Later roadmaps, and I think it adapts particularly well to an AI-assisted world, so I was curious to read Teresa's Take on different roadmap models. It's a fun trip through different prioritization frameworks, and I do like her reframing of the Now/Next/Later approach:

Here's what I've seen work best: Take the Now Next Later format, but instead of filling every column with features at different levels of detail, change the type of content as you move across columns. [...]

Specifically, I list solutions in the Now column, opportunities in the Next column, and outcomes in the Later column.

Thanks for still believing in RSS! If you'd like you can reply via email.

Deezer: AI-generated tracks now represent 44% of all new uploaded music

Rian van der Merwe — Sat, 25 Apr 2026 23:40:08 GMT

This is characteristically dry press release language, but the stats are interesting:

Deezer, the global music experiences platform, is now receiving almost 75,000 AI-generated tracks per day, representing roughly 44% of the daily uploads. This amounts to more than 2 Million AI-generated tracks uploaded per month. Thanks to Deezer's industry unique measures, consumption of AI-generated music on the platform is still very low, between 1-3% of the total streams. In addition, a majority (85%) of these streams are detected as fraudulent and are demonetized by Deezer.

I’m simultaneously surprised (but not, because grifters) that the amount of uploads is that high, and surprised (but not, because music lovers) that it’s generally a very unsuccessful way to make money. My continuing refrain will be that let’s use AI for the things that it’s good at, and leave the really important stuff (like art) to humans.

Thanks for still believing in RSS! If you'd like you can reply via email.