Submitting Tail Villain to OpenAI Build Week!

When I came across OpenAI Build Week, I wondered whether I should submit Tail Villain. It was my first hackathon, but the entire process could be completed online and solo entries were allowed, so I decided to try. It turned out to be a fun experience.

Tail Villain had launched in May, well before OpenAI Build Week began. I wrote about that process in Launching the Tail Villain Beta.

Tail Villain already had roadmaps, Study sessions, mock interviews, and reports, along with Gemini-based text streaming and live voice streaming. During Build Week, I extended that existing product with personalized RAG, adaptive review, GPT-5.6, and OpenAI Realtime.

The submission therefore needed more than a long feature list. I had to separate the existing product from the work added during those eight days and give the judges a practical way to verify the difference.

OpenAI Build Week overview

OpenAI Build Week was a global online hackathon centered on building with Codex and GPT-5.6. In KST, registration ran from July 10 at 2:00 a.m. through July 22 at 9:00 a.m., while submissions opened on July 14 at 1:00 a.m.

The total cash prize pool was $100,000, or roughly ₩147 million at the July 24, 2026 exchange rate of about ₩1,470 per dollar. Apps for Your Life, Work & Productivity, Developer Tools, and Education each awarded $15,000, approximately ₩22 million, for first place and $10,000, approximately ₩14.7 million, for second. I submitted Tail Villain to the Education track, with winners scheduled to be announced on August 12.

The Devpost page for OpenAI Build Week showing the event dates, prize pool, and participant count

Gathering everything the submission required

While reviewing the requirements for the Devpost submission page, I converted them into an evidence checklist. The submission needed a working production URL, a repository, a public demonstration video, an English project narrative, private judge credentials and testing instructions, README coverage of GPT-5.6 and Codex usage, and a Codex feedback session identifier.

The features already existed, but the judges would not know what I had built over the previous months. They would not know where to start, what changed during Build Week, or which paths used OpenAI, and I could not exactly tell them to figure it out on their own.

The story centered on a personalized practice loop. A Goal and Background become a roadmap. RAG carries that context into Study and Interview modes. Quick Review updates memory state. GPT-5.6 handles structured and interactive text workflows, while OpenAI Realtime provides spoken interviews.

The user journey had to come before the feature inventory. Once that sequence was clear, the technical pieces had a reason to appear.

Separating the work completed during Build Week

Rather than making the entire product look like Build Week work, I decided to state clearly what I had added on top of the existing product during the event.

The README separated the work completed during Build Week from the pre-existing product. That work included personalized RAG shared by Study and Interview modes, privacy-safe retrieval observability and rubric-based evaluation, FSRS-backed Quick Review, provider-neutral GPT-5.6 routing with Gemini fallback, OpenAI Realtime, TTS and STT, consistent streamed openings and responses, and the operational account-recovery path needed for judge access.

Dated commits and development logs remained available as evidence. A working feature proves that the code exists now. Commit history and logs help establish when it was added and why.

Integrating GPT-5.6

I avoided putting GPT-5.6 in front of every AI feature in the submission. Tail Villain supports multiple providers, and different operations need different response characteristics.

Latency-sensitive Study and Interview turns use the faster GPT-5.6 route. Roadmap analysis, topic generation, and evaluation use a different model. Gemini remains an explicit fallback when an OpenAI request fails transiently.

The submission documented both the model names and their responsibilities. It connected user actions to generation paths, explained fallback behavior, and described the functionality expected regardless of provider.

Codex was already part of my workflow

I had already been using Codex as a coding agent for a long time. Agents produced probably 99 percent of Tail Villain’s code, and I delegated work ranging from architecture and implementation to documentation, tests, visual design, and research. My role was to set the product direction, make design decisions, and supervise the work. Most of the time, I was very satisfied with the result.

There were still moments when an agent misunderstood me, or I reached a usage limit and suddenly could not do anything. Those moments made it obvious how dependent I had become on agents. I am no longer sure I could return to typing every line of code by hand. Not that I expect to.

Writing the reviewer README

Tail Villain contains more features than a reviewer can explore casually in one session. Instead of asking judges to browse every menu, I wrote a sequence that let them scan the core product:

create a roadmap from a Goal and Background
  → open Study Mode and observe personalized context
  → run a Text, AI Voice, or Live Interview
  → complete a Quick Review and update the review schedule
  → inspect the interview report and readiness feedback

This route shows that RAG is shared product context rather than an isolated retrieval demo, voice belongs to the same interview lifecycle, and interview results continue into adaptive review.

Judge credentials did not go into the repository. The README stated where reviewers would receive access, while the actual credentials stayed in Devpost’s private field. Environment secrets and API keys were excluded, and Codex session evidence was reviewed separately because it could contain personal details, resume content, internal discussion, or secret-like patterns.

Making the final demo video

This took more time than I expected. Before the deadline, I organized the feature explanation, recorded the demonstration again, and replaced the voice-over with a new English version. I had already submitted the first version when I realized that it did not mention GPT, so I recorded it again. The final version directly stated that Tail Villain used GPT-5.6 and that Codex supported its development.

The video could be no longer than three minutes, so I could not explain every feature. I focused on making the core functionality from the README visible in the demo.

Closing

I completed the submission, although I am not expecting too much. The prize pool is large, but 46,793 people registered worldwide, and I am one of them. Development alone was not enough. A strong submission also needed documentation, explanatory images, a YouTube demo, clear positioning, and design. I could not deliver every one of those disciplines at a high level by myself.

It is tempting to say that AI can handle all of that. That is half true. Design used to be an area I could barely touch, but I can now use Superpowers skills to create a design system that fits the product and apply it without drawing a single image myself. AI still reflects the ability of the person using it. A designer would have produced a better visual result, while a marketer would have written a stronger submission narrative and chosen better supporting images.

That is probably why specialists and teams exist.

And that is the end of the Tail Villain submission story.