I opened a lesson in my own online course the other day and felt a small flash of annoyance — click into the lesson, stare at a black screen for a beat before the picture shows up, and then partway through it stalls. There was even a stray button that popped the video out into a little floating window in the corner. My machine is fast. My internet is fast. It had no business being this sluggish.

What I like about this story is that Tim — my AI agent — didn't rush to fix it. It didn't jump to "the video's probably corrupt" or "the connection's probably slow" and start hacking away. It dug for evidence first, and what it found was that the thing I assumed was broken wasn't broken at all. So today I want to walk through a bug fix that started with one rule: don't trust what your eyes tell you — go check.

The setup — an online course I just put on sale

A bit of background first. I recently launched an online course teaching people how to use AI to run Meta ads, hosted on our own learning platform. All the lesson videos live on Bunny Stream — a CDN service for video. It encodes your video into multiple resolutions (240p all the way up to 1080p) and serves each viewer from the server closest to them. A little later, the same course exposed a different kind of content-model problem too: one bonus lesson should have been plain text, but the LMS still tried to force it into a video-player shape.

When I first wired the videos into the page, I took the easiest route possible: I dropped in Bunny's off-the-shelf iframe player — basically embedding their whole video-player screen inside my page. Paste it in, it plays, no code to write. Convenient.

But in real use it showed three symptoms: (1) every time I switched lessons, the screen sat black for too long; (2) playback stalled in fits and starts; and (3) there was a picture-in-picture button that kept popping the video out to float in the corner — which I never wanted.

Step one — dig into the logs, don't guess

This is the part of how Tim works that I love. I didn't say "just make the video faster" and let it guess blindly. My iron rule is: when you hit a bug, check the evidence first — never guess. So Tim went layer by layer through the actual facts:

  • Were the videos fully encoded? — Checked every lesson. Encoding complete, every resolution present from 240p to 1080p.
  • Was the CDN serving slowly? — Timed a real file load. About half a second. Normal, fast.
  • Were the files mangled, bitrates off? — All normal.

The verdict: the videos weren't broken, Bunny wasn't broken, and the CDN wasn't slow. Every single thing I'd assumed was the culprit was actually working fine.

Here's the picture. It's like me complaining that my car is slow off the line, so I assume the engine has a problem. The mechanic opens the hood and the engine's perfect — full tank, tires properly inflated. The thing weighing it down was the bulky body shell I'd bolted on top. So heavy that a perfectly good engine couldn't pull it.

The real bug — the off-the-shelf player, not the video

Once I'd ruled out everything that wasn't the problem, one suspect was left standing: that off-the-shelf iframe player I'd pasted in at the start.

Its problem was that every time I switched lessons, it had to "build an entire player from scratch" again — load its UI, load its scripts, re-initialize everything, every single time. By the time it was ready to play, you'd already been staring at a black screen. On top of that, it didn't preload the video ahead of time, and in some cases it risked pulling the whole MP4 file down in one big chunk instead of streaming it in pieces — which is what made it stall.

Put simply: the convenience up front (paste it in, it plays) came with a weight I couldn't carry in real use. So the question changed from "where is the video broken" to "how do I tear off this heavy shell and play the video as directly — and as lightly — as possible."

The fix — drop the off-the-shelf player, write my own with hls.js

Before touching anything, Tim offered me two options. The shortcut: just hide the annoying pip button and call it done — but the black screen and the stalling would still be there. The more durable path: stop using the off-the-shelf iframe entirely, and play the video with the browser's own built-in player. I picked the second one, because I wanted to fix the root, not paper over the symptom.

So Tim switched to a plain browser <video> tag (the lightest possible option, since it's already built into the browser) and brought in a small library called hls.js to feed the video in as a stream — pointed straight at Bunny's HLS link, no heavy shell in the way anymore.

HLS (HTTP Live Streaming) is a way of streaming that chops the video into small chunks and sends them one at a time — playing as it loads, no waiting for the whole file. It also picks the resolution for you based on your connection speed right then (slow connection drops to 480p, fast connection climbs to 1080p). Tim configured it to start at a low resolution so the picture appears fast, then climb on its own, and switched off the download and pip buttons I didn't want while it was at it.

Prove it in a real browser — not "should be better"

Something I always hold to is that when you finish a fix, you measure it for real — you don't just claim "should be faster." So Tim opened a real browser with Playwright, played the video, and measured it as numbers:

  • First frame within 4 milliseconds — down from seconds of black screen, basically instant now.
  • Smooth playback, nearly 200 seconds buffered ahead — you can skip forward without a hitch.
  • It auto-selected 480p based on the connection, then climbed on its own — no manual setting.
  • Zero console errors — nothing failing silently behind the scenes.

From a video where you clicked and prayed the black screen would clear, to one that plays instantly like opening YouTube. And critically — the fix was at the player layer. It never touched the video or Bunny, which were working perfectly the whole time.

The lesson — off-the-shelf convenience has a bill that comes due later

This reinforced something I run into constantly when building real things:

  • Don't guess what's broken — go look at the evidence. If Tim had rushed to fix what I was complaining about, it would have sat there fiddling with Bunny or swapping out the video host — when the original was doing nothing wrong. Wasted time, fixing the wrong thing.
  • Off-the-shelf is great at the start, heavy as you grow. The iframe player works the instant you paste it in, sure. But in real use it hauls in a pile of stuff you don't need. Past a certain point, writing your own thing that fits exactly is lighter and faster.
  • There are always two paths — patch the symptom, or fix the root. Tim laid out both and let me choose, instead of deciding for me. I picked the root fix because I'll be using this course for a long time and I don't want to get bitten by it twice.

The reason I keep telling these tiny stories is that this is the difference between a tool a customer glides through and one that stutters until they quit the course halfway. Nobody ever sees this kind of behind-the-scenes work. They just feel "the video plays fast."

Newton — an AI that doesn't guess, it chases the real evidence for you

Everything I just described is how Newton works — a full AI agent living on your own private server 24/7, that you talk to and give tasks from your phone like you're chatting with a person. When something breaks or drags, it doesn't leap to a guess and start swinging. It digs through the logs and the evidence first until it finds the real culprit, then lays out the options for you to decide.

The reason I believe in running your AI on your own server, not on someone else's platform, is that I control every layer — tear out a whole player and rewrite it, change how the video streams, measure the result in a real browser, all of it, no waiting for a vendor's permission. And once I polish a small detail like today's, that way of thinking becomes something Tim carries into the next job — the same as when I went engine by engine checking which one actually remembered things, or when I moved my AI back onto the flat subscription seat instead of the metered API. Unflashy behind-the-scenes work that makes the whole system a little better each time.

If you want an AI agent that lives on your own machine, runs around the clock, is easy to talk to from your phone, and solves problems by "chasing the real evidence" instead of guessing — take a look at Newton. It sets up in 10 minutes, and you don't need to know a thing about servers. See how it works →

— Pond