Designers move into VS Code
Van Walt Meijer says her designers now work in VS Code with GitHub Copilot, so code becomes a shared medium for exploring and implementing ideas. Her team already contributes pull requests to production. She says ideation needs a different pace, because loading and testing the full production app slowed exploration and stakeholder feedback.
The fix was Mini-Foundry, a lighter, modular version of the product built by the team's UX engineers. She says more than 100 designers and product managers now use it. It bundles shared components, relevant data, and repository-specific agent skills. Designers pick up Git along the way by creating branches, making commits, and building on each other's changes.
A separate Microsoft post from August 31, 2026, by Jenny Lanier Wolski of CoreAI, describes Mini-Foundry the same way. It calls it a prototyping sandbox that lets designers and PMs prototype in code without Foundry's production complexity. That post puts the tool inside the wider CoreAI Design System effort. It also says that shared Fluent 2 components alone did not make the portals feel coherent. This fits Van Walt Meijer's account of Mini-Foundry's role. It does not independently verify her usage figure or her evaluation claims.
Journey quality is a separate layer
Her central argument is that faster building does not show that the experience works. Code checks can verify component and design-token use. Visual comparisons can catch changes in typography, margins, and component states. These checks are deterministic, meaning the same inputs and rules give the same result. But every screen can pass while the path between screens leaves users lost.
Her example is an illustrative one:
- A developer who is comfortable in VS Code but new to Foundry creates and tests a hosted agent with Foundry Toolkit.
- They then move to the Foundry portal to monitor it.
- They must find the monitoring view for the agent they just tested.
- They must confirm they are in the right project.
- They must work out whether their changes worked.
If both surfaces work but the developer has to rebuild context between them, she says the journey is still asking too much.
How the rubric system works
The team's "journey rubric Lab" follows a principle she states as "checked when possible, judged when needed." Each rubric packages four things:
- criteria
- examples
- executable checks or judging prompts
- a report
Deterministic checks cover specific requirements. Model-based assessments interpret evidence against criteria and labeled examples. She says the model-based judgments can vary between runs, which is why repeated evaluation and human calibration matter.
Setup starts with a brief for the flow. The brief covers:
- where the journey begins
- who is attempting it
- what they need to accomplish
- what observable evidence would count as success
The team then supplies the application URL and task boundaries, picks the model and settings, and runs the rubric. Her advice on reading results is practical:
- Run repeated attempts to see where the path is reliable and where it breaks.
- Inspect individual runs, including failures, instead of trusting the headline score.
- After a change, rerun the same brief to get a comparison baseline.
The post gives no public install guide, repository, or configuration commands. Readers should treat this as a described internal workflow, not a procedure they can follow step by step.
Runner versus judge
The post separates the model that attempts the journey from the model that judges it. The runner gets a user profile, task requirements, and safety boundaries. It receives a compact text snapshot of visible content, controls, and state. It reads that against the user's goal and returns an action for a browser tool to carry out. Screenshot analysis is available for closer inspection. A run counts as complete only when there is visible evidence that the stated outcome was reached.
The author lists these prompting observations from her team's setup:
| Model | Reported experience or prompting approach |
|---|---|
| GPT Sol and Astra | Stood out for visual interpretation. Short, direct instructions focused on the next action. |
| GPT Terra | Extra guidance on editing fields, waiting through loading or blank pages, and avoiding repeated clicks. |
| Claude Sonnet | Separated priorities, tool rules, and completion checks, with limits on repeated verification and waiting. |
| Claude Opus | A lighter prompt that leaves more planning to the model. |
She explicitly says these are observations and prompting choices in her setup, not universal rankings. The post gives no sample sizes, cost figures, latency figures, or controlled comparisons. Treat these as anecdotes from one team, not benchmark data.
Three to five dimensions
She argues for three to five stable scoring dimensions. Overlapping criteria can count one problem several times. A single overall score can hide the exact moment a user gets stuck. For the agent-building journey she offers five illustrative dimensions:
- Task success: can the developer create, test, and monitor the intended agent?
- Continuity: does configuration and project context stay understandable between VS Code and the portal?
- Clarity: can the developer tell what changed, what it means, and what to do next?
- Progress: can they keep moving without loops, repeated steps, or dead ends?
- Recovery: after a failure, can they identify the problem and continue without starting over?
She says these are broader examples, not the team's internal dimensions or scores. One boundary is firm: permissions and resource boundaries stay as explicit checks, and a strong score elsewhere cannot offset them. An image caption mentions a 0–4 scale, but the text gives no score values or scoring anchors.
For regression testing she advises holding the scenario and scoring examples stable and comparing a focused change against its baseline. If the rubric changes, the baseline has to be reassessed.
Where human review fits
The post is clear that an automated run can surface a concern but cannot establish how people experience it. An alert should name the affected step, the relevant dimension, and the evidence of a possible breakdown. Colleagues then try to reproduce it and use research to confirm or challenge it. Human review also helps separate real product friction from problems caused by the model, the instructions, or the browser interaction.
She also warns that a prototype preview is not proof of production readiness. Tests, real integrations, and review still apply. Mini-Foundry is for exploration, and production pull requests are the path for reviewed changes.
Analysis: what to take from this
Three caveats apply:
- The source is the team itself. The post is a first-party account with no outside validation. It publishes no data showing the method improves user outcomes.
- Some details are thin. The 100-user figure is self-reported. The model observations come with no numbers.
- The tooling is not public. The post names no released evaluation product.
The practical lessons still hold up for developers and IT teams working with agent-driven testing:
- Define task completion in observable terms.
- Keep permissions and resource limits as hard pass/fail checks, not scored qualities.
- Review failed runs step by step, not just the aggregate.
- Expect different models to need different prompts, and re-test when you switch.
- Expect run-to-run variation from model judges. Repeat runs and calibrate them against human testing.
As a general industry observation, not a claim from the post, a similar split between deterministic checks and model-judged ones applies to other agentic UI testing.
Foundry's own documentation points the same way on measurement. Microsoft's Foundry tutorial on building and evaluating an enterprise agent uses built-in evaluators and the evals API to run scalable, repeatable evaluations in the cloud. That covers output-level evaluation of an agent. Van Walt Meijer's approach tackles a different problem, which is whether a human-facing path across tools holds together.
The post's own framing sums up the aim: "a better experience, not a better-looking number." Whether the method delivers that is something Microsoft has yet to show with public evidence.