Context-engineering voor coding agents

Context engineering is het werk van beslissen wat een coderingsagent ziet voordat de agent handelt. Het is de grootste hefboom die je hebt voor de kwaliteit van de uitvoer, omdat een capabel model maar zo goed is als wat je ervoor zet.

In Jira maakt de context die een agent nodig heeft al deel uit van het werk. Het werkitem bevat het doel en de acceptatiecriteria, en de Teamwork Graph verbindt het met de code, de beslissingen en de documentatie eromheen, zodat een agent handelt op basis van de werkelijke bedoeling in plaats van een lege prompt. Die context blijft gedeeld binnen je team, en zit niet vast in lokale bestanden op één machine.

In deze handleiding lees je wat context engineering is, waarom het contextvenster de echte beperking is voor coderingsagents en hoe je context in Jira ontwerpt zodat agents krijgen wat ze nodig hebben zonder dat je alles handmatig via elke prompt hoeft aan te reiken. In de praktijk komt dat neer op een paar stappen die je uitvoert in het werk dat je al uitvoert:

• Geef de agent het doel, niet alleen een prompt. Schrijf het Jira-werkitem als de specificatie, met acceptatiecriteria waartegen de agent wordt beoordeeld.

• Laat de grafiek de omringende context bieden. Door het werkitem als startpunt voor de prompt te gebruiken, breidt Teamwork Graph dit uit naar de documenten, beslissingen en gerelateerde context rond de taak.

• Houd standaarden gedeeld en actueel. Afspraken staan in Confluence en worden door elke agent en teamgenoot uit dezelfde bron gehaald.

• Geef elke agent dezelfde contextlaag. Dezelfde organisatiecontext bereikt elke coderingsagent, zoals Claude Code, Cursor, Codex, GitHub Copilot, de Jira-agent voor coderen en meer.

Wat is context engineering?

Context engineering is de praktijk waarbij je bewust beslist welke informatie een model bij elke stap te zien krijgt, zodat een coderingsagent heeft wat nodig is om het werk correct uit te voeren. Die informatie is meer dan de prompt: het is de codebase, je standaarden, afhankelijkheden, git-geschiedenis, tooldefinities, doel en acceptatiecriteria. Die set voor elke taak samenstellen is het nieuwe werk.

Prompt engineering betekent dat je de informatie selecteert en zelf in één instructie invoert. Context engineering betekent dat het systeem levert wat de agent nodig heeft in een taak met meerdere stappen: wat erin gaat, wat wordt opgehaald, wat wordt samengevat en wat wordt weggelaten, zodat de agent de rest op aanvraag kan vinden.

Het is belangrijk om op te merken dat meer context niet per se betere context is:

• Context met een hoog signaalgehalte is de informatie die daadwerkelijk helpt bij de taak die voorligt

• Context met een laag signaal is de verouderde, irrelevante of dubbele inhoud die het model nog steeds moet lezen

Naarmate een contextvenster zich vult met tokens met een laag signaal, worden antwoorden trager en minder nauwkeurig, ook al is het model niet veranderd. Die verslechtering wordt context rot genoemd: de geleidelijke afname van de uitvoer naarmate het contextvenster zich vult met verouderde, weinig informatieve of tegenstrijdige tokens. Goede context-engineering draait net zo goed om het verwijderen van verouderde context als om het toevoegen van de juiste context.

Waarom is het contextvenster de beperking voor coderingsagents?

Een coderingsmodel kan alleen redeneren over wat binnen het contextvenster past, dat klein is in vergelijking met je codebasis, je documentatie en de geschiedenis van je team. Een capabele agent levert nog steeds verkeerde of onveilige code op wanneer je conventies, je architectuur of de beslissing achter een taak nooit in het venster terechtkwamen.

Wanneer de agent zelf context moet verzamelen, komen een paar vormen van mislukking steeds weer terug:

• De agent dwaalt af tijdens een lange taak omdat de beslissing die de agent eerder nam uit het contextvenster wordt geduwd wanneer nieuwere tokens met een lager signaal zich opstapelen.

• Er wordt te veel opgehaald, waardoor er veel meer in het venster terechtkomt dan wordt gebruikt en het tokenbudget aan overbodige informatie wordt besteed.

• Het herkent nooit een standaard die je er niet expliciet aan hebt gegeven en levert vervolgens code op die een patroon doorbreekt dat de rest van het team volgt.

• Het werkt prima alleen, maar heeft geen idee wat de rest van het team of een andere agent in hetzelfde gebied doet.

In plaats daarvan zorg je ervoor dat de juiste context eenvoudig toegankelijk is, zodat de agent zelf naar boven kan halen wat nodig is terwijl die bezig is, zodat je prompts op hoofdlijnen kunnen blijven in plaats van dat je elke conventie en beslissing handmatig moet uitschrijven.

Hoe ontwerp je context voor coderingsagents in Jira?

In Jira maak je van het werk zelf de context: de intentie zit in het werkitem, de omringende kennis is verbonden via de Teamwork Graph, en duurzame standaarden en beslissingen worden opgehaald uit Confluence en Loom, waar elke agent en teamgenoot uit dezelfde bron put. Jira gaat verder dan lokale bestanden op één machine, naar de Doel, de doorlopende beslissingen en gesprekken, en de geschiedenis in je werk. Zo blijft al die informatie gedeeld, zodat de context waarop een agent handelt gestructureerd, actueel en consistent is voor het hele team.

Context engineering is gebaseerd op drie principes:

1. De juiste informatie selecteren

2. Het gestructureerd houden

3. Laten voortbestaan

1. Selectie en ophalen: schrijf het werkitem als de specificatie

Selectie is het kiezen van de kleinste set context met een hoog signaal voor een taak, ophalen is het ophalen van de juiste feiten op aanvraag in plaats van alles vooraf in het venster te dumpen. In Jira beginnen beide met het werkitem.

• Hoe het werkt in Jira: zet het doel in de omschrijving en de acceptatiecriteria in een checklist. Dat geeft de agent de intentie en de maatstaf waarop de agent wordt beoordeeld, in een structuur die de agent kan lezen. Wijs het werkitem vervolgens toe aan een verbonden agent. Het begint bij het werkitem en de gekoppelde context, niet bij de volledige codebasis. Sparren met de agent om die specificatie aan te scherpen, maakt deel uit van het werk: de agent leest razendsnel veel informatie en helpt je de hiaten te vinden voordat het begint.

• Binnenkort beschikbaar: Jira Planner zet ideeën om in plannen en werkitems die klaar zijn voor agents, met de context al toegevoegd. Meld je aan voor de wachtlijst.

2. Gedeelde context: koppel het werk, plak het er niet in

Structuur en indeling zijn code: geef context vorm zodat een agent er zijn weg in kan vinden, en houd die gekoppeld in plaats van gekopieerd. De Teamwork Graph zorgt ervoor dat de context eromheen beschikbaar is zonder dat je die elke keer handmatig hoeft samen te stellen.

• Hoe het werkt in Jira: koppel het werkitem aan gerelateerde werkitems, de code en de Confluence-pagina's met de specificatie, de RFC of het beslissingsrecord. De agent neemt de context rond de taak over, niet alleen de tickettekst. Een Loom-rondleiding telt ook mee: een opgenomen bugreproductie of ontwerpredenatie neemt het transcript en de samenvatting mee in de graph, zodat een uitleg die je aan een teamgenoot zou hebben gegeven context wordt die een agent kan lezen. Dit levert de 'juiste opgehaalde feiten' uit je eigenlijke werk, niet uit een afzonderlijke opgeslagen vectors die je moet genereren en onderhouden.

3. Volharding: houd standaarden en beslissingen aan waar ze elkaar versterken

Persistentie, of geheugen, betekent dat duurzame feiten beschikbaar blijven in verschillende sessies, zodat de agent niet elke keer vanaf nul hoeft te beginnen. De drie categorieën om over na te denken: wat de agent tijdens een taak bijhoudt, wat de agent tussen taken moet bewaren en wat de agent kan opzoeken wanneer dat nodig is.

• Hoe het werkt in Jira: conventies, architectuurbeslissingen en voorkeurspatronen staan in de gedeelde Confluence-space, waar het hele team en elke agent via de Graph uit dezelfde bron putten, in plaats van uit een kopie op iemands machine die niemand anders kan zien. Naarmate werk door het systeem loopt, wordt de Graph rijker, zodat de volgende agent meer heeft om uit te putten. Context bouwt zich op terwijl werk wordt gedaan, zonder extra handmatige stap voor de ontwikkelaar.

Twee dingen zorgen ervoor dat dit werkt voor iedereen in een team: één contextlaag die elke agent kan gebruiken, en governance die die laag betrouwbaar houdt en waarvoor toestemming is gegeven.

Eén contextlaag voor elke agent

De context die je ontwikkelt, is alleen de moeite waard als elke tool die kan gebruiken. Elke agent je standaarden opnieuw aanleren is de snelste manier om context weer verloren te laten gaan.

• Hoe het werkt in Jira: geef elke coderingsagent via twee paden dezelfde organisatorische context. Met de Teamwork Graph CLI krijgt je agent vanuit de terminal rechtstreeks toegang tot die context en de bijbehorende tools. Stel de tool één keer in en je agent kan de graph raadplegen terwijl die werkt. De Atlassian Rovo MCP Server doet hetzelfde voor MCP-clients zoals Claude, Cursor, Codex en GitHub Copilot. De Teamwork Graph is wat dit hoe dan ook mogelijk maakt: werkitems, beslissingen, documentatie en code die als één doorzoekbare laag met elkaar verbonden zijn. Je stelt de engineercontext één keer op en gebruikt die met welk model dan ook dat het werk doet.

Toezicht: houd de context betrouwbaar en toegestaan

Context is alleen nuttig als deze actueel is en de agent deze mag zien. Toezicht houdt de gedeelde laag betrouwbaar naarmate meer agents er gebruik van maken.

• Hoe het werkt in Jira: agents nemen dezelfde rechten over die je team al gebruikt als basis, zodat een agent ziet wat de persoon die het gebruikt kan zien, en niet meer, en verder kan worden beperkt met agentspecifieke regels. Voor meer informatie over hoe toegang, goedkeuring en audit samenhangen, ga je naar Richtlijnen en veiligheid voor agentgestuurde engineering in Jira.

Hoe past Jira in de rest van je contextstack?

Het grootste deel van de context van een codeeragent bevindt zich tegenwoordig op één machine: de repo die open is, een paar lokale bestanden en alles wat de ontwikkelaar in de prompt heeft getypt. Dat werkt wanneer de ontwikkelaar alleen werkt, maar de informatie is verspreid, persoonsgebonden en de agent vergeet dingen. Jira en de Teamwork Graph brengen de context die ertoe doet samen in één gedeelde, actuele laag met toezicht waaruit het hele team en de agents putten.

Niets hiervan vervangt je codeeragent, je IDE of je lokale configuratie. Die doen nog steeds de details per repo en de daadwerkelijke code. Jira is de gedeelde laag daarboven, zodat de context van waaruit iedereen werkt gestructureerd en actueel is, en hetzelfde voor je hele team.

Zo geef je je eerste agent echte context in Jira

Bij contextengineering draait het uiteindelijk om het verstrekken van de tools en informatie aan een agent waarmee die zelfstandig kan vinden wat die nodig heeft. Jira en de Teamwork Graph zijn de gedeelde contextlaag die het via MCP of CLI bereikt; het gaat er dus om die laag nauwkeurig en verbonden te houden.

Begin met één goed geformuleerd werkitem om het verschil te zien tussen een agent die moet gissen en een agent die op basis van intenties werkt.

1. Geef de agent een maatstaf waaraan die getoetst kan worden. Kies één afgebakende taak met laag risico die je eenvoudig ongedaan kunt maken, zoals een zelfstandige herstructurering of een kleine bugfix, en schrijf het doel in de omschrijving met acceptatiecriteria in een checklist.

2. Laat de agent context overnemen in plaats van die te plakken. Verbind het werkitem met de bijbehorende code door naar de werkitemsleutel te verwijzen in je branch, commit of pull request, en koppel het document of besluit daarachter. De agent pikt de gekoppelde context rond de taak op, niet alleen de tekst van het ticket.

3. Verwijs naar een gedeelde standaard. Koppel de conventie die moet worden gevolgd aan een Confluence-pagina, zodat de volgende agent en teamgenoot dezelfde bron gebruiken.

4. Wijs het toe aan een agent. De agent begint met het werkitem en daaraan gekoppelde context, dus een gerichter startpunt dan de volledige codebase of een lege prompt.

5. Beoordeel aan de hand van de criteria die het hebben voortgebracht. Controleer de pull request aan de hand van de acceptatiecriteria die je in het werkitem hebt geschreven, zodat de uitvoer wordt beoordeeld op basis van de oorspronkelijke maatstaf die je aan de agent hebt opgelegd.

6. Laat de agent de cirkel rondmaken. Vraag of de agent het werkitem aan het einde bij kan werken met een samenvatting van de sessie, de belangrijkste beslissingen en afwegingen en de gekoppelde pull request, zodat de volgende teamgenoot of agent via de Teamwork Graph verder kan gaan waar deze is gestopt.

Voer een paar werkitems uit op deze manier en de grafiek wordt gaandeweg ingevuld: elke agent laat een samenvatting, de belangrijkste beslissingen en de gekoppelde pull request achter bij het werkitem, zodat de volgende met een vollediger beeld begint dan de vorige. Dat is contextengineering dat zich opstapelt in plaats van bij elke uitvoering opnieuw begint.

Veelgestelde vragen over contextengineering

Wat is het verschil tussen contextengineering en prompt-engineering?

Prompt-engineering is de discipline waarbij je handmatig relevante informatie samenstelt voor één prompt. Contextengineering is de discipline waarbij je een systeem implementeert dat informatie levert voor een agent tijdens een taak die uit meerdere stappen bestaat, inclusief ophalen, structuur, geheugen en het doel zelf, zodat het systeem de details op verzoek naar behoefte naar boven brengt.

Hoe krijgen AI-codeeragents context uit Jira?

Agents halen context uit het werkitem, de omschrijving en acceptatiecriteria en uit de Teamwork Graph, die gerelateerd werk, documentatie en code met elkaar verbindt, zodat de agent handelt op basis van de werkelijke intentie en niet op basis van een lege prompt.

Waarom produceren codeeragents verkeerde code, zelfs met een goede prompt?

Een prompt bevat zelden je conventies, architectuur of de beslissing achter een taak. De meeste fouten van agents zijn contextfouten, geen fouten in het model, en betere context lost meer op dan een betere formulering.

Heb ik contextengineering nog steeds nodig als mijn agent mijn repo al leest?

Ja. Een repo vertelt een agent wat de code is, maar niet waarom die op die manier is gebouwd, welke standaarden de agent moet volgen of wat er nog meer gebeurt in het team. Contextengineering levert de rest.

Wat is context rot?

Context rot is de geleidelijke verslechtering van de uitvoer van een agent naarmate het contextvenster zich vult met verouderde tokens, tokens met weinig signaal of tegenstrijdige tokens. Antwoorden worden trager en minder nauwkeurig, ook al is het model niet veranderd.