How I AI: Terry Lin's Vibe Coding Workflow for Building an Apple Watch Fitness App

Logging a workout set by voice is the core of Cooper’s Corner, an Apple Watch and iPhone app built by Terry Lin, a product manager and self-described "AI-powered gym bro". His process is as structured as his workout data, combining the AI-native editor Cursor with Apple's Xcode, staged planning, small commits, and frequent check-ins where the AI explains its own code.

The idea began with the friction of typing exercises, weight, and repetitions between sets, a common annoyance with most fitness apps. Terry was already using the GPT mobile app for speech-to-text and wondered why a workout app couldn't do the same thing: transcribe his voice and automatically structure the data. Before investing in a full app, he first tested that core loop.

Terry's solution required building for both mobile and watch, a process with its own unique challenges. In this episode of How I AI, he demonstrates two key workflows. The first is his Apple-platform development loop, which he calls Create, Review, Execute. The second turns a simple index-card sketch into a digital interface concept ready for Figma.

Mobile development adds device builds, simulators, and real-world testing to the coding loop. Terry uses AI for planning and editing, but he keeps Xcode for builds, his devices for testing, and his own judgment for reviewing the code. It's a hybrid approach that keeps the human in the loop where it matters most.

Building a multi-device fitness app with a Create, Review, Execute cycle

In Cooper’s Corner, Terry can say a set like "I did dumbbell shrugs, 35-pound dumbbells, 10 reps", and the app converts the transcription into structured fields for exercise, weight, and repetitions. Because voice recognition can mishear a value, the logged data remains visible and editable. The app also includes analytics to track consistency over seven, thirty, and ninety-day periods.

Step 1: Test the voice-to-data loop before building the app

Terry’s first version was a small pipeline built from tools he already had:

1. Record: At the gym, he’d use the built-in voice memo app on his Apple Watch to record his sets.
2. Transcribe: He would then copy the audio files to his computer.
3. Process: A simple Python script took the audio transcriptions and fed them to GPT-4 to pull out the exercise, weight, and reps.
4. Output: The structured data was then dropped into an Excel spreadsheet.

The spreadsheet version tested the central behavior without requiring a mobile application. It gave Terry a way to judge whether voice logging was useful before expanding the system.

The prototype proved the core idea was viable, but it also exposed its limits. The spreadsheet data wasn't structured enough for the kind of historical analysis and progress tracking Terry wanted to build. To get there, he needed a proper backend and a dedicated app.

Step 2: Dual-wielding Cursor and Xcode

Building for iOS still means working inside Xcode, Apple’s native IDE. But Terry wanted Cursor’s AI features, so he developed a process for "dual-wielding" both tools at once, pointing them to the same project folder:

• Cursor for coding: Terry opens the project folder in Cursor for AI-assisted edits, features, and refactoring.
• Xcode for builds and debugging: He compiles the app in Xcode, runs it in simulators and on devices, and investigates Apple-platform build and runtime failures there.

Step 3: Use the Create, Review, Execute cycle

To manage complex tasks and prevent the model from getting tripped up, Terry separates planning, critique, and implementation with three custom Cursor rules. This separation lets him inspect and refine the plan before any code gets written.

1. PRD Create: He kicks things off with an issue from his project management tool, Linear, and runs his PRD Create rule. This rule takes the basic ticket and fleshes it out into a full Product Requirements Document (PRD). It lays out the goals, includes references, and defines user stories in Gherkin format (Given-When-Then). This gives the AI clear, structured instructions to follow.
2. PRD Review: A second rule prompts a model to critique the plan. It looks for missing context, edge cases, and ambiguous requirements, acting as a sanity check before execution.

If another model were to take this plan, how would you rate this out of 10 if they had no context and they had to execute on this?

If the plan scores lower than a nine out of ten, Terry asks the reviewer why it docked points and what the gaps are. He iterates on the PRD until it scores high enough. The score is a stopping rule, not proof that the plan is perfect; he still has to judge whether the requirements and risks are adequately covered.

1. PRD Execute: Once the plan is solid, this rule breaks the work into phases and creates a Git commit after each one. The multi-device Cursor workflow keeps planning, review, Xcode builds, and device testing visible throughout execution.

Step 4: Vibe refactoring for AI collaboration

Terry noticed that as he generated more code, some files grew to over a thousand lines. This became a problem for the AI, which reads files in 200-line chunks and could get tripped up parsing so much context. To solve this, he created a dedicated Cursor rule for what he calls 'vibe refactoring', reorganizing the codebase to make it easier for his AI partner to work with.

His rule of thumb is to keep files under 400 lines. This is a personal heuristic, not a universal rule, but it serves as a trigger. When a file gets too large, he uses his refactoring rule to analyze it and decide whether splitting it would improve organization and navigation for both himself and the AI.

Step 5: Rubber ducking with the AI

In software engineering, 'rubber ducking' is the practice of explaining a problem to an inanimate object to find a solution. Terry reverses this with his 'Rubber Duck' rule, asking the AI to explain newly generated functions and logic back to him. This helps him learn the codebase the AI is writing.

The rule can also generate short quizzes about the code. Terry might have it pop-quiz him over dinner. While a correct answer doesn't prove the code is perfect, the exercise forces him to understand the implementation and exposes areas that need closer inspection before he relies on them.

Turning index-card sketches into interface concepts

Before coding a UI, Terry sketches a flow, photographs it, and asks a multimodal model to render a cleaner concept that he can continue editing.

Step 1: Sketch the flow on index cards

Many of Terry's ideas start on the New York subway, where there’s often no internet. He sketches screens and flows on plain index cards, which happen to have a similar aspect ratio to a phone screen. The process is fast, portable, and low-stakes, allowing him to iterate on ideas without opening any design software.

Step 2: Upscaling with GPT-4 Vision

Terry photographs the index-card sketch and uploads it to a multimodal model for a cleaner rendering. The index-card UI workflow carries the rough layout through image generation, correction, and editable Figma components.

Hey, this is a mock up. Can you help me upscale this?

The output is a digital concept with recognizable iOS-style interface elements. It is still a generated image, not an accessible or functional interface.

Step 3: From image to Figma components

Terry then uses UX Pilot to translate the image into editable components and assembles the design in Figma with Apple UI Kit components. He checks the resulting layout rather than treating image-to-component conversion as exact.

Structure the work so errors remain visible

Terry's process is defined by checkpoints. He tests the core behavior before building the app, separates planning from implementation, commits code in small, reviewable chunks, runs the result through Apple’s native development tools, and even has the AI explain its own work back to him. Each step is a deliberate opportunity to catch an error before it compounds.

Terry's workflow is worth copying if you're building something with a complex, platform-specific toolchain like mobile development. Start with the simplest end-to-end test of your core idea, and verify the output manually. Add structured rules for planning and refactoring only when you can name the specific problem they solve, like models getting lost in large files. Most importantly, don't treat a high reviewer score, a successful build, or a polished mockup as proof of quality. Human judgment is still required to decide when the app is truly ready for users.