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. 😂
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.
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. 😂
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.
Merging both reviews, these were the ones worth fixing now:
#handleKey didn't check modifier keys.P and S keys and the hover/pin boxes scan() didn't filter isReportNoise, as shown above. oklch(), lab(), color() and color-mix() produced a media (like print) were counted as active. will-change could push out a real error.touchesSheet checked the whole subtree on every mutation, which invalidated the cache almost every frame.css.target, css.hits, css.pin) cssPath didn't escape special characters, which breaks with Tailwind classes like sm:w-1/2. 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
}
npm test: 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.
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. 🐞