A no-code AI app build: diagnose the system before asking for a fix

Devin Chasanoff builds a smart personal-trainer app from an existing prototype, three design specifications and a phase-gated implementation plan. He uses Google Antigravity to carry out the milestones and pauses to inspect the results.

The first milestone initializes version control and project scaffolding, adds TypeScript types and Firebase tooling, and seeds an exercise catalog. The agent runs the compiler, lint and build checks before Chasanoff approves the gate.

The second milestone builds a backend server and runs the validation cases listed in the plan. The agent summarizes its tests and creates a Git checkpoint before moving on.

The third milestone adds the app shell, navigation, client state and workout tracker. Chasanoff can finally open the locally hosted app and test the interface instead of relying only on the agent’s report.

The initial page fails to load. He opens the browser developer console, captures the error and gives it to Gemini. After the agent fixes it, he reloads and verifies that the workout page and timer appear.

A single placeholder exercise is not enough to test the tracker. He asks for a realistic workout containing both ordinary sets and supersets, so he can check how the interface handles different blocks.

The old workout remains visible despite the new data. The agent traces that behavior to browser-cached data and changes the mechanism; Chasanoff reloads and checks that the new, more varied plan appears.

After making separate interface refinements, he moves to the AI coach milestone. The goal is a chat interface that can propose workouts and allow a user to accept or modify them.

The first coach response is unusually fast and repeats the same plan. Rather than assume a successful response means the model is connected, he asks Gemini which parts are implemented and learns that some behavior is still a fallback.

The agent lists what works and what does not: the chat interface and proposal flow exist, while server-side persistence and some presentation features are not complete. Chasanoff asks whether adding an API key would enable a real model call.

He privately adds the Gemini API key and model name to a local environment file, without showing the secret on camera. The agent runs connection tests, but the app still returns a canned response.

Chasanoff inspects the application logs and narrows the problem to two possibilities: the key is invalid, or the app is not loading it. He substitutes a harmless test value to check whether the environment file is being read.

The test shows the app was not reading the expected value. Gemini fixes the loading issue; Chasanoff removes the temporary logging, restores the real key privately and restarts the development server.

A model response now arrives, but the proposed workout is empty. He gives the agent a screenshot; it reports a naming mismatch between parts of the app and fixes it. He then tests the complete request again.

The coach generates a four-day plan. Chasanoff tests modifying a workout, asking an informational question that should receive text instead of a proposal card, and using speech-to-text for a request.

He notices that typing a new request without attaching the previous proposal can generate a new plan instead of modifying it. The behavior reveals why the context supplied with a request matters.

He checks the handoff from a specific day into the coach and applies a suggested change. The local workout updates, but he wants a day-specific card instead of a whole-week preview for a one-day change.

Chasanoff asks Gemini to add an individual-day proposal card. When he tests it, the card appears, but the proposed workout does not reliably match the plan already on screen.

He creates and accepts a new weekly plan, then asks for a core finisher on one day. The output differs from the existing workout. A subsequent modification appears closer, so he keeps testing instead of treating the first success as proof.

He suspects the inconsistency relates to how plans are stored. The app has local browser data and is intended to persist data to Firebase, but the database connection is not yet complete.

To make differences easier to see, he asks for a weekly view. He then sets up controlled tests: add one exercise to Tuesday or a workout to Wednesday and compare the rest of the week before and after.

The change affects more of the plan than requested. Chasanoff describes the observed mismatch to the agent and investigates how the coach receives the existing schedule, rather than asking only for a cosmetic correction.

He asks whether the server is retrieving the current plan from Firestore. Gemini reports that the intended architecture does so, but the database is not connected, leaving the coach without the expected context.

He also asks what happens when the user modifies an unaccepted proposal. If the proposal has not been saved to the database, fetching the stored plan alone may miss the current state.

Chasanoff compares two options: connect Firestore or pass the current plan and any pending proposal with each request. He asks the agent to explain the proposed change in plain language before writing code.

The agreed design attaches a snapshot of the active week or staged proposal to the client request. The server uses that context and the coach is instructed to preserve unrelated exercises when making a targeted edit.

Gemini implements and checks the change. Chasanoff emphasizes that the request changed how the system receives context, rather than asking the model to patch a single bad output.

He tests a core finisher, then modifies that pending proposal to remove a plank. He checks the resulting card and accepts it, confirming that the intended items remain.

A second test swaps Thursday and Friday workouts. The displayed week changes as requested, which gives him evidence that the new context path can preserve the rest of the plan in these examples.

The next milestone adds progress, settings and a view of the coach’s living memory. The design uses local browser storage for responsiveness and anticipates syncing to Firestore for persistent data.

The progress and settings screens appear, but Chasanoff notices layout issues on mobile and missing navigation. He asks the agent to adjust the layout and list the checks he should perform at the next gate.

He tests whether telling the coach about equipment and an upcoming event updates the settings and memory. When expected information does not appear, he asks first whether the feature should already work at this stage.

He questions Gemini’s proposed fixes because Firebase is not connected. Further discussion reveals an in-memory fallback and leads him to ask how server-generated information reaches the browser’s local state.

They agree to return an updated profile with the chat response, update the client’s local data, and sync to Firebase later. Chasanoff asks for a conceptual summary of the plan before authorizing the implementation.

On the first retest, the equipment appears but the event is still absent from memory. The agent makes another correction, and he retests until both equipment and the time-limited memory appear in the interface.

At the end, the local app supports workout tracking and coach-driven changes, but cloud persistence, authentication, assets and deployment remain future work. Chasanoff plans further verification and interface refinements as well.