I Kept Finding One More Place This Bug Was Hiding

In the last post I wrote about my episode links 404ing in the newsletter and on social. I fixed it, ran the numbers, felt good about it. Then I kept finding the same bug in one more place.

The bracket that wouldn't die

The newsletter fix relied on one rule: when the copy needs a link, put in the placeholder [EPISODE_URL], and I'll swap it for the real address before anything ships. That rule is written into the prompt twice.

The AI ignored it anyway. Going back through what's actually gone out to subscribers, I found 23 different versions of that same bracket. [Link to Episode] showed up eleven times. [Listen Now]. [PODCAST_LINK]. One that just made up an entire fake episode title inside the brackets. On top of that, thirteen emails opened with Hey [Name], because the model was writing a form letter to nobody in particular.

None of that is a typo. It's a model doing what models do: following the spirit of an instruction instead of the letter of it, and inventing its own wording when the exact phrase doesn't come to it. Telling it more firmly wasn't going to fix that. So instead of trying to make the AI more obedient, I built one function that recognizes "this looks like a spot for a link" no matter how it's worded, and made every place that builds a newsletter or a social post run through it. Same fix as before: if a real link resolves, it goes in. If nothing does, the line comes out. Names get quietly dropped rather than the whole sentence, since a newsletter isn't written to one person.

Then the buttons

While that fix was in review, I went looking for the follow-up I'd already flagged: a couple of spots in the app that build a share link by hand instead of using the fixed version. I found five.

Two of them were the ones I already knew about, on the immediate post buttons for X and Instagram. A third was the same mistake on LinkedIn. A fourth was a copy-pasted version of that LinkedIn code sitting on a different screen entirely. And a fifth was the plain "Share Link" button on an episode page, the one I use myself to grab a link and drop it in a text message. That one had been dropping part of the episode number the whole time, so ten of the forty five links it's ever generated didn't work. Nobody had told me. I only found it by clicking it.

For the buttons that go through our server, the fix was straightforward: stop letting the app hand the server a finished link at all. Send the episode, let the server build the address the same way it does everywhere else. LinkedIn posts straight from the browser with no server in between, so I had to duplicate a small piece of that logic on the browser side. I don't love having two copies of the same rule, but there was no way around it without rerouting the whole LinkedIn flow.

The bug found itself again

Here's the part that made me actually stop. Both fixes landed as separate changes, and when I combined them, the LinkedIn fix turned out to only recognize the exact word [EPISODE_URL], not the 22 other spellings the first fix had just taught the system to catch. It was the same mistake the first fix existed to prevent, sitting in a file that didn't exist yet when I wrote that fix.

I only caught it because putting the two together forced me to look at both at once. If they'd shipped a day apart instead of together, that LinkedIn button would have gone right back to posting a bracket to a live audience.

What's next

The numbers are better. Forty five links that already worked stayed working, ten broken ones got fixed, and over a thousand links that used to point at nothing now either point at real audio or don't show up at all. But I'm done acting like I've found the last one. There's still one more spot doing the old unchecked version, on a different page, and I'm tracking it as its own piece of work instead of assuming this pass caught everything.

If your show runs through PodGlue, none of this changes what you do day to day. It changes how much I trust a "done" after a first pass, which is why I keep going back and clicking the actual thing instead of trusting that the code looks right.