How we transformed our product process with AI: fewer boundaries, more shared knowledge

A case study on how, at Embat, we redesigned our product process using AI, and what we learned along the way. How AI, shared context, and a mature Design System have enabled us to blur the boundaries between design, product, and development.

According to the latest State of AI Design (Designer Fund + Foundation Capital, 2026), 91% of designers now use AI in their work at least once a week — up from 54% the previous year. The conversation stopped being "whether to use it" a while ago. Now it's "how to integrate it." And every team is answering that question very differently.

At Embat, after months of research and iteration on our process, we have our own answer. So integrated, in fact, that in May the person who made the most commits to our front-end repository wasn't one of our developers. It was a designer.

Let us tell you how we got here.

What made the change possible

For years, our design process worked the way it does on most teams: linear, expensive to iterate, with heavy documentation written before we knew whether the solution was the right one. Over the past few months, we've flipped it.

Three things started to converge at the same time.

1. AI models capable of working directly on a real code repository, not on abstract mockups. We've been using Claude Code, but every team should find the tool that best fits their needs. It's not so much about the tool itself: today it's possible to prototype on production-grade code at a level of fidelity that didn't exist just a few months ago.
2. A Design System that was mature enough and — this is key — AI ready. That means all the interaction patterns, the rules about when to use each component, the usage guidelines, no longer live only in the heads of the design team: they're in markdowns and guidelines that are part of the system itself. The Design System stops being just a component library (though it never really was) and becomes a body of knowledge that an agent can consult.
3. Specialised skills. This has become one of the most relevant parts of our system. We've been creating skills that bring specific context to an agent or system of agents for concrete tasks: one that helps you explore a problem and challenge assumptions, another that knows the business inside out and how Embat's different modules are used, another that connects with our research databases to bring in real feedback. Each skill is a living asset that we improve with every cycle.

The combination of these three factors allowed us to flip the process on its head.

Different conversations, a shared language

Today, our entire process speaks the same language. It starts with an input — customer feedback, a product hypothesis, or a discovery finding — and keeps accumulating from there. What used to be separate phases that translated from one to another (the PRD became design, design became code, code became documentation) are now different forms of the same context, which we extract depending on what each moment calls for: a prototype, a PRD, a Jira ticket, a technical markdown, a release note.

Our flow (today) works like this:

Step 1: Input arrives and the guided conversation begins

When an input arrives, we kick off with the /product-discovery skill, which challenges us and also automatically searches our feedback sources: research databases, past interviews, and internal Slack channels. This phase stops being a solo exercise on a blank page: it's a guided conversation with plenty of context already available. This conversation happens in Claude Code, already connected to the repository, so that the context we accumulate lives from the start in the same environment where we'll prototype later on.

Step 2: Conceptualising the experience

Once we have a reasonably clear idea of what we want to build, we move into defining and conceptualising the experience with /ux-designer. This skill is a multi-agent system: a top-level product designer agent with access to five other agents, one for each of Embat's customer archetypes. We think alongside them about what the ideal experience would look like.

Step 3: Prototyping with shared context

We now know what we want to build, so we move into prototyping. Here /ui-designer comes in, another multi-agent system where each agent owns a domain of the Design System and draws on all of our interaction patterns. We describe the functionality and the agent builds a prototype that runs locally, using real components from the product.

What matters isn't only that it's fast, but that iterations stop being expensive. We used to iterate once or twice because each round cost weeks. Now we iterate six or seven times within a few days. We test different approaches, discard the ones that don't work, and refine the ones that do. When something doesn't quite click in the interface, we change it in minutes or a few hours. And anyone from the product team can join in on these iterations, with no need to know prototyping tools or have deep knowledge of moderately complex interaction patterns.

Step 4: Validation with stakeholders and process enrichment

By this point in the process, we've done enough iterations to deploy to staging. From there, we validate with internal stakeholders and with customers. The sessions are recorded; the transcripts feed the same Claude conversation that started during discovery. Context doesn't get lost between phases: it accumulates.

Step 5: Documentation with context

Once the validations are through, the prototype gets locked in and we move into documentation. And here something interesting happens: we don't write it from scratch. Claude has all the accumulated context for the project, so it can generate the PRD and publish it directly in Notion, create user stories directly in Jira, and leave a markdown in the repository branch explaining which components are real, what's mocked, what design decisions were made and why, along with detailed design specs (measurements, tokens, behaviour by state) in the style of what Figma generates for handoff.

The development team receives something radically different from what they used to: a code branch with a working prototype, stories in Jira, and markdowns with all the necessary context. Not a Confluence page with specs and a link to Figma.

The impact: barriers blur

As surprising as it may sound, the most interesting thing about this change isn't the speed. It's what we can now do with it.

Product Manager and Product Designer, more aligned than ever.

Each role keeps its expertise: the Product Manager in business definition, the Designer in craft and contact with the user. But during ideation and prototyping, the line between the two dissolves. Both can prototype. Both can generate documentation. Cross-validation is mandatory, but ownership of the functionality depends on who leads it, not on the job title.

Design and development now speak the same language.

The deliverable to development is no longer an artefact that another team has to translate into code. It's real code, built on the same repository the front-end team uses, with the same components. The translation gap between what design imagined and what development built has practically disappeared.

The idea has never looked so much like its implementation.

The same conversation that began with a discovery interview is the one that ends up generating the final documentation. There are no jumps between tools, no rewordings. Context accumulates and progressively transforms into artefacts.

The product designer's role doesn't disappear. It expands.

When we tell people about this process, the question that almost always comes up is: if a Product Manager can prototype, what's the point of having a designer?

The honest answer is that we already know this question confuses prototyping with design. Prototyping is just one phase of the design process, the tangible consequence of prior work. And a poorly conceived prototype is just as useless built by hand in Figma as it is built by an agent in minutes. What matters is the judgement behind it.

The product designer's work is still, above all: contact with the user (observing, interviewing, detecting needs that haven't yet been articulated), the judgement to decide what not to do (a well-configured agent can suggest simplifications, but someone has to validate them, contextualise them, and take ultimate responsibility), transversal coherence (so the product feels like a whole and not like features taped together), and the fusion between areas, helping business, product, design, and technology understand each other. 80% of respondents to the latest State of AI Design say they prefer human judgement over AI's on the decisions that matter.

And above all that, there's a new layer of craft: designing the system that allows others to build well too. The design team maintains and refines the infrastructure that makes it possible for any maker to prototype with designer-grade quality: the Design System, the agentic skills, and the expertise documents. This, more than a change of role, is an expansion of it: the skills that already defined us gain more space when we free up time from mechanical work. And design remains the ultimate owner of the experience: someone else building the prototype doesn't exempt design from reviewing it, correcting it, and stepping into the equation when needed.

But that's the theory. After two months working this way, we've learned a few things we perhaps didn't expect.

What we've learned

Context is the new artefact. The headline deliverable used to be the PRD or the mockup. Now it's the accumulated conversation in Claude, because everything else can be derived from it: the prototype, the specs, the markdowns, the release notes, and even the copy for this blog. Taking care of the quality of that context (what information we give the agent, how we structure it) is now a central part of the work.

Speed isn't the goal, it's the consequence. There's a well-known phrase in the startup world: fail fast, learn fast. The real value isn't in prototyping faster per se, it's in being able to iterate more times without friction, fail cheaply, learn cheaply. A prototype we build in two hours isn't better than one that took a week. What matters is being able to discard it and build the next one that afternoon, or even during the validation session itself. Speed buys exploration. And for a startup like Embat, where the need to move fast and stay open to change isn't optional, this capability is fundamental.

The Design System becomes a critical asset. When the agent prototypes using real components, any inconsistency or gap in the DS shows up immediately. The agent ends up hardcoding a component or a piece to work around it. Each prototype is an audit of the system. And each new or evolved component that comes out of the process feeds back into the DS, fuelling a virtuous cycle. With the flip side: if we stop showing the DS some love, the repository degrades and the cycle breaks.

Adoption is a culture problem, not a tools problem. The easy part is installing Claude Code and setting up access. The hard part is changing the habit of starting everything by writing a document in Notion. This requires explicit intent: training sessions, initial pairing, and above all, clear norms. In our case, we've established that any feature presented at our weekly Experience Review has to be an interactive prototype, not a document.

Where we are now

None of this is closed. It's a living process: we iterate it, challenge it, and refine it with every cycle. And that's exactly the kind of challenge we wanted to have.

But one thing is clear: the previous model, where every step of the process was a translation between formats that nobody could modify, no longer makes sense in a world where a well-configured agent can produce, in a matter of hours, something practically indistinguishable from the real product: same components, same code, same environment.

This change might not be comfortable for many. Some roles will have to learn and develop new skills. Others may feel their territory is being invaded by roles that didn't enter it before. And others of us are letting go of tools we'd made our own and had spent years perfecting. But that discomfort is exactly the signal that we're in the right place: the one that forces us out of the role we knew and into building a wider one.