However, what the author seems to have done is used a prompt with claude that probably looked something like this:
"Some piece of code is causing the page to load very slowly. To debug this, I'd like to use binary search, where we keep commenting/uncommenting 50% of the remaining code, and then I manually check if the page is still very slow. Let's start now; Comment out a component (or parts of a component) that you estimate is 50% of the page, and I will tell you if the page is still slow."
I'm old school. I used to do "manual bisection" on git history by just `git checkout <commit_id>` until I find first introducing bug commit.
Then another "bisection" on commit changes until minimal change found.
Deterministic bugs are quite "fine". For me personally worst are randomly occurring bugs in specific conditions for eg. some race conditions.
Exactly the same. I'd first (or have Claude or whatever) use git bisect. Then I'd focus on the commit that is problematic. And why not have the "binary" detective work TFA talks about.
That said... 1600 ms per heart emoji. Unicode strikes again, combined with a fallback to SVG because that font couldn't color a heart emoji. What a rube-goldberg of a kitchen sink world we live in. It's just sad really.
Honestly beam me back up to the late 80s or early 90s: give me a car with pop up headlights, a Hi-Fi stereo with a CD player, an arcade cab, a Commodore Amiga and my ASCII charset. Life was better.
P.S: nice TFA btw, I enjoyed it
IMHO git bisect is slower, especially depending on the reload/hot-reload/compile/whatever process your actual app is using.
There are various contributing factors to this, but they include clear docs, notes and refactors that clear up parts the agent commonly gets confused by, choosing boring technology (your dependencies are well understood) and access to command-line tools that let it lint + typecheck + test the code. A lot of the scaffolding and wiring necessary are built into Cursor and Claude Code themselves now. Hope that helps!