AI-Assisted Development: A Practitioner's Honest Guide
I’m not an engineer. I haven’t written production code by hand in over a decade. But in the last year, I’ve shipped a full consulting website, built a consumer AI product from scratch, and created high-fidelity prototypes at Amazon that engineers used as starting points for production systems. All using AI-assisted development.
This isn’t a tutorial. It’s an honest account of what the workflow actually looks like from a product leader who uses it daily.
What I Actually Use AI Development Tools For
Rapid prototyping. This is the killer use case. When I need to show stakeholders what a product could look like — not a wireframe, not a mockup, a working prototype with real components — AI-assisted development gets me there in hours instead of weeks. At Amazon, I built prototypes using real design system components and packaged the code as starting points for engineers. The conversation shifted from “should we build this?” to “let’s refine this.”
Full product builds. This website — jonlewis.ai — was built entirely with AI-assisted development. Astro, Tailwind, content management system, dark mode, SEO, the works. It’s not a toy. It’s a production site with real traffic. My AI Family Planner is a full-stack consumer product built the same way — custom pipelines, authentication, the full stack.
Code review and debugging. I can read code well enough to catch issues, understand architecture, and make informed decisions. AI tools let me go further — refactoring, fixing bugs, adding features — without needing to context-switch to an engineer for every change.
What People Get Wrong About “Vibe Coding”
The term “vibe coding” makes it sound casual. It’s not. The workflow requires product judgment at every step. The AI writes code. You have to know whether it’s the right code — whether it solves the actual problem, whether it’ll scale, whether it matches the design system, whether it introduces security issues.
The people who struggle with AI-assisted development aren’t the ones who lack technical skill. They’re the ones who lack product clarity. If you can’t articulate exactly what you want and why, the AI will build you something that’s technically functional and completely wrong. Garbage in, garbage out — the AI just makes the garbage faster.
Where AI-Assisted Development Excels
Speed. Something that would take an engineer a sprint takes me hours. Not because the AI is better than an engineer — because I’m eliminating the handoff. No requirements doc, no sprint planning, no context translation. The person who understands the problem is the person building the solution.
Iteration. Change direction instantly. “Actually, make that dark mode.” “Add a filter here.” “Restructure this section.” With traditional development, each of those is a ticket. With AI-assisted development, it’s a conversation.
Reducing ambiguity. The biggest source of waste in product development is the gap between what the PM meant and what the engineer built. When I build the prototype myself, that gap disappears. The engineer gets something they can see, touch, and extend — not a spec they have to interpret.
Where AI-Assisted Development Struggles
Complex state management. AI tools are great at generating components and layouts. They’re less reliable when dealing with intricate state logic across multiple systems. I’ve learned to keep the AI-built pieces modular and let engineers handle the complex orchestration.
Consistency across a large codebase. The AI doesn’t hold full context the way a senior engineer does. On larger projects, you need to be deliberate about patterns, conventions, and architecture — or you end up with a codebase that works but is hard to maintain. That’s why the system matters more than the prompt.
Knowing when to stop. The temptation with AI-assisted development is to keep going. Add one more feature. Fix one more thing. The same product judgment that makes the workflow powerful is needed to know when the prototype is good enough to hand off.
Who AI-Assisted Development Is For
This workflow isn’t going to replace engineers. It’s going to change what product leaders can do independently. If you’re a PM, a founder, or a product consultant who spends more time writing specs than you’d like — AI-assisted development lets you build the thing instead of describing the thing.
The moment I realized this workflow had changed things for me was at Amazon, watching an engineer open the prototype I’d built and start extending it immediately. No requirements doc. No clarification meeting. He just looked at the code, understood the intent, and started making it production-ready. That handoff — the one that usually takes weeks of translation — took about ten minutes.
Facing a similar challenge?
Let's talk →