Context Engineering für Programmierungsagenten

Beim Context Engineering geht es darum, zu entscheiden, was ein Programmierungsagent sieht, bevor er handelt. Das ist der wichtigste Einflussfaktor, den du im Hinblick auf die Qualität der Ausgabe hast, denn ein leistungsfähiges Modell ist nur so gut wie das, was du ihm vorgibst.

In Jira ist der Kontext, den ein Agent braucht, bereits Teil des Prozesses. Der Vorgang enthält das Ziel und die Akzeptanzkriterien, und der Teamwork Graph verknüpft ihn mit dem Code, den Entscheidungen und den zugehörigen Dokumenten, sodass ein Agent auf Grundlage der tatsächlichen Absicht handelt statt auf Basis eines leeren Prompts. Dieser Kontext bleibt im gesamten Team verfügbar und verschwindet nicht in lokalen Dateien auf einem einzelnen Rechner.

Dieser Leitfaden befasst sich damit, was die Context Engineering ist, warum das Kontextfenster die eigentliche Einschränkung für Programmierungsagenten ist und wie du den Kontext in Jira so aufbereitest, dass Agenten erhalten, was sie brauchen, ohne dass du es ihnen bei jedem Prompt einzeln vorgeben musst. In der Praxis läuft es auf ein paar Schritte hinaus, die du in dem Vorgang ausführst, den du bereits bearbeitest:

• Gib dem Agenten das Ziel vor, nicht nur einen Prompt. Verfasse den Jira-Vorgang als Spezifikation mit Akzeptanzkriterien, anhand derer der Agent bewertet wird.

• Lass den Graph den entsprechenden Kontext liefern. Wenn du den Vorgang als Ausgangspunkt für den Prompt verwendest, erweitert der Teamwork Graph ihn um die Dokumente, Entscheidungen und den zugehörigen Kontext rund um die Aufgabe.

• Sorge dafür, dass Standards gemeinsam genutzt werden und immer auf dem neuesten Stand sind. Konventionen befinden sich in Confluence und werden von jedem Agenten und Teamkollegen aus derselben Quelle abgerufen.

• Biete jedem Agenten dieselbe Kontextebene. Derselbe organisatorische Kontext erreicht jeden Programmierungsagenten, wie Claude Code, Cursor, Codex, GitHub Copilot, den Jira-Programmierungsagenten und weitere.

Was ist eine Context Engineering?

Beim Context Engineering geht es darum, bewusst zu entscheiden, welche Informationen ein Modell in den einzelnen Schritten erhält, damit ein Programmierungsagent alles hat, was er braucht, um die Aufgabe korrekt zu erledigen. Diese Informationen sind mehr als der Prompt: Sie sind die Codebasis, deine Standards, Abhängigkeiten, der Git-Verlauf, Tooldefinitionen, Ziele und Akzeptanzkriterien. Das Kuratieren dieses Datensatzes für jede Aufgabe ist der neue Job.

Prompt Engineering bedeutet, dass du die Informationen zusammenstellst und sie selbst in eine einzelne Anweisung einspeist. Unter Context Engineering versteht man, dass das System dem Agenten alles bereitstellt, was er für eine Aufgabe mit mehreren Schritten benötigt: was eingegeben, abgerufen, zusammengefasst und weggelassen wird, damit der Agent den Rest bei Bedarf selbst finden kann.

Dabei ist zu beachten, dass mehr Kontext nicht unbedingt besser ist:

• Kontext mit hoher Aussagekraft sind die Informationen, die bei der jeweiligen Aufgabe tatsächlich hilfreich sind.

• Kontext mit geringer Aussagekraft ist veralteter, themenfremder oder doppelter Inhalt, den das Modell dennoch lesen muss.

Wenn sich ein Kontextfenster mit wenig aussagekräftigen Token füllt, werden Antworten langsamer und ungenauer, obwohl sich das Modell selbst nicht geändert hat. Diese Verschlechterung wird als Context Rot bezeichnet: der allmähliche Leistungsverlust, wenn sich das Kontextfenster mit veralteten, wenig aussagekräftigen oder widersprüchlichen Token füllt. Bei gutem Context Engineering geht es genauso sehr darum, veralteten Kontext zu entfernen, wie darum, den richtigen Kontext hinzuzufügen.

Warum stellt das Kontextfenster eine Einschränkung für Programmierungsagenten dar?

Ein Programmierungsmodell kann nur das berücksichtigen, was in das Kontextfenster passt – und das ist im Vergleich zu deiner Codebasis, deiner Dokumentation und dem Verlauf deines Teams ziemlich klein. Selbst ein fähiger Agent liefert einen falschen oder unsicheren Code ab, wenn deine Konventionen, deine Architektur oder die Entscheidung hinter einer Aufgabe nie berücksichtigt wurden.

Wenn es dem Agenten überlassen bleibt, Kontext zu sammeln, treten immer wieder einige typische Fehlermuster auf:

• Der Agent kommt bei einer langen Aufgabe vom Kurs ab, weil die Entscheidung, die er zu Beginn getroffen hat, aus dem Kontextfenster verdrängt wird, sobald neuere Token mit weniger Aussagekraft hinzukommen.

• Er ruft zu viele Daten ab, zieht viel mehr ins Fenster, als er braucht, und verschwendet das Token-Budget für Datenmüll.

• Er erkennt keinen Standard, den du ihm nicht vorgelegt hast, und liefert dann Code ab, der gegen ein Muster verstößt, an das sich der Rest des Teams hält.

• Alleine funktioniert er gut, hat aber keine Ahnung, was der Rest des Teams oder ein anderer Agent im selben Bereich macht.

Stattdessen kannst du durch leicht zugänglichen, passenden Kontext dafür sorgen, dass der Agent selbstständig genau das findet, was er im Verlauf benötigt, sodass deine Prompts auf einer allgemeinen Ebene bleiben können, anstatt jede Konvention und Entscheidung manuell im Detail vorzugeben.

Wie schaffst du den richtigen Kontext für Programmierungsagenten in Jira?

In Jira machst du den Vorgang selbst zum Kontext: Die Absicht steckt im Vorgang, das umgebende Wissen ist über den Teamwork Graph verknüpft, und dauerhafte Standards und Entscheidungen werden aus Confluence und Loom eingebunden, wo jeder Agent und Teamkollege auf dieselbe Quelle zurückgreift. Jira geht über lokale Dateien auf einem einzelnen Rechner hinaus und umfasst die Ziele, die laufenden Entscheidungen und Unterhaltungen sowie den Verlauf in deinen Vorgängen. So bleiben all diese Informationen für alle zugänglich, damit der Kontext, auf dessen Grundlage ein Agent handelt, für das ganze Team strukturiert, aktuell und konsistent ist.

Das Context Engineering basiert auf drei Prinzipien:

1. Die richtigen Informationen auswählen

2. Für eine jederzeit klare Struktur sorgen

3. Mit Hinblick auf Beständigkeit gestalten

1. Auswahl und Abruf: Verfasse den Vorgang als Spezifikation

Auswahl bedeutet, für eine Aufgabe die kleinste Menge an Kontext mit hoher Aussagekraft auszuwählen. Beim Abruf werden die richtigen Fakten bei Bedarf abgerufen, anstatt von vornherein alles ins Blickfeld zu bringen. In Jira beginnt beides mit dem Vorgang.

• Vorgehensweise in Jira: Trage das Ziel in die Beschreibung und die Akzeptanzkriterien in eine Checkliste ein. Damit informierst du den Agenten über den Zweck und die Kriterien, an denen er gemessen wird – und zwar in einer Struktur, die er lesen kann. Weise dann den Vorgang einem verbundenen Agenten zu. Er beginnt in diesem Fall beim Vorgang und seinem verknüpften Kontext, nicht bei der gesamten Codebasis. Der Austausch mit dem Agenten, um diese Spezifikation zu präzisieren, ist Teil des Vorgangs: Der Agent kann umfangreiche Inhalte schnell durchlesen und hilft dir, eventuelle Lücken zu finden, bevor es losgeht.

• Demnächst verfügbar: Das Jira-Planungstool verwandelt Ideen in für Agenten geeignete Pläne und Vorgänge, die bereits mit dem Kontext verknüpft sind. Lass dich auf die Warteliste setzen.

2. Gemeinsamer Kontext: Verknüpfe den Vorgang, anstatt ihn einzufügen

Struktur und Format sind entscheidend: Gestalte den Kontext so, dass sich ein Agent darin zurechtfindet, und achte darauf, dass er verknüpft bleibt, anstatt ihn einfach zu kopieren. Der Teamwork Graph sorgt dafür, dass der umgebende Kontext verfügbar ist, ohne dass er jedes Mal wieder manuell zusammengestellt werden muss.

• Vorgehensweise in Jira: Verknüpfe den Vorgang mit zugehörigen Vorgängen, dem Code und den Confluence-Seiten, die die Spezifikation, das RFC oder den Entscheidungsvermerk enthalten. Der Agent übernimmt den Kontext rund um die Aufgabe, nicht nur den Ticket-Text. Auch ein Loom-Walkthrough zählt: Eine aufgezeichnete Fehlerreproduktion oder Designbegründung wird mitsamt Transkript und Zusammenfassung in den Graph übernommen, sodass eine Erklärung, die du einem Teamkollegen gegeben hättest, zu einem Kontext wird, den ein Agent lesen kann. Das liefert dir die "richtigen abgerufenen Fakten" direkt aus deinem eigentlichen Vorgang – und nicht aus einem separaten Vektorspeicher, den du erst aufbauen und pflegen musst.

3. Persistenz: Behalte Standards und Entscheidungen bei, wo sie sich positiv auswirken

Persistenz – oder Speicher – bedeutet, dass dauerhaft gültige Fakten über mehrere Sitzungen hinweg verfügbar bleiben, damit der Agent nicht jedes Mal wieder von vorne anfangen muss. Wichtig sind dabei drei Bereiche: Was der Agent während einer Aufgabe vorliegen hat, was er zwischen den Aufgaben behalten sollte und was er bei Bedarf abrufen kann.

• Vorgehensweise in Jira: Konventionen, Architekturentscheidungen und bevorzugte Muster befinden sich im gemeinsamen Confluence-Bereich, in dem das gesamte Team und jeder Agent über den Graph auf dieselbe Quelle zugreifen, statt auf eine Kopie auf dem Rechner einer einzelnen Person, die sonst niemand sehen kann. Während der Vorgang das System durchläuft, wird der Graph immer umfangreicher, sodass der nächste Agent auf mehr Informationen zurückgreifen kann. Der Kontext sammelt sich im Laufe der Arbeit an, ohne dass der Entwickler dafür einen zusätzlichen manuellen Schritt ausführen muss.

Zwei Dinge sorgen dafür, dass alle im Team zusammenarbeiten können: eine gemeinsame Kontextebene, die jeder Mitarbeiter nutzen kann, und Regeln, die sicherstellen, dass alles zuverlässig und zulässig bleibt.

Eine gemeinsame Kontextebene für jeden Agenten

Der Kontext, den du entwickelst, lohnt sich nur, wenn jedes Tool ihn nutzen kann. Jeden Agenten erneut in deine Standards einzuarbeiten, wäre der schnellste Weg zu einem "Context Rot".

• Vorgehensweise in Jira: Schaffe für jeden Programmierungsagenten über zwei Wege denselben organisatorischen Kontext. Das Teamwork Graph-CLI ermöglicht deinem Programmierungsagenten direkten Zugriff auf diesen Kontext und seine Tools über das Terminal. Nach der einmaligen Einrichtung kann dein Agent den Graph bei der Arbeit abfragen. Der Atlassian Rovo MCP-Server übernimmt dieselbe Aufgabe für MCP-Clients wie Claude, Cursor, Codex und GitHub Copilot. Der Teamwork Graph sorgt dafür, dass alles in die richtige Richtung läuft: Aufgaben, Entscheidungen, Dokumente und Code sind als eine einzige, durchsuchbare Ebene miteinander verknüpft. Du erstellst den Kontext einmal und nutzt ihn dann mit dem Modell, das die Arbeit erledigt.

Governance: Sorge dafür, dass der Kontext zuverlässig und zulässig bleibt

Kontext ist nur nützlich, wenn er aktuell ist und der Agent ihn sehen darf. Governance sorgt dafür, dass die gemeinsame Ebene vertrauenswürdig bleibt, wenn mehr Agenten darauf zugreifen.

• So funktioniert es in Jira: Agenten übernehmen dieselben Berechtigungen, die dein Team bereits als Baseline verwendet. Ein Agent sieht also, was die Person dahinter sehen kann, und nicht mehr. Außerdem kann sein Umfang mit agentenspezifischen Regeln weiter eingeschränkt werden. Wie Zugriff, Genehmigung und Audit zusammenpassen, erfährst du unter Guardrails und Sicherheitsmaßnahmen für die Entwicklung in Jira.

Wie passt Jira zum Rest deines Kontext-Stacks?

Der Großteil des Kontexts eines Coding-Agenten befindet sich heute auf einem Rechner: das Repository, das er geöffnet hat, einige lokale Dateien und alles, was der Entwickler in den Prompt eingegeben hat. Das funktioniert allein, aber wird nicht zentral organisiert, ist auf bestimmte Personen bezogen und speichert nichts. Jira und der Teamwork Graph ziehen den wichtigen Kontext in eine gemeinsame, aktuelle und verwaltbare Ebene, auf die das gesamte Team und seine Agenten zugreifen.

Nichts davon ersetzt deinen Coding-Agenten, deine IDE oder deine lokale Konfiguration. Diese übernehmen weiterhin die Repository-spezifischen Details und den eigentlichen Code. Jira ist die gemeinsame Ebene darüber, sodass der Kontext, auf dessen Grundlage sie alle arbeiten, strukturiert, aktuell und in deinem Team überall derselbe ist.

So gibst du deinem ersten Agenten in Jira echten Kontext

Beim Context Engineering geht es letztlich darum, einem Agent die Tools und Informationen zu geben, die er braucht, um seine Aufgaben selbst zu erledigen. Jira und der Teamwork Graph sind die gemeinsame Kontextebene, die es über MCP oder CLI erreicht. Die Arbeitsabläufe sorgen dafür, dass diese Ebene richtig und verknüpft bleibt.

Beginne mit einem gut formulierten Vorgang, um den Unterschied zwischen einem Agenten, der Vermutungen anstellt, und einem Agent, der auf Grundlage deiner Absicht arbeitet, zu erkennen.

1. Gib dem Agent einen Maßstab, an dem er gemessen werden kann. Wähle eine klar abgegrenzte Aufgabe mit geringem Risiko aus, die sich leicht rückgängig machen lässt, zum Beispiel ein in sich geschlossenes Refactoring oder eine kleine Fehlerbehebung, und lege das Ziel in der Beschreibung mit Akzeptanzkriterien in einer Checkliste fest.

2. Lass den Agent den Kontext übernehmen, anstatt ihn einzufügen. Verbinde den Vorgang mit seinem Code, indem du in deinem Branch, Commit oder deiner Pull-Anfrage auf den Vorgangsschlüssel verweist und das zugehörige Dokument oder die zugrunde liegende Entscheidung verlinkst. Der Agent erfasst den verknüpften Kontext rund um die Aufgabe, nicht nur den Tickettext.

3. Verweise auf einen gemeinsamen Standard. Verknüpfe die Konvention, der der Agent folgen soll, mit einer Confluence-Seite, damit der nächste Agent und Teamkollege dieselbe Quelle verwenden.

4. Weise den Vorgang einem Agenten zu. Der Agent startet mit dem Vorgang und dem damit verknüpften Kontext – ein fokussierterer Ausgangspunkt als die gesamte Codebasis oder ein leerer Prompt.

5. Prüfe anhand der Kriterien, die ihm zugrunde liegen. Prüfe die Pull-Anfrage anhand der Akzeptanzkriterien, die du im Vorgang geschrieben hast, damit die Ausgabe anhand der ursprünglichen Messlatte bewertet wird, die du dem Agenten gegeben hast.

6. Der Agent soll den Kreis schließen. Fordere ihn auf, den Vorgang am Ende mit einer Sitzungszusammenfassung, den wichtigsten Entscheidungen und Abwägungen sowie der verknüpften Pull-Anfrage zu aktualisieren, damit der nächste Teamkollege oder Agent über den Teamwork Graph dort weitermachen kann, wo er aufgehört hat.

Führe auf diese Weise ein paar Vorgänge aus und das Diagramm füllt sich nach und nach: Jeder Agent hinterlässt eine Zusammenfassung, seine wichtigsten Entscheidungen und die verknüpfte Pull-Anfrage im Vorgang, sodass der nächste mit einem umfassenderen Einblick startet als der letzte. Das ist Context Engineering, das sich aufeinander aufbaut, statt bei jedem Lauf zurückgesetzt zu werden.

Häufig gestellte Fragen zur kontextbasierten Entwicklung

Was ist der Unterschied zwischen Context Engineering und Prompt Engineering?

Mit Prompt Engineering kannst du relevante Informationen manuell für einen einzelnen Prompt zusammenstellen. Mit Context Engineering implementierst du ein System, das einen Agenten über eine mehrstufige Aufgabe hinweg mit Informationen versorgt, einschließlich Abruf, Struktur, Speicher und dem Ziel selbst, sodass die Details bei Bedarf auf Abruf bereitstehen.

Wie beziehen KI-Agenten Kontextinformationen aus Jira?

Agenten beziehen Kontext aus dem Vorgang, seiner Beschreibung und den Akzeptanzkriterien sowie aus dem Teamwork Graph, der verwandte Vorgänge, Dokumentation und Code verbindet, sodass der Agent auf Grundlage der tatsächlichen Absicht handelt und nicht auf Basis eines leeren Prompts.

Warum erzeugen Coding-Agenten selbst mit einem guten Prompt einen falschen Code?

Ein Prompt enthält selten deine Konventionen, deine Architektur oder die Entscheidung hinter einer Aufgabe. Die meisten Agenten-Fehler sind Kontextfehler, keine Modellfehler, und besserer Kontext sorgt für mehr als nur für eine bessere Formulierung.

Brauche ich noch Context Engineering, wenn mein Agent bereits mein Repository liest?

Ja. Ein Repository sagt einem Agenten, was der Code ist, aber nicht, warum er auf diese Weise erstellt wurde, welche Standards zu befolgen sind oder was sonst im Team passiert. Context Engineering liefert den Rest.

Was ist Context Rot?

Context Rot ist die allmähliche Verschlechterung der Ausgabe eines Agenten, wenn sich sein Kontextfenster mit veralteten, signalarmen oder widersprüchlichen Tokens füllt. Antworten werden langsamer und weniger präzise, obwohl sich das Modell nicht geändert hat.