multi-turn inc.
INDEX

index

AI Arena

product

Over the Lunar New Year holiday I built one product end to end. It's called AI Arena.

It started with a competition. Last year I entered AI TOP 100, run by Kakao Impact and the Brian Impact Foundation, and took a bronze. It isn't a coding contest. It measures how well you can wield AI to solve a given problem quickly and correctly. This year I also joined the campus edition's qualifier and finals as a beta tester. After watching it up close across two years, I wanted to turn the format itself into a product: an arena where you set problems, people solve them with AI, and the answers get graded into a ranking.

The holiday was a good stretch of time to build it. And honestly, it was the first time I had ever built a whole product from front to back.

Here the problem is writing, not code. You write prompts, describe your analysis, explain your strategy. So the solving screen is deliberately emptied out — no header, no sidebar, just the problem and a timer. Once you step in, there's nothing but you and the problem. When you submit, OpenAI's GABRIEL grades the answer against a rubric: define the criteria in plain language and it has GPT score each answer against them. Those scores gather onto a handful of axes, and settle into a radar-chart profile and a daily record of how your skill shifts.

Most of what it took to build was something I was doing for the first time. Deploy on Vercel, data and auth on Supabase, login through OAuth. I designed the screens myself and put an AI agent on the homepage. I wrote a few problems too — though, honestly, I never put real work into them. The very thing the competition lives on, good problems, is still the weak link.

By finish quality it was rough in places. But measured in what I learned, those few weeks were unusually dense. Deploying to Vercel for the first time, writing a Supabase schema for the first time, debugging an OAuth callback for the first time, running a grading pipeline for the first time — each one was a small "oh, so that's how it's done." I also learned, in my hands rather than in theory, that building a product is less about bolting on one feature after another than about continually choosing what not to build.

The part that turned out most interesting was those grading axes. As I saw it, what separated people at the competition came down to four things: the instruction that pulls an accurate answer out, the verification that catches a wrong one, the application that solves a complex task with AI, and the judgment of when and how to use AI at all. Who solved the problems well and who didn't split along those four axes — and those same four are exactly what the product now measures.

That arena runs under a slightly different name now. It began as a competition format, but it has become a tool that measures how well an organization's people use AI. It's called Fluent. It fills the slot of the coding test, for an age when the test is written in prompts rather than code.

fluentdot today — Fluent, a tool that measures how well an organization uses AI.

The experience of building one product all the way through stayed with me, apart from the thing itself. The next one I'll build with a little less fumbling.

Where it lives now: fluentdot.com