Skip to content
Meydad Marzan

Case study · 2026

AI-native building tools at Microsoft AI

Diagram titled “In service of building” with three columns. The Kit: the established primitives, solving for reuse and product truth. The Studio: the production platform, building what builds the products agnostic of model. The Hub: the collaborative layer, where our work compounds.

Outcome headline

Ideas become grounded prototypes that anyone can collaborate on, with a path to production, in a fraction of the time.

AI-native building tools at Microsoft AI · Shipped Aug 2026

1/ A few weeks ago in Microsoft AI, we launched AI-Native building tools: ideas become grounded-prototypes, everyone can collb on, with a path to production, in a fraction of the time.
@meidadmar on X · 09-01-2026

Summary box

My role
Initiator, creative director and architect. Set the vision and system architecture, and took the program from zero to three shipped products (Kit, Studio, Hub) with no dedicated headcount, only part-time contributions from three people.
Team
A part-time program manager, a part-time UX designer on MCP, a part-time UX designer on the Kit, and a part-time UX engineer "that has decades of experience". Credited publicly: Lucas Colusso (started the Kit), Jeeyoung Jung (design system foundations), Ankita Dasgupta, Max Parola (MCP), Eugene Gavriloff (bringing it all together). Draft note: confirm each person is OK being named on your site
Timeframe
Mar 2026 – Aug 2026
Partners
No external partners; these were customers. Every monetization product (CRM, MAP, Clarity) onboarded to the Studio and the Kit, then the Edge and Copilot teams.
Scope
Three layers: the Kit (the established primitives), the Studio (the production platform), and Vibehub (the collaborative layer). Vibehub use spread "across all of Microsoft". Three products onboarded, every designer on them, and 60 weekly users outside design.

The problem

Everyone has the same models. What they don't have is context: product strategy, the design system, content standards, critique heuristics. Without a shared knowledge base, AI prototyping turns into DIY chaos, design drift and inconsistent quality. And the tools designers and PMs were using (VS Code) were never built for them.

The stake: before these tools, designers worked in Figma, a pixel representation that engineers then had to translate into code. Now designers work directly in code. The Kit grounds that code in product truth, so the outcome is relevant and precise, and built with the actual components. Velocity went up on both sides: 60 minutes from first prompt to sharing in Vibehub, and 50% less engineering time building from prototypes.

My leadership

In my own words on X (Aug 20, 2026), reflecting on the first weeks: "We have been building a full suite of AI Native building tools. From grounding kits in github, through a canvas studio tool that cuts through setup complexities to a hub where everyone can post their prototypes and colab. These are not roles – these are modalities." People now have to work out which position they're playing based on where they are on the field. Sometimes a PM brings an idea that's almost baked, and the UX designer's job is to polish it and cover the edge cases. Sometimes the prototype arrives half baked, and PMs need a maintainer's mindset to think about how the idea fits the scale of the company. (source)

Draft note: to write, covering:

  • How the direction was set ("in service of building")
  • Why a small, part-time team rather than a funded program
  • How you got other teams to adopt it ("more teams joined")
  • What you personally built or reviewed

Key decisions

Decision 1: Put the context in one kit, not in everyone's prompts.

We brought our standards, context and skills into one repository, bundled the markdown files that produced the best outcomes, and added MCPs and agents for harder tasks (component code, a full content scrub). Then we tuned the kit for token usage, latency, UI consistency and output quality. Benchmarking models is nice. Benchmarking models on your own harness is hard, and that's where the learning compounded.

A grid of Microsoft Advertising prototype screens generated with the Kit, including campaign creation and conversion goal flows, captioned “50 versions of Microsoft Ads”.
“50 versions of Microsoft Ads”: prototypes grounded in the Kit. From the Sep 1 thread.
Left: the Kit repository in a code editor, with markdown skill files and component code. An arrow points right to the prototype screens it generates.
One repository of standards, context and skills in; grounded prototypes out.
The “vibekit evals” dashboard: output tokens, generation time, turns, UI consistency and content design scores for simple, medium and complex test builds, with a run history across kit versions.
Benchmarking on our own harness: every kit release runs reference builds and gets scored.

Decision 2: Build a studio for designers and PMs, not another IDE.

Studio is "Lovable for (y)our product; grounded in product truth": a desktop app on the CLI that uses existing models and quotas, with no per-seat subscription and no token markup. It includes templates so no one starts from scratch, plan mode because one-shot rarely works, point-to-prompt so you don't have to describe an element in words, and a code-vs-visual view to check that the model used real components engineering can lift and shift.

Studio: templates, so no one starts from scratch.
Plan mode and point-to-prompt on a real product surface.

Decision 3: Make it multiplayer.

We built Vibehub so people could host prototypes and share them with peers. Then we connected it to Studio (upload multiple versions as you iterate) and added git, remix and comments that turn into prompts. You see a project, hit remix, and collaborate.

The Microsoft VibeHub home page: “Got the Prototype? Share your work and spark ideas,” an internal Microsoft tool for sharing vibe-coded prototypes.
Vibehub: a place to host prototypes and share them with peers.
Upload from Studio straight to Vibehub, one version per iteration.
See a project, hit remix, collaborate. Comments turn into prompts.
Draft note: confirm: the Vibehub home screenshot shows usage counters; OK to show them on your site?

Decision 4: Tune the harness to the persona.

Non-product folks want an idea fast and can use a lighter model with less weight on consistency. Practitioners (UX designers and PMs) use the strongest models and want the harness to overvalue consistency with platform design rules and product truth. Execs bring heavy context, want to break the mold, expect high quality in one shot, and need state-of-the-art models with looser guidance.

Impact

  • Public: "Quality went high and more teams joined." "This made quality and speed go up." Vibehub "grew beyond imagination across all of Microsoft."
  • Built by four part-time people.
  • The machine, measured (public, Sep 15, 2026): "~60 min prompt to publish. The machine alone needs ~35. The other 25? Unknown." Every kit release runs three reference builds (simple, medium, complex), scored on UI consistency, content design, turns, time and tokens. "Last run caught one hardcoded border radius that should have been a token." (source)
  • Measured: prompt to shareable prototype went from days to 60 minutes (median). Engineering build time down more than 50%. 100% designer adoption across three products (CRM, MAP, Clarity), 60 weekly users outside design, and the Edge and Copilot teams onboarded.
  • Team growth and hiring: Draft note: to write

What I'd do differently

Draft note: to write A possible thread: when to keep investing in the harness versus training a model to your own needs. On Sep 23, 2026 I posted: "Stop caring so much about harnesses. Focus on training a model to your own needs" (source), after writing in June that "the only way fw is building your own harness to get closest to your product truth, with the highest efficiency. Having an in house model helps too" (source).

Next

→ Sales Intelligence & Customer Engagement at Google Ads (2022–2025)