Digital Product Talks #36: Vibe Coding and Judging AI Output

Kind of convincing, right? That design lead was Kevin Martin, and I got to talk it through with him on the latest Digital Product Talks. Kevin is Product Design Lead at Riverty, Bertelsmann's fintech. If you've ever ordered something online in Germany and paid the invoice 30 days later, there's a fair chance Riverty was handling it.

Kevin has been there four and a half years, leading a small design team. That makes his AI stories more interesting to me, because small teams are practical about how they adopt AI, because the hours run out before the tasks do.

The wins: prototypes, dashboards, and saved dev weeks

Kevin's team recently redesigned their product, new user journeys and all. Instead of walking stakeholders through static screens, they prototyped it first in Figma Make, then in Claude, and shared a clickable version across the company. He was struck by how fast they got into a good discussion, just because people could click through the thing instead of staring at a slide.

He shared a few more stories about how his team put AI to work. One involved a portal that was number-heavy, a bunch of tables and dashboards. Usually, structuring those means a few hours of research per view, figuring out how to cluster the data, what to filter, and so on. Now AI builds a working foundation in a few minutes, and you shape it into something proper from there.

Another story was about email templates. No developer had the capacity to build them, so a working student did it with Claude and Cursor. The developers only connected the interface at the end. Kevin estimated they’d saved about three weeks of developer time.

Kevin has also spent the last few years driving accessibility at Riverty. The logical next step was an external review tool, at five figures a year. While that decision sat pending, they set up Claude to help. It ended up covering 70 to 80% of the review work, with a contrast plugin in Figma handling the design side. This means a five-figure line item turned into one dedicated person and a few hours of work a month. Crazy, right?

Who reviews AI-generated code?

While all that sounds great, every one of those stories comes with its own warning. Those email templates that saved three weeks? Kevin is very clear that his designers can't fully judge the code they produced.

"We're producing code ourselves now. Ideally, someone should catch us and say whether it's good or not, because we can't assess that from where we sit." Kevin Martin, Product Design Lead at Riverty

Vibe coding your way around a missing frontend dev sometimes works, but it's not the way of working for the future. If you want a product that can survive scrutiny in the long term, you still need a developer to review it.

There's also the part where you can take vibe coding too far. When the team shared their new prototype internally, a colleague took the public link, dropped it into Claude, and asked for feedback. Feedback from Claude on a prototype built with Claude. Funny, but where's the designer in this loop?

The limits also show up in smaller, annoying ways. Claude has a ceiling of its own once complexity and creativity come in. It kept flipping Riverty's logo, which is a simple R made of two blocks. We hit the same thing at COBE, where Claude couldn't reuse our logo accurately, no matter what file format we gave it.

"Maybe it's too creative for it," Kevin said.

Designers become architects (and notaries?)

So where does that leave the people who used to do the producing? We’ve touched on this in an article of our own, and it’s something Kevin agrees with: designers are becoming architects. With AI doing the producing underneath, designers plan, structure, and make sure the logic behind the screens holds.

The way to avoid chaos is with guardrails. For Kevin’s team, that means writing rules down in formats the AI can read, such as .md files that control the design system, so the green button doesn’t turn pink out of nowhere. Or for UX writing, there is a tone of voice that keeps it consistent no matter who prompts it.

At some point we joked that UX designers are becoming the new notaries. The stamp is what makes it safe to go live, whether you put in one hour or ten. And the rate scales with the value of the project, naturally.

But that stamp doesn't come from a certificate. Kevin said it comes from two things. The first is product understanding, which means genuinely thinking your way into the product and its users, which only comes from experience. The second is a very German word he kept coming back to: Bock. You have to have Bock. You have to want to get your hands into this stuff, try it, build with it, fail with it, and stay with it.

What vibe coding means for your product team

The title of this one says it: with vibe coding, building became the easy part. But knowing what's good enough to put in front of users, run in production, and carry your brand still takes years of doing the work.

That judgment, applied at every step from design through development to QA, is what we spend our days on at COBE. If what your team needs is a second pair of eyes on something you've built, with AI or without, we're happy to help.

Want to hear the full conversation with Kevin Martin? Listen to the episode on the Digital Product Talks podcast on Spotify or Apple Podcasts.

‍

TL;DR

In a rush? Worry not, we’ve prepared a quick summary for you.

What is vibe coding? Vibe coding is building something (a screen, a component, a working prototype) by prompting an AI tool instead of writing the code or drawing every element by hand. 

Can you ship AI-generated code to production? Sometimes, but not without a developer reviewing it first. For anything meant to last, you still need someone who can read the code and vouch for it.

Who should review AI-generated code? Someone who can actually read it. AI can hand you a working foundation in minutes, but it can't tell you whether that foundation is sound, so a developer still needs to check anything headed for production.

Will AI replace product designers? No, but instead of producing screens, designers move up to planning, structuring, and checking that the logic behind the product holds.