Ik zie het overal: de “echte” productprompt leeft in een Slack-thread. Iemand past een zin aan, iemand anders copy-pastet die naar productie, en niemand weet welke versie straks klanten bedient.
Dat is geen experiment meer. Dat is een release zonder eigenaar, zonder review en zonder rollback. Precies waar prompt versiebeheer voor nodig is.
- Een prompt in chat is een wijziging in productiegedrag, geen brainstormnotitie.
- Prompt versiebeheer betekent: eigenaar, versie-ID, review, eval-gate en rollback.
- Dit is org-side change control. Los van stille provider-updates (model drift).
- Begin klein: één flow, één registry, één golden set, één afspraak wie mag promoten.
Wat er gebeurde
Een team waar ik mee werkte had een support-agent die “al weken prima” liep. Op een dinsdagmiddag paste een collega de system prompt bij in Slack: iets vriendelijker, iets korter, “even testen”. Die tekst belandde dezelfde dag in de productconfig. Geen ticket. Geen diff. Geen wie-tekent-af.
Donderdag kwamen de eerste klachten. De agent weigerde plots minder vaak door te verbinden naar een mens. JSON-antwoorden kregen een inleiding. De parser hapte. De chat bleef groen. De workflow niet.
Niemand kon zeggen welke promptversie om 14:12 live stond. De Slack-thread had drie varianten, waarvan er één “final_final_v2” heette. Dat is geen releaseproces. Dat is productiewijziging via groepschat.
Ik zie dit patroon bij startups én bij grotere organisaties. Niet omdat mensen slordig zijn. Omdat prompts nog niet als deployable artifact worden behandeld. Code heeft PR’s. Config heeft change windows. De prompt mag blijkbaar “even”.
Als je productprompt alleen in Slack staat, heb je geen prompt versiebeheer. Je hebt een open edit-slot op productie.
Waarom dit relevant is
Een promptwijziging verandert gedrag: toon, weigeringsdrempel, toolkeuze, schema, escalatie. Dat is functionele change. Zonder eigenaar weet je niet wie mag promoten. Zonder versie kun je niet terug. Zonder review mist iemand de zin die een safety-regel weghaalt. Zonder eval-gate ship je op gevoel.
Dit is iets anders dan AI model drift. Drift is provider-side: dezelfde alias, ander gedrag. Hier gaat het om jullie eigen tekst die zonder change control de productielijn in loopt. Beide breken workflows stil. De mitigatie overlapt (meten, golden set), maar de oorzaak niet.
LLM Best Practices over prompt evals zegt het rechtuit: een prompt is production code. Die heeft een eval set, een metriek, een regressierun en een promotion gate nodig. Heavy Thought over golden sets vult aan: een golden set is geen mapje voorbeelden, maar cases plus een scoring contract. Zonder dat contract blijft “het lijkt beter” marketing.
Drie plekken waar Slack-prompts het hardst pijn doen:
- Geen bron van waarheid. Drie kanalen, vijf varianten, één live. Niemand weet welke hash of tag actief is.
- Geen rollback. Als gedrag kantelt, moet je gissen welke zin het was. Terwijl je klanten al de nieuwe toon zien.
- Geen gate. Een “kleine teksttweeak” kan weigeringen, grounding of schema kapot maken. Zonder paired eval zie je dat pas in productie.
Zonder baseline blijft elke wijziging een verhaal, zoals ik schreef in zonder baseline is je AI-ROI een verhaal. Prompt versiebeheer is daar de org-kant van: je koppelt elke release aan een meetbare set cases, niet aan een thumbs-up in chat.
Wat je nu kunt doen: prompt versiebeheer in vier stappen
Geen nieuw platform als eis. Wel vier gewoonten die elke productprompt behandelen als software die jullie zelf releasen.
- Eén registry, één eigenaar. Haal productprompts uit Slack. Stop ze in git, een config-repo of een simpele registry met prompt-ID, versie, auteur en changelog. Eén persoon (of rol) mag prod-pointers zetten. Chat blijft voor voorstellen, niet voor live tekst.
- Versie-ID op elke call. Log prompt-versie én model-ID bij elke request. Zonder die join-key kun je regressies niet toewijzen. Rollback wordt dan een pointer-swap terug naar de vorige goedgekeurde versie, geen archeologie in threads.
- Eval-gate vóór promote. Bouw een kleine golden set (start met 20–50 echte cases). Run kandidaat en huidige prod op dezelfde cases. Blokkeer promote bij schemafalen of een duidelijke kwaliteitsdaling. Future AGI over evaluation-driven development laat zien hoe je zo’n lokale loop als gate gebruikt. Heavy Thought over evaluation gates koppelt die gate aan change surfaces: prompt, model, retrieval, tools, policy.
- Treat prompt changes as deployments. Staging of shadow, canary op een slice, iemand tekent af, pas daarna 100%. Zelfde ritme als code. “Even in Slack plakken” verdwijnt uit het proces.
Wat “goed genoeg” vandaag al is
Je hoeft niet meteen een enterprise prompt platform te kopen. Een map prompts/ met support-triage.v4.md, een JSONL met cases ernaast, een CI-job die faalt bij regressie, en een shortlist wie prod mag aanwijzen: dat is al serieus prompt versiebeheer. Later kun je registry, feature flags en canary toevoegen.
Voor prompts en evaluatie die dit volhouden, helpt vaak AI-modeloptimalisatie meer dan nóg een chattool. Wil je agents waarvan de instructies niet via Slack “live” gaan? Kijk naar managed AI-agents of plan een kort gesprek via contact.
Wil je prompts die als release lopen, niet als chat-experiment?
We helpen teams prompt versiebeheer, golden sets en eval-gates neerzetten. Geen hype. Wel wijzigingen die je kunt terugdraaien.