Elezea - RSS Feed

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! Feel free to get in touch.

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! Feel free to get in touch.

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! Feel free to get in touch.

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! Feel free to get in touch.

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! Feel free to get in touch.

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! Feel free to get in touch.

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! Feel free to get in touch.

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! Feel free to get in touch.

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! Feel free to get in touch.

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! Feel free to get in touch.

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! Feel free to get in touch.

The Slide

Rian van der Merwe — Sat, 25 Apr 2026 23:34:55 GMT

The single biggest challenge for new managers — giving up the responsibility for the product… for the building. Learning how to give accountability for projects of significance to the team. It's an essential set of complex skills involving trust, communication, and, most importantly, judgment. Failure to understand delegation is failing to be a leader. Senior or not.

— Michael Lopp, The Slide

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

AI Prototyping Is Changing How We Build Products at Uber

Rian van der Merwe — Fri, 24 Apr 2026 15:26:01 GMT

There is no doubt that this post was at least 80% written by AI but I’m not even super mad about it because that is just the way of the world now, and the summary it generated from how Uber works is actually legit interesting:

A prototype without a PRD can drift away from the problem the team intends to solve. A PRD without a prototype can remain abstract, leaving room for inconsistent interpretations. [...] If going from idea to prototype is now fast and cheap, the PRD can no longer be the primary place where ideas are defined. Its value increasingly lies in capturing intent, tradeoffs, success metrics, and decisions.

The PRD as an artifact is in the spotlight right now in a way that I think is really healthy. Should it remain but change its JTBD? Should it be an eval instead? Who knows. Let’s figure it out together...

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

tldl v2.3.0 — Email subscriptions

Rian van der Merwe — Wed, 22 Apr 2026 23:11:37 GMT

Per-podcast email subscriptions for tldl. Pick the shows you care about at /subscribe and the summary lands in your inbox as soon as a new episode is out.

What's new

Per-podcast email subscriptions. Sign up at /subscribe, confirm via double-opt-in, and get an HTML summary email (TL;DL header, red CTA, summary body inline) every time a monitored podcast publishes a new episode.
Preferences management. Returning subscribers can update which podcasts they're subscribed to via a signed /preferences/manage link delivered by email. One-click unsubscribe per podcast, or unsubscribe from everything.
From address on tldl-pod.com. Emails now come from "TL;DL" <summaries@tldl-pod.com> with DKIM and SPF aligned on the tldl-pod.com domain.

Under the hood

New D1 database (tldl-subscribers) for subscribers, subscriptions, and pending confirmations.
Postmark broadcast stream (episode-summaries) with HMAC-SHA-256 signed manage/unsubscribe tokens.
Zone-level rate limiting on POST /subscribe and POST /preferences (5 req / 10 min per IP + colo, 1-hour block).
Double-opt-in flow with throttled per-email pending confirmations.

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

Org Design in the Age of AI

Rian van der Merwe — Wed, 22 Apr 2026 00:15:59 GMT

This post on org design really resonated.

Most companies today are using AI the way you'd use a faster horse — to make the existing structure run a little better. The companies that pull ahead will be the ones willing to ask a harder question: what would we build if we were designing this organization from scratch, today, knowing what AI can do?

We have to seriously rethink the SDLC, design it from scratch in the context of how our own organizations work. It’s not about a global “right” process any more. The question now becomes “How can the humans in our team, at our company, at this point in time, work best together to serve our customers?”

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

The peril of laziness lost

Rian van der Merwe — Tue, 21 Apr 2026 23:31:35 GMT

Oh, this is very good. On the classic take that the core characteristic of outstanding engineers is “laziness”:

The problem is that LLMs inherently lack the virtue of laziness. Work costs nothing to an LLM. LLMs do not feel a need to optimize for their own (or anyone's) future time, and will happily dump more and more onto a layercake of garbage. Left unchecked, LLMs will make systems larger, not better — appealing to perverse vanity metrics, perhaps, but at the cost of everything that matters. As such, LLMs highlight how essential our human laziness is: our finite time forces us to develop crisp abstractions in part because we don't want to waste our (human!) time on the consequences of clunky ones.

The best engineering is always borne of constraints, and the constraint of our time places limits on the cognitive load of the system that we're willing to accept. This is what drives us to make the system simpler, despite its essential complexity.

This is exactly why I practice Fear-Driven Development, and why everything I do in code includes multiple versions of asking Claude Code “do we need this?” and “is this adding bloat?”

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

Two small new things on the blog

Rian van der Merwe — Sun, 19 Apr 2026 20:29:02 GMT

Now that the site is off WordPress, I can finally start doing a bunch of things I've wanted to do for years. Here are the first two:

1. Auto-posting side-project releases

When I tag a GitHub release on one of my side projects — tldl, listentomore, discogs-mcp, and others — a post now appears on this site automatically. Title, tagline, release notes, and a link back to the GitHub release.

I ship a lot of small improvements, and historically none of that work was visible anywhere except the GitHub tab nobody reads. Now it shows up on the blog as a first-class content type.

2. Per-content-type RSS feeds

If you only want the long essays and not my link posts or quotes about other people's writing (or the release notes, for that matter), you can now subscribe to just those. There are six feeds:

Everything — the full firehose
Essays only
Link posts
Quotes
Releases
Summary — titles and descriptions only

I've also updated /subscribe with the full list. And a reminder that RSS is very much alive and well. Get started with What is a Feed?.

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

discogs-mcp v3.2.0 — Catalog-wide search

Rian van der Merwe — Sun, 19 Apr 2026 19:58:22 GMT

Adds search_discogs for catalog-wide queries beyond your own collection, plus two real-world accuracy fixes: owned-marker correctness across pressings, and exact genre/style matching.

What's new

search_discogs tool — search the full Discogs catalog, not just your collection. Default type is master so album lookups don't return duplicate pressings. Results get a ✓ marker when you already own them.
Tool lists in README, marketing page, auth_status, and server_info refreshed with grouped categories (Search, Collection, Folders, Custom Fields, Diagnostics).

Fixes

Exact genre/style matching (#17) — substring matching caused music to match Non-Music, flipping the filter to OR mode and returning unrelated releases. Now uses exact equality per release.
Release-result owned-marker is now strict on release.id. Previously, owning one pressing of an album marked every other pressing as owned too, because isOwned() matched on master_id first. Caught by real-world dogfood on "Christian Scott Stretch Music".

Under the hood

Root CLAUDE.md for Claude Code auto-discovery; removed stale development/CLAUDE.md.
GitHub release workflow auto-cross-posts to elezea.com.

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

tldl v2.2.0 — RSS-first monitoring and audio-URL dedup

Rian van der Merwe — Sun, 19 Apr 2026 18:59:50 GMT

Two meaningful changes since v2.1.0. tldl now detects new podcast episodes directly from RSS feeds with conditional GETs instead of relying on Podcast Index re-crawls, so episodes typically land in the queue within minutes of publication. A second fix catches episodes that get retitled or have their GUIDs regenerated after publication — a surprisingly common pattern in the wild.

What's new

RSS-first monitoring. The monitor now fetches RSS feeds directly with If-Modified-Since / If-None-Match headers, queues full episode metadata without a Podcast Index round-trip, and falls back to PI only on RSS errors. Detection lag drops from "hours" (PI re-crawl cadence) to "minutes" for feeds that update frequently.
POST /admin/rebuild-index. Backfill endpoint now populates audioUrl on every existing index entry so the new dedup check works retroactively.

Fixes

Silent duplicate episodes. Episodes that publishers edited after publishing — new title, regenerated GUID, or both — used to slip past dedup and get transcribed twice. A new audio-URL dedup signal (origin + pathname, query-stripped, lowercased) catches them. Confirmed against a real-world retitle where Lenny's Podcast re-published an episode with a different title + GUID, and 100 historical near-duplicates silently deduped on the first force-check after deploy.

Under the hood

Queue messages carry full episode metadata when the source is RSS, so the consumer branches on rssSourced and skips Podcast Index + iTunes enrichment entirely on that path.
New audioUrl field on EpisodeIndexEntry.
Monitor cron cadence tuned to every 2 hours — RSS conditional GETs keep the feed-scan cost low, and most monitored feeds don't publish often enough to justify the previous 30-minute cadence.

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

What actually changed about being a PM

Rian van der Merwe — Sat, 18 Apr 2026 14:54:37 GMT

I have decided that in this new AI era I will be practicing FDD. Fear-Driven Development. Every time I send a pull request, which happens a lot now, I'm terrified of an engineer sending it back to me and asking me to please stay in my lane and stop sending them slop. So I plan, write specs and implementation plans, test thoroughly, and I don't trust the agent's inevitable confidence.

I'll come back to that, but let me first frame what this post is about. The loudest take on PM work right now is that AI is collapsing the role — that we're one product cycle away from redundancy, or being reduced to prompt jockeys. That hasn't been my experience at all. The job got more hands-on, harder (brain fry is real), but also a lot more fun. What follows is what actually shifted for me over the last 5 months at Cloudflare, what didn't, and a couple of things I got wrong.

What changed

We all ship now. The biggest shift in my day-to-day is that my team and I write code. Not as a vanity exercise or to replace engineers — there is no universe in which I'm touching our data pipeline code. But for prototypes, internal tools, small features, and live bugs or UX improvements that are safe for us to do, we just go ahead and make a PR instead of adding things to the backlog. This quote from one of our EMs sums it up well:

I like these dashboard revamps. Far better if PMs can express their visions for the product directly to Opencode, avoids a lot of back and forth.

This is where FDD comes in. The terror of shipping slop is the thing that keeps me responsible. Telling Claude "hey, build me X" is a fast road to code that doesn't work the way it should, or worse, works but introduces ten regressions along the way. So the pattern I run now is: brainstorm first, usually with a skill that forces me to articulate what I'm actually trying to do; write a spec; turn the spec into an implementation plan; and only then start generating code.

Counterintuitively, the planning is what makes the whole thing faster (and better!). Skip the brainstorm and you'll spend ten rounds of PR review untangling code the model wrote confidently and incorrectly. Plan properly and the build itself is usually the fast part.

Context is the product, and evals are the new PRD. The second change is arguably even more consequential: I spend real time maintaining a context layer. A CLAUDE.md, a library of skills, stakeholder memory, agent routing, a second brain that feeds all of it. None of this was part of my job a year ago, and treating AI as a chat window means missing most of what it can do. My own PM rubrics live inside this layer too. My /okr and /prd commands load the problem-first frameworks and antipattern checklists I'd apply myself, so the first pass on any draft or review is already done before I open the doc.

The same shift is showing up in specs and PRDs. When a document has two audiences (the team building the product and the agent helping them) the writing changes. Ambiguity gets expensive. Rhetorical flourishes don't survive the first load into context. A good spec is one that loads cleanly as context and runs as a plan — that's a different job than writing a memo for stakeholders. Ornella at Braintrust has a good post on how evals are the new PRDs:

An eval is a structured, repeatable test that answers one question. Does my AI system do the right thing? Think of it as a unit test for AI behavior.

Her argument is that in AI-native products the eval suite is what actually defines the product. A PRD says what you want; an eval tells you whether you got it. For PMs, the artifact that matters is the one you can run.

We take more load off engineering. CUSTESCs (our customer escalations) used to take hours and hours of PM and engineering capacity. Someone would dig through Jira, read code across a dozen repos, chase down the relevant ClickHouse tables, check the docs against what the customer expected, and go back and forth for days before anyone had a useful working hypothesis.

Our team now has a /custesc command that does most of that in parallel. It pulls the ticket, runs three agents at once across code, Jira, and the wiki, generates and runs ClickHouse queries to check the leading hypothesis, and passes the draft through a blind validator and challenger before it lands as a classified analysis. Ticket ID to root cause in about 20 minutes, most of the time.

This moves where the investigation work sits. A CUSTESC used to be a tax on engineering. Now I can run the full investigation myself and come to engineering with a classified issue and a working hypothesis, instead of a vague "can someone take a look at this?" One enormous side benefit: I've learned more about our products in the past couple of months than I have in the 1.5 years before that.

What didn't change

Figuring out what to bet on. What to say yes/no to is still the hardest part of the job. AI can lay out the tradeoffs; it can't tell you which user/business opportunities to prioritize this quarter. The roadmap is still a set of bets you own. (What "roadmap" even means in this new world deserves a post on its own, but suffice to say we have fully adopted Now/Next/Later)

Trust with engineers. There is no AI shortcut for being useful to your team over time. Showing up and owning the ambiguous stuff is still the job. The calls no one wants to make are still yours. If anything, PMs being able to prototype makes the line between helping and stepping on toes harder to hold. It's a human line, and it gets redrawn every week.

Owning outcomes when things go wrong. AI doesn't absorb accountability. It won't take the hit in a postmortem, and it won't rebuild trust with a customer after an incident — you will. The hardest moments in the job haven't changed.

What I got wrong

I underestimated the context layer. For the first year I treated AI as a chat tool: ask good questions, get good answers. I thought prompt engineering was the skill. The thing I missed is that skills, memory, agent routing, and the specs you load in are the product. Prompts sit downstream.

I thought adoption would be gradual. I assumed PMs would pick this up on a normal curve: some fast, some slow, most in the middle. What I'm seeing industry-wide is a widening gap between PMs who are willing to change how they work and PMs who aren't. You can see the gap in how fast they investigate a problem, how concretely they argue about a design, and how useful they are to other teams.

Getting started is easy and the early wins are obvious. The hard part is being open to changing your job. 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.

Where this leaves us

I don't know what this job looks like in another year. The pattern of the last few months has been that the ground shifts faster than the opinions written about it, and most of the stable-sounding takes age badly within a quarter. What I'm trying to do is pay attention to what's getting easier, what's getting harder, and what's making me uncomfortable. And reminding myself that "uncomfortable" is usually where the real learning happens.

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