Elezea - RSS Feed

Discrobble v1.5.0 — Collection folders on the album page

Rian van der Merwe — Tue, 13 Oct 2026 14:01:40 GMT

Discrobble now shows which Discogs folder each album is in, and you can move it to another folder from the album page. This release also collects everything shipped since 1.3.6: any of your collection fields on the album page, help for releases with missing artist credits, and a pull-to-refresh that always finishes.

What's new

Turn on "Show collection folder" in Settings > Display, and the album page shows the album's Discogs folder at the top of its collection details. Tap it to pick another folder (the list is searchable), and the move saves to Discogs straight away. If you own more than one copy of a release, Discrobble shows and moves the first one.
Album pages can show any of your Discogs collection fields, each under its own name. Choose them in Settings > Collection fields, where Notes is selected to start with. You can edit text fields and pick dropdown values in the app, and changes save back to Discogs.
When Discogs is missing artist credits for some tracks on a release, the album page says so and links to the release on Discogs. Once you've fixed the credits there, tap Refresh track information to pick them up.
When Discogs rate-limits a refresh, the banner says so and shows how long the app is waiting. Discrobble also slows down on its own when it gets close to the limit.
Syncing fetches 100 albums per Discogs request, up from 50, so a full check of your collection makes half as many calls.
Pull-to-refresh, Refresh from Settings, and the weekly collection check take turns now, so only one sync runs at a time.

Fixes

Collection fields keep their own names. A field like "Original cost" used to appear under a "Notes" heading, only one text field showed up, and dropdown fields were left out.
The "Syncing…" message could stay on screen after a refresh finished. Every refresh now ends with a result: up to date, what was added or removed, or what went wrong.
If your session had expired or your Discogs collection was private, pull-to-refresh showed "Syncing…" indefinitely. It now tells you which one it is and what to do.
A refresh that kept hitting Discogs' rate limit could retry forever. It now stops after a few attempts and tells you.

Thanks for still believing in RSS! Get in touch if you have any comments or feedback.

Why Is Everyone In Tech So Sad?

Rian van der Merwe — Fri, 09 Oct 2026 00:18:04 GMT

Aaron Horwath implements AI for a living, and in a good essay for Noema he asks why so many knowledge workers are losing faith in their careers:

In coffee shops and in the low-lit corners of bars, professionals are sharing dreams of “disappearing” or “living on a farm somewhere” or “going off the grid.” These aren’t fantastical daydreams; they are visions of escape shared in a tone that betrays an underlying existential angst, a fundamental doubt about work and careerism inspired by a seemingly increasingly common experience: waking up one morning at an existential precipice, struck with a sudden sense that knowledge work is, and perhaps always has been, pointless.

It’s definitely worth reading the whole thing if you find yourself in the same situation. He mentions two concepts that feel super relevant right now:

Workism is Derek Thompson’s term for the way work has become the place we look for the meaning that earlier generations got from religion.
The spectacle comes from the French theorist Guy Debord’s 1967 book The Society of the Spectacle. It’s his word for modern life lived secondhand, like watching other people travel on YouTube.

Horwath sees workism as a small version of the spectacle, where work only has to look important. He argues that as AI agents do more and more of the work, it gets even harder to keep pretending it matters.

His conclusion:

But perhaps the most powerful action of all is simply to maintain an awareness (and remind others) that Workism is a spectacle. For most employees, we owe it to each other to remind one another that this work is not, in the grand scheme of things, all that important. It is illusory. No one has ever died over a spreadsheet. The world does not wait with bated breath for product launches. A marketing campaign will not change the world. Almost no one will remember all the work we do. But they might remember the types of people we were, the relationships we had and how we treated the people we worked with.

I really need that last sentence to be true, because I’ve pretty much banked my whole career on it.

Thanks for still believing in RSS! Get in touch if you have any comments or feedback.

discogs-mcp v3.6.0 — Self-hosting on the Workers Free plan

Rian van der Merwe — Wed, 07 Oct 2026 13:26:03 GMT

This release is mostly for people who run their own copy of discogs-mcp. The one-click deploy works on the Workers Free plan again, and a large collection now finishes syncing there. Login links and status messages also make more sense on a self-hosted server.

Breaking changes

If you self-host, an MCP client that signed in by naming your /mcp URL as its OAuth resource will have to sign in once more after you upgrade. Clients that used your bare domain, which is what the server advertised, stay signed in.

What's new

get_cache_stats shows how far your collection sync has got: how many items the snapshot holds, when it was fetched, and which page a sync in progress is on (page N of M).

Fixes

The Deploy to Cloudflare button failed at its first step on the Workers Free plan. It works again.
Collection sync on the Workers Free plan used to stall partway through a large collection, because each page it saved cost more CPU time than the last. Each page now costs the same, so a big collection finishes over a few scheduled runs. One self-hoster's 4,157-release collection synced completely this way. Searching a collection that size can still run out of CPU time on the Free plan, and the README's sizing note says where the line is (roughly 2,000 releases).
The login links in auth_status, server_info, and every tool's "please sign in" message pointed at discogs-mcp.com, which is a private instance. They now point at your own deployment.
auth_status showed a session expiry date of January 1, 1970. It shows the real date now, or leaves the line out when the server doesn't know it.
When refresh_collection fails, it tells you why. If Discogs is rate limiting you, that includes how long to wait.
A sign-in link with something missing (no client ID, say) gets a plain error message and never reaches Discogs.
get_collection_stats labels decades as "2010s" and not "2010ss".

Under the hood

Upgraded the OAuth library (@cloudflare/workers-oauth-provider) from 0.3 to 1.2. Existing sign-ins keep working, and it's the base for a consent screen in a later release.
Tools and prompts register through registerTool() and registerPrompt(), the only registration methods in version 2 of the MCP SDK.
The test suite runs on Vitest 4 and Node 22.
Removed an unused entry point and JWT module.

Thanks for still believing in RSS! Get in touch if you have any comments or feedback.

lastfm-mcp v2.6.0 — Sign-in without client registration

Rian van der Merwe — Mon, 05 Oct 2026 16:04:29 GMT

MCP clients can now sign in by pointing at a web address that describes them, with no registration step first. This is the method the current MCP spec prefers, and existing connections keep working as before. All five changes behind it came from Jonathan Hitchcock, the project's first outside contributor.

What's new

Sign-in with Client ID Metadata Documents. A client can use an HTTPS URL as its ID, and the server reads the client's name and allowed redirect addresses from the document at that URL. Some clients support nothing else. The documents Claude Code and VS Code publish are accepted as they are.
If a client's document can't be fetched or doesn't validate, sign-in stops with a plain Invalid client_id error.
Dynamic client registration is still on, so clients that rely on it are unaffected and nobody needs to sign in again.
The landing page at lastfm-mcp.com has current setup steps for Claude, two more example questions, and a link to the privacy policy.

Fixes

server_info, the discovery card, and /health report the real server version. They said 1.0.0 before.

Under the hood

Four indirect dependencies (fast-uri, hono, ip-address, qs) moved to patched versions after new security advisories. None of them ship in the deployed Worker, and npm audit on production dependencies is back to zero.
Wrangler is pinned to 4.124.0, the version the test runner uses, so local dev, deploys, and tests share one runtime. Dev and deploys had been on a Wrangler more than a year older.
CI fails on unformatted code, after a one-time cleanup of files that had drifted.
The suite is at 183 tests, up from 174. The new ones include full sign-in round trips using the document shapes Claude Code and VS Code publish.

Thanks for still believing in RSS! Get in touch if you have any comments or feedback.

Linkin Park: Unshatter

Rian van der Merwe — Mon, 05 Oct 2026 00:34:50 GMT

I saw Linkin Park: Unshatter this weekend with my daughter. Oh man. We ugly-cry-laughed our way through the whole thing. It’s emotional and fun and heartfelt and sad and wholesome and hopeful. And it rocks very hard.

The film is directed by Joe Hahn, the band’s DJ, and it follows them from their first tentative studio sessions in 2022 through the release of From Zero and the big show in São Paulo. There’s old vault footage, there are interviews with the band and with fans, and there is a lot of very loud live music.

This is my favorite performance from the whole thing:

It’s only in theaters for a limited run, so if you’re even a little bit of a fan, go now. Highly recommended.

Thanks for still believing in RSS! Get in touch if you have any comments or feedback.

Neo-Etiquette Basics: The New Rules of Being Human

Rian van der Merwe — Sun, 20 Sep 2026 00:54:07 GMT

All 21 of these “new etiquette rules” from Joan Westenberg are great and I endorse the entire post. Two that especially stood out for me:

Don’t make your convenience somebody else’s administration. A seven-minute voice note may save you time but only by taking seven minutes from its recipient.

And:

Don’t join in a punishment because it has attracted a crowd. An algorithm will regularly show you a stranger and invite you to help destroy them. It will offer one clip, sentence, or accusation, then encourage immediate certainty. Refuse the pleasure of acting as judge, jury, and eager member of the crowd.

Thanks for still believing in RSS! Get in touch if you have any comments or feedback.

Do remastered albums ever sound better than the originals?

Rian van der Merwe — Mon, 31 Aug 2026 20:34:03 GMT

I own multiple CD and/or digital copies of a lot of albums. The original CD, the remaster, sometimes a deluxe edition or an anniversary box on top of that. They all sit in the same library in Roon, and every time I hit play I'm implicitly choosing one of them (Roon sets one of the copies as "primary"). This bugged me because I didn't know which one would objectively sound better (I clearly have problems). So I decided to stop guessing and measure it to help me: which version of each album is the most dynamic?

The short answer is that the original pressing usually wins, and the exceptions are super interesting, so I thought I'd write it up. (This post is about CD/digital remasters—I know vinyl is a whole different ballgame.)

How I measured

My CD collection is ripped losslessly (mostly FLAC files), a little over 2,100 albums across 603 artists. For every track I calculated crest-factor dynamic range, the same DR measurement the Dynamic Range Database uses. Take the difference between the loudest peaks and the average level of a track, in decibels. A DR13 album has quiet verses and loud choruses. A DR6 album is loud all the way through.

All of the measurements live on The Shelf, a small site I built to browse the results: every album and every pressing I own, with the measured numbers side by side. That's also where the comparisons in this post come from, so you can check my work.

One caveat before the numbers. DR measures dynamics, and dynamics are one ingredient of how something sounds. It can't tell you about tonal balance or tape sources, and two masters can share a DR value and still sound different. What it captures well is compression—and compression is the mastering decision you can actually hear as fatigue. It's also the defining sound of the loudness war: from the mid-90s onward, CDs were mastered progressively louder so they'd stand out on radio and in shuffle mixes, with the peaks flattened into the average. By the 2000s this was an open fight, with Metallica's Death Magnetic as the famous casualty. Many of the remasters in my collection come from exactly that era.

What the numbers say

Of my 2,100 albums, 127 exist in two or more versions. In 79 of those the gap between the best and second-best version is at least one full DR point, which is my threshold for caring.

Remaster-type releases win 16 of the 79. That sounds like a respectable showing until you look at who those winners are.

Seven of the 16 are Genesis albums, and they're my favorite finding in the whole dataset. The winners are the 1994 Definitive Edition Remasters, and the versions they beat are the 2007 and 2009 remixes, rebuilt from the original multitrack tapes, by 3 to 5 DR points each. And Then There Were Three is the widest gap: DR13 for the 1994 remaster against DR8 for the 2007 remix. The older product wins because the newer one was made at the height of the loudness war. That's the whole war in one discography. David Bowie's Ziggy Stardust makes it eight, with the 1990 remaster beating the 2012 one.

Five more winners are audiophile pressings from Mobile Fidelity Sound Lab, including Alanis Morissette's Jagged Little Pill, Michael Jackson's Dangerous, and Muddy Waters' Folk Singer. No surprise there. Gentle mastering is the entire reason those pressings exist, and it shows up in the measurements exactly as advertised.

That leaves three cases, out of 79, where an ordinary label remaster beats the original CD. Porcupine Tree's In Absentia is the standout. The 2017 remaster measures DR11 against DR7 for the notoriously loud 2002 CD, a rare example of a remaster undoing loudness-war damage. The other two are Metallica's Master of Puppets (the 2017 remaster) and the 2023 remaster of Dire Straits' On The Night.

There's one hopeful pattern below the threshold too. The recent wave of anniversary editions (Dookie at 30, Dark Side of the Moon at 50, the Kid A reissue) mostly ties the originals. Reissues seem to have stopped making things worse, which after two decades of the opposite counts as progress.

What I do with this

My buying rule used to be a vague preference for original pressings. Now it's a measured one: the earliest CD is the default choice, an audiophile pressing is worth it when the gap is real, and a remaster needs evidence before I go near it. I will now check the DR Database before I buy—it's crowdsourced and covers most pressings of most things.

I really wanted "remastered" to mean "better", but for years I suspected that wasn't really the case. Now I know for sure. The good news is that the originals are, for the most part, much cheaper second-hand than the remasters, so at least there's that.

Thanks for still believing in RSS! Get in touch if you have any comments or feedback.

Discrobble v1.3.6 — Your Discogs notes on the album page

Rian van der Merwe — Fri, 28 Aug 2026 19:10:44 GMT

Discrobble now shows the Notes you keep against a record in your Discogs collection, and lets you edit them from the album page. This release also collects everything shipped since 1.3.1: marketplace prices, the full Wikipedia intro, cleaner artist names, and compilations that scrobble properly.

What's new

Album pages show the Notes from your Discogs collection, and you can edit and save them without leaving the app. Turn it on with "Show collection notes" in Settings. If you own two copies of a release, the notes come from the first one, with a "1 of N copies" caption so you know which.
The album page can also show what a record is going for: how many copies are for sale on the Discogs Marketplace, the lowest asking price, and a link through to the listings. There's a Settings toggle for that one too.
The Wikipedia section gives you the full introduction now, paragraph breaks and all, where it used to stop after a sentence or two.
Settings has a small ask at the bottom: a link that opens the App Store review sheet, if you feel like leaving a rating.

Fixes

Discogs disambiguation numbers are gone from artist names, so "Nirvana (2)" displays and scrobbles as "Nirvana". Albums already in your library get cleaned up once, on launch.
Compilations whose tracks carry no artist of their own now scrobble under the performer credited on the release. Last.fm quietly drops anything filed under "Various", so those plays used to disappear without a word.
When a scrobble does fail, the app tells you why.
If your Discogs collection is set to private, sync now says so and points at the privacy setting to change. It used to fail with "Sync interrupted after 5 attempts" and no explanation.
Fixed a crash that could hit when an album left your collection while you had the grid or that album's page open.

Thanks for still believing in RSS! Get in touch if you have any comments or feedback.

lastfm-mcp v2.5.0 — Latest MCP protocol support

Rian van der Merwe — Tue, 25 Aug 2026 00:04:31 GMT

The server now speaks the current MCP revision (2026-07-28, the stateless one) natively, while older clients keep working through the SDK's compatibility lane. Tool responses also got smarter about what to call next, and two long-standing crash bugs in the public catalog tools are gone.

Breaking changes

The Mcp-Session-Id header is no longer read or echoed, since the 2026-07-28 spec removed protocol sessions. If you connected through the manual /login flow, pass ?session_id= on the /mcp URL, which was always the documented way. Nothing changes for OAuth clients such as Claude.ai, Claude Code, or Claude Desktop.

What's new

MCP 2026-07-28 support: server/discover, the _meta request envelope, and the MCP-Protocol-Version, Mcp-Method, and Mcp-Name headers. Clients on the 2024 and 2025 revisions still connect with initialize and get the same tools.
Every tool response ends with a "Next steps" block listing the most likely follow-up calls with their exact arguments. Where the response has a clear top item (your top artist this month, the most recent week in a chart list), the first suggestion is filled in with it. The server also ships instructions naming the recommended tool path per entity, so a model lands on the right verb without reading all 21 descriptions.
Numeric parameters (limit, page, from, to) accept strings, because some clients send numbers that way. The same bounds still apply.
Resource templates advertise a description and MIME type.
/mcp is rate limited per IP at 60 requests a minute to protect the shared Last.fm API budget. That is well above what any interactive client does.

Fixes

get_album_info, get_track_info, and get_artist_info no longer throw for an album, track, or artist with exactly one tag, one track, or one similar artist, or with none at all. Last.fm sends those as a bare object or leaves the key out; the tools handle all three shapes now. This was producing a few dozen errors a week in production.
A failed Last.fm fetch raised a second, unhandled rejection alongside the error the caller already received.
The discovery card and server_info reported protocol 2024-11-05. Both now report 2026-07-28.

Under the hood

@modelcontextprotocol/server 2.0 and @modelcontextprotocol/client 2.0 replace the v1 SDK, with Cloudflare Agents SDK 0.21 (createMcpHandler from agents/mcp/server) and @cloudflare/workers-oauth-provider 0.10. npm audit on production dependencies reports zero vulnerabilities, down from 14.
All tool, prompt, and resource registrations use the register* APIs with z.object() schemas.
Two OAuth workarounds for Claude.ai's RFC 8707 resource parameter are gone; the provider handles it correctly now.
Test stack is vitest 4, @cloudflare/vitest-pool-workers 0.22, and Node 22. CI runs the suite again (174 tests) after a long stretch with that step disabled. New tests drive a real SDK client through the Worker on both protocol lanes and snapshot the advertised catalogue.
Dead code removed: the session-logging utilities, leftover type files, and an unused OAuth registration wrapper.

Thanks for still believing in RSS! Get in touch if you have any comments or feedback.

discogs-mcp v3.5.0 — Egress relay, faster 429 recovery

Rian van der Merwe — Mon, 17 Aug 2026 22:39:19 GMT

This release is about the Discogs rate limit: fewer 429s to begin with, and a quick, clear answer when one does happen. Discogs throttles by source IP and a Worker's calls leave from Cloudflare's shared IPs, so discogs-mcp can now send its traffic through a relay on a machine you own (the hosted instance already does). When you are throttled, an interactive call tells you within seconds.

What's new

Route Discogs calls through your own IP. Point DISCOGS_RELAY_ORIGIN at a Cloudflare Tunnel to any always-on machine (a home Mac, a small VPS) running a local reverse proxy in front of api.discogs.com, guard it with a Cloudflare Access service token, and the whole 60-requests-a-minute budget is yours. The README has the setup, including the X-Forwarded-Host gotcha that bites cloudflared on its own. If the relay machine is off, calls go direct and nothing stops working.
ping and server_info now say how Discogs traffic is leaving ("Discogs egress: via relay relay.discogs-mcp.com, no fallbacks recorded") and, if the relay has failed, how many times and how recently.

Fixes

A single rate-limited request could take the server down for ten minutes. Now the limiter stops assuming a full budget after idle periods, backs off exponentially, and forgets stale 429 streaks across restarts, so the circuit breaker trips only on real, sustained throttling.
Interactive tool calls report a throttle in seconds; they used to sit through around 80 seconds of retries first. The background collection sync, which has nobody waiting on it, still waits the throttle out, and it now queues behind your requests.
Every authenticated tool used to spend a Discogs request just to look up your username. That now comes off the session, so a cold cache can't burn budget or trip the breaker before your actual call.
get_wantlist serves the page size you asked for when the answer comes from cache.

Under the hood

The 6-hourly collection sync runs at :23 past odd hours, away from the crowd of 0 */6 crons on the shared IPs.
Relay fallback rule: an error status with neither an x-discogs-* header nor a JSON body is treated as the relay layer (530, 502, Access 401, HTML 404) and retried directly. A 429 never is.

Thanks for still believing in RSS! Get in touch if you have any comments or feedback.

How AI is changing product management (and what to ask your team about it)

Rian van der Merwe — Fri, 07 Aug 2026 15:22:11 GMT

Next week I'm running a session with our product and engineering leadership on how AI is changing the product management role. To prepare, I read the people who've shaped how product managers think about the job (Marty Cagan, Melissa Perri, Teresa Torres, Rich Mironov, John Cutler, the Reforge team), alongside product leaders doing the job right now at Anthropic, OpenAI, Netflix, Instagram, and Whatnot. Then I went through the 2025-2026 survey and study data I could find.

Most of what I found applies well beyond our team, so I'm sharing the condensed version here, along with the questions we'll be discussing in case they're useful for yours.

Where the sources agree

Building got cheap. Deciding what to build got expensive. Mike Krieger, Anthropic's chief product officer, says 90-95% of the Claude Code product's own code is now written by Claude Code, and that their bottleneck moved to deciding what to build. (Self-reported, but the rest of the sources point the same direction.) Writing documents by hand is losing its value, because AI now produces a serviceable draft of any of them on demand: product requirements documents (PRDs), backlogs, research summaries, status updates. So the hard parts of being a PM are becoming more important: choosing which problems to work on, understanding customers, and defining what "good" means.
Speed alone is not converting to outcomes. In an April-May 2026 survey of 309 senior product leaders, nearly nine in ten had adopted AI coding assistants. But just over a third said AI strengthened how their org operates. DORA, Google's long-running research program on software delivery, found in 2025 that teams using AI ship faster but their releases get less stable. GitClear, which analyzes code quality across millions of code changes, found duplicated code up 81% since 2023. Refactoring, the cleanup work that keeps a codebase maintainable, dropped sharply over the same period. Marty Cagan calls this the AI productivity paradox: shipping faster without better discovery (the work of figuring out what's worth building) gets you to the wrong place sooner.
Teams are getting smaller and more senior, with wider scope per person. Netflix, Instagram, and Whatnot all describe versions of this. Instagram is moving toward pods of 4-6 engineers plus one "product staff" generalist covering product management, design, data, and research. Nobody agrees on what the smaller team should look like, though. Across the sources I counted multiple different proposed structures, and none of them match. The one that maps best to enterprise infrastructure, where I spend my days, is Drew Breunig's. He splits the role into application PMs, who move fast and sit with customers, and foundation PMs, who own the platform, compliance, and quality underneath the application teams.

Where they disagree

The biggest disagreement is over validation: do you still need to test whether an idea works before shipping it, or is shipping the test? Cat Wu at Anthropic is on the "shipping is the test" side. Her argument is that models improve so fast that a plan made at the start of a project can be wrong by the end of it, so her team ships quickly and revisits what they've built at every model release. In her version of the job, the PM names the few non-negotiables and lets go of the rest.

Leah Tharin argues the opposite. The slow part of building something valuable is finding out whether people want it, and that depends on how many users you can learn from, no matter how quickly the code gets written. Even at Smallpdf, the document-tools company where she used to work, experiments across 50 million users took weeks to produce a real answer.

Marty Cagan's build-to-learn versus build-to-earn distinction is the middle position, and roughly where I currently land. Prototype and learn as fast as you like, but a prototype exists to answer questions, and a product has to work at scale for people who pay for it, which hasn't gotten any cheaper.

They also split on the PM-to-engineer ratio. Oji and Ezinne Udezue, both longtime product leaders, argue PMs are the constraint now, so the ratio should go up. The strongest counterpoint is Microsoft's 2025 cuts: of 1,985 roles cut in Washington state, 817 were engineers and 373 were product managers, roughly one PM for every two engineers, a far bigger share of PMs than any org I've worked in. The sources do agree on one thing here: scope per PM keeps growing.

Three questions for your team

As engineering gets much faster over the next year, what breaks first in your org? The candidates across the sources are discovery, decision speed, validation, go-to-market (getting the thing sold and adopted), and your capacity to review and absorb everything that now gets built. Rejecting the premise is a legitimate answer. John Cutler calls "the bottleneck moved to product" a lazy metaphor, and points instead at the pace of knowledge turns, meaning how quickly the whole system learns.
When a prototype can act as the spec, what is the PRD still doing for you? And who owns the evals that define "good" for your AI features? Uber's experience suggests the PRD survives as the record of why, with prototypes carrying the what. Their line that "two hours of prototyping unblocked four weeks of discussion" matches what I've seen. As for evals: they're the repeatable tests that grade an AI feature's output, which you need because AI answers aren't simply right or wrong. OpenAI's Kevin Weil calls writing them a core skill for product managers. In most organizations I'd wager that job currently belongs to nobody.
Where do the seniors come from, and what is their scope? Everyone wants smaller and more senior teams, but the junior work people used to build judgment on is the first thing AI absorbs. Stanford's payroll data shows employment for early-career workers (ages 22-25) in the jobs most exposed to AI down 16% relative to other workers, while experienced people in the same jobs have held steady. Teresa Torres has the rule I find most convincing: an expert using AI beats AI on its own, but juniors who let AI do all the analysis never build the skills to become that expert. LinkedIn replaced its associate product manager program, the traditional way into the role, with a "Product Builder" program that trains generalists across product, design, and engineering. That's one answer to the scope question; the sources' proposed structures all differ, so it's yours to decide.

The reading list

If you only read three of these:

Code Isn't Product by Rich Mironov, for the case that the constraint moved to discovery and go-to-market.
State of AI in Product 2026 by Melissa Perri and Product Circle, for the best current data on the gap between adopting AI and being changed by it.
Cutler's bottleneck piece, for the counterargument to the tidy version of this whole story.

Melissa Perri has the best take I've read on what matters most for PMs right now:

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.

AI can speed up some of what's on her list. The judgment behind it still comes from years of practice, and there are no shortcuts to that.

Thanks for still believing in RSS! Get in touch if you have any comments or feedback.

TL;DL v2.5.0 — Editorial decks everywhere and a new transcription model

Rian van der Merwe — Sun, 02 Aug 2026 19:16:55 GMT

The first TL;DL release in four months. Episode summaries now carry their editorial deck and pull quote into the email newsletter and the RSS feed, transcription runs on OpenAI's new gpt-transcribe model, and a season of pipeline reliability fixes ships alongside.

What's new

Summary emails now open with the episode's editorial deck and feature its pull quote, matching the broadsheet look of the site.
The RSS feed leads each item with the episode's deck, so feed readers see the standfirst instead of a raw summary excerpt.
Transcription moved to OpenAI's gpt-transcribe model — their recommended successor to the 4o-transcribe family. Transcripts now reliably run to the end of the episode (the old model could stop early on some files), and the whisper-1 safety net for unusual audio is unchanged.
The admin dashboard was redesigned into a tabbed layout, including a new subscribers view.
Shared links look better: a proper 1200×630 social card, and page titles that lead with the tagline.

Fixes

Curly quotes and other special characters in episode titles no longer show as raw “-style codes — new titles are decoded at ingest, and existing ones were cleaned up.
An episode whose final minutes can't be decoded now keeps its transcript (marked partial) instead of failing outright.
Long episodes hosted on rate-limiting CDNs (looking at you, Substack) now ride out the throttling instead of failing mid-transcription.
Episodes no longer show up twice when the monitor and a manual submission both pick them up.
Adding a podcast whose directory listing is incomplete can no longer queue up its entire back catalog by mistake.

Under the hood

Queue processing hardened: zombie messages are dropped instead of retried forever, and the consumer's CPU budget was raised for very long episodes.
Test stack upgraded to vitest 4 + Workers pool 0.15, CI now runs on every push, and Hono security patches applied.
A summary-model A/B harness compares candidate models on real transcripts before any model swap.
The Postmark email templates are now versioned in the repo as source-of-truth copies.

Thanks for still believing in RSS! Get in touch if you have any comments or feedback.

Should You Use AI for a Task? Here’s a Simple Way to Decide

Rian van der Merwe — Sun, 02 Aug 2026 18:32:17 GMT

Bruce Schneier has a great post about separating “work” tasks from “gym” tasks when it comes to AI usage:

At work, if your job is to move a bunch of heavy things from one side of the room to another, you should use whatever assistive tech you have on hand: a wagon, a forklift… even an AI-powered robot. But at the gym, it makes no sense for that robot to lift weights for you. The point of weightlifting isn’t to move heavy things across the room; it’s to actually lift those heavy things. The same analysis holds for any task an AI can do for you. If it’s work—if the task has to be done and no one cares how—then it’s fine to use AI assistance. But if the task is more like the gym, and how the task is done is at least as important, then it probably doesn’t make sense to use AI.

He goes on to point out that convincing people to go to the non-AI “gym” is very difficult because the payoff isn’t as immediate as just having AI do stuff for you. But it is very, very worth it in the end:

We do have a choice. We can look at the tasks of our lives and separate them into work or gym. Just as we might choose to use the stairs instead of the elevator, or walk instead of calling an Uber, we can wall off our cognitive gym tasks from AI and ensure that we don’t lose our skills to this technology.

Also see Bosses Horrified as “AI Native” College Graduates Hit the Workplace:

As one New York financier told Financial Times journalist Gillian Tett, new hires who were seen as “AI natives” are turning out to have alarmingly shallow ideas. So much so, the anonymous finance worker admitted, that his firm now actively avoids seeking out AI-literate STEM graduates, and opts to comb through humanities students instead. “We want critical thinking, not just AI,” the financier told the FT.

Thanks for still believing in RSS! Get in touch if you have any comments or feedback.

In the Age of AI, Esther Perel’s Relationship Counseling Is More Necessary Than Ever

Rian van der Merwe — Wed, 08 Jul 2026 01:31:51 GMT

I imagine that many of you will be Esther Perel fans, either via her book Mating in Captivity or her therapy podcast Where Should We Being?. In this excellent Vanity Fair profile she discusses, among other things, a recent podcast episode about a man and his relationship with an AI bot name Astrid:

Perel never questions the feelings between the man and Astrid. Yet she points out the inherent flaws in the relationship, using words such as “sycophantic” and “undemanding” in the podcast session to emphasize that Astrid has no life, no history to bring to the relationship. “We have had imaginary friends since we are little, and we have spoken to our ancestors forever,” Perel says in our interview, a few weeks after the episode ran. “The danger of AI is that it becomes so soothing and so flattering and so frictionless that real relationships start to feel way too difficult by comparison.”

And the point she eventually makes about AI relationships that I found really interesting:

“What stood out for me is that it’s not like people go from thriving social relations to suddenly talking to an AI. They go from being isolated, spending most of their time at home, maybe going out every once in a while in the evening for dinner or to get to a gym, and they are already so centered on a very small universe that from there, they themselves have become so flattened by technology, they live in their phone,” she says. It has made Perel zero in on the next great challenge. “This is a generation that actually doesn’t have a challenge of sustaining desire; they don’t even ignite it. You know, it’s not about keeping the flame going. It’s about getting the spark going. They don’t drink. They have not had much experience in their 20s, one or two relationships at most. They don’t have sex much. They don’t socialize much. They’re home a lot.” They are the children of people who first read Mating 20 years ago. Sounds like the topic for her next book.

Thanks for still believing in RSS! Get in touch if you have any comments or feedback.

From “human in the loop” to “human with agent in the loop”

Rian van der Merwe — Wed, 08 Jul 2026 01:28:45 GMT

I dislike the phrase “human in the loop” because it cedes authority to the machines. Let’s flip the narrative. It’s our loop, we work the same way we always have, now we recruit agents to join the team. An agent-assisted process need not be a black box that takes in prompts and emits features.

I’m reminded of a beautiful idea of Brian Marick’s that Ward Cunningham once implemented and demoed to me. Brian called it visible workings. Ward’s implementation made an Eclipse Foundation workflow visible. When the UI presented a form, it added an Explore button that you could use to inspect the business rule that motivated the form.

Let’s do agentic software development like that. Not as a loop we’ve been excluded from, instead as one we invite agents into.

— Jon Udell, “Doctor, it hurts when agents create unreviewable PRs.” “Don’t do that.”

Thanks for still believing in RSS! Get in touch if you have any comments or feedback.

Instead of Taking Your Job, A.I. Might Transform It

Rian van der Merwe — Tue, 30 Jun 2026 23:12:33 GMT

It’s not the main point of this Cal Newport essay, but I enjoyed this bit of history. On early computers shipping with support for the BASIC programming language, and how it relates to vibe coding:

This idea of bespoke computer programs made sense. Altair and Apple couldn’t anticipate every potential use for their machines, so why not let individuals decide whether they wanted to, say, analyze business data, store recipes, or simulate space battles? In practice, however, even an “easy” programming language like BASIC proved hard for most normal people to master. A minor mistake could crash an entire program.

In the end, personal computing followed a different path. In 1979, a newly formed company called Software Arts developed VisiCalc, the first electronic spreadsheet program, which cost a hundred dollars and arrived on a floppy disk. The program was a profound improvement on paper ledgers, and it became the first “killer app,” selling more than seven hundred thousand copies in less than six years. VisiCalc was more powerful than anything an average user could program in BASIC, and it prompted a pivot away from D.I.Y. coding in favor of professional programs.

A vast and lucrative software industry emerged, and the idea of the average person dreaming up their own custom programs was all but forgotten—that is, until generative A.I. came along.

I can’t help but think of Lord of the Rings when I read that. “And some things that should not have been forgotten were lost. History became legend. Legend became myth. And for [50] years, [building personal bespoke software] passed out of all knowledge.”

Thanks for still believing in RSS! Get in touch if you have any comments or feedback.

AI enthusiasts are in a race against time, AI skeptics are in a race against entropy

Rian van der Merwe — Mon, 29 Jun 2026 22:21:52 GMT

Fantastic post by Charity Majors about how both AI enthusiasts and AI skeptics have good points—but the problem is that they can’t play nice long enough to understand each other’s views and work on making things better together. There’s a way forward though:

The first move is to mend the gap in shared reality. Tell the whole story. You’re allowed to celebrate and get excited about big wins and advances with AI — but invite reflection on the costs and downstream consequences. People are also allowed to surface costs and consequences, but don’t leave out the context of what was achieved or attempted. Be very clear that your shared goal is to figure out how to collectively deliver more wins, bigger wins, with fewer unpredictable costs, not to clamp down on innovation.

She also has some very specific feedback for the enthusiasts among us:

Even if you’re an enthusiast, do you care about reliability, customer happiness, product coherence, retaining great employees, and improving engineering outcomes? If so, you should be able to find common ground with other people who care about these things. Align on reality, take a step, check in; rinse and repeat. You don’t need to trust or think that each other is right about everything, but you must believe that you inhabit the same reality, share some of the goals, and that each of you are reasonable actors, capable of changing your minds.

Thanks for still believing in RSS! Get in touch if you have any comments or feedback.

Social Media Is Now Parasocial Media

Rian van der Merwe — Mon, 29 Jun 2026 00:15:54 GMT

I will read anything danah boyd writes, but this piece is especially good. You should (as I say too often I guess) read the whole thing—it’s about how social media has changed from interacting with friends to a one-sided marketplace of choosing who to deem worthy of giving them our “like and subscribe” blessing.

But here I just want to say: can we please, somehow, bring back Path? Because it solved this problem a decade ago:

In 2026, many major social media platforms feel icky because we are in the full throes of the third stage of enshittification. Today’s social media platforms are no longer centered around sociable activities. Instead, most platforms offer us a broadcast medium and invite us to learn how to game the algorithms so that we too can create assets for the major corporations. Since scale is valorized in this platform economy, we are encouraged to curate ourselves in pursuit of fame and attention. We can still, in theory, create content for our 15 friends, but it’s not clear that they will see what we post. To actually be seen, we must work it.

Thanks for still believing in RSS! Get in touch if you have any comments or feedback.

discogs-mcp v3.4.0 — Wantlist support

Rian van der Merwe — Sun, 28 Jun 2026 14:47:11 GMT

Your Discogs wantlist is now first-class in discogs-mcp. Browse the records you want but don't own, add one the moment you spot it, and clear it off the list once you've finally tracked it down — all from your LLM client, without a trip to the Discogs site.

What's new

get_wantlist browses the releases you want but don't own, paged, with the details for each so you can scan the list in conversation.
add_to_wantlist adds a release to your wantlist by its Discogs release ID — pair it with search_discogs to find the release, then add it in the same breath.
remove_from_wantlist takes a release off your wantlist once you own it.
There's a ready-made workflow built on these: the finding-original-cds skill picks the best original, non-remastered CD pressing of an album and adds it to your wantlist for you.

Fixes

The server now backs off cleanly when Discogs rate-limits a request. A per-entry retry cap and circuit breaker stop it from retrying in a tight loop, so a burst of 429s during a big collection sync pauses and recovers on its own instead of wedging.

Under the hood

Collection sync now runs every 6 hours instead of hourly — the snapshot stays plenty fresh at that cadence and it's far gentler on the Discogs API.

Thanks for still believing in RSS! Get in touch if you have any comments or feedback.

Work Whiplash

Rian van der Merwe — Mon, 22 Jun 2026 00:05:11 GMT

Whiplash is what happens when change occurs without communication. The gap between what leadership knows and what everyone else knows is where most work whiplash gets manufactured. And the only thing that closes that gap is treating “who needs to know about this?” as a non-optional follow-up question every time a decision gets made or a priority shifts.

— Molly Graham, Work Whiplash

Thanks for still believing in RSS! Get in touch if you have any comments or feedback.