Hi everyone, I'm Antonio. I'm 53, I work as a factory worker during the day, and in the evening I keep building my own projects: modules, classes, a small 2D game engine and a debugging tool called BeeLadybug.

Last time I told you how I argued with AI for hours over a floating search bar that only needed a few lines of CSS.

This time the story is different. This time the AIs were more bugged than my code. 😂

What BeeLadybug is

BeeLadybug is an open-source inspection overlay that runs inside a Shadow DOM. You send it raw data, and adapters turn the page into something you can read:

import('https://cdn.jsdelivr.net/npm/bee-ladybug/src/index.js') .then(({ BeeLadybugCore, WebDOMAdapter, CSSAdapter }) => { const bee = new BeeLadybugCore(); new WebDOMAdapter(bee, { root: document.body }).attach(); new CSSAdapter(bee).attach(); window.bee = bee; });

Paste that in the console of any page (Chrome may ask you to type allow pasting first), press F6 to start the CSS hunt, and F8 to export a full HTML report.

The plan: just write the docs

I'm writing the documentation one adapter at a time. Canvas, WebDOM, and then CSSAdapter, about 1,235 lines.

To document it properly I asked an AI to read the module and explain it to me. Instead of an explanation, I got a list of bugs.

Then I asked a second AI to check the same folder. It found a different list. One said "10 functions" and then listed 11. Another said "5 points" and wrote 6.

After a full day of work, reading 1,500 lines of code with two AIs arguing in my head... my brain got bugged too. 😂

How I got out of it: I checked with my own eyes

I stopped trusting the numbers and opened the file myself. One of the claims was that the S key scan didn't filter the same noise as the F8 report.

Line 144, inside scan():

if (!el || isBeeChrome(el) || isSkippedTag(el)) continue;

Line 216, inside snapshot():

if (!el || isBeeChrome(el) || isSkippedTag(el) || isReportNoise(el)) continue;

There it was. The quick scan was missing isReportNoise(el), so on a WordPress site it reported fake problems on #wpadminbar and on hidden elements, while the F8 report skipped them correctly.

The bug was real. The counting was wrong, but the bugs were real.

The 11 bugs (short version)

Merging both reviews, these were the ones worth fixing now:

  1. With the CSS hunt on, Ctrl+S / Ctrl+P / Cmd+S were blocked. #handleKey didn't check modifier keys.
  2. With the overlay hidden (F2), the P and S keys and the hover/pin boxes were still active on the page.
  3. A stylesheet change before the first mouse move inspected the element at (0,0).
  4. scan() didn't filter isReportNoise, as shown above.
  5. Modern colors like oklch(), lab(), color() and color-mix() produced a fake "invisible text" warning.
  6. Stylesheets that were disabled or had a non-matching media (like print) were counted as active.
  7. The snapshot cut to 80 rows before sorting by severity, so a harmless will-change could push out a real error.
  8. touchesSheet checked the whole subtree on every mutation, which invalidated the cache almost every frame.
  9. HUD states (css.target, css.hits, css.pin) stayed stuck after turning the hunt off.
  10. cssPath didn't escape special characters, which breaks with Tailwind classes like sm:w-1/2.
  11. The other adapters didn't recognize CSSAdapter's own boxes (data-bee-ladybug-css), so they could count them as page nodes.

One small fix, as an example. The keyboard shortcut problem was solved like this:

#handleKey(event) { if (event.ctrlKey || event.metaKey || event.altKey) return; if (this.core && this.core.visible === false) return; // ... S scans, P pins }

The result

  • npm test: 70 tests, 70 passing
  • npm run lint: clean
  • npm run typecheck: clean

The things that are design limits, not bugs (like overflow inside overflow:hidden ancestors, or @import sheets not being visible), will go in the docs as known limitations. I think that's more honest than pretending they don't exist.

What I learned

  • Writing docs is a code review. When you have to explain a function, you notice when it doesn't do what you think.
  • Two AIs disagreeing doesn't mean nobody is right. It means you have to open the file and look.
  • Don't trust counts, trust lines. "Line 144 vs line 216" is a fact; "10 or 11 bugs" is just noise.
  • You don't need a degree to read code. You need patience, coffee, and the stubbornness to check one line at a time.

BeeLadybug is on npm as bee-ladybug, and the docs (in Italian, for now) are on beeenginejs.com.

If you're also building things at night after work: keep going. Your brain will get bugged, but your code will get better. 🐞