How to Legally Vibe Code at Banksalad

To let operators freely change Saladgame missions while blocking code-level risks, they introduced the Saladgame DSL. The core idea is to allow only safe operations like map, filter, and reduce on the limited input of spending history.

For this, they used GitLab's micro-language-framework to handle token parsing and the DSL skeleton, and implemented only the necessary operators as plugins. For example, comparison operations like <= could be defined just by filling in the desc, symbol, validate, and evaluate interfaces, and they added Korean token support on top of this so operators could read and write more easily.

They designed the back office so that when an operator enters mission rules in Korean, the LLM suggests the DSL. Two kinds of context were included together in the prompt.

• Grammar and operator descriptions of the DSL: the entire spec injected as text via the desc command
• Real use cases: existing DSL examples accumulated in the DB provided together

However, there was a hallucination problem where the LLM would plausibly generate features that weren't even supported. To prevent this, they built a TestSaladgameDSL API that immediately checks whether the generated DSL produces the expected results, and on top of that, added a double review where a second LLM prompt critically re-examines the generated output.

Finally, they had the LLM propose not just the DSL but also test cases to check boundary conditions, and ultimately only missions that passed manual testing by a QA engineer were released to users. In conclusion, this approach shows that rather than using the LLM without limits, what matters for future engineering is building a DSL layer that saves tokens while reusing predictable results multiple times.