Then I built it anyway, and it changed how I work.
I’m the kind of person who tries to sit outside on a warm, sunny day with a book and actually relax — and instead finds herself walking back inside to fix a bug, add a feature, tweak something that’s been nagging at me since the last commit. So when I read that you could trigger AI coding agents from your phone, my first reaction was: why in the world would I want that? The whole point of stepping outside was to get away from the keyboard, not carry it with me.
Then I actually thought about what it would mean, and I set it up anyway. Now I can kick off a plan, answer the questions it asks along the way, review the pull request, merge it, and watch the change go live — all from a lawn chair, without going back into the house. I still get to sit outside with my book. I just don’t have to choose between that and shipping.
I started using AI to help with code a couple of years ago, and honestly, it was fine. Useful, but not a substitute for actually knowing what I was doing — I still had to catch what it got wrong, still had to know enough to steer it. Somewhere in the last year, that changed. As I worked through more of my own app projects — refactors, new builds, whatever idea had shown up that week — I started paying real attention to how I was using it: which model for which job, which mode for which kind of work. That’s when it went from a helpful assistant to something closer to a second set of hands I could actually direct.
The pattern that stuck: an idea shows up, usually out of nowhere, and I don’t start typing code. I start by building a plan — a detailed prompt with a clear goal, real context, and a defined output — using the strongest model I have access to. Then I hand that plan to lighter, faster models to actually execute it. Credit where it’s due: the plan-first approach is something I picked up from Jake deVarennes, and it’s a big part of why my AI-assisted output got so much more reliable. Splitting “figure out what to do” from “go do it” sounds obvious in hindsight. It wasn’t, until it was.
None of this works if I just trust the output. Even with a well-defined plan, AI still introduces bugs a good prompt can’t anticipate — so testing isn’t optional, it’s the whole second half of the job.
And it’s not only bugs. There are regular moments where the agent tells me something can’t be done, and I know that’s wrong — usually because it’s something specific to the tool I’m building, context the model has no way of knowing on its own. I push back, hand it my own plan for how it should work, and more often than not it comes back agreeing, and fixes it. Other times the first pass technically works but is clunky, and testing surfaces that — I suggest a cleaner approach, and it implements it. That back-and-forth, not one dramatic catch, is what verification actually looks like day to day. I’m not just approving what the model hands back. I’m the one who knows the tool, and I have to keep proving that.
With that pattern in place, I can go from idea to a working baseline in a day — usually hours. From there it’s a week of using it, finding new ideas, fixing what breaks, before it’s in a genuinely good state. Give it three or four weeks of that same loop and it’s solid. None of that timeline is about the AI being fast. It’s about the plan being right early, and the verification loop catching what the plan couldn’t.
That’s what AI-augmented development means in my hands. Not a tool that writes code for me. A tool I can direct with a clear plan, hand off to the right model for the job, and hold to the same bar I’d hold my own work to — the pattern behind everything I build.