Prompt Engineering for Production Systems
Prompts are code. Here's how we version, test and monitor them across every SolvixaLabs product.
EduBrain answers millions of student questions. Bloom Again holds emotionally delicate conversations. Axiora OS acts on people's calendars. In all three, the prompt layer is production infrastructure — and we treat it that way.
Prompts live in the repo
Every system prompt is a versioned file with an owner, a changelog and a test suite. Editing a prompt goes through code review like any other change, because it is code — it's just written in English.
Evals before vibes
For each prompt we maintain a golden dataset: real (anonymized) inputs with graded expected behaviors. A change must beat the current version on the eval suite before it ships. Vibes-based prompt editing feels productive and is how regressions happen.
Three eval types cover most needs:
- Assertion evals — the output must contain, or must never contain, specific things. Cheap, fast, run on every commit.
- Rubric evals — a judge model grades outputs against a written rubric. Good for tone and pedagogy.
- Human review queues — sampled production traffic reviewed weekly. The ground truth that keeps the other two honest.
Design for the failure case
A tutoring prompt that's brilliant 95% of the time and confidently wrong 5% of the time is a bad prompt. We explicitly instruct models on what to do when uncertain — say so, ask a clarifying question, or escalate to a human. In Bloom Again, uncertainty handling isn't a nice-to-have; it's a safety requirement.
The compounding loop
Instrument everything, review samples weekly, fold findings back into prompts and evals. Six months of that loop beats any clever technique you'll read about on social media.