THE FILE / AI
● JUNYOUNG PARK · WEAVEL’S ENGINEERING CHAPTER● YC SUMMER 2024● PROMPTMODEL · APE · VISUAL-LANGUAGE RESEARCH

Person / Founder & engineer

Junyoung Park and the Problem of Getting AI to Behave Twice

Before Weavel became Typa, Junyoung Park was building tools to make AI instructions easier to test, revise, and trust. His path runs through Seoul National University, open-source software, and a research question about doing more with fewer trainable parameters.

Advertisement

Junyoung Park’s early work on AI comes with an unusually useful reading companion: the code. There are prompts to compare, experiments to repeat, and versions to inspect. Before the company he co-founded became Typa, a business selling help with content, Park was working on a more intimate difficulty for engineers: persuading a language model to do the same useful thing twice.

Anyone who has revised an instruction until a chatbot finally behaved will recognise the problem. Success can feel suspiciously like an accident. Change a phrase, try again, and the answer improves. Try another example and it falls apart. The computer has produced an answer; the person at the keyboard has acquired a superstition.

Park’s work at Weavel belongs to the effort to give that process some discipline. Alongside Andrew Chung, he built tools for people making products with large language models. Their work ranged from collaborative prompt management to automated optimisation. They also shared an academic byline, investigating how a vision-language model could be adapted with a smaller training budget. The settings differed. Both involved making an existing AI system more useful without starting over.

The engineering before the company name

Park studied computer science and engineering at Seoul National University. His professional background includes research in a lab focused on natural language processing, the branch of computing concerned with language. In startup introductions he is often simply Jun. The shortened name sits comfortably beside a portfolio concerned with shortening the distance between an idea and a working application.

His collaboration with Chung crossed the boundary between research and products. By the time Weavel introduced its prompt engineer, Ape, the pair had built more than ten LLM applications together. That is a shared team history, rather than ten separate companies or ten commercial successes. Its significance is practical: they had repeatedly encountered the work that surrounds a model after the initial demonstration has finished.

A demo needs one persuasive example. A product needs to keep behaving when somebody supplies an awkward question, an unexpected format, or a case the developer never thought to try. That gap gives Park’s early software its subject. The work happens around the model: keeping instructions organised, recording what changed, and deciding whether a new version deserves to replace the old one.

The early Weavel team gathered behind a Y Combinator sign
A company photograph with a useful landmark: the early Weavel team at Y Combinator. The sign, at least, needed no prompt engineering.

A prompt gets a revision history

Promptmodel, an open-source project to which Park contributed under the GitHub name engineerA314, approached the problem as a team activity. It brought together a web editor, version tracking, a Python software development kit, and a dashboard for evaluating and managing prompts. Its intended users included developers and colleagues who did not write code.

That last detail changes the shape of the problem. A prompt can contain product policy, tone, formatting requirements, and domain knowledge. The person best placed to edit it may be a product manager or a specialist rather than the engineer who connected the model. Putting every adjustment through an engineering handoff makes a simple sentence surprisingly expensive.

Promptmodel’s editor included a way to see differences between versions. Its Python integration connected those managed instructions to application code. The project documented cloud, local, and self-hosted setups. These are workaday features, but they describe an important ambition: let a team discuss an instruction as a shared piece of the product, with a record of its changes.

Version history is an antidote to the phrase “it worked yesterday.” It gives yesterday an address. For a team trying to understand why an AI feature has changed, that can be more valuable than another impressive answer. Park’s contribution history places him inside this patient work of making AI development inspectable.

A prompt’s working life
01EditChange the instruction
02CompareInspect the revision
03EvaluateCheck the output
Promptmodel organised prompts as shared, versioned product work. A conceptual guide to the workflow, rather than a performance measurement.

The smaller training bill

The research side of Park’s record asks a related question at a different level. In 2024 he co-authored Towards Efficient Visual-Language Alignment of the Q-Former for Visual Reasoning Tasks, published in Findings of EMNLP. His collaborators were Sungkyung Kim, Adam Lee, Andrew Chung, Jusang Oh, and Jay-Yoon Lee.

The subject was InstructBLIP, a system connecting visual information with a language model. Within that architecture, a component called the Q-Former helps connect the two. The team investigated how to adapt that component efficiently for visual reasoning, using benchmarks including ScienceQA and IconQA.

The reported result was specific: parameter-efficient fine-tuning could achieve performance comparable to full fine-tuning while using under two percent of the trainable parameters. The comparison concerned the studied adaptation setup. It was neither a claim that the entire model had become fifty times smaller nor a promise that every AI task would enjoy the same saving.

<2%

of trainable parameters, with comparable performance to full fine-tuning in the paper’s reported Q-Former experiments.

The researchers also examined how different parts of the Q-Former mattered for different tasks. Their analysis found particular importance in self-attention layers for perceptual visual-language reasoning, while the importance of feed-forward layers depended on the complexity of the patterns involved. Efficiency required looking inside the component, rather than treating every adjustable part as equally useful.

The accompanying repository makes the work concrete. It documents data preparation, training configurations, and experiment identifiers. A reader can trace the research question into a set of operations. That is a substantial part of Park’s story: collaboration that leaves something other people can examine, use, and challenge.

Ape enters the workshop

Weavel joined Y Combinator’s Summer 2024 batch. Its Ape launch addressed the repeated manual labour of prompt engineering. The team described conversations with more than a hundred YC companies and a recurring difficulty: judging whether a changed instruction had actually improved the output.

The proposed workflow started with recorded inputs and outputs. Those examples became evaluation data; candidate prompts could then be assessed and refined. The pitch gave the process a compact formula:

“good input + right guidance = better prompts”

Weavel’s Ape launch

The name supplied the joke. An AI prompt engineer would help engineer the instructions for another AI. Beneath that recursive arrangement was a straightforward product task: reduce the amount of manual experimentation required to reach a useful result. Park was among the contributors building the open-source implementation.

Ape’s repository subsequently presented it as a library for comparing prompt-optimisation methods. It includes implementations of approaches such as DSPy-MIPRO and EvoPrompt, alongside community trainers. A common structure lets people try different methods without rebuilding the surrounding experiment each time.

Its examples require the user to supply a generator and a metric, and distinguish training data from test data. Those requirements are revealing. A tool can search for a better instruction, but someone still has to define what better means. The metric supplies the judgement the optimisation procedure will pursue.

That makes the work less theatrical and more demanding than asking for a nicer answer. A method that improves mathematical reasoning may behave differently on classification or SQL generation. Ape’s benchmark collection spans those kinds of tasks. Its value as a research tool rests on making differences visible, rather than assuming that one good result settles the matter.

What remained when Weavel became Typa

The company later took the name Typa and turned toward content creation. Its current product combines drafting, a knowledge base, brand voice, and publishing workflows. Users can bring in an idea through familiar communication channels and review the resulting material before publication. The website makes approval a condition of posting.

Park’s place in that history is as a co-founder of Weavel, the company behind Typa. The current YC directory places him among former founders. His LinkedIn now lists Nari Labs, and his GitHub profile links to that company. The early engineering record remains a distinct chapter, with its own products and research, rather than merely a preface to a new brand.

There is a useful way to read that chapter without borrowing a grand mission for him. Promptmodel made revisions visible. Ape made optimisation methods comparable. The visual-language paper investigated which trainable components could deliver useful adaptation. Each project turned a broad aspiration into a narrower question that could be worked on.

The practical questions are also the interesting ones. They bring the discussion back to the people maintaining a product, the choices those people make, and the evidence available when something changes. Who can change the instruction? What happened between versions? Which examples count as a test? How much needs to be trained? Answering them determines whether an AI system becomes a tool somebody can rely on after the novelty has worn off.

Park’s early career is recorded in these decisions. A university collaboration became a published experiment. Repeated application building became shared tooling. A founder’s name appears beside code that other engineers can still read. For a field fond of announcing the future, there is something appealing about a body of work that invites you to open a file and see how it runs.

Open the files