One defunct podcast host left 70 broken audio players across the KaiNexus website. The obvious and known fix was to replace them one at a time. I wanted to see whether AI could help me do it faster without creating a larger mess. And to avoid a lot of drudgery.

Hipcast, our former podcast host, had gone out of business. The audio had already moved to Spotify and other services, but the old embeds remained. Repairing them became a practical test of using AI for continuous improvement.

It also taught me enough to take on a second, larger project: moving our videos from Wistia to Vimeo so we could eliminate an annual expense of $4,000.

Both projects involved far more than asking an AI tool to replace some code. The useful part was combining automation with the same discipline we would expect in any improvement effort: understand the current condition, test on a small scale, build in checks, and stop when something does not look right.

Part One: Replacing the Broken Hipcast Embeds

We (meaning Claude and I) inventoried every HubSpot page (the host for our website) containing a Hipcast reference, then separated current pages from archived or redirected pages. The final migration covered 70 active pages: 62 blog posts and eight site pages with broken or unusable Hipcast players and audio links.

The countermeasure was to replace each dead player with the matching episode from the KaiNexus podcast on Spotify. Spotify seems much less likely to disappear than Hipcast. No online service comes with a lifetime guarantee, but this was an easy risk-reduction decision.

Finding the right episode was not always a simple lookup. Hipcast and Spotify used different identifiers. Titles varied, and the surrounding page sometimes provided better evidence than the title alone. So Claude compared page text, episode titles, and publication dates. Strong matches required multiple pieces of evidence. Claude helped me build the matching process, but ambiguous cases waited for my human review instead of being forced into an automated answer.

We also found a less obvious problem. Spotify for Creators URLs looked valid but did not render correctly when embedded. Each replacement therefore needed the canonical Spotify episode ID and episode URL. A link that looks plausible is not the same as a player that works.

All 70 active pages received verified Spotify episode embeds. Redirected and obsolete pages were intentionally left unchanged. We did not change an ambiguous or unmatched episode without verification.

Why Not Replace the HTML by Hand?

I could have opened every page in HubSpot, searched for the old iframe, found the matching Spotify episode, pasted new HTML, saved the page, and checked the result. Repeating that sequence 70 times would have been drudge work. It would also have created many opportunities to paste the wrong code, miss a page, or overwrite something unintentionally.

That manual process contains several of the eight wastes of Lean: unnecessary motion between screens, overprocessing through repeated copying and pasting, and defects that would create rework. It also misuses human talent. I was needed to judge ambiguous matches and decide when the evidence was sufficient. I was not needed to copy HTML 70 times. I know how to do it, but that's boring. Learning how to use AI and other technology was fun.

With help from Claude, I built Python scripts (meaning, really, Claude built them) that used API calls to inspect content, prepare replacements, and update HubSpot posts and pages. The scripts had to handle two HubSpot structures: the blog-post content field for 62 pages and page modules or widgets for the other eight.

Automation made the repetitive work faster. The testing and safeguards kept that speed from creating a larger problem.

Building Quality Into the Process

Claude separated inspection from execution. The scripts started in read-only mode, and any change required an explicit execute command. Credentials were temporary and entered through hidden prompts to avoid security problems.

We published five pages first and verified the Spotify players on the live site. We then repaired the remaining drafts, ran automated preflight checks, published a second five-page "canary" batch, and checked those pages before publishing the remainder. The process stopped if it found unexpected drift or a verification failure.

This was a form of jidoka: detect an abnormal condition and stop instead of passing a defect forward. The scripts did not continue just because there were more rows to process.

I remained part of the process. I reviewed uncertain matches, checked canary pages in a browser, and decided whether the evidence justified the next step. Claude generated and refined much of the code. It did not decide what a good result looked like.

Here's an example of a page that went from a broken embed to a working one: Control Charts and Why Donald Wheeler Calls Them Something Else.

Part Two: Moving from Wistia to Vimeo

Once the Hipcast project worked, I saw a related opportunity.

KaiNexus was paying about $4,000 a year for Wistia, including analytics features we were not using. Our new marketing directory, Anna, and I determined that Vimeo could meet our actual needs. Moving the videos and replacing the embeds would let us cancel Wistia without giving up video hosting that people relied on.

YouTube could have been an option, but that introduces ads for most users and the risk that a competitor's video gets recommended as related. Or it created the risk that the user went to YouTube and got distracted by videos of sea lions.

The first project gave me a repeatable approach: inventory first, automate what can be repeated reliably, test in small batches, and keep a human decision point before broad changes. This time, I worked with ChatGPT to create a staged migration process using the Wistia, Vimeo, and HubSpot APIs.

I had been happy with Claude, but this was an opportunity to see how ChatGPT would work. It also got the job done.

The scripts transferred the available videos from Wistia to Vimeo and created a verified mapping between the old and new video IDs. They then transformed the current HubSpot drafts so unrelated unpublished work would be preserved. The Vimeo privacy settings also had to remain intact.

We tested five initial publishing canaries. Later, we tested cleaner Vimeo player settings on one page before applying them broadly. Only after those checks passed did we update the remaining drafts and publish the pages sequentially. Each page received a fresh drift check immediately before publication and live verification immediately afterward.

The Verified Results

• 133 HubSpot pages updated: 14 blog posts, 105 site pages, and 14 landing pages
• 161 unique Wistia media IDs identified
• 160 videos migrated successfully to Vimeo
• One unavailable Wistia asset removed without a replacement
• 554 live Vimeo embed occurrences verified
• 133 of 133 live HubSpot pages passed final verification
• $4,000 in annual cost eliminated by canceling Wistia

The final audit found no remaining migrated Wistia IDs, no missing Vimeo IDs, no changed privacy hashes, and no missing clean-player parameters. All 160 Vimeo videos passed the final appearance, privacy, and hash checks.

One representative result is the Capture Ideas from Employees page, where the migrated Vimeo player is live with the intended controls and minimal appearance.

After the final verification, I deleted the temporary HubSpot, Vimeo, and Wistia API credentials. Removing access that was no longer needed was part of finishing the work.

Sharing the Improvement and the Learning

After each project, I documented the improvement in our own KaiNexus instance. The records described the problem, the approach, the checks we used, and the outcome. For the Wistia migration, that included the $4,000 in annualized savings and links to representative pages that anyone could test.

I also posted a shorter summary in our #AI Slack channel. Slack was useful for starting an immediate conversation about how I had used Claude and ChatGPT. KaiNexus gave us the more durable record. A Slack message is easy to notice today and much harder to find six months from now.

That distinction matters. Continuous improvement software should help an organization capture the work, measure the impact, and preserve what people learned. The goal was not merely to announce that these projects were finished. I wanted colleagues to see the method: inventory the current condition, automate the repetitive parts, test with canaries, stop when something looks wrong, and keep a person involved in the decisions.

That makes the learning available for another improvement instead of leaving it in my browser history.

An example of me putting that into KaiNexus:

How I Want to Use AI for Continuous Improvement

AI did not identify the business problems, decide what evidence was sufficient, approve the publishing sequence, or verify the final experience in a browser. Those remained human decisions.

Claude and ChatGPT helped me write and refine tools that could perform repetitive work consistently. The scripts reduced manual effort while the preflight checks, canaries, and stop conditions limited the risk.

I would rather spend my time deciding whether a change is safe and useful than copying HTML from one browser tab to another. The company saved money, the website got better, I learned something useful, and we preserved enough of the method for others to learn from it.

What repetitive, error-prone digital maintenance work is your organization still tolerating because the manual fix seems too tedious? That might be a useful place to combine Lean thinking, human judgment, and carefully controlled AI assistance.