Elezea - RSS Feed

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.

Stand out of our Light

Rian van der Merwe — Sat, 18 Apr 2026 01:07:15 GMT

It’s my firm conviction, now more than ever, that the degree to which we are able and willing to struggle for ownership of our attention is the degree to which we are free.

– James Williams, Stand out of our Light: Freedom and Resistance in the Attention Economy

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

Is Hip-Hop in Decline? A Statistical Analysis

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

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

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

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

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

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

I am finally — FINALLY — off WordPress

Rian van der Merwe — Thu, 16 Apr 2026 02:24:03 GMT

A quick meta-post incoming! This site has been running on WordPress and Dreamhost for 18 years. It worked fine, but the overhead was really starting to get to me: a MySQL database, monthly hosting costs, plugin updates that arrive every other week, and embarrassing page load times...

I've wanted to move to a static site for years, but it felt impossible. Every time I started to think about it I just gave up. How do I migrate 1,700 posts without breaking almost 20 years of URLs? What do I do about search? The Last.fm widget? Email routing? The existing CSS? There were too many things I didn't know I didn't know, so I never got very far.

A few months ago I started working on a fresh migration plan with Claude Code, using the obra/superpowers skill set. Not to write code yet, but to think through the plan. What's the best long-term architecture for a move like this? What's the actual order of operations? Where are the traps?

We iterated on it many times over several weeks. Each pass surfaced something I hadn't thought about: redirect strategy, shortcode handling, whether my existing CSS depended on WordPress-specific class names, email routing before cancelling the old host, rollback options if something went wrong... The plan got longer and more detailed, but it also got clearer. What had felt like an insurmountable thing gradually became something with known phases, concrete steps, and tradeoffs I could actually evaluate.

By the end of the planning process, the migration had a 1,300-line plan covering everything from exporting WordPress content to the DNS cutover runbook. And then Claude and I did the actual migration... in a single weekend.

So WordPress and Dreamhost are both gone. What you see here now is Astro, deployed to Cloudflare Workers, with no database and no server-side runtime. Content lives as Markdown files in a git repo. Search runs entirely client-side via Pagefind. And of course, it's also the fastest the site has ever been.

A lot of people I know have a project like this — something they've wanted to do for years, have started and abandoned, and have filed away under "someday." It stays there because the project doesn't feel possible. You can't begin to think of all the complexities involved, so you just don't start.

I think we've learned now that AI is pretty good at making work legible. If you iterate on a plan long enough the project stops being a vague, scary thing and becomes a checklist you can actually run through. So hey, find your "I'm free" thing. It might be more doable than it looks.

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

Evals Are the New PRD

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

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

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

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

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

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

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

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

No One Else Can Speak the Words on Your Lips

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

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

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

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

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

Zombie Flow

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

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

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

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

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

AI might actually need more PMs

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

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

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

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

Eight years of wanting, three months of building with AI

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

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

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

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

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

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

Endgame for the open web

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

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

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

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

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

Negative space in writing

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

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

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

And:

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

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

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

Agentic manual testing

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

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

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

And:

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

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

From Assistant to Collaborator: How My AI Second Brain Grew Up

Rian van der Merwe — Sat, 14 Mar 2026 15:13:36 GMT

Over the past few months I’ve been writing about how I use AI for product work. The first post covered the philosophy: context files, opinionated prompts, and how to compose the right inputs for each task. The second added slash commands and daily summaries. The third was a hands-on setup guide. And the fourth introduced project brains for keeping complex initiatives organized.

This post covers a different kind of change. The earlier additions were incremental: more commands, better context, smoother workflows. What changed recently feels more like a threshold. The system graduated from a tool I invoke for specific tasks to something closer to a collaborator I dispatch to do real work. Three capabilities drove that shift: multi-agent orchestration, cross-session memory, and the encoding of domain expertise into the system itself.

Multi-Agent Workflows

The clearest example is customer escalation investigations. As a PM for data products, I regularly investigate customer-reported issues: logging gaps, data discrepancies, behavior that doesn’t match expectations. These investigations require pulling information from multiple sources and cross-referencing it all into an analysis that engineering can act on.

I built a slash command that handles this as a multi-phase workflow. When I run it with a ticket ID, here’s what happens:

The system reads the customer ticket, extracts the core problem, identifies which product area is involved, and classifies the issue type.
Three specialist agents launch simultaneously, each focused on a different data source. One searches the codebase for the relevant logic and recent changes. Another searches for related tickets and prior incidents across projects. A third checks documentation and internal wiki pages for relevant operational context.
A fourth agent receives the combined findings and produces database queries that can confirm or refute the working hypothesis.
The system combines everything into a structured analysis: issue classification, root cause anchored in code where possible, customer impact, and recommended next steps.
A blind validator independently re-fetches every source cited in the draft to verify the claims hold up. Then an adversarial challenger looks for alternative explanations and tests whether the classification is correct.

The output is a document I can review with an engineering colleague or paste into a chat thread. It includes a confidence assessment and a data collection status table showing what was checked and what was unavailable, along with how the analysis compensated for gaps.

The command file that orchestrates all of this isn’t prompting in the traditional sense. It defines which agents to dispatch, what information each one needs, when to wait for results before proceeding, and how to handle failures gracefully. Writing this felt more like designing a workflow than writing a prompt.

I’ve applied the same pattern to other tasks. A “fix feasibility” command evaluates whether a ticket describes a code change simple enough for a PM to implement with AI coding assistance, and produces an implementation brief if the answer is yes. The specific use cases differ, but the architecture is the same: break the problem into specialist tasks that run in parallel, then synthesize and validate the results.

Cross-Session Memory

AI conversations are stateless by default. Every new session starts from zero, which means re-explaining context that should already be established. Over a few weeks of working on the same projects, this friction adds up.

I addressed this with a four-layer memory system:

The first layer is stable facts: a compact file that captures the current state of all active work, including project status, recent decisions, and environment constraints. This is the primary orientation file. When I start a session, the AI reads it and immediately knows what’s in flight.
The second is a session log: a reverse-chronological list of handoff notes. Each entry records what happened in a session and what threads remain open. The last three entries give enough context to pick up where I left off.
Third, a corrections file. This holds behavioral fixes for things the AI consistently gets wrong. It’s a staging area that should shrink over time as fixes get promoted elsewhere.
And finally, a decisions log: a cross-cutting record of decisions that don’t belong to a specific project. Each entry captures context and rationale so I don’t relitigate settled questions.

Two commands manage this. /session-start loads all four files and presents a brief summary of current state and recent sessions. /session-end reviews the conversation, writes a handoff note, and then checks whether any learnings should be promoted to infrastructure.

“Promote to infrastructure” means taking something learned during a session and baking it into the files the agent actually reads. A correction about how to handle a specific edge case in escalation investigations might start in the corrections file, then get promoted into the escalation command or a domain skill once it’s validated. The corrections file shrinks over time as knowledge graduates into the right places.

This creates a loop where the system improves its own instructions. I approve every change, so it’s not self-modifying in a creepy way. But in practice each work session can make the next one slightly better, and the compound effect over weeks is noticeable.

Domain Expertise

The earlier posts described skills like pm-thinking, which applies product methodology (problem-first thinking, measurable outcomes) to any PM-related conversation. That’s useful, but generic. It works the same way regardless of what product you’re building.

The bigger shift was building skills that encode institutional knowledge about specific products. I now have skills for each major product area my team owns: log delivery, analytics, audit logs, alerting, and data pipelines. Each skill contains the product’s architecture and common failure modes, along with which code repositories to search and which database tables hold relevant data.

This is what makes the multi-agent workflows genuinely useful. When the code investigator agent examines an escalation about missing logs, the domain skill tells it which service handles job state and which repository contains the delivery pipeline. It also flags recent architectural changes that might be relevant. Without that context, the agent produces plausible-sounding analysis that misses the specific details engineering needs.

Now every investigation that uses a skill validates or extends the knowledge it contains, and /session-end catches insights that should be added back.

How The Work Changes

A few practical observations from working this way:

The role has shifted from “write the right prompt” to “design the right process.” The escalation command is a workflow with phases, dependencies, and validation steps. Thinking about it that way produces better results than trying to pack everything into a single conversation.
Validation has to be built in. The blind validator exists because agents make mistakes. They cite files that don’t exist, mischaracterize what code does, or draw conclusions the evidence doesn’t support. Catching those issues before they reach anyone else is the whole point.
Cross-session memory requires discipline. The system only works if I run /session-end after substantive sessions and keep stable facts current. When I skip it, the next session starts cold and I lose the compounding benefit. Automation helps, but the commitment to maintain the memory is mine.
And domain skills need regular maintenance. Products change. Code gets refactored, pipelines get rearchitected. Skills that aren’t periodically updated drift from reality. I haven’t solved this well yet. It’s still a manual process of noticing when a skill’s knowledge is stale and updating it.

The system still makes mistakes. Multi-agent workflows are more thorough than single-prompt conversations, but they’re not infallible. The confidence assessment in the escalation output exists because sometimes the answer is “medium confidence, we couldn’t confirm this from the available data.” That honesty about limitations is more useful than false certainty.

Where This Is Going

I’m sure the specific commands and skills will look different in six months as I learn what works and what doesn’t. But the underlying pattern feels durable: compose specialist agents with deep domain context, validate their output, and feed learnings back into the system.

I’ve published updated files to the Product AI Public repo, including the session memory commands and a generalized version of the multi-agent escalation workflow. If you’re building something similar, those might be useful starting points.

The value of this system is in how the pieces reinforce each other. Domain skills make agents useful for real investigations. Session memory means the system gets smarter over time. And the promote-to-infrastructure loop ties it together, so each piece of work has a chance to make the next one better.

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

When Using AI Leads to “Brain Fry"

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

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

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

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

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

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

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

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

AI should help us produce better code

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

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

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

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

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

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

On Meeting Your Child Again, and Again

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

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

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

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

Why It's Still Valuable To Learn To Code

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

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

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

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

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

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

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