AI Salon x Dev Korea #2: why AI can't judge your ads, and building the right app with fewer agents

Want to feel what the night was like? From the talks to the networking and everything in between, here's the aftermovie from AI Salon x Dev Korea #2 🎥.

On October 13 we ran AI Salon x Dev Korea #2 together with AI Salon Seoul and SVC Seoul. About 90 people came out.

Since the first AI Salon x Dev Korea in July, the format has stayed the same: two practical talks from people building real products, then plenty of time to talk. This time both speakers came at AI from the same angle without planning it. AI can make almost anything fast now, so the hard part has moved to deciding what is worth making.

Food was gimbap again, like last time, served at check-in.

AI can make an ad in seconds. Most of them flop.

Jerome Yip opened. He works on paid acquisition and creative strategy for large ad accounts on Meta, Google and TikTok, and builds his own apps through his small app studio. He also mentioned he had practiced the talk the day before in front of his kids, who thought it was okay.

His starting point: LLMs and the tools built on them are good at outputting and replicating, and bad at creative strategy. You can measure a creative quantitatively, its bitrate, colors, word density, even the hook. What you can't measure is whether it's good, because that depends on the product, the audience, the timing and the sample size. On top of that, attention on social media is at its lowest, competition at its highest, and everyone is now making ads with AI.

Then he ran an exercise. Two versions of the same hook from Yazio, a big calorie counting app, played side by side on mute, and the room voted. It split, slightly in favor of A. With the sound on, everyone could tell B was the fake, made with Nano Banana and an ElevenLabs voice.

He then gave the same frames to four frontier models in a blind test, twice, with the order reversed. The results were all over the place. Gemini, given the audio as well, said both were the same in the first round and preferred the original in the second. If a model can't judge a hook consistently, why would you trust it to decide what goes into your creative?

His setup

None of that means he works without AI. His stack has three layers:

• Intelligence: Codex and Claude Code with his own custom harness, plus an LLM council to challenge outputs, always in loops with him in the middle validating.
• Context: for any new product, he scrapes thousands of App Store reviews and runs sentiment analysis on them (checked, not taken for granted), reads Reddit, and looks at related products. He keeps every screen of his apps as simple HTML, collects competitors' paywalls and onboarding flows, and pulls their ads from public ad libraries.
• Execution: Flora for images and video, HyperFrames to edit videos locally, Remotion for motion, ElevenLabs for voice, and the usual models for copy.

The context layer is where he pushed hardest. His analytics go from Firebase to BigQuery, connected to his local setup alongside Apple Search Ads, Meta and RevenueCat data, and every release change, a new paywall, a different onboarding step, gets logged in Notion and GitHub. That's what lets you ask a pointed question like: why did 80% of installs used to reach the paywall, and now only 60%? Did the onboarding change, or the traffic? An LLM can work through those hypotheses in an hour or two. A person would take far longer.

For tools, he relies on Apify to scrape first-party data like reviews and ad libraries instead of trusting a chatbot's summary, ScreensDesign for its library of around 2,500 onboarding flows, Foreplay for ads, and Exa for search.

Gain, escape, protect

His working theory on why people buy anything: they want to gain something, escape something, or protect something.

He walked through it with MyFitnessPal. Nobody pays for calorie counting itself. So you split the market into broad reasons, like losing weight to feel better about yourself, or eating satisfying food that still fits your goals. Then you go down to personas, which are situational: you just saw photos of yourself from a friend's wedding and didn't like what you saw. Then you pick the angle that speaks to that person. He played two real MyFitnessPal ads built on completely different angles, and pointed out that behind each one there was almost certainly a detailed script and a strategist who chose it.

The part people wrote down was alignment. He has an LLM pull the key frames and transcript from an ad, then score every step of the funnel against the ad's angle: the App Store page, the welcome screen, the onboarding and the paywall. If the ad promises you'll look different and the app opens on recipes, alignment is zero. In his test, the "satisfying food" angle scored as much better aligned. His caveat was immediate: that doesn't make it true. It's a hypothesis to test.

His conclusion: AI helps him tremendously, but human judgment, experience, creativity and taste decide what ships. And test properly. A hundred installs on a video tells you almost nothing.

The Q&A went straight to practical questions:

• Retention is the hardest metric to move. Everything before it can be impulsive. Compare what users expected when they installed with what you actually delivered.
• Organic vs paid: he starts with search ads because you're capturing intent, not creating demand. Organic is very hard, and everyone who runs ads is still trying to crack it.
• Metrics: cost per trial is what Meta gives you, but trials don't all convert. He's seen many trials cancelled in the first 15 minutes, and delaying the conversion event to optimize for qualified trials can help. CTR and CPC matter much less than return on ad spend.
• Multiple angles mean more work down the funnel, which is where custom product pages on the App Store and onboarding questions that branch by angle come in. So pick your hypotheses carefully.

Link: Building an AI assisted creative research and production system, full talk

Build the right app, not just a fast one

Chris DeWeese followed, opening with the line that summed up the night: with AI you can build an app in an afternoon, including the wrong one.

He asked who in the room had asked AI to write code. Almost every hand went up. He pointed to Dev Korea's own State of Dev in South Korea 2026 survey, where 70% of the 166 developers who answered use AI to write code. So the question becomes: what's your job?

Chris has shipped around 200 apps since 2016, and he used three of them to answer:

• A hyper-casual mobile game built by hand in 2020, a mix of Pong and Breakout, that hit number one in its category in several countries, including the US.
• Bin Buddy, a recycling app for Korea's confusing trash rules: take a photo, find out how to sort it. Vibe coded, and fewer than 10 paid subscribers after months. No plan, no marketing strategy.
• I Can Tell Time, a kids' app he built by hand about 10 years ago, with over a million downloads, much of it from schools' iPads. He rebuilt it with AI in about two weeks, added a subscription with a free trial, started Apple Search Ads in April, grew it to about $1,100 MRR, and sold it for $22,000.

The difference between the second and the third wasn't the code. It was the plan.

Six questions before any code

His workflow splits the work between him and the agents: he plans, checks and learns; the agents build. Before building anything, he answers six questions:

1. Who is it for?
2. What's the one job?
3. When is it done?
4. How do I check it?
5. How do people find it?
6. How does it make money?

He showed it live with a signup page he had built the day before. He asked the room how long it would take, and the guesses went from an hour down to a minute. He wrote a short plan, handed it to Cursor's cloud agents, got around 360 lines of code he never read, had the agent run an end-to-end test that actually typed in an email and submitted it, and then checked it on his phone in about a minute.

About 80% of his time goes into planning. For I Can Tell Time, he kept asking why until only the core was left: an interactive clock where a kid drags the hand and reads the time. No gamification, no leaderboards. He also doesn't look at competitors at this stage, because your own experience and perspective are what make the idea yours.

He showed what happens without that discipline. He pointed Opus 5.5 at a game codebase he hadn't touched in six years and let it run for a few hours. It came back with new game modes, achievements and daily challenges. It looked great until people tested it and found it confusing. His rule: cut features, don't add them.

Most of that planning happens on paper. He brain-dumps everything into a journal, sleeps on ideas, then asks different AI models to poke holes in them. If you have to force an idea, it's the wrong idea.

Four agents are enough

For building, he uses four: Claude Code to build almost everything, Codex with computer use to tap through and test the app, an image model for art, and Codex again to review the code, because a different AI reviews more strictly than the one that wrote it. More than 10 agents, he argued, and they start editing the same files and spending tokens fixing each other's work.

On top of that sits Grok Bot as a kind of chief of staff, connected to his tools and a headless Mac Studio for anything that needs computer use, in a loop where anything that fails goes back in to be fixed. His current startup, Pilot Computer, flight scheduling software for flight schools, runs this way end to end. When the app crashes, the bot reads the Sentry logs and fixes it. He hasn't fixed a bug himself in months.

He was just as honest about where AI didn't work. He tried to have Claude build a tool to manage his Apple Search Ads bids, and it kept guessing numbers, so he gave up and did it by hand. Not everything needs AI. He prefers tight permissions with auto mode over approving every command, and he isn't a fan of unit tests for his kind of apps: if an AI agent can't get through your app, it's too complicated.

The Q&A had one of the better debates we've had:

• Security: keep the app simple. Fewer screens means less surface for bugs. Bin Buddy dropped its account system entirely and runs image recognition on-device with Apple's frameworks, so there's no server and nothing to hack.
• Testing: one attendee pushed back hard. Agentic UI testing on a big app is slow, non-deterministic and expensive, while a traditional UI test is fast and fails when AI breaks something. Chris agreed it took him many iterations. His setup now is Qwen 3.6 running locally on a Mac Studio to write the plan, and Jev, a fast computer-use model, picking the actions to go through the app, which he said makes it close to instant.
• Marketing: put $100 into Apple Search Ads if people search for what you built, $100 into Meta if it's visual, and go all in on whatever gets a little traction.
• Ideas: the apps that made him the most money solved his own problems. Even if it flops, you've fixed your own pain point.
• Why sell: school apps are seasonal, and the money from the sale bought hardware and time to build more.
• Why iOS only: for identical apps, about 90% of his revenue came from iOS, and about 60% of complaints from Android.

Link: Orchestrating AI agent workflows to build your apps, full talk

The room

Around 90 people joined us. After the talks, people stayed around for networking until closing.

Huge thanks

This event wouldn't have happened without:

• Jerome Yip and Chris DeWeese for two talks full of what actually worked and what didn't
• Jay Kim and AI Salon Seoul for bringing AI Salon back to Seoul
• SVC Seoul for hosting us again
• The volunteers who kept the night running: Brian, Jason, and Oscar
• And everyone who came, asked sharp questions, and stayed to talk

Watch the talks

Both talks are online:

• Building an AI assisted creative research and production system, by Jerome Yip
• Orchestrating AI agent workflows to build your apps, by Chris DeWeese

You can find every published Dev Korea talk on our talks page.

See you at the next one.

---

Ready for your next move?
Visit Dev Korea to explore the latest job openings at dev-korea.com/jobs, or if you're hiring, post a job at dev-korea.com/post-a-job and connect with our growing international tech community.