“Vibe-prototyping”: augmenting feedback-dependent development workflows and discovery with AI

Whenever someone mentions AI and software development in the same sentence, you’ll likely hear them bring up engineering speed next. While there’s no denying that AI can accelerate code production, the reality is that coding speed isn’t necessarily the biggest bottleneck in real-life projects. More often than not, it’s uncertainty around planning and requirements.

The good news is AI can help you fix that as well, even for highly complex initiatives. In fact, our recent client project involved exactly that: building Electronic Medical Record (EMR) capabilities without clear requirements. We ended up heavily using AI for prototyping, and the results were nothing short of impressive:

Higher-quality feedback from stakeholders compared to clickable Figma prototypes
Faster feedback cycles, with changes reviewed and acted on within 1–2 days
Ability to reconsider and rebuild the most challenging EMR functionality without freezing the rest of the program for another planning and design phase

Here’s how that project went and what we learned in the process.

When the EMR scope arrived

If you’ve spent enough time developing commercial software, you know that the ideal way to start working on anything consequential is by running a discovery session. In this scenario, business, design, and technical stakeholders meet to align on strategic goals, KPIs, task ownership, UX targets, and deadlines to mitigate common risks and shorten delivery timelines. This is the approach we recommend to all clients — you can read more about it here.

The starting point for this particular workflow, however, wasn’t a meeting — it was the EMR scope itself.

The trigger: EMR scope mid-stream

We were already busy working on the client’s healthcare platform when the EMR workstream emerged. The platform was sufficiently complex as is, with multiple moving parts, including customer-facing flows, back-office operations, e-commerce, and training management. Then, midstream, a new requirement landed: a highly tailored EMR capability that had to integrate seamlessly with the existing system.

The challenge wasn’t just the complexity of the EMR. The task lacked detailed specifications and designs that would normally guide implementation — the usual inputs for a structured delivery approach weren’t there.

Starting point: Replicating the legacy system

With limited references, we turned to the one concrete thing we had — the legacy system. We began by replicating key functionality, building early versions of core flows, and putting them in front of stakeholders as quickly as possible.

The goal wasn’t perfection. It was to replace abstract discussions with something tangible. Using AI to produce new code, we could give stakeholders a way to react to real software rather than designs.

What the prototypes revealed

Those early prototypes quickly exposed the limits of our legacy replication approach. What looked straightforward on the surface turned out to be layered with hidden complexity: business rules, edge cases, constraints, and implicit assumptions baked into the legacy system. Simply recreating existing flows wasn’t enough.

Anatomical charting made this especially clear. As a visual and domain-specific feature, it evolved multiple times, but the same pattern held across the EMR experience.

Once stakeholders could interact with real workflows, our engineering focus shifted beyond producing polished replicas of the legacy systems. As a result, better questions emerged:

• What problem is this solving?
• What should it allow — or prevent?
• What needs to change, and what should remain familiar?

That shift marked a turning point. We moved from replicating the past to rethinking the product while using rapid AI-driven prototyping, frequent feedback, and continuous iteration.

Why coded prototypes worked better than designs

In a traditional model, the next step would be predictable: pause, gather requirements, align stakeholders, complete designs, and then resume development. That approach works when the target is stable, but ours wasn’t.

Our scope was evolving, with new information emerging nonstop. We had already invested meaningful time in planning. Starting another full discovery cycle would have cost time without guaranteeing more clarity.

There was also a practical reason for us to prefer coded prototypes over design-heavy exploration. The workflows we were dealing with were highly dynamic. A static design, or even a clickable Figma prototype, could not easily show the behavior, edge cases, constraints, and state changes people actually needed to react to.

That difference mattered. Stakeholders gave us significantly better feedback when they interacted with coded functionality compared to when they reviewed mockups. Their feedback was more opinionated, specific, grounded, and, overall, more useful.

To clarify, this wasn’t about replacing the design entirely. We still relied on an existing design system and design input where needed. But for uncertain, fast-moving areas, adding a full design cycle often slowed learning. In some cases, waiting even a day for updated designs delayed progress more compared to generating a usable prototype.

In this context, working software became the most effective tool for discovery and feedback.

Unlocking a new delivery rhythm

Essentially, we shifted from a design-first model to a prototype-first approach — using coded prototypes as the fastest path to discovery.

It was mostly the efficiency of AI-augmented coding that made this shift viable. Using Claude Code, we could move from idea to working functionality fast enough to keep feedback loops alive.

While you can describe this approach as “vibe-prototyping,” it was in no way careless or random experimentation. We made sure to follow a disciplined, iterative prototyping protocol:

• Build a narrow but meaningful slice
• Make it usable
• Put it in front of stakeholders
• Gather feedback
• Iterate quickly based on collected data

In many cases, we could take a new idea from concept to a reviewable state within one or two days. Most weeks included two or three stakeholder checkpoints, keeping discussions anchored in a live product rather than abstract plans.

The biggest benefit wasn’t faster coding, but rather faster learning. Once stakeholders interacted with real software, feedback became more specific. Missing business rules surfaced earlier. Priorities aligned more naturally because instead of imagining different interpretations of a feature, everyone reacted to the same thing.

The product itself became the shared language. This also changed the delivery rhythm:

• Multiple feedback cycles per week
• Rapid iteration within 1–2 days
• Continuous refinement without pausing the entire program
• Less time spent by the client debating assumptions — and more reacting to real functionality

Most importantly, many prototypes weren’t throwaway artifacts. Some evolved directly into production features, accelerating delivery while improving decision-making.

Where the tools fit

The tools still matter, but not in the way people often think. Claude Code helped us move quickly from idea to working software, changing the economics of discovery. But this isn’t about one tool outperforming another.

The broader shift is this: AI has made code-based prototyping fast and affordable enough to replace large parts of traditional discovery and design research.

That means the conversation around discovery no longer has to stop at “should we design this first?” In dynamic, ambiguous scenarios, teams can often learn more from a working prototype than from another round of static design, regardless of whether they use Claude Code, Cursor, Codex, GitHub Copilot, or something else.

Yes, we still had guardrails for AI

In highly regulated domains like healthcare, speed without discipline is a massive risk. For this reason, our approach wasn’t about trading rigor for velocity — we simply couldn’t allow it.

“Vibe-prototyping” served only as our discovery mechanism. Production required an entirely different level of control. So, we added:

• Automated tests
• Code reviews
• Strong validation practices — no treating AI as autopilot.

While AI-assisted development continued beyond prototyping, we added stricter verification to support production-grade quality.

That distinction is critical. AI is far from capable of replacing engineering judgment, but it can amplify it. Without proper oversight, teams don’t get better outcomes — they just move faster in the wrong direction. With the right guardrails, however, the economics of delivery can improve significantly.

What this changes for product discovery

To repeat what we’ve said in the beginning, the story here isn’t about AI speeding up coding for developers — it’s about AI lowering the cost of exploration. As code generation becomes cheaper, faster, and better overall, teams no longer need to resolve every uncertainty through documentation before creating something real.

A very wrong conclusion to arrive at here would be that any of this can replace Agile, Kanban, or other disciplined delivery practices. Neither does this approach remove the need for product thinking, architecture, or validation. What it does, however, is change where discovery happens.

Instead of separating planning from implementation, teams can bring them closer together — using working software as the primary tool for understanding the product.

For tech leaders, the takeaway is simple: When requirements are unclear, workflows are complex, and time matters, a prototype-first approach can outperform extended discovery cycles. Not because planning is less important, but because parts of it can now happen directly in the product.

Closing thoughts and more takeaways

• In complex, dynamic workflows, real prototypes can generate more actionable feedback than static designs.
• AI tools make it feasible to run multiple build-review-iterate cycles within a single week.
• The biggest gain is faster learning — not just faster coding.
• Speed only creates value when paired with testing, review, and strong engineering judgment.

Curious to see how this approach can play out for your project?

If you’re interested in more details or actionable insight — or hands-on prototyping or engineering support — we’re always happy to help. Contact us to share your challenge with our experts and see how we can add value to your digital initiatives.