Fix a tangled app by specifying its states before prompting

Devin Chasanoff is building a personal-trainer app from a detailed implementation plan. The active workout view is meant to be easy to use during exercise, but its current behavior is confusing.

Completing a set opens a rest timer without clearly advancing the workout. Two controls can navigate to the same place, extra future-set information crowds the page, and supersets must alternate between exercises. Chasanoff wants the interactions to work as a coherent whole.

Fixing isolated bugs one at a time can introduce conflicting behavior and bring old bugs back. Instead, he rewrites his list of complaints as a system describing presentation, components, state, display conditions and user actions.

First he lists visual changes such as labels and layout, then identifies the pieces making up the page. These names are a way to describe the interface and help the agent locate the intended changes; they do not necessarily require separate code components.

Next he identifies state at the page and exercise levels. The page tracks the current set and whether it is in rest mode; it can derive upcoming sets and whether the current set is first or last. Individual exercises track whether a set is complete.

He defines which elements appear in rest mode and during an active set. The last set needs a special state: once it is complete there is no current set, but the workout has not yet been logged. Listing such cases makes the intended transitions explicit.

For a current-set card, unfinished values should be editable, while completed values should be displayed as text. The button should change from completing a set to editing it. He similarly specifies upcoming-set previews and navigation controls.

Action rules connect a user's click to the resulting state. Completing a normal set marks it complete and enters rest mode without immediately changing the current set; after rest ends or is skipped, the app advances. The final set follows a different path.

To prevent later changes from undoing this behavior, Chasanoff pastes the specification into Gemini and asks for test cases. He wants checks for visibility and state as well as small user journeys that connect an action to its display.

He decides to continue in the existing Google Antigravity session rather than start a new one. The agent can use the prior implementation context to reconcile his proposed variables with the actual code and then return to the broader implementation plan.

He asks the agent to pause the plan, implement the specification and cover the generated test cases. He reports that Gemini worked for about seven minutes and the resulting tests passed, then checks the app himself.

The revised rest view shows the timer and upcoming work. Completed sets can provide a reference for previous weight and repetitions. When the user presses Next without completing a set, a menu offers marking it complete, skipping it, previewing the next set or returning.

He walks through the last sets: the upcoming preview shrinks as fewer sets remain, and completing the final set presents a completion card. He confirms and saves the workout, concluding that specifying the system helped him address connected behaviors together.