Translated from the Korean original. Some screenshots show the original Korean interface.
Hi, I'm Jaeseon Kim from FE Team 1.
I'm interested in tools that help more people take part in product development, rather than AI replacing people.
Building screens in natural language, or "vibe coding," is no longer new. Anyone can turn an idea straight into a screen, and the results have become quite polished. But the moment you try to use it for real work, you hit a wall. Even a well-made screen doesn't fit with our product, and when several people build together, every result looks different.
That is exactly where we added a "harness." Anyone can build freely, the results stay safely on top of the design system, and the tool takes on the tedious work that comes after.
1. As free as it is, it's rough
Vibe coding is powerful, but because it is so free, the results vary widely. It is fine when you work alone. The real trouble starts when several people build at the same time.
- It looks nice, but it doesn't look like "our product." It is built from generic components instead of our design system, so even when it looks good, it doesn't fit with the existing product.
- It's fast, but it breaks as it piles up. As quickly written code accumulates and gets tangled, features that used to work can break without anyone noticing (regressions). Tracing the cause is hard, too.
- It's free, so everyone does it differently. When several people build the same thing in their own ways, pulling it together into one product takes a lot of manual work.
So what Design Studio sets out to do is clear.
What users build should carry straight into the real product, and work from many people should come together as one. That way, people can focus on ideas.
2. Foundation: start on the same structure as the real product
Even when a screen was built with vibe coding, if its structure differed from the real product, developers ended up rebuilding it. Whatever time we saved by building fast came back as rebuild cost.
So we set up the environment so that users' work sits on the same structure as the real product from the start. There is no grand technology here. We reference the real product source as is (a submodule) and bundle it with our in-house design system and shared UI, so the output comes out in a form developers can take over directly.
3. The unit of work is "one screen"
The smallest unit of work is one screen. Each screen holds three things together.
- Screen (UI)
- Sample data
- Planning spec
Data comes only from the sample data inside the screen, with no external connections, so anyone can reproduce the exact same screen and discuss it.
4. The tool handles "how," people decide "what and why"
When users describe the screen they want as a spec, the tool builds it. If something is missing, it doesn't build right away; it asks first and fills the gap with the user. Once that's settled, the result appears immediately.
So users can focus on "what to build and why" instead of "how to build it." The more the tool takes over the building, the stronger the planning gets, and the better the screens become.
5. The harness: the tool takes on the hassle
Users can focus on ideas only if the tool takes on the tedious work. They don't need to learn version control, design rules, or collaboration procedures in advance. If they want to go deeper later, they can dig in then.
So all the user sees is plain language and a one-line result like "Submitted!"
- On top of that, work is split by screen, so even when many people build at once, they rarely step on each other.
Looking easy is the point. We didn't remove the complex work. The tool just takes it on and keeps it out of sight.
6. Automation stops here; people decide
The more AI tools you build, the stronger the temptation: "Wouldn't it be faster to automate the last step too?" We deliberately left that last step to people.
However much the tool does for us, we believe people must own the responsibility for the final decision.
These days, "how far do people stay in control" matters as much as "how much do we automate."
7. Building it together in the field
Design Studio is already in use in the field.
The planners who tried it first didn't just use it; they also thought with us about how to make it easier. Their input is going straight into the next improvements.
Other divisions are also using the tool as a base to build other products. Passing through different contexts, from planning to development, the tool keeps getting sturdier.
Design Studio isn't a finished tool. It's a platform we keep refining together with the people who use it.
8. What's next
The foundation is in place. Next is adding depth on top of it.
More solid.
Give it the same plan, and the screen can still come out slightly different each time. We are automatically measuring and verifying that variance to make the results consistent. We have also strengthened safeguards that stop people from colliding on the same part when they work at the same time.
Wider.
Now, designers too. We are preparing an experience for adjusting designs directly on the screen, along with a range of themes.
Through all of this, we hold on to one thing: speed and automation must not push out human judgment.
The final decision always belongs to people.
References
On how far people and AI should divide their roles, this post shares its view with the two pieces below.
- Human-Centered AI: Three Fresh Ideas | Ben Shneiderman High automation and strong human control are not an either-or choice. A piece on designs where people stay in control and AI assists. - Guidelines for Human-AI Interaction | Amershi et al., Microsoft Research (CHI 2019) 18 principles for how AI should behave initially, during interaction, when wrong, and over time, designed so people can control and correct it (original PDF, source: ACM DL)
Related articles
