A user complaint about poorly segmented subtitles led to a bug fix that introduced a new, subtle issue. The original problem was that subtitles were split into fixed word chunks, disregarding sentence structure. This led to nonsensical breaks, such as cutting off mid-sentence.The fix involved implementing rules for better chunking, including respecting punctuation and aiming for a specific word count per chunk. A crucial addition was a pixel-width cap for rendered chunks to ensure they fit on screen. This width cap was intended to measure the actual rendered text's width.However, the code measuring the text width incorrectly uppercased the text before measurement. This was due to borrowing a step from a different part of the video pipeline that deliberately used all caps for visual style. Uppercased text in the chosen font is wider than mixed-case text.The measurement was accurate for the uppercased input, but the actual subtitles were rendered in their original mixed case. This discrepancy meant the width guard, believing the text was much wider, forced unnecessary splits. This created one-word chunks, a worse user experience than the initial problem.Crucially, all automated tests passed because the width-measurement function operated correctly on the input it received, which was the uppercased text. The tests did not verify that the measured text matched the text actually rendered on screen. The bug was only discovered by a human watching the rendered video.This situation highlights a common pitfall: separate code paths for production and verification that are supposed to agree on assumptions like text transformations. When these assumptions drift, subtle bugs emerge that automated tests miss. The author suggests sharing transformation functions between paths or regularly sampling and inspecting the actual rendered output as mitigation strategies. Trusting solely in green test suites without human oversight can allow such subtle divergences to persist unnoticed.