Join the conversation
.png)
Get ahead of the curve and learn from leading care providers and companies such as Cityblock Health, One Medical, Oak Street Health and more
Watch the full conversation with Andrew Schutzbank, Rik Renard and Thomas Vande Casteele here to go deeper on vibe coding, product philosophy, and practical tips for getting started.
If you're a product manager, clinical operations lead, or healthcare professional with an idea but no engineering team - or an engineering team that’s working on other stuff - this conversation is for you. Andrew Schutzbank - MD, built product at Iora Health, and now independent advisor - recently joined us to discuss how he built Schutzduck, an AI advisor, entirely through vibe coding.
Here's what you need to know to start building.
Vibe coding is writing software with AI, by expressing what you want through natural language. Instead of writing code line by line, you describe what the software needs to do, how it should feel, and AI tools generate the code and the actual working prototype.
This fundamentally changes how clinicians could transpose their ideas and bring them to life.
Traditionally, a clinician would write requirements in a document, hand them to product, who would translate them into specs, which engineers would eventually build. Months later, the clinician would see something that doesn’t solve the problem. Sound familiar?
With vibe coding, clinicians can play with the actual interface, click around, test workflows, and refine in real-time. Then hand over something tangible to product or engineering teams. The result: better mutual understanding and higher velocity: not just speed, but speed in the right direction.
Before diving into tools, Andrew shared his core product philosophy, central to over a decade building product at healthcare companies.
The first principle sounds obvious but is worth repeating as it is so often not followed: focus on solving a problem, rather than building a solution.
"The best products are where the user or customer achieves what they wanted, right? So in the case of a patient, they're better, their symptom got reduced, or their functionality returned... then the product is successful."
The technology stack, the features, the roadmap, are all secondary. What matters is whether you're solving a real problem for someone.
This matters even more with vibe coding, where the barrier to building is so low that you can easily get distracted building things nobody needs. Stay anchored to the problem.
Andrew's second principle: you can't predict the future, so stop trying.
His favorite example?
“I asked everyone in 2020 how many people had COVID on their roadmap in 2019? And the answer is no one, and is the most important thing that happened, pretty much in our lives."
Traditional product development assumes you can map out a year of features in advance. Vibe coding inverts this. Because you can build and test ideas in hours instead of months, you don't need to predict. You can respond.
The key insight from Andrew: you don't need to know the tech stack upfront. Start by picking an AI tool that feels natural to work with, then let it guide you on the rest.
Andrew asked Claude what tools to use and negotiated the choices:
"I discuss all these choices with it... You can ask the tools what tools to use and argue with it. Always negotiate with whatever you get. Push back, ask the question twice."
If you're unsure about a technical decision, ask multiple AI tools. Don't just accept the first answer. Question it. Compare options. Make informed choices even if you're not technical.
The biggest mistake newcomers make is treating AI as a black box. Copy-paste the code without understanding it, and you'll get stuck the moment something breaks.
Andrew's rule: although vibe coding tools like Bolt, Lovable, Replit, etc. are alluring, they could become black boxes where you input language and see a working product. Better to work with Claude, ChatGPT or Cursor to write the plan and the code; then paste it in a coding tool. You have to be in the middle pushing the buttons.
"You gotta be in the middle pushing the buttons, and you don't have to type the line out, but you should at least paste the line in. And read it, and try and figure out what it does. Or ask. If you're not going to be curious and inspect what you're getting... then you're not getting the full experience."
This isn't just about learning—it's about building empathy and understanding. As Andrew puts it:
"I feel like I'm cosplaying as an engineer. Like, I'm speaking a language I don't understand, I'm frustrated about things that never occurred to me that should just work... I've developed a lot of empathy for engineers, even more than I had before."
This connects to a recurring theme in CareOps: shadowing. When clinicians shadow engineers, they develop empathy for technical constraints. When engineers shadow clinicians, they understand workflow realities. Vibe coding is a form of shadowing—you're experiencing the engineering process firsthand, building products while learning how systems actually work.
The result? You don't need to become a software engineer, but you understand the logic. You can make better product decisions. You can communicate more effectively with technical teams. And critically, you maintain control over your product.
Here's the dark side nobody talks about: vibe coding is addictive.
Andrew calls it "trapped in flow":
"It's such a good feeling, I'm making so much progress. It's this feeling of with this next change, it's gonna fix the problem I'm working on... It's a constant tease... it's a dangerous, addictive experience, again, like video games."
The ease of making changes can trick you into building endlessly without shipping. One more feature. One more fix. The flow state feels productive, but you're not necessarily making progress.
Andrew's solution? Trello (or another application to manage tasks and to do’s) as a forcing function. He documents feature ideas and user stories before building them, creating friction that prevents scope creep. It's old-school product discipline applied to a new paradigm.
For healthcare product and clinical operations teams, vibe coding opens up new possibilities:
Rapid prototyping: Test workflow improvements or clinical tools in days instead of quarters. Get feedback from clinicians before committing to a full engineering buildout.
Internal tools: Build custom dashboards, data integrations, or administrative interfaces without competing for engineering resources.
Process automation: Experiment with AI-assisted documentation, patient communication, or care coordination tools specific to your workflows.
Service innovation: Like Andrew's Schutzduck, create entirely new service offerings that combine your domain expertise with AI capabilities.
The key shift: you're no longer dependent on an engineering team to validate ideas. You can build, test, and iterate yourself. And if something works, then you involve engineers to scale and harden it.
Andrew's final advice echoes his product philosophy: don't do too many things at once.
"The first corollary we can't predict the future is then don't do too many things at once. Because then you will be unable to recognize your present."
Pick one problem. Build one solution. Ship it. Learn from it. Then decide what's next.
The power of vibe coding isn't that it lets you build everything; it's that it lets you build the right thing by making experimentation cheap.
