3 Steps to Building an AI-Augmented Design Team — Insights from Kamil Marczak

It started with a translation problem

In February of this year, Kamil was kicking off a B2B booking product for a client in the shopping center industry. He made a decision that turned out to change how he thinks about his entire practice.

Instead of showing up to the first client meeting empty-handed, he used AI tools to generate mockups overnight. Not final designs — anchors.

“I didn’t want to, like, achieve the final goal with that, to, like, try to, like, understand the user without any time spent during that project. But generally, the idea was that to discuss, to brainstorm ideas — to have the mockups as some sort of, like, a translation tool between me and the product manager.” — Kamil

That framing — mockups as a translation tool, not a deliverable — captures something important about what AI-native design actually means in practice. It’s not about producing more screens faster. It’s about changing what conversations are even possible at the start of a project.

Step 1: Move authority closer to the work

One of the first things Kamil noticed when he joined Boldare was how different the culture was from what his peers described elsewhere. The pattern at other companies was familiar: business decides which tools get adopted, issues a mandate, and designers adapt. At Boldare, the decision about what to try was his to make.

In Boulder, we have this condition where we could decide for ourselves, I imagine we have this sort of freedom because usually when I talk with my friends, other designers, there’s usually some sort of chain of command where, for example, business says, now we have to use cursor, or now you have to use, like, something different. But generally, in Boulder, we have really lots of creative freedom. — Kamil

This isn’t just a nice cultural perk. It’s structurally necessary right now. The tooling landscape is moving too fast for top-down decisions to keep up. By the time a committee has evaluated a tool and issued a recommendation, three better alternatives have appeared. The companies learning fastest are the ones that have pushed the authority to experiment as close to the actual work as possible.

Step 1: Shift authority to practice. Decisions about how to work need to live with the people actually testing tools every day — not in a management layer that can’t move at the speed the market demands.

Step 2: Dissolve the phases, not just the roles

The standard framing of AI in design is individual productivity: you can move ten times faster. Kamil lived that reality — and ran straight into its limits.

For the first sprint, I managed to design most of the mock-ups of the screen states, like, 50 screens, I could say. More than those I could do them in more like a few days, and nobody was prepared to get through them. Like, it was too many decisions, too many… like, too many outputs to go through. — Kamil

Individual speed becomes a bottleneck. When one person is running at ten times the pace of the rest of the team, the work piles up — and the decisions embedded in that work go unreviewed and unimplemented correctly.

What does it matter when I can enhance my speed 10 times, when, for example, the rest of the team is maybe doing their own 10 times, but in different direction? Or they’re doing the same speed, so they can’t understand what I’m currently working on. — Kamil

The real shift isn’t about which roles dissolve — it’s about the phases. Discovery, design, and build used to be sequential handoffs. In an AI-native workflow, a designer can touch code without owning it, can generate prototypes in JavaScript without being responsible for their production quality, can sit alongside developers and product managers in a shared flow rather than waiting for their turn.

Kamil learned this lesson early on: he got pulled into caring too much about the quality of AI-generated code in his prototypes. It created friction exactly when he needed to be exploring.

Focusing too much on the quality of code is something I wouldn’t recommend to a designer trying to use those AI tools on an everyday basis. — Kamil

Step 2: Bring AI into the whole product cycle. From the first client conversation through discovery, design, build, and maintenance. The team stops working in isolated phases and starts learning in one shared flow.

Step 3: Practice collectiveness over process

The designers guild at Boldare had existed long before AI changed the picture. But AI gave it a new and urgent function: a place to make individual learning collective.

The format that emerged was called AI Labs — weekly calls, optional, but well-attended, because the FOMO of not showing up is real. The structure is deliberately light. Each session starts not with “what tool should we all adopt?” but with a why: what business problem are we trying to solve, and is there an AI approach worth testing against it?

It’s also useful because while working in a silo, me or anybody else could get stuck with an AI tool which we recently trying in our workflow. But somebody else could not. And it could be a matter of the quality of the prompt, it could be a matter of inputs we try to use with that tool. So if somebody is stuck and the other designer happens to find a solution how to use a specific tool, it’s great to have those experiences shared on the guilds. — Kamil

The team also started building a shared library of prompts and workflows — not a top-down approved list, but a living document of what’s actually working across different products and designers.

Orchestration of the AI tools inside a team, I think it’s even more important that exploring anything what happens to be new on the market. — Kamil

Step 3: Start with why, together. Make AI experimentation a team ritual grounded in real problems — not a side project for Friday evenings. Shared learning compounds faster than individual exploration ever could.

The thing worth unlearning

If there’s one message for the head of design or chief of product, it’s this: the individual productivity framing of AI is a trap. Not because the gains aren’t real — they are — but because optimizing for individual output while leaving the team structure unchanged creates pressure the team can’t absorb.

Many big companies, they are figuring it out now that they are measuring the success and the efficiency of using AI individually by the matter of the productiveness of each of the specialists. But it happens to be that while we are focusing on the team, it’s not so… there are not so bright colors nowadays, and we have to focus how the team manages to work with AI too. — Kamil

Software is a team sport. It was obvious long before AI arrived. The challenge now is remembering that — and building accordingly.