Agents Work Better When the Goal Can Fail
I gave an agent one measurable objective: make my site green in PageSpeed Insights. It worked.
I’ve been playing with /goal as a way to make agent work less vague.
Not “improve my website.”
Not “make it better.”
Not “optimize performance.”
A real goal:
Make danylovorvul.com green in PageSpeed Insights mobile.
That was the whole objective.
The starting point was not terrible, but it was not green.
Performance was 76.
Accessibility was 90.
Best Practices and SEO were already 100.
The useful part was that the benchmark was external and brutally specific. PageSpeed did not care if the code looked elegant. It cared about FCP, LCP, TBT, Speed Index, CLS.
So the agent had a clear loop:
- inspect the site
- identify what blocked the benchmark
- change the static generator and templates
- rebuild
- rerun Lighthouse
- repeat until green
The fixes were boring, which is usually a good sign.
Analytics moved out of the critical path. CSS got minified during build, not in source. Critical shell CSS was inlined for first paint. The full stylesheet became non-blocking. Fonts and analytics were delayed until after the initial benchmark window or user interaction.
No redesign.
No new framework.
No “performance rewrite.”
Just a clear target and a checker that could say yes or no.
After the loop, Performance went from 76 → 100.
FCP went from 3.5s → 0.8s.
LCP went from 4.2s → 0.8s.
Speed Index went from 4.7s → 0.8s.
TBT stayed 0ms.
CLS stayed 0.
This is why I like agents with hard objectives.
The hard part is not always the implementation. The hard part is making the desired state machine-checkable.
I saw the same thing while playing with design goals and the static design checker from Impeccable. If the agent has only taste, it drifts. If it has a constraint and a checker, it can iterate.
A good goal turns the agent from “assistant that suggests” into “process that converges.”
The benchmark becomes the boss.