Give your agent a laboratory

A short piece of prompting advice from Brian Lovin, built around one rule:

You must give your agent the ability to view and verify its own work.

His test for whether you have done that is blunt. If the agent ever asks you to do something manually, stop and work out how to give it the tools to do that itself. Vague instructions like make it faster or find bugs fail because the agent has no way to tell whether it succeeded, so it works briefly, keeps asking you to check, or fixes one thing and breaks another.

Most of the post is two before-and-after prompt pairs. The performance one replaces “the app is really slow, do a complete audit” with an instruction to build a laboratory before touching any code, in four phases: instrumentation (a benchmark harness, timing utilities, console.time markers and performance traces via the Chrome DevTools MCP, baselines recorded for critical paths), diagnosis (identify the top three to five bottlenecks and write a hypothesis for each), iteration (one hypothesis at a time, re-run the benchmark, commit after each success so changes can be cherry-picked), and a final HTML report comparing before and after. The second pair does the same for implementing a Figma design, replacing a single instruction with a refinement loop of screenshot, compare, list every difference, fix, repeat.

Lovin is careful that this is not a template. He expects the need for verbose prompting to decline as models improve, says not every task needs this much scaffolding, and warns against formalising a workflow into a skill too early: you need reps to develop model feel first.