What Changes When You Build an App With an AI Agent Instead of Writing Every Line Yourself

I'm a few weeks into building a mobile app solo. It's in the identity and habit-change space, still early, still unnamed publicly. This isn't a launch post. It's an honest account of a process decision that changed more about how I work than I expected: building most of it with an AI coding agent instead of writing every line myself.I want to be specific about what actually changed, because "AI writes the code now" is both true and the least interesting part of it. Starting with the boring part Before I touched a single screen, I wrote the full database schema. Every table I could reasonably foresee needing for the MVP, plus row-level security policies on all of them, before a single real user existed. This felt like the slow option. UI is the visible part of building something. A schema is invisible until it's wrong. The reasoning held anyway: a screen is cheap to redo. If a button's in the wrong place or a flow feels clunky, that's an afternoon's fix. A wrong data model discovered halfway through building screens is a different kind of expensive, because every screen you've already built made assumptions about the shape of that data. Fix the schema, and you're not just changing a table, you're going back through every screen that touched it. Security followed the same logic. Retrofitting row-level security into a schema that already has real user data in it is a genuinely worse migration than writing the policies before anyone's signed up. So I paid that cost early, while it was cheap and nobody was affected by getting it wrong the first time. One near-miss came out of this discipline. I nearly wrote the onboarding flow before confirming the auth system actually worked end to end. Onboarding needs to write to a signed-in user's profile row. No authenticated user, no row to write to. Small thing to catch, but it would have cost a wasted build cycle if I'd skipped the check and found out three screens later. The actual shift with an AI agent Here's the part that surprised me. Using an agentic coding tool didn't mainly save time on typing. It moved the actual work upstream, into specification. A vague instruction produces vague code, or confidently wrong code, the same way it would from a human contractor who doesn't have the context in your head. The agent doesn't know what "make the check-in screen" means unless you tell it what "means" actually means here. Take the streak logic on the evening check-in screen. A loose version of that instruction might say something like "update the user's streak when they check in." That's enough for a human who already has ten similar apps' mental models to draw from. It's not enough for an agent that has no reason to guess your specific rules. The version that actually worked specified: if the challenge was marked complete and the last check-in was exactly yesterday, increment the current streak. If there's a gap, or this is the first check-in, reset current streak to one. Always track longest streak separately, and never let it decrease. If the challenge wasn't completed, reset the current streak to zero but leave longest streak and the last-checkin date untouched. Written out like that, it's not really a coding task anymore. It's a business logic decision, made explicit enough that execution becomes mechanical. The agent didn't need to guess what "update the streak" should mean, because there was nothing left to guess. That's the actual skill shift. Less time spent on syntax, more time spent thinking clearly enough to write requirements that don't leave room for a wrong interpretation. It's closer to writing a spec for another engineer than it is to traditional solo coding, except the turnaround on that spec is minutes instead of a sprint. The decisions that aren't really about code A few product calls came out of this build that had nothing to do with the tooling, but wouldn't have gotten made carefully without slowing down to write them out as explicit instructions. One: nowhere in the app does missing a day produce a red X or guilt-tripping copy. "I didn't get to it today" needed to be a normal, expected outcome the app handles calmly, not a failure state dressed up in shame. That's a one-line design principle, but it touches copy, color choices, and how the streak-reset behaves. It only became consistent across all of those because it got written down once, clearly, instead of being a vague feeling I was hoping would come through in the details. Two: the home screen loads today's content two different ways. There's a personalized path, meant to come from an AI content-generation pipeline I haven't built yet, and a static fallback path that pulls from a fixed template library if personalization isn't ready. I built the fallback first, on purpose, so the full user loop, sign up, see today's content, hear it read aloud, do the challenge, check in, would be testable today rather than blocked on a piece of the system that's still weeks out. Small decision. It's the difference between having something real to use this week versus waiting for every piece to be finished before any of it is usable. Neither of these show up in a demo. Nobody screenshots a streak-reset rule. But they're the actual texture of whether the product feels considered or feels like a template with your name on it, and they got made carefully because the process forced me to say exactly what I meant before anything got built. Where this leaves the build The core loop works end to end now. Schema, auth, onboarding, the daily content screen with a working fallback, and the check-in flow with real streak logic. The AI personalization layer and the paywall are next. I'm stopping here for a bit to actually use the app myself for a week before adding anything else. That's less a productivity tip and more an admission: it's easy to keep building past the point where you've actually tested whether the thing you built works the way you hoped it would feel, not just the way you specified it to function. I'm documenting the rest of this build in public as it happens, mistakes included.