For a long time, I used AI the way I think many developers started using it. Chatting with ChatGPT, asking questions, poking at what it could do. Later, I brought it into my editor, Zed and VS Code, as autocomplete. Then the slow move over to terminal based AI assistance. Useful, sometimes even impressive. But it didn’t feel natural.
I think part of the problem was how I was thinking about it. AI as the “Lovable model”: one prompt in, an okay-ish app out. Interesting, yes, but I could never wrap my head around that as a serious workflow. A rough app from a single prompt is still a rough app.
The shift came when I stopped thinking of AI as autocomplete or a one-prompt app generator, and started treating it more like a engineer on my team. Not someone who owns the product, the architecture, or the decisions, but someone who can work extremely well inside a clear frame.
That’s when it started fitting with how I already work.
Setting the frame
I start every project the same way, long before AI comes into it. For a web app, that might be Next.js, Firebase and Firestore, Vercel for hosting, and Auth0 if authentication is needed. For the UI, I pick something like shadcn or Material early. Then I spin up a basic skeleton and add in the basic building blocks, so the project has a clear shape.
On mobile, the same principle applies. Flutter, Material 3 or Cupertino, basic navigation and state, auth if needed. Or React Native, I’m happy working in both. The stack matters less than picking one early and letting it set the edges.
I also try to keep the technical architecture crisp. More event-driven flows, smaller modules, clear contracts. Not because of AI specifically, but because that’s how any team can move cleanly. Vague architecture creates vague handoffs.
Then I put on the product manager hat. First, I write a non-technical PRD for the whole product, so we know what we’re building. From there, I pick a single feature and write a focused PRD for it. Once that feature is done, I move on to the next one. That sequencing keeps everything grounded.
Where AI fits
The realization for me was that AI didn’t need a new workflow. It just slotted into the one I already had.
Once the frame is set, the product is defined, and I’ve picked one feature to work on, that’s where AI comes in. Before AI, that’s where I would sit down with a senior developer on the team. We’d walk through the PRD, discuss approaches, debate tradeoffs, and figure out how to implement it. Now I can do that same thing with AI.
I don’t throw a feature over the wall and wait for code. I use the PRD as a starting point for a back and forth. How might this be implemented? What could get messy later? What needs to be isolated? Which events and data shapes make sense?
Because the groundwork is there, that conversation is focused. AI isn’t inventing a product from scratch. It’s helping implement one feature inside a system that already has edges. That’s the part that started to feel natural.
Sometimes I still get into the code myself, spiking a tricky bit or sketching a pattern. But that’s the same as before AI. It keeps my hands on the code without changing the overall way I work.
The more I thought about it, the less strange it seemed. I already trust code I didn’t write every day. Frameworks, SDKs, UI kits, auth providers. I don’t read every line. I trust the contract, the tests and the boundaries. AI-generated code isn’t the same as a third-party library, but the trust pattern is familiar. That gave me a mental model for it. Not magic, not full inspection. Just clear contracts and sensible checks.
The shape was already there
What clicked for me wasn’t a new tool. It was recognizing a familiar shape. AI fits right where a strong engineer would. After the frame, after the product thinking, inside clear contracts. Not before.
The guidance is simple: frame first. Build clear edges, then use AI to pressure-test and implement feature by feature. Treat it like you would a good teammate. Set expectations, review early, and then let the tests and the process carry more of the trust.
This isn’t a revolution in how I work. If anything, it has pushed me to tighten practices that good software teams already use.
For me, naming that out loud was the shift. It made the hype quieter and the work clearer. And that’s where AI actually makes me faster, without giving up the way I like to build.
Leave a Reply