The frontend work a screenshot cannot show

A screenshot leaves the order of network responses invisible.

It also leaves out the keyboard focus after a dialog closes. A failed save may lose a draft, or a button may respond slowly on an ordinary phone. Those behaviors determine whether someone can use the screen after the demo ends.

My earlier note about AI in frontend work called these concerns lifehacks. I'd now describe them as application behavior that needs explicit decisions. Faster scaffolding can leave more time for that work, provided the team actually allocates it.

Define the search states

A search page can look complete with an input above a results list. Suppose someone changes the query before its first request finishes. The second request returns first, then the older response arrives with results for the previous query.

If that older response replaces the visible results, the page now answers a question the person has already changed. Its layout may look exactly as intended.

Specify what the page shows before a search, while it loads, then when it completes. Empty results need a state of their own. Partial results require a policy, as do failure or cancellation. Decide which request owns the visible content, including whether previous results remain during a new search.

Cancellation can enforce part of that policy. Request identifiers offer another approach; a data library may already provide the required behavior. The implementation needs a decision it can apply consistently across requests.

A context file can record the application's conventions with relevant component examples. Include the expected error handling beside the outcome it protects. A requirement that a slower response must never replace a newer query's results gives a generated implementation something specific to satisfy.

Communicate changes without moving focus

A spinner communicates activity visually. Assistive technology needs a status it can announce too. W3C's guidance covers messages about events like completed searches or successful saves that should be communicated while focus stays in place. W3C status message guidance

Use a button element for an action. Connect each field to its label, then choose which status changes need announcing. Announcing every fragment of a streaming response can interrupt the person trying to use the page.

An error message should describe the recovery state. If the draft remains saved, the message can confirm that. A retry needs an available action. If a payment may already have completed, the recovery path needs to resolve that uncertainty before another attempt.

These are product decisions about what someone can do while waiting or recovering from failure. A screenshot contains neither the sequence of events nor the uncertainty the person faces.

Measure the interaction people use

Core Web Vitals measures different parts of performance. LCP concerns loading the main content, with a recommended good threshold of 2.5 seconds. INP measures responsiveness at a 200-millisecond threshold. CLS measures layout movement, with a threshold of 0.1. These thresholds are assessed at the 75th percentile. Web Vitals

Laboratory checks help investigate problems before release. Field measurements describe actual use. A simulated load without user input cannot measure INP; Total Blocking Time supplies a laboratory signal about blocking, with its own definition. Web Vitals measurement guidance

Choose the check according to the failure it can detect. A bundle budget can expose an unexpected dependency. A lab run can reveal a loading regression. Device-specific interaction delays may first appear in field data.

If editing a large table is the application's demanding task, measure that interaction after sustained use. A landing-page score leaves its behavior untested.

Test the behavior a change must preserve

An assistant can draft a component or explain an unfamiliar API. It can also propose tests. Giving it the required behavior makes the resulting change easier for a reviewer to assess.

For search, control response order in the test, then check which query owns the result. A dialog test needs to follow keyboard navigation through closing, including focus return. A failed-form-submission test should check whether entered values remain.

A rendering test can pass without exercising those behaviors. Each test needs a failure condition tied to what someone experiences in the application.

METR's February 2026 update describes selection effects that complicated newer productivity measurements. Concurrent agent use introduced another measurement problem. A team estimating its own time savings needs to count local review work with repairs before applying a speedup claim from elsewhere. METR's measurement update

Review the sequence between screens

I want to be responsible for how the interface behaves while someone waits. Recovery also needs a decision. Keyboard access should remain usable on a small screen, with slow connections accounted for in the interaction.

Automation can implement those decisions when the requirements are explicit. Keep each change small enough to review. Repeated mistakes need more context in the request; an optional AI feature also needs a working fallback when unavailable.

Exercise those conditions in the application. Delay a response before canceling it halfway through. Try a duplicate submission, then navigate the page without a mouse. Those checks expose behavior the screenshots leave unseen.