Yesterday, I shared what I built: four automated podcast feeds generated from my daily information diet that run without my intervention.
Today I’m sharing how it works, and just as importantly, what it actually takes right now.
I’ve built a working system, not a demo.
It consists of four automated feeds—news, professional updates, deep thinking, and healthcare—delivered daily as audio. There’s no recording, no editing, and no production pipeline in the traditional sense. The system runs end-to-end and produces something I actually use.
Take a listen. I think it’s instructive - a super-clear summary up front, and then discussion and even insight, synthesized from the different newsletters.
The GitHub repository is here. If you’re the kind of person who learns by pulling things apart, fork it and see what breaks.
The stack looks like this: Gmail → Claude Desktop (via MCP) → NotebookLM → element.fm → Apple Podcasts.
Each component plays a specific role. Gmail serves as the intake layer for newsletters and other inputs. Claude, connected via MCP, orchestrates data movement between systems. NotebookLM performs structured synthesis, turning raw content into usable summaries. element.fm converts those outputs into audio feeds, and Apple Podcasts acts as the distribution layer.
The system works because the wiring is now available. The leverage comes from recognizing what can be built, then figuring out where that wiring exists and how to connect it.
I didn’t start with tools. It started with an itch I thought I could scratch with my product instincts.
It takes too long to read the newsletters I subscribe to. What if I could listen to them? On Apple Podcasts?
I was already familiar with Google’s NotebookLM. It’s a tool purpose-built for hallucination-free learning and communication. It reliably synthesizes multiple source documents into slides, infographics, and audio files. Before this initiative, that feature was uninteresting to me. For this project, it’s foundational.
From there, the remaining question was how to connect the pieces. I don’t need to build a product; I need to connect systems that already exist. MCP provides the wiring to do that.
Finally, how do you get the audio files from NotebookLM into Apple Podcasts?
Fifteen minutes with ChatGPT, and the answer was apparent: route them through element.fm.
That shift—from building to connecting—is the point. I spent my time composing the system, not constructing it.
This part tends to get glossed over, but it’s where most of the actual work happens.
The workflow is not clean. Tools fail silently, connections break, and some steps require manual restarts. Error messages are often incomplete or misleading, which means progress depends less on technical expertise and more on how you respond to ambiguity.
What’s required is not engineering depth, but a willingness to stay with the problem. You need to be able to read an error without overreacting, isolate the failing component, and take the next reasonable step. That’s the current barrier—not credentials or background, but a willingness to think through unfamiliar problems.
The “bumpy edges” showed up quickly.
The first was around integration. Currently, there’s no MCP-based way to pull outputs directly from NotebookLM.
On the other side, element.fm was a good fit for hosting—free, API-accessible, and simple—but it doesn’t have MCP support either.
That gap matters. It means the system doesn’t fully “snap together.”
The workaround was to introduce a small amount of wiring code: pull the generated audio files down, translate them into a format element.fm accepts, and then push them via its API.
I didn’t write any of that code. Claude did. My role was to know what needed to exist and to guide Claude toward that solution.
That’s the pattern right now. The limitation isn’t whether the system can be built. It’s whether you can imagine what’s possible, and decide the best approach to realizing it.
An MCP integration would remove most of this. It will likely happen. And if it doesn’t, it’s straightforward enough to build.
The second set of challenges was operational, and they’re more familiar.
What happens when part of the pipeline fails? How do you know where it stopped, and how to resume? What if inputs arrive late? What does a re-run do—overwrite, or append? What happens if you miss a day?
These aren’t new problems. They’re the same failure modes you see in any production system.
The difference lies in how much time and emotional energy I had to spend on hardening these parts of the system.
In several cases, Claude was able to identify what had broken, propose a fix, and implement it. That’s not hypothetical “agentic” behavior—that’s practical debugging and recovery happening in-line.
None of this is unusual. It’s a representative slice of the edge cases that made this slower and messier than the ideal version.
Even so, the build was an order of magnitude faster than it would have been without AI-assisted development.
And the trajectory is clear. Many of these limitations will disappear over the next few months, either as integrations improve or as the systems themselves learn to handle them.
In practical terms, the requirements are straightforward: a Claude Pro account, a weekend, and a reason to care about your information diet.
You don’t need to be an engineer. But you do need to be persistent enough to work through things that don't function correctly on the first attempt, because they won’t.
The tools are available to almost everyone. The difference is whether you treat them as tools or as thought partners.
The moment you start asking, “What if I could…” you begin to see different patterns for how problems can be solved. Over time, you start to reframe the problems themselves.
That shift compounds quickly. In my experience, it’s something you have to go through to understand.
And once it happens, you operate differently.
I’ve spent a career inside transitions like this—helping developers move from stateful systems to stateless architectures, guiding teams through the shift from monoliths to distributed systems, and introducing analysts to repo-based workflows that improved quality without slowing them down.
The pattern is consistent. A small group figures it out early, a larger group adopts once it stabilizes, and another group waits until it becomes unavoidable.
The highest-leverage role isn’t just building the system. It’s making it understandable to other people.
David Epstein describes this as “living at the seams”—operating between domains and translating shifts as they happen. That’s where this work sits.
This is not a future transition. It is already changing how work gets done inside current roles and teams.
Two people can sit in the same meeting, have access to the same tools, and operate at entirely different levels. That divergence is new, and it’s accelerating.
This is as fundamental to modern work as Microsoft Excel was when it was introduced.
Before Excel, financial analysis required specialized tools and dedicated analysts. After Excel, anyone could build models, run scenarios, and explore questions on their own.
That shift wasn’t about speed. It was about access, opportunity, and who gets to do the work.
What made this system work was accumulated context: understanding what fragile systems look like, recognizing when to push versus when to wait, and developing intuition for how tools fail in practice.
That kind of judgment doesn’t appear immediately, but it also doesn’t need to be rediscovered individually.
That’s why this is documented in public: not to showcase the system, but to make it usable by anyone else.
Tomorrow I’m stepping back from the mechanics.
The more important question isn’t whether you can build this. It’s what happens to your team, your organization, and your community when some people do—and some people don’t.
dhkondata covers AI adoption for practitioners—real workflows, documented in public. Subscribe to follow along.
.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.