Je AI verzint je product er maar bij

Waarom de output zo sterk varieert

Hier is dezelfde prompt, naar hetzelfde model gestuurd, zestig seconden uit elkaar.

Prompt: "Schrijf acceptatiecriteria voor een ticket: gebruiker kan instellingen van de AI-provider configureren."

Eerste poging — zonder context: de output is een generieke checklist. "Gebruiker kan een AI-provider selecteren uit een dropdown. Gebruiker kan instellingen opslaan. Gebruiker ziet een bevestigingsbericht." Het had elk product, elk platform, elk decennium kunnen zijn. Er is niets mis mee. Er is ook niets nuttigs aan.

Tweede poging — met productcontext: de output verwijst naar Jira Cloud adminpagina's, Forge resolver-rechten, API-sleutelvalidatie per provider (OpenAI, Anthropic, Google, Mistral, xAI), databereikgedrag op organisatie- vs. projectniveau, en aan licentie gebonden schrijfacties. Het specificeert dat instellingen worden opgeslagen via @forge/sql en dat de UI Atlaskit-componenten met xcss-tokens gebruikt. Het klinkt alsof het is geschreven door iemand die daadwerkelijk in die codebase heeft gewerkt.

Het model is niet veranderd. De temperatuur is niet veranderd. De invoer is veranderd. Dat gat — tussen generiek en verankerd — is het hele onderwerp van dit artikel.

Wanneer AI-output inconsistent aanvoelt, is het instinct om het model de schuld te geven: van provider wisselen, tier upgraden, temperatuur aanpassen. Bijna altijd is dat de verkeerde hendel.

Elke prompt begint bij nul. Het model heeft geen geheugen van je product, je gebruikers, je beperkingen of je laatste gesprek, tenzij je die informatie expliciet aanlevert. "Schrijf acceptatiecriteria" betekent iets heel anders voor een Jira-native Forge-app die engineeringteams van tien tot honderd mensen bedient dan voor een consumentenmobiele fitness-tracker.

Het model reageert op de wereld die je beschrijft. Als je niets beschrijft, verzint het er een — en die is zelden de jouwe.

Dat is waarom twee mensen in hetzelfde team hetzelfde model kunnen gebruiken en volledig verschillende resultaten kunnen krijgen. Het is geen kwestie van vaardigheid. Het is niet de promptstructuur. Het is of het model genoeg productrealisteit heeft gekregen om mee te werken.

Voor het bredere kader waarom dit zulke dure fouten veroorzaakt in Jira, begin bij: AI lost slecht uitgelijnde teams niet op. Het verbergt ze.

De oplossing is geen betere promptingtechniek. Het is het bouwen van een herbruikbare contextlaag — een compacte, eerlijke beschrijving van de wereld van je product — die voor elke prompt wordt bijgevoegd. Je schrijft het één keer. Je hergebruikt het overal. Het model stopt met raden en begint te werken met dezelfde beperkingen als je team.

De vier lagen

Productcontext is niet één blob tekst. Het valt netjes uiteen in vier lagen, die elk ander werk doen.

• Productsamenvatting behandelt wat het product doet, voor wie en welke resultaten tellen — operationele waarheid, geen marketingcopy. Het verschil doet er toe. "Een projectmanagementtool voor teams" kan alles beschrijven. "Just is een Jira-native AI-copilot voor product- en engineeringteams op Jira Cloud. Kerntaak: ambigue Jira-issues omzetten in gestructureerde uitvoeringsplannen — verduidelijkingen, stap-voor-stapplannen en terugschrijven naar Jira-velden — zonder het issuepaneel te verlaten. Geen chatbot. Geen zelfstandige tool. Gebouwd op Atlassian Forge." beschrijft precies één product.
• Doelgroep behandelt wie de gebruikers zijn, wat ze nodig hebben, wat ze verwachten en wat ze niet weten.
• Designtaal behandelt visuele patronen, componentenbibliotheek, interactiegewoonten en de dingen die je nooit doet.
• Stack en beperkingen behandelt echte frameworks, runtimelimieten, integraties en expliciet verboden keuzes.

De slechte versie van elk veld past bij duizenden producten. De goede versie past bij precies één. Dat is de test.

Doelgroep is waar generieke context breekt

Doelgroep is meestal het eerste veld dat teams te sterk vereenvoudigen. "Product managers en ontwikkelaars" klinkt redelijk. Het is ook te vaag om het model betere beslissingen te laten nemen.

Een nuttig doelgroepveld is specifiek over teamsamenstelling, AI-vertrouwdheid, vertrouwensverwachtingen en wat gebruikers niet willen. Voor Just betekent dat PMs en senior engineers in Jira Cloud-teams van 10 tot 100 mensen, met matige AI-vertrouwdheid, die hun eigen API-sleutels beheren en meer waarde hechten aan betrouwbare output dan aan indrukwekkende output.

De "Niet voor"-regel telt even zwaar. Zeggen dat dit niet is voor teams buiten Jira Cloud of voor gebruikers die volledig autonome agenten willen, elimineert hele categorieën verkeerde aannames voordat ze ontstaan.

Dit is wat context verankerd maakt in plaats van decoratief. Het model wordt niet alleen verteld wie de gebruiker is. Het wordt ook uitgelegd in welke wereld die gebruiker opereert en welke soorten workflows verkeerd zouden aanvoelen.

Extraheer wat er al is

De meeste teams hebben alle vier contextlagen al — ze zijn alleen verspreid over codebases, designbestanden, docs en teamgeheugen in plaats van in een vorm die AI kan gebruiken.

Vanuit je repository: wijs een coding-agent — Claude Code, Codex of vergelijkbaar — op je codebase en vraag om een markdown-samenvatting die productdoel, stack, implementatiegrenzen en bekende beperkingen dekt. Een goed gestructureerde repo levert in minuten een bruikbaar eerste concept.

Vanuit je designbestanden: identificeer de naam van de componentenbibliotheek, drie tot vijf sleutelinteractiepatronen waarop je product steunt, en drie dingen die de UI nooit doet. De anti-patronen zijn even belangrijk als de patronen.

Vanuit bestaande docs: onboardingnotities, README-bestanden, interne briefs of marketingcontext kunnen allemaal fragmenten leveren voor de productsamenvatting en doelgroepsdefinitie. Ze hoeven niet perfect te zijn om nuttig te zijn.

Vanuit je eigen hoofd: als niets van het bovenstaande nog bestaat, open dan nu een leeg document en schrijf één alinea per veld. Het zal onvolmaakt zijn. Onvolmaakte context verslaat geen context ruimschoots.

Je hebt geen perfecte documentatie nodig. Je hebt een compacte, eerlijke beschrijving nodig van de wereld waarin je product leeft.

Sla het één keer op, hergebruik het overal

Context loont alleen als het herbruikbaar is. Het één keer schrijven en in één sessie plakken helpt die sessie. Het persistent maken helpt elke sessie.

• In Just heeft het adminpaneel een eigen sectie voor elk van deze vier contextvelden — Productsamenvatting, Doelgroep, Designtaal en Stack. Plak je inhoud eén keer per project in elk veld. Elk toekomstig inzicht, elke verduidelijking, elk plan en elke uitvoerstap in dat project wordt automatisch verankerd door deze context.
• Als je Just niet gebruikt, maak dan één context.md-bestand in de root van je repo of in gedeelde docs. Structureer het met dezelfde vier secties. Plak het aan het begin van elke AI-sessie — codeerassistenten, chattools, documentgeneratoren. Het formaat doet er minder toe dan de gewoonte: context eerst, dan de prompt.

Behandel je contextlaag als een levend document, niet als een launch-day-artefact. Herzien wanneer het product ingrijpend verandert — een nieuwe integratie, een grote doelgroepverschuiving, een design-systeemmigratie. Niet elke sprint herzien. Als je productsamenvatting elke twee weken verandert, is het geen productsamenvatting — het zijn vergadernotities.

Context is geen prompt engineering

Productcontext is geen prompt engineering. Het is geen truc, geen template en geen slimme hack. Het is het model hetzelfde briefing geven dat je een nieuwe aannemer op dag één zou geven: hier is wat we bouwen, voor wie, hoe het eruit moet zien en waarop het draait.

Teams die dit één keer doen — en het consequent hergebruiken — krijgen output die aanvoelt alsof die afkomstig is van iemand die het product echt begrijpt. Omdat dat in elke functionele zin ook zo is. Het model is niet slimmer geworden. Je bent gewoon gestopt het te vragen te raden.