Part 4: Feeling the Vibe (Coding), What This Transition Taught Me
It’s not a magic bullet
A lot of senior executives believe design teams vibe coding is a magic bullet for saving costs. I don’t think it is, at least not yet. I believe it will get there, but right now that gap between expectation and reality is the biggest challenge.
Once you’re in the reality of it, Git and everything that comes with it is a lot to grasp. We don’t know the basics or the principles of engineering, and getting our heads around that and onto the same page has taken real effort.
Governance, with no template
Nobody hands you a template for governance. Vibe coding brings new things to assess, from how our process changes to what that means from a risk perspective.
One question came up with platform engineering: if we start vibe coding and pushing code live, are we held accountable in the same way as a developer? My team aren’t developers, so is that fair? I’m not sure, and I don’t have the answer. Does QA end up reviewing our code too?
Where we left that debate was a plan to create a hosted visual prototype that developers and the wider developer community can use. They can see how we’ve used the design system and which tokens we’ve chosen, and use that to inform what they’re building, rather than lifting our code directly.
There’s a technical gap too. Developers code in Angular, while our design system elements and code are in React. Still a work in progress.
Everything lives and dies by product strategy
This might be particular to the way we’re working at my current company, but everything lives and dies by the product strategy. I know that sounds obvious, yet how you approach vibe coding is directly linked to what the strategy is trying to achieve. Aligning design and vibe coding to it matters even more when you have multiple products, possibly multiple design systems, and multiple geographies all happening at once.
Documenting for the next wave
The learning curve was the big thing for the team and me, so we’re very aware that we need to document as much as possible. I was keen that for every tool we can say why you’d use it and how it differs from the others. That way, as more people join the team, they know what to use, when and how.
Governance was heavy, especially with a distributed remote team, and it had to be baked in from the start. The other piece is design quality and design system usage. We’re building skills and instructions within Claude so designers work to the design system and quality stays high.
The Bottom Line: Vibe coding isn’t a shortcut. It’s a new way of working, and it needs a clear product strategy, solid governance and a lot of patience.
I recorded my thoughts on this case study out loud, then used Claude to transcribe them and draft them into writing. I reviewed and edited the result, so the ideas, experiences and opinions are all mine.
