On October 14, 2026, Vibe Coders Tokyo #11 "Good Quality Apps" took place at Le Wagon Tokyo in Meguro. Co-hosted by the MagicPod Community, the evening focused on one question: how do you keep the quality of an app you built with AI?
About 48 people joined in person and 28 online, bringing together a diverse mix of vibe coders — engineers, designers, students, and founders.
Talk: QA and Testing Knowledge for Vibe Coders
The lightning talk was given by Yoshiki Ito, a QA engineer at MagicPod. He started his career as a tester and has worked in software testing for more than 10 years. Drawing on that experience, he shared the QA mindset every vibe coder should know.
"Quality is value to some person"
The talk started from this line by Gerald Weinberg. If you are building an app for other people rather than a tool for yourself, your users decide what quality means — and AI won't follow quality rules nobody told it about.
Three frameworks to think with
- The Kano model — think of quality in three types: must-be, performance, and attractive. Lock in must-be quality first, then polish the attractive features.
- ISO/IEC 25010 self-review — after building a feature, ask the AI to list what's missing from angles such as reliability, usability, and security.
- Security — a study of 200 publicly deployed vibe-coded apps found that about 91% had at least one vulnerability. Say "production-ready" in your AI requests, and self-check authentication, permissions, input validation, and how secrets are handled.
From "checking that it works" to "trying to break it"
- Regression testing — a fix in one place can break something unrelated. Turn the flows that would hurt most into a checklist and run it after every change.
- Exploratory testing — set a time limit and go after the places bugs are likely to hide: past dates, closed days, double submissions, duplicate clicks.
- Getting outside help — bug bashes and AI agents like Claude Code with Playwright MCP. Don't take "no problems found" at face value — make the final call yourself.
Three things you can start tomorrow (no tools needed)
- Add "production-ready" to your AI requests
- Make one checklist of your key flows
- Spend 15 minutes trying to break your own app
Q&A highlights
- Q. Any OSS tools or skills you'd recommend? A. Many companies build in-house Claude Code Skills tailored to their workflows, sometimes combined with Playwright.
- Q. Can regression testing apply to unit, integration, and system testing? A. Yes — any level can include a regression element.
Slides: QA and Testing Knowledge for Vibe Coders (Speaker Deck) →
Group Exercise: Looking at Each Other's Apps Through a Tester's Eyes
The second half was a two-part exercise. For about 20 minutes, attendees split into groups, shared their own deployed apps, and went bug hunting together. Then each group presented the bugs they found and how they planned to fix them.
The apps people brought spanned a wide range of genres and languages:
- AEDoko — guides you to the three nearest AEDs from where you are
- The Garden of Poems — every poem you write leaves something growing in a night garden
- moytoi — wedding and event invitations in Kazakh, sent over WhatsApp in five minutes
- A restaurant map app, a personal portfolio site, and more
What stood out was how many attendees tried the talk's ideas with AI on the spot. For the restaurant map app, an ISO/IEC 25010 review concluded it was "not ready for a general public launch yet." For the portfolio site, a production-readiness check came back with "I wouldn't sign off yet; five issues remain."
One standout bug: an attendee had an AI agent probe their app with 45 HTTP checks on both desktop and mobile. It found a reproducible bug — signing in at 127.0.0.1 redirected to localhost and lost the session, and pinpointed the exact line in middleware.ts causing it. This is exactly the kind of bug that everyday clicking-around misses, and "trying to break it" catches.
Try Kybr, Get Space Food
To let attendees find out on the spot whether their own app really is bug-free, we ran a hands-on Kybr campaign at the venue. Anyone who scanned their app with Kybr and booked a feedback meeting got free space food. People were showing each other their screens asking, "What did it find?"
The team behind moytoi ran their app through Kybr too. Kybr automatically mapped out eight user journeys — browsing, account creation, invitation creation, payment, guest replies, permissions, and account deletion — and all eight passed.
Feedback meetings are underway now, and we plan to share what we hear in a follow-up post.
Voices from the Event
"Everyone listened really closely, and during the workshop some people put the ideas into practice right away and found bugs. The room was full of energy to build something good and something fun."— Yoshiki Ito, Speaker
"The bug bash part of Yoshiki's slides really stuck with me. It's something attendees could actually try together, and I'd love to do it at the next event."— Online Attendee
"Getting to try a new tool on the spot was fun. Yoshiki's presentation was very insightful — even as someone who works as an engineer every day, I came away with new learnings."— Attendee
Wrapping Up
AI has dramatically shortened the distance between an idea and a working app. That makes the next challenge for vibe coders clear: how to make sure the app has the quality real users need.
Next time, we'd love to try a bug bash where attendees test each other's apps. A big thank you to Xinni and Alastair of Vibe Coders Tokyo for organizing, to Le Wagon Tokyo for hosting us, and to everyone who came.