How I built an Apple Watch workout app using Cursor and Xcode (with zero mobile-app experience)

1. 0:00 – 2:30

   Introduction to Terry and his fitness tracker app

   1. CVClaire Vo0:00

      you used AI to make getting swole at the gym easier. I am so excited about this. Let's see how you built this!

   2. TLTerry Lin0:06

      I started using the GPT mobile app as, like, speech-to-text, and I was like, "Well, if the model can understand when I'm talking to it, like it is right now, why can't a workout app do this, and then tag the data for me? Make it like a structured data set with analytics."

   3. CVClaire Vo0:19

      Let's talk about how you built this thing, 'cause I wouldn't even know where to start in terms of the mobile and watch side of things.

   4. TLTerry Lin0:25

      I was like, "What if I have a Python script that takes these files, and it takes the GPT-4.0 and it just suits it to me in an Excel?" Two months later, I now have an Apple Watch and an iPhone app. Now, I did jumping jacks, 35 reps. See, it sends it to the phone, so whatever device you have, log your workouts pretty much with no work.

   5. CVClaire Vo0:40

      It does simplify this experience of going to the gym, like the gym bros with their notebooks, where they're writing down their reps or in their notes app. This is awesome. [upbeat music] Welcome back to How I AI. I'm Claire Vo, product leader and AI obsessive, here on a mission to help you build better with these new tools. Today, we have Terry Lin, product manager, vibe coder, and AI-powered gym bro. He's [chuckles] gonna show us how he made a mobile and watch app to track his workouts using Cursor, Xcode, and index cards. Let's get to it. This episode is brought to you by Paragon, the fastest way to ship product integrations. Are integrations on your product roadmap? Whether you want to ingest your users' files from apps like Google Drive or OneDrive, sync data with their CRMs, or automate tasks like searching Salesforce records, integrations are mission critical for products and SaaS. But integrations take months to build, and existing solutions aren't good enough. Embedded IPAs are great for automation but break under high volume, and unified APIs are limited by their endpoints and data access. With Paragon, developers can ship new integrations in days, with purpose-built products to support any use case, from high-volume ingestion to real-time actions and automations. That's why engineering teams at you.com, Pipedrive, Cinch, and hundreds of other B2B SaaS and AI companies use Paragon, so they can focus their efforts on core product features, not integrations. Visit useparagon.com/howiai to see how Paragon 2.0 can help you accelerate your product's integration roadmap today, and get $1,000

2. 2:30 – 6:40

   Demo of the voice-powered workout tracking across devices

   1. CVClaire Vo2:30

      off. Terry, I'm super excited to have you on the podcast. Welcome.

   2. TLTerry Lin2:35

      Thank you, thank you. Uh, long-time listener, first-time caller.

   3. CVClaire Vo2:38

      Well, speaking of first time, we have had a lot of web developers, including myself, on this podcast, but we actually haven't spoken to very many people building for mobile, and I know mobile apps have special challenges, technically, you know, just building them. And then I'm super curious to see how folks like you are approaching using AI to build mobile apps. So before we get into the how, let's see the what. What did you build with AI?

   4. TLTerry Lin3:08

      So I built a mobile fitness tracker called Cooper's Corner, uh, and essentially, the problem I was trying to solve, maybe if I put my PM hat on for a sec, was I would go to the gym, I would try to be consistent, and then, you know, life gets busy. You start to slip one to two days, and then you go back a week later, you're like, "Oh, what was I doing?" And so I tried these fitness apps where you kind of have to, like, create an account, set up your exercises, tell them what your gym has equipment-wise, and it felt like doing a lot of homework. And even when you're working out, you have to, like, log what you did, you know, your rest timers, things like that. And then last year, I started using the GPT mobile app as, like, speech-to-text, and I was like, "Well, if the model can understand when I'm talking to it, like it is right now, why can't, like, a workout app do this, and then kind of like tag the data for me and, um, make it like a structured data set with analytics?" And so that's kind of how I started down that path, and then, uh, I basically started with a little script, and then eventually, two months later, I now have, like, an Apple Watch and a, uh, iPhone app. So I'll run you through how it works, and then we can talk through, uh, how I built this.

   5. CVClaire Vo4:09

      Okay, so you used AI to make getting swole at the gym easier. I am so excited about this, uh, as someone who definitely never, never skips a gym, gym day.

   6. TLTerry Lin4:21

      Yeah, well-

   7. CVClaire Vo4:21

      Okay, let's, let's see how you built this.

   8. TLTerry Lin4:23

      Okay, cool. I'll run you through how it works real quick, just to get us so everyone has, like, a visual context here. So this is the login screen. I don't know if you can see it. He's the hero of the image. Does this look good?

   9. CVClaire Vo4:34

      Aw, Cooper. Cooper, the dog.

   10. TLTerry Lin4:37

       Yeah.

   11. CVClaire Vo4:37

       Yeah.

   12. TLTerry Lin4:37

       And I don't know if you can see him, but he's sleeping right there, literally, like, on the side of my screen.

   13. CVClaire Vo4:41

       Oh, hi, Cooper! [chuckles]

   14. TLTerry Lin4:43

       Yeah. Okay, so the first thing is authentication, right? I'm using Sign in with Apple. There's kind of a UX decision there, because I don't want you to create an email and have to, like, you know, enter a code. And so one of the first things you'll notice is when you log into the phone here, it logs into the Apple Watch, so there's some stuff I can talk about there. But essentially, you could basically just use voice and record your workout here, and so I'll give this a shot. I did dumbbell shrugs, 35-pound dumbbells, 10 reps. And so what I built is, you could record it from your phone, or you could do it from the Apple Watch here, 'cause sometimes when you're at the gym, you don't always have your phone, uh, too, right? So let's see if it got it right. There we go. See? Dumb... And it has the transcript here. If I try it from the phone... Right, now I did jumping jacks, 35 reps. See, it sends it to the phone, so whatever device you have, it's kind of cool, it can, uh, log your workout-

   15. CVClaire Vo5:41

       This is awesome

   16. TLTerry Lin5:41

       ... pretty much with no work.

   17. CVClaire Vo5:43

       So for people that are not watching on screen, this is an app that goes across your mobile device and your smartwatch, and you basically speak to it at the gym, say what exercise you did, what weight, what reps, and it just automatically populates a structured record of-... that exercise, including what time you did it. It shows a picture of the equipment you might have used, or, um, a picture of somebody doing jumping jacks, or in this case, push-up jumping jacks. And it does simplify this experience of going to the gym, you know, like the gym bros with their notebooks, where they're writing down their reps-

   18. TLTerry Lin6:23

       Yeah

   19. CVClaire Vo6:23

       ... or in their notes app in Apple. So you built this. It's multi-device, it's multimodal, it goes voice to text, and text to structured output. Let's talk about how you built this thing, 'cause I wouldn't even know where to start in terms of the, the mobile

3. 6:40 – 7:20

   Analytics and history views for tracking consistency

   1. CVClaire Vo6:40

      and watch side of things.

   2. TLTerry Lin6:42

      Yeah, and there's one more thing to show you real quick, I'll flash it on, is we were talking about how do you be consistent? So there's actually, like, a history view here, so you can look at your seven-day, 30-day, 90-day analytics to see how consistent you are. And you can see in, like, the last 30 days, I've been going to the gym 21 days, right? So now I know when I've been slacking and when I haven't been. And also I can see, like, my top exercises. You can see I do a lot of jumping jacks here. I do leg presses, and then if you click into the leg press, you have, like, a whole history of what you've done. So now you have, like, a scatter plot of where my weight's going, uh, like a history of if I'm actually progressing or not, too. So that's kind of it. I could walk through how I built that, but any

4. 7:20 – 9:05

   Dual-wielding Cursor and Xcode for mobile development

   1. TLTerry Lin7:20

      questions there?

   2. CVClaire Vo7:21

      No. Let's go through how you built it.

   3. TLTerry Lin7:23

      Okay. So one thing with iOS apps is that, uh, you usually have to use Xcode, which is Apple's IDE, to actually build the code. So I do something called dual-wielding here. So this is what Xcode looks like, and what I do is usually I do a side by side with Cursor here. So the way I link this is I make both of them point to the same folder on your computer, and then Cursor will do the coding, uh, and then I will do the building and the debugging in Xcode. Uh, the reason is because sometimes on the phone, when you get errors, like compile errors, build errors, uh, Xcode is really where you have to go to get that, because Cursor... It's not like a web browser, where you can just kind of look at the tools and then start looking at the console. And so, uh, there's a little bit of a kind of workaround you have to do, and I've seen some people online have these hot reload apps, but this is kind of the solution I've found that works best for me. And also, if you have to build to the Apple Watch, you kind of have to do it separately, so that's kind of why I have this split workflow, uh, for now.

   4. CVClaire Vo8:24

      Got it. So we want Cursor to somehow build a native integration here, so you have a little bit more cross-pollination, if you could.

   5. TLTerry Lin8:32

      Yeah. Yeah, and it's not like web apps, where you just run a local host, and then you kind of-

   6. CVClaire Vo8:37

      Yeah

   7. TLTerry Lin8:37

      ... can see it in your browser. You have to kind of always build it on your phone. And right now, you're seeing this in the iOS simulator. I would say, even when you're testing mobile apps, like, swiping around with my mouse here feels very different than when I'm on my phone testing in here, and it's even different when I'm in the gym, actually, like, running around and, like, trying to record stuff, and sometimes the audio's not great, too. So I think when it comes to, like, mobile apps, when you're testing this, you just have to get as close to the actual experience, otherwise, you're kind of just testing in a box and not really getting the true

5. 9:05 – 11:19

   Building a v1 using AI tools

   1. TLTerry Lin9:05

      kind of user experience there.

   2. CVClaire Vo9:07

      So how did you get this started from zero? Kind of what was your setup in terms of defining the product, getting Cursor set up? How did you work through that, that workflow, and then doing the build, um, and testing in Xcode and on your phone?

   3. TLTerry Lin9:22

      Yeah. So like we say in product, you wanna like start... think big, start small, right? So the V1 of this was actually just using Apple Voice Memo, like, on the Apple Watch. Uh, I would record that, and then you would copy it to my computer, and then around February this year, I started getting into vibe-coding, and I was like, "Well, what if I have a Python script that takes these files, and it takes to GPT-4.0 and then just shoots it to me in an Excel?" And so what that looks like here is kind of this spreadsheet here. This looks like the very V1 of it, where you see the transcription. It attempts to tag it with different muscle groups and, like, rep sets. Uh, but the problem here is that this is not structured data, right? It's just whatever the model thinks is the exercise. And so then I was like, "All right, well, then, what is the solution then?" Is then you gotta put it into a database, where it's actually structured data. You have, like, the foreign keys. You can actually manipulate it better, it becomes more consistent. So that's kind of where it went, from this to a backend API that I built in Cursor.

   4. CVClaire Vo10:19

      I wanna pause here, because I actually think this, for folks that are listening, is a pretty cool hack, which is using voice notes on your, on your watch to just narrate your workout at s- at the gym, and then download that text, you know, put it in even ChatGPT or some sort of, like, no-code little flow, and populate it in a spreadsheet. That's just such a simple-

   5. TLTerry Lin10:43

      Yeah

   6. CVClaire Vo10:43

      ... and easy way to start, and then what you're saying is, you're a PM and an engineer, and you want foreign keys and a database. So you decided, "Let's make this a full app."

   7. TLTerry Lin10:53

      Yeah, and it's also, if you look at the spreadsheet, how do you make sense of this, right? Over time, you're not really... Y- y- you don't have these analytics that you see here on the right side in the phone. And so I was like, "Well, how do you then do that?" You can ideate with GPT. I think when you work with models, they could either work with you or work for you. This is very much in that working with you side, or just ideating on features, and how you can potentially make, like, an MVP into, like, a low hacky tool that gives them higher iteration.

6. 11:19 – 19:38

   A three-step AI workflow: create, review, execute

   1. CVClaire Vo11:20

      So okay, so you decided to build this app. How are you actually building? What is your step-by-step workflow in Cursor?

   2. TLTerry Lin11:28

      Sure. So I have kind of a three or four-step process in Cursor. So first step is creating a PRD, second is having a model review it, and then third step is executing. And so the way I have that set that up, there's kind of three rules here. There you see PRD create, PRD review, PRD execute. Uh, and so if we take a file here, uh, as an example here, I have an existing ticket. What I'll do is I'll take, uh, an issue, I'll add it to Cursor here, and then I'll have it run through PRD create.... and what this rule does is essentially breaks it out into what you need to implementation. So any reference diagrams to actually take do this task, uh, what are the goals we're trying to do? Uh, one thing I do is I use Gherkin user stories to actually describe the scenario. So the format is, like, given something happens, when the user does this, uh, then do this action. And so there's also some investigation here that happens. So if I don't know how to actually do something, where the model doesn't know what files to use, what databases to touch, that's kind of a checkpoint here. And then this is kind of like the V1 of the PRD, where it's not fully fleshed out, but at least it's the structure of it. And then one thing I realized is sometimes early on, when I was vibe-coding, this document would not be enough, and that's kind of why I created a PRD review rule, where it basically, uh, does, like, a check on that PRD. So one question I do-- I ask is, "If another model were to take this plan, uh, how would you rate this out of ten if it had no context and it had to execute on this?" And so you're basically sanity-checking your PRD to see if it's actually has any gaps that a model could trip up on down the line.

   3. CVClaire Vo13:13

      [upbeat music] You've seen the doom and gloom headlines: AI is coming for your job. But the reality is a little bit brighter. In Miro's latest survey, seventy-six percent of people say AI can boost their work. It's just that fifty-four percent still don't know when to use it. As a product leader and a solo founder, I live or die by how fast I can turn fuzzy ideas into crisp value propositions, roadmaps, and launch plans. That's why I love Miro's Innovation Workspace. It drops an AI copilot inside the canvas, so stickies, screenshots, and brainstorm bullets can become usable diagrams, product briefs, and even prototypes in minutes. Your team can dive in, riff, and iterate, and because the board feels like a digital playground, everyone has fun while you cut cycle time by a third. Miro lets humans and AI play to their strengths so that great ideas ship faster and happier. Help your teams get great done with Miro. Check out miro.com to find out how. That's M-I-R-O dot com. So how did you build these Cursor rules, and how did you know what to build and how, how to put stuff in this template?

   4. TLTerry Lin14:30

      Honestly, a lot of blood, sweat, and tears. I think when I first started vibe-coding in February or March, no one was really talking about memory banks or rules yet, and so the problem I was running into was, every time I modeled it got to do more and more complex tasks, it would at some point trip up over itself. It would make up stuff. It would make up file directories. It would get endpoints wrong. And so I realized after repeating it, telling it what to do time and time again, I started noticing these patterns and, like, how to give it context. And I was like, "Well, why am I repeating this over and over again? I should just make these into the rules," and so that's kind of how I ended up with these processes. And you notice I also broke them into, like, three PRD rules. The reason is because originally my rules were super verbose, maybe eight hundred lines long, and I realized I was just running into a lot of context windows with these same rules. So you'll see, like, they're now no more than two hundred lines long, and so I c-- I actually, like, I'm much more cognizant of how many tokens I'm using with these rules. And so over time, I've kind of gotten more efficient with that, uh, as I get more experience with Cursor.

   5. CVClaire Vo15:31

      And the second part of this, which I think is so interesting and mirrors how things work inside product organizations, is you write a PRD, and then somebody looks at it, somebody reviews it, and says, "Is this good?" And that person could be, you know, a PM lead, it could be a peer PM, or it could be an engineer. And it seems like you're taking this from an engineering point of view and saying, like, "As a model, reviewing this zero context, what do you think?" And I like this idea of rating zero to ten. Do you feel like the ratings are generally pretty accurate?

   6. TLTerry Lin16:01

      Yeah, and it's more of a barometer for me and how well I prepared it. If it's, like, a seven out of ten, I'll then ask it, "Well, what are the th- three points? Why did you dock it?" And it'll give me some reasons on why those gaps are. "Is this an edge case? No, we could ignore that," and it'll kind of... You want to get it to at least to, like, a nine out of ten before you do it, and the reason is then when you have it run through the plan, it could probably one-shot it pretty quickly.

   7. CVClaire Vo16:23

      Mm-hmm.

   8. TLTerry Lin16:24

      And so I'm doing that here on the side. You see there's a seven out of ten here, and so it gives me, like, a strawman and steelman of it, and so you see the gaps identified. I can then be like, "All right, uh, inconsistent API, like, are these actually things we need?" And then I'll kind of then kind of iterate this until it's a ten out of ten, and then that's when I then run the execute rule, which I think you've seen as, like, the checkbox rule. You have it in chunks. Uh, something I do extra is I have a Git commit before and after each phase and ask it to pause, so I don't just have it one-shot everything. But, uh, this is when I know I can let it run, go get a coffee, and then come back and just do some QA.

   9. CVClaire Vo17:02

      Got it. So your step is write it as a PRD. Gosh, you poor AI PM. You write the PRD, then someone else tells it if it's good or bad, then, [chuckles] then you iterate.

   10. TLTerry Lin17:11

       Yeah. [chuckles]

   11. CVClaire Vo17:12

       Then the poor PM has to make epics and tasks.

   12. TLTerry Lin17:16

       Yeah.

   13. CVClaire Vo17:16

       The AI PM has to make the checklist, and then you're giving very explicit directions on check-in at every single point, and then you say, "Here you go. Here's your PRD. Here's your checklist. Let it run." Um, and then are you coming back and checking that code, doing the build in Xcode, and then verifying it all works and shipping it?

   14. TLTerry Lin17:37

       Yeah, so here's an example of one, um, where on the Apple Watch, when I showed you, I hit record, and I stopped it. It was saying, "Sent to iPhone," but it wasn't staying on long enough. So if you're recording this, you may miss it, and then you may wonder, "Hey, did it actually even go to the phone?" And so this was adding, like, a little timer so you can see that if you're kind of walking around the gym, and there's, like, a feedback that, "Hey, this is-- Y- we got this. You don't have to worry about it. You don't have to worry about it failing." And so this is what the PRD looks like. I logged it originally in a tool called Linear, and so I pulled that in here, and then I ran it through prdcreate, and so it created this doc.... and so I'm very explicit where I even tell it what files you wanna touch, just because I don't want it to search through my code base, waste tokens. So like, "Hey, here's what you need to do. Here are the files, here are the endpoints. Just go run with it." Yeah, so here's some of the example of the phase checklist. You see phase one, it does the checklist, and every phase, it kind of pauses, right? There's, like, a safety checklist here, right? "No placeholder codes. We don't want you to make stuff that could break things." There's some error handling, and then it kind of runs through this.

   15. CVClaire Vo18:42

       Yeah, and I wanna pause for folks that are not watching. On that checklist, if you could go back to it, it's really interesting. Every phase at the end of the phase says you have to verify the paths, um, make sure you're using real data, no placeholder, that you're handling errors well. And so it's really interesting that you really, again, are following this pretty classic development pattern of, like, product manager re- you know, defines requirements-

   16. TLTerry Lin19:06

       Yeah

   17. CVClaire Vo19:06

       ... breaks down the tasks, engineer executes, you do a QA phase, and then you move on to the next task. So you've sort of, um, structured your rules and your process to map to that, and then the only difference is you're using an AI PM, [chuckles] an AI engineer, and AI EM to sort of run QA, uh, to, to run through all this.

   18. TLTerry Lin19:29

       Yeah, and I think 80% of the time, I'm working with the model. It's this last 20%-

   19. CVClaire Vo19:34

       Mm-hmm

   20. TLTerry Lin19:34

       ... where the checklist-

   21. CVClaire Vo19:34

       Yeah

   22. TLTerry Lin19:35

       ... is just burning through tasks, uh, for me, too.

   23. CVClaire Vo19:37

       Yep.

   24. TLTerry Lin19:37

       So I think

7. 19:38 – 23:25

   Token conservation and vibe refactoring explained

   1. TLTerry Lin19:38

      the biggest switch is probably just learning to work with the model, I think, is where if you get good at that, I think after this stuff, it's just kind of table stakes. It's just executing, uh, for you.

   2. CVClaire Vo19:47

      And I have to... I, I, I'd love to understand. You've mentioned conserving tokens for a while, and I have to understand your motivation because I am just like, "Eat all the tokens you want. I just do not care. Tokens, everyone. You get a token, you get a token." Um, is this a cost-sensitivity thing? Is it a performance of the tasks, where, you know, too much context in, in the, the Cursor context window actually degrades performance? What is your motivation for token conservation?

   3. TLTerry Lin20:18

      Probably my sanity, if I had to put a thought to that. [chuckles] So the reason I say sanity is because, uh, LLMs are really good at just generating a bunch of code. It can be very verbose, and so sometimes when you have very large files... I noticed Cursor, when they go through your code-based files, they read in, like, 200-line chunks at a time, and what I realized over time was that I had, I had these files that were, like, 1,000, 1,000, 1,500 lines long, and it was taking a lot of time just going through that, and then as it was going through tasks, it would just start getting tripped up a lot. And then that's when I kind of stumbled upon this concept of, like, I call it vibe refactoring, where you basically have to take vibe-coding, and you have to, like, reorganize it into something that's cleaner. Uh, and then, that way, I guess it's like good engineering principles. They do that to you, right? You refactor code, you keep it clean. So that's something I do with another rule here, where I kind of have the PRD rule, but it's not meant to create features. It meant- it's meant to refactor existing code bases, and so I essentially give it the same, you know, context docs. I give it the API endpoints, and I give it different guidance on, "Hey, what do we need factoring? Why should we do this? How do we make sure it doesn't break?" Like, "How will we QA this after it's done?" And it kind of runs through the same process of where you're doing that PRD planning, but your goal is very different. It's more of a cleaning your apartment, making sure everything works fine, kind of, end kind of goal.

   4. CVClaire Vo21:36

      Okay, so I have to call this out for all the engineers, engineering leaders, large engineering organizations, uh, that are watching the podcast. Yes, AI does have the ability to generate lots of code and maybe not the highest quality code always, um, in pursuit of shipping features, and I know there's a lot of nervousness in the industry about, "Oh, my God, what if we give PMs access to ship code or designers access to ship code? The code's gonna be so ugly. They're not gonna know. It's gonna cause a lot of tech debt." But what I, I have experienced is that e- exactly this. It's actually quite good at refactoring, and I almost suggest to engineers that are adopting these tools or teams that are adopting tools, is, like, build the refactoring as a known cost of your AI implementation. Almost plan it that way, where it's like, "Okay, I'm gonna, I'm gonna vibe code to the feature working, so I can check that customers like it, that I can see that it works, that I can see if I like the design," all that kind of stuff. Get it out there. You know, like, secure, perform it, but not beautiful code, and then go back and spend a vibe day refactoring. And I love that you actually have built... I, people would love to see these rules, so maybe we'll bribe you to share them. But-

   5. TLTerry Lin22:51

      Yep

   6. CVClaire Vo22:51

      ... um, I love that you've built this rule of, like, this is how a good refactor goes. "Here are my engineering principles that I want you to prioritize. Here's the things that you should think about. Here are the performance things you need to think about." I think it's just a really nice process, and I've had this experience myself, where I just, I build a feature, I get it out. People like it, great. I wasn't happy with the code, but I knew that, and I go back and refactor, and it's so much cheaper and faster, honestly, than almost any other path to, like, the good code. Um-

   7. TLTerry Lin23:22

      Yeah

   8. CVClaire Vo23:22

      ... so I think this is a, an exceptional way to do things.

8. 23:25 – 25:28

   Optimizing file sizes for better AI performance

   1. TLTerry Lin23:26

      Yeah, and I have an example on my screen here of what that plan would look like for a refactor. So the quicker way, quickest way to do that is just to do a line count and have the model do it. "Hey, what are my biggest files? Which ones are, like, God mode that we need to factor down?" So one of these is this recorder file. We don't need to go into it, but that was that recording logic I just showed you. There's 900 lines. I generally try to keep them under 200 to 400 lines, just because I don't want the model to use context going over code maybe it doesn't need to do a task, right? And same thing here, it has that checklist, right, each phase, and then, yeah, basically, each phase, it'll try to do a build the next code and then make sure there's no compile errors, and it'll just keep chugging through that, and we have that safety checklist, uh, here, too.

   2. CVClaire Vo24:08

      And let's make this clear for, uh, folks that are listening, is you very intentionally set up one of the design principles of your code base that you want your files-... to be of a s- a small enough size that the LLMs itself have an easy time working with and navigating individual files, getting tasks done. And I think this is really interesting, because I think about it a lot. I think as a human, what is my preferred structure of a file? Do I like embedded functions? Do I like a bunch of little bitty files across the, the codebase? What is my preference? And sometimes I like these longer files, because I'm in a file, and I'm like, "Well, I want the definition of this here. I just wanna be able to read and understand what this, this is doing." But a AI engineer reads the files very differently. And so-

   3. TLTerry Lin25:01

      Yep

   4. CVClaire Vo25:01

      ... what I like about your approach here, is you're optimizing for your AI colleague, and the way that they read this context. And it may or may not be the same as an engineer or human may want to read and retain the context. And so I think that's gonna be a real challenge for teams that are putting this kind of flow into production, is making those design principles work for all systems that are contributing code.

9. 25:28 – 28:13

   Using “rubber duck” rules to learn from AI-generated code

   1. TLTerry Lin25:29

      Yeah, and one thing that's useful if you make it smaller files, is I have this final rule called rubber duck. So in engineering, there's a concept where if you're trying to work through an issue, you talk to an inanimate object, you explain the code line by line. And so what I use this file for is if I'm just trying to learn or optimize the rate of learning, like we just generate a bunch of code, I don't know what some of it does. If I wanna just learn what it does, can you just take this file and explain it to me? And then sometimes I'll have dinner, you know, I'll just ask it to, like, pop quiz me. And I'll just, like, e- it'll give me a function, I'll think about it, and then I'll kinda use this to rubber duck as a partner, um, too. And so yeah, it's...

   2. CVClaire Vo26:05

      This is a-

   3. TLTerry Lin26:06

      So-

   4. CVClaire Vo26:06

      ... this is a great idea. 'Cause I do this a lot once, when I have let Cursor, you know, run through a big chunk of code, is I just-

   5. TLTerry Lin26:14

      Yeah

   6. CVClaire Vo26:14

      ... I summarize it with, like, "Explain to me what you did, and how you did it, and why you did it." We actually put those really clear explanations into our pull request descriptions, so it's very clear how something was built. But you're getting the A-plus colleague award by actually quizzing [chuckles] yourself on how your own app works.

   7. TLTerry Lin26:33

      Yeah.

   8. CVClaire Vo26:33

      And I think a lot of people are worried that, um, you know, vibe coders or whatever, are gonna build these apps and have zero idea how they actually work, whether they're secure, and honestly, they'll have zero idea, um, of the underlying technologies, and won't actually develop technical skills that could make them an overall better builder. And this is a really good strategy, kind of built in, to use your vibe-coding process as a learning tool. Um, which I, I think is, is the best way to do things. I have, um, been a, a self, you know, a self-taught software engineer. I've always had to learn by, like, tapping a colleague on the shoulder and saying, like-

   9. TLTerry Lin27:15

      Yeah

   10. CVClaire Vo27:15

       ... "What do you think of this code? How did you build this? Why did you make this decision? Why did you select this library?" All that kind of stuff, and now you just have this, like, infinitely patient colleague- [chuckles]

   11. TLTerry Lin27:24

       Yeah

   12. CVClaire Vo27:24

       ... to, to do that with. And I just think it's such an amazing learning opportunity for folks that want to develop technical skills, wanna be able to code themselves or in partnership with AI. So I think this is a really awesome process, and I would... I, I definitely want this, these rubber, rubber duck rules.

   13. TLTerry Lin27:44

       Yeah, and I think rubber ducking, vibe-coding is essentially like a reverse rubber ducking, right? Like, we're telling the LLM what we want, but then it's spitting out the code for you, right? And I think building this muscle actually helps you build faster over time, because you're learning how to debug stuff with LLM as your tutor. As you go through this process, you can start to see when it starts to makes mistakes, and you can get through them faster just by going through this process and learning through your codebase. And kinda the rate of learning is what you're trying to optimize for, uh, with this rule.

10. 28:13 – 31:20

    Prototyping with index cards and GPT-4

    1. CVClaire Vo28:13

       I always think this is so interesting, all of you organized vibe coders out there. Ryan, who was on our podcast, has a somewhat similar, slightly different flow. Yours is a little bit more technically oriented. I still just like to float through the ether, eating as many tokens as possible, letting the LLM take me where it will. [chuckles] Maybe I will bring some more of this structure. I'm just really good at writing PRDs, you know? Um, and so I start from there, and then just let it, let it rip. Um, but, but I love this process. Okay, I want you to show us one more thing, which is a little bit more on the design and exploration side, which is how you combine, um, you know, offline drawing and online to build little mobile prototypes and try out ideas.

    2. TLTerry Lin29:01

       Yeah. So with mobile, the fun thing is, I prototyped this using index cards here. So I'll show you what that looks like. Uh, so sometimes in New York, when you're in the subway, you run into these dead spots where you don't have reception. And so one thing I started doing, is I started using these little index cards here, where I would just draw out the UX, and I could, like... You could kinda like press something, you could change it to kinda simulate that, uh, kinda UX. And then what you can do, is you can send this picture into GPT-4 on your mobile device, and just tell it, "Hey, this is a mock-up. Can you help me upscale this?" And so here's kinda what it looked like here as a scribble, right? And then you can start getting variations, asking it to change different layouts, and then eventually you can put this into a tool. I use a tool called UXPilot, which can actually spit out, uh, Figma components. And then when you drag it into Figma, uh, there's- Apple has some libraries you can use. So this is what the UI kit looks like. You can do, like, segmentation bar. They have different names for their different things on the iPhone. You see this is... And then you just click Insert, and you can just start building, like, a iOS app very quickly with kind of the default Apple layout, too. So that's how you can quickly kind of spin up a design.

    3. CVClaire Vo30:12

       Okay, so you are prototyping a mobile app on your mobile app-

    4. TLTerry Lin30:16

       Right

    5. CVClaire Vo30:17

       ... sometimes with no connection, by using an index card, which is a perfect aspect ratio for-... prototyping a, a mobile app, you take those, you upload them to ChatGPT, use four- do you use the 4.0 image generator? Is that what you're using to get the, um, prototype?

    6. TLTerry Lin30:34

       Yep, and I think this was around the time when they released ImageGen. It just got really good, and so that's when I realized, "Oh, it could take a lo-fi thing and upscale it for me very quickly."

    7. CVClaire Vo30:42

       Cool, and then you drag it into Figma, and then use some of the out-of-the-box components. I have to ask, have you ever just uploaded the [chuckles] those, um, index cards directly to Cursor to see what it, it does with them?

    8. TLTerry Lin30:57

       I have tried, but the results aren't great because I think it's like an input-output equation. And if you give it a lo-fi thing, it just gives you something that's pretty sloppy. Um, yeah, I think everyone knows that you- the more hi-fi you get, the better quality you can get, and so that's kind of where I'm really struggling at, is, like, getting the design... Like, I think getting the design 80% of what you want is pretty easy, but that last 10, 1% is, like, really, really hard

11. 31:20 – 32:29

    Human creativity and the last 10%

    1. TLTerry Lin31:20

       to fiddle with LLM.

    2. CVClaire Vo31:22

       Well, this is what I tell designers all the time, is I say, "Your value add is not getting the forms on the, on the website. They're- it's not getting the buttons in the app." It is that last 10% that really-

    3. TLTerry Lin31:35

       Yeah

    4. CVClaire Vo31:35

       ... differentiates an app, and I still think there's this great place for human creativity, and craft, and innovation in that space. And so I hope the designers that are listening, um, you know, look at this app, and they go, "I know what the 10% is," and then they-

    5. TLTerry Lin31:50

       Yeah

    6. CVClaire Vo31:50

       ... they bring that to their, their companies or their projects.

    7. TLTerry Lin31:54

       Yeah, it's like just looking at this app, there's things that annoy me, and I'm like, "Oh, this is, like, the last 10%, but it works. I should do other things," 'cause just gotta keep shipping, right, as one person, so.

    8. CVClaire Vo32:02

       Oh, my gosh, you're giving us PMs, and our love for MVP is a bad name 'cause you know those engineers and designers always wanna finish that last 10%. [chuckles]

    9. TLTerry Lin32:12

       Yeah, yeah. I think as a, as a PM, when you do these side projects, I think it also makes you communicate better with your engineers and designers just 'cause you know what they go through, and, like, when you go back and bring this context back, you can just have much better conversations, uh, by doing these side projects, too.

    10. CVClaire Vo32:28

        Great. I,

12. 32:29 – 36:16

    Lightning round and final thoughts

    1. CVClaire Vo32:29

       I completely agree. Well, Terry, this has been so fun. We are going to do a couple lightning round questions and then get back to your dumbbell shrugs. Um, my first question is, you know, the thing that I was struck with at the beginning of this podcast is the sort of, like, Xcode, Cursor, rebuild flow. And so if you could make an ask out there on behalf of all the mobile app developers to anyone thinking about AI software coding tools like Cursor or any of the agentic workflows, what's your ask?

    2. TLTerry Lin33:05

       Anything that lets me know what's going on in the mobile. Uh, one example is there's no Network tab in Xcode, so you don't actually know what traffic is going in, so it makes it hard to debug. I have to then do print statements, which gets very old school and annoying to do.

    3. CVClaire Vo33:19

       Got it, so just basic quality-of-life improvements for mobile, mobile engineers. Do you feel like the LL- L- LLM models are pretty good at, you know, mobile languages? Do you feel like you're getting high-quality code output when you're developing for mobile? I've heard a lot, uh, from users that [lips smack] you know, these LLMs are really well-trained on some ecosystems and languages and less so on others. Have you had any challenges there, or you feel like they're pretty good?

    4. TLTerry Lin33:46

       I haven't had issues yet. I think where I have issues is if it uses an older library or kind of way to describe the language, but other than that, it's been okay. 'Cause I think these tools now can access the docs. You could use websites, so you can kind of figure it out from there, and I think they'll just get smarter over time, so I haven't seen that be an issue right now yet.

    5. CVClaire Vo34:03

       Great. Okay, and then my last question: You're so organized, so maybe you never have this problem, unlike me, who is very disorganized. But when the LLM is not listening, when it's making 900 line, uh, code files instead of 200-line code files, what is your tactic for getting an LLM back on the right track?

    6. TLTerry Lin34:26

       Uh, let's see. I will use a lot of Git commits, and then that's my fallback, basically. I'm almost overly committed to that tactic.

    7. CVClaire Vo34:34

       So you are just breadcrumbing along the way, each change. So you do risk mitigation as opposed to redirection. So you're like, every little change, you're doing a Git commit, so if it ever gets off track, you can just go back and reset.

    8. TLTerry Lin34:49

       Yep, every three tasks, there is a Git commit before or after, and that's how I know I can let it rip because I have that risk mitigated, right?

    9. CVClaire Vo34:56

       Oh, come on, you gotta live. You gotta do, like, a 15-file plus 2,500 lines minus 74-line commit. You gotta live, my friend. [chuckles]

    10. TLTerry Lin35:07

        Yeah.

    11. CVClaire Vo35:08

        Uh, see, here's where we can show we're just very different people, red-

    12. TLTerry Lin35:12

        Yeah

    13. CVClaire Vo35:12

        ... blue, fire, ice, you know, hot, uh, AI coding, YOLO, very controlled Git commit- [chuckles]

    14. TLTerry Lin35:21

        Yeah

    15. CVClaire Vo35:21

        ... [chuckles] coder. Okay, well, this is very fun. Terry, thank you for showing us your flow. I think this is really useful for anyone, um, coding in these tools, for PMs looking how to get started or apply their process, [lips smack] and then for people stuck on the subway thinking about how they can make their next app. Uh, where can we find you, and how can we be helpful?

    16. TLTerry Lin35:41

        Yeah, you can find me on LinkedIn or on X. Uh, it's me, Terry Lin.

    17. CVClaire Vo35:46

        Amazing. Thanks so much. [upbeat music] Thanks so much for watching. If you enjoyed the show, please like and subscribe here on YouTube, or even better, leave us a comment with your thoughts. You can also find this podcast on Apple Podcasts, Spotify, or your favorite podcast app. Please consider leaving us a rating and review, which will help others find the show. You can see all our episodes and learn more about the show at howiaipod.com. See you next time!

Episode duration: 36:16