KI Features für Jira Data Center

This transcript was generated automatically and has not been manually reviewed. It may therefore contain errors. The spoken word in the recording is always authoritative.

Gil Breth: Herzlich willkommen zu einer neuen Ausgabe des INNOQ Podcasts. Mein Name ist Gil Breth und wir widmen uns heute dem Digital Independence Day, auch kurz gesagt dem D-Day. Der letzte war am 5.4. und beim Digital Independence Day geht es darum, ich zitiere einmal von ihrer Webseite, jeden ersten Sonntag auf die gute Seite zu wechseln. Und wir bei INNOQ haben uns überlegt, wir möchten auch unseren Beitrag zu diesen Rezepten, die sie auf dieser Webseite veröffentlichen, beitragen und dazu habe ich mir meinen sehr geschätzten Kollegen, den Nicolas Inden, eingeladen. Lieber Nicolas, magst du dich einmal kurz vorstellen, was du bei der INNOQ so machst?

Nicolas Inden: Hi Gil, grüß dich. Ja, danke dir, sehr gerne. Ich bin Nico und bin jetzt seit 2018 bei INNOQ und bin meistens in so einer Schnittstellenposition unterwegs zwischen Kunde und Entwicklerteam. Habe da auch sehr viel damit zu tun, wohin der Kunde eigentlich will, was genau umgesetzt werden soll und wie wir das für uns in verdaubare Häppchen formulieren und umsetzen, sodass wir nachher ein richtig cooles Produkt rauskriegen. Genau.

Gil Breth: Super. Ja, vielen lieben Dank für die Vorstellung, lieber Nico. Dann reden wir doch einmal kurz über dein Rezept und zwar geht es um das Thema KI-Features für Jira Server und das Ganze ohne die Atlassian Cloud. Was war denn da so deine Motivation zu diesem Rezept?

Nicolas Inden: Im Prinzip habe ich einen Weg gesucht, um auf der einen Seite das, was ich so tagtäglich im Projekt mache, irgendwie zu unterstützen, auf der anderen Seite auch meinen Spieltrieb, was lokale KI-Modelle angeht, so ein bisschen auszuleben. Und da habe ich das einfach mal probiert, was heute geht, was kann ich mit lokaler KI machen, wie kann sie mir helfen, meine Informationen, die ich so vom Kunden bekomme, irgendwie zu verarbeiten und dann halt in unsere Instrumente, in dem Fall Jira, reinzukriegen, wo wir sie dann nachher halt auch mit dem Team weiter bearbeiten. Und das hat tatsächlich für einen Wow-Effekt bei mir gesorgt, muss ich ganz ehrlich sagen, weil da haben Dinge funktioniert, die ich vorher so nicht erwartet habe und deshalb haben wir uns getroffen, um jetzt über dieses Thema zu sprechen.

Gil Breth: Ja, bei mir hat das direkt so etwas ausgelöst, das ist so dieser klassische Gedanke: Du kriegst irgendwie eine E-Mail, du kriegst irgendwie einen Anruf, dann musst du das noch formalisieren, du musst das irgendwie in Jira oder auch ein anderes Ticketsystem reinkippen und das ist natürlich ganz charmant, wenn man das mit einer KI lösen kann. Das geht aber natürlich auch nicht immer in jedem Kontext, gerade wenn es auch sehr sensible Daten oder Informationen sind. Also ich versuche auch immer erstmal den lokalen Weg zu gehen, so ein bisschen was mit den Themen und Projekten zu tun, in denen ich so unterwegs bin und deswegen war ich da ganz hellhörig, als du mir das erzählt und auch gezeigt hast. Aber wie ist denn das bei deiner Idee? Vielleicht kannst du mal so einen Überblick über dieses Rezept geben, was sind denn so die Zutaten und was mich natürlich auch interessieren würde, kannst du es ein bisschen vergleichen zum Funktionsumfang von Jira selber, also muss ich da irgendwo Abstriche machen? Aber reden wir erstmal über die Zutaten, was steckt denn so drin in deinem Rezept, woraus besteht es denn?

Nicolas Inden: Genau, also die Zutaten richten sich so ein bisschen danach, was ich an Tooling habe, in diesem Fall ist das Jira und was ich an Informationen habe und wie ich die da reinkriege. Also im konkreten Beispiel arbeiten wir mit Jira Data Center, also einer selbst gehosteten Instanz von Jira und dort ist unser Kanban Board drin, mit dem wir alles planen und auf der anderen Seite haben wir tagtäglich entweder Slack-Unterhaltungen oder Calls oder was auch immer mit dem Kunden, wo Ideen auftauchen oder Features noch ein bisschen verfeinert werden und da war halt der Gedanke, wie kriege ich das wunderbar in dieses Jira rein? So, das ist also die Senke, das Jira. Aber die Information, die ich auf der anderen Seite kriege, möchte ich natürlich jetzt ein bisschen strukturieren, deshalb Thema KI. Mein naiver Gedanke war, schmeißt man doch einfach unsere Slack-Konversationen, unsere Calls, so wie wir sie denn dann auch mal aufzeichnen und transkribieren, da rein und schauen, was eine lokale KI damit machen kann. Hier kommt das Thema lokale KI auch wieder zum Tragen, der ein oder andere möchte vielleicht diese Information, wo man dann einfach mal ein bisschen quatscht, auch nicht in eine Cloud-KI reinschmeißen. Das ist so von der persönlichen Einstellung auf der einen Seite, manchmal bietet es auch einfach das Projekt nicht, dass man einfach über Themen spricht, die nicht die eigene Infrastruktur verlassen sollten. Genau, das ist also die zweite Zutat, die KI. Und die dritte Zutat ist der MCP Server. Das ist im Prinzip das Bindeglied. Die KI an sich hat ja erstmal ein eigenes Weltwissen, was aber nichts von unserem Projekt weiß, über das wir gerade sprechen. Und damit sie weiß, worüber wir sprechen, brauchen wir diese Verbindung zu unserem Jira Server, wo ja hoffentlich schon einige Dinge angelegt sind und Kontextinformationen enthalten sind. Deshalb gibt es einen MCP Server, der sagt der KI: Hier, guck mal hier, es gibt ein paar Werkzeuge, die ich dir anbiete, wie zum Beispiel Jira Issues aufzulisten oder nach bestimmten Issues zu suchen, Issues zu erstellen und ganz ganz viele andere Dinge. Und was dabei rauskommt, ist jetzt eigentlich Punkt 4, die Diskussion, die ich nachher führen kann. Ich kann quasi mit der KI sprechen, kann einmal über das Feature sprechen, wie es inhaltlich umzusetzen sein könnte und auf der anderen Seite habe ich direkt die Verbindung in Richtung unser Projektmanagement, wo ich es dann anlegen kann. Aber das ist jetzt so ganz grob der Überblick.

Gil Breth: Okay. Ja. Das ist ja, sage ich mal, von den Zutaten her überschaubar, das finde ich gut an der Stelle. Ich würde mal gerne bei der Instanz noch mal nachfragen, weil das ist ja gerade, wenn man viel auf die Atlassian-Lösungen setzt, schon ein Thema. Geht es nur mit der von dir gerade beschriebenen Server beziehungsweise Data Center, also mit einer eigenen Instanz, geht es auch mit der Cloud-Instanz, also was ist so die Mindestvoraussetzung?

Nicolas Inden: Es geht mit beidem. Es gibt für beide Versionen entsprechende MCP Server, die man verwenden kann. Wer eine Jira Cloud-Instanz benutzt, der kann das genauso durchführen. Muss dann bei der Konfiguration des MCP Servers entsprechend nicht die lokale Instanz wählen, sondern die Jira Cloud und dann geht das genauso. Aber man kann das auch ganz allgemein so nehmen, dass dieses Tooling auch für andere Dinge funktionieren wird, wenn jemand kein Jira hat, dann brauche ich im Prinzip für diese andere Projektmanagement-Software in Anführungszeichen nur den passenden MCP Server finden, der die Kommunikation zwischen der KI und dem Projektmanagement herstellt und dann dürfte das auch funktionieren.

Gil Breth: Okay. Ja, aber ich hatte in meiner Vorbereitung auf die Aufnahme heute auch noch mal recherchiert zum Thema Lizenzen, das ist ja immer wieder ein Thema, gerade wenn es um, sage ich mal, On-Premise oder auch Cloud-Lösungen geht an der Stelle, dass, was ich jetzt gerade noch richtig im Gedächtnis habe, glaube ich, am 30.03.26, also diesen Jahres, gibt es keine neuen Lizenzen mehr. Das heißt jetzt nicht, dass die alten nicht mehr funktionieren, also für ich glaube Data Center, aber es wird keine neuen mehr geben. Das heißt aber, da verbaue ich mir keinen Weg, wenn du sagst, das ist ja auch mit der Cloud-Lösung an sich kompatibel.

Nicolas Inden: Genau, da kann man, wenn man möchte, später wechseln. Die aktuelle Jira Data Center Edition, die wird noch unterstützt bis 2029, war es, glaube ich. Und danach läuft die Unterstützung aus. Jetzt sagt Atlassian, die Unterstützung läuft aus. Keiner weiß, also ich weiß zumindest nicht, ob dann die Instanz auch ausgeht, ich glaube nicht, aber man möchte natürlich auch keine nicht mehr supporteten Instanzen in der Richtung benutzen. Also ein bisschen Zeit ist da noch, wenn ich eine eigene Jira Data Center Instanz habe und ich habe auch den Weg frei, dann zu wechseln.

Gil Breth: Mhm. Okay. Reden wir noch mal ein bisschen über das lokale KI-Modell, also für welches hast du dich denn entschieden?

Nicolas Inden: Es gibt nicht die eine Entscheidung. Ich habe ein paar probiert, die gut funktionieren, da kann ich ein bisschen drüber erzählen. Das ist einmal GPT-OSS in der 20B-Variante. Jetzt mag man sagen, das ist nicht mehr das allerfrischeste, aber es ist schnell und es funktioniert. Wichtig bei der Wahl des KI-Modells ist letztlich einfach, dass es Tools unterstützt, weil das ist das, was der MCP Server benutzt und der KI zur Verfügung stellt. Das KI-Modell muss Tooling benutzen können.

Gil Breth: Mhm.

Nicolas Inden: Und GPT-OSS kann das gut, kann vor allen Dingen auch gut genug, sage ich jetzt mal, diese Diskussion über Features und dann das Tooling vom MCP Server nutzen. Es gibt natürlich auch viel aktuellere Modelle, die da schon in diversen Punkten weiter sind, wie zum Beispiel ein Qwen 3.5 Modell oder jetzt vor ein paar Tagen gerade erst rausgekommen, das Gemma 4 Modell. Das waren tatsächlich auch jetzt meine letzten Experimente, dass ich mal geschaut habe, funktioniert das auch mit Gemma 4 und ja, klar, funktioniert auch mit Gemma 4.

Gil Breth: Ja.

Nicolas Inden: Was man so ein bisschen drauf achten muss bei den Modellen, ist die eigene IT-Ausstattung. Dadurch, dass die KI auf dem eigenen Rechner läuft, muss der natürlich auch so ein bisschen Dampf haben und die auch unterstützen können. Das ist so der Trade-off, den man eingeht, wenn man sagt, man möchte keine Cloud-KI benutzen, dann braucht es halt einen Rechner, der gut genug ist, um das lokal machen zu können.

Gil Breth: Ja, wenn du sagst, ein bisschen mehr Dampf haben, mach mal konkret, worüber reden wir da? Also hast du ein paar Zahlen für diejenigen, die sich vielleicht gerade einen neuen Rechner konfigurieren müssen?

Nicolas Inden: Grundsätzlich benutzt KI die GPU und braucht sehr viel RAM. Das heißt, entweder habe ich einen Rechner mit einer dedizierten GPU, der sehr viel RAM hat, das ist aber meistens die sehr teure Variante. Wenn ich mir jetzt so eine RTX 5090 von Nvidia angucke, die ist schon echt teuer und gemessen in der KI-Welt hat selbst die nicht viel RAM. Wenn ich dann in Grafikkarten, in GPUs gehe, die jetzt in der Cloud für KI verwendet werden, die möchte man als Privatmensch gar nicht bezahlen. Was da tatsächlich lohnenswerter ist, ist zum Beispiel so eine Hybrid-Infrastruktur anzuschauen, zum Beispiel die MacBooks von Apple, die jetzt alle Apple Silicon benutzen seit einigen Jahren. Das ist eine Architektur, wo CPU und GPU den gleichen RAM benutzen. Wenn ich mir jetzt so ein MacBook mit 64 oder 128 GB RAM konfiguriere, dann habe ich einen sehr großen Teil davon eben auch für die GPU zur Verfügung. Das Ganze gibt es auch in der PC-Welt. Was mir da bekannt ist, sind die Strix Halo Systeme von AMD, die haben auch so einen Ansatz, die gibt’s auch mit bis zu 128 GB gemeinsamen Speicher. Jetzt spreche ich immer von 128, man möchte natürlich immer so viel, wie es irgendwie gibt. Wenn man guckt, was man wirklich braucht, ist es tatsächlich ein bisschen weniger. Wenn man sich die KI-Modelle anschaut, da ist meistens so eine Angabe dahinter, wie viel Parameter dieses Modell gerade benutzt. GPT OSS 20B bedeutet 20 Billionen Parameter. Und es gibt so eine Faustformel, die ist ein bisschen pessimistisch, man sagt, wenn es ein 20B Modell ist, dann brauche ich 20 GB RAM, um das betreiben zu können. Damit kommt man eigentlich immer hin, in der Realität ist es ein bisschen weniger, was man braucht, hängt auch noch mal von der Quantisierung des Modells ab. Aber das würde jetzt vielleicht ein bisschen tief gehen. Aber grundsätzlich die Modelle, die ich jetzt getestet habe, sind einmal 20B bei GPT OSS, 35B bei dem Qwen 3.5 Modell und 26B beim Gemma 4 Modell und das lässt sich alles mit 64 GB RAM oder auch 32 GB RAM bewerkstelligen. Man muss immer überlegen, wir machen hier kein Agentic Coding, wo riesengroße Kontexte entstehen. Das spielt auch noch mal eine Rolle dafür, wie viel RAM man nachher braucht, sondern es sind relativ übersichtliche Diskussionen, die wir hier mit der KI führen, deshalb sollte man mit 32 GB da auskommen.

Gil Breth: Mhm, mhm. Ja, das ist spannend, weil je nachdem, was für ein, also ich denke da in so Support-Szenarien, wenn du ein wirklich First-Level-Supporter bist und musst erstmal vielleicht Dinge etwas aufbereiten, strukturieren, fährt man damit, glaube ich, gut. Wenn es nachher komplizierter ist, also Klassiker sind immer so Performance-Probleme in der Softwareanwendung, ja, das ist immer sehr vielschichtig, mehrdimensional. Ich glaube, dann wird der Kontext auch schnell sehr groß, aber für da, wo vorne erstmal viel passiert, halte ich das auch für ein gutes Setup und vor allen Dingen deine Daumenregel, die kann man sich ganz gut merken mit dem 1 GB RAM pro Milliarde Parameter. Das finde ich gut, das finde ich sehr gut. Ich wollte auch gerade eben noch sagen, dadurch, dass du ja, ich glaube LM Studio war es ja an der Stelle verwendest, kann man ja auch wirklich mal eben schnell verschiedene Modelle sich installieren und auch Erfahrung sammeln, das vergleichen, gucken, was besser funktioniert, ja, was für einen für seinen Szenarien irgendwie gut klappt. Einen Punkt, den ich gerne mal dich fragen würde, wir reden über lokale KI-Modelle. Wir haben natürlich aber mittlerweile auch oder auch schon länger europäische Anbieter. Kannst du da auch mal einen Vergleich ziehen, also warum sollte ich es lokal machen, was spricht gegen vielleicht einen europäischen Anbieter, das dort zu hosten, zu nutzen?

Nicolas Inden: Aus meiner Sicht ist der größte Vorteil bei der lokalen Anwendung tatsächlich die Aktualität der Modelle. Wir haben es jetzt gesehen, Google hat Gemma 4 vor ein paar Tagen rausgebracht und ich kann das eigentlich mehr oder weniger sofort, wenn es rauskommt, mit LM Studio und Konsorten lokal testen. Das heißt, ich bin da immer auf dem aktuellsten Stand, kann testen, was mittlerweile geht und was nicht geht. Es gibt diverse Anbieter in Europa, die KI-Inferenz per API anbieten und ja, die sind jetzt gerade im besten Fall, sage ich mal, bei einem Qwen 3 Coder Next, wenn ich jetzt mal deutsche Anbieter betrachte, angekommen. Ich habe zumindest noch keinen deutschen Anbieter gesehen, wo ich einen Qwen 3.5 habe. Deshalb ist das definitiv der Vorteil und natürlich das persönliche Empfinden, wo möchte ich gerne meine Daten haben?

Gil Breth: Ja. Okay, ja, danke einmal für die Einschätzung und Abgrenzung. Dann lass uns doch mal über die dritte Zutat, das Thema MCP, sprechen. Mhm.

Nicolas Inden: Genau, der MCP bietet mir ja dann für die KI die Welt meines eigenen Wissens, in diesem Fall Jira. Und ich hatte es eben schon mal ein bisschen angeteasert, der MCP Server sagt meiner KI, was sie tun kann, um an dieses Wissen zu kommen. Konkret wäre das im Fall von Jira, sagt der KI, wie ein Issue angelegt werden kann oder eben auch, wie ich nach Issues suchen kann. Das ist ein ganz großer Vorteil, ne? Also ich kann in Jira selber zwar mit JQL sehr komplex zusammenbauen, wonach ich suche, aber manchmal fällt es einem auch einfach leichter, das in normaler Sprache zu formulieren. Und diese Übersetzung kann dann tatsächlich die KI selber machen, wenn sie dieses Tool an die Hand bekommt durch den MCP Server und ich dann vorne reinschreibe, zeig mir doch mal bitte alle Epics im Status erledigt an, dann macht’s damit automatisch das JQL, kann’s reinschmeißen und bekommt die Ergebnisse für mich zurück.

Gil Breth: Ja. Jetzt ist das ja bei den MCP Servern so, es gibt ja oft nicht nur den einen, warum also für welchen hast du dich noch mal konkret entschieden und was waren ein bisschen deine Kriterien? Also wann hast du es festgemacht, dass das die beste Lösung ist?

Nicolas Inden: Okay, ich habe zwei verschiedene probiert. Angefangen hat’s tatsächlich mit einem selbst gewebten, wo ich einfach mal losgerannt bin und dachte mir, das kann doch so schwer nicht sein und tatsächlich war da auch innerhalb von ein paar Stunden getan, dass ich einen MCP Server da hatte, der mit unserem lokalen Jira sprechen konnte. Aber wie das nun mal so ist mit Sachen, die man selber baut, irgendwann kommt man an den Punkt, ja, es ist cool, aber möchtest du es das jetzt auch nicht auf immer und ewig maintainen? Dann habe ich geschaut, was gibt es denn schon und klar, es ist schon jemand auf die Idee gekommen und es gibt MCP-Atlassian als MCP Server. Link gibt’s auch unten in den Shownotes nachher sicher. Der ist maintained, der ist etabliert, funktioniert und die Wahl, die wir jetzt letztlich getroffen haben.

Gil Breth: Mhm, okay. Ja, sehr gut, alles klar. Ja, guter Hinweis, also die sowohl D-Day als auch den Server und die anderen Sachen werden wir natürlich in den Shownotes verlinken. Genau. Das ist ein bisschen mal über die technische Einrichtung sprechen. Also vielleicht kannst du das noch mal ein bisschen so Schritt für Schritt durchgehen, was war notwendig, was hat gut geklappt, was hat nicht funktioniert, was hat ein bisschen gehakt, hat es überhaupt irgendwo gehakt? Oder lief das smooth durch?

Nicolas Inden: Klar, man tastet sich ja immer so ein Stückchen voran, ne? Erstmal möchte man das natürlich lokal probieren, dann musst du gucken, gibt es Jira noch, um es lokal hochzufahren per Docker, klar, gibt es. Die Trial-Lizenz, das ist das, was jetzt heute leider nicht mehr geht. Ich habe wirklich, als ich es ausprobiert habe, es waren ein paar Tage vor dem Datum, wo Atlassian gesagt hat, so ab jetzt gibt’s keine Trial Keys mehr. Ich habe noch einen der letzten ergattert und konnte es ausprobieren. Das war so eine Sache, das heißt, wer jetzt zuhört und das gerne ausprobieren möchte, sollte am besten schon irgendwo eine laufende Jira-Instanz zum Testen dafür haben. Das ist das eine und dann, als wir das alles so zusammengebaut haben und ein bisschen ausprobiert haben, fallen so kleine Details auf, ne? Dann fange ich an, über ein Thema zu sprechen mit der KI, sag, erstell mir doch mal bitte ein Epic dazu. Dann rödelt die KI so ein bisschen hin und her und probiert diese Tools aus dem MCP Server aus, mal funktioniert das sofort, mal kann man richtig schön im Verlauf mit der KI sehen, dass bestimmte Toolaufrufe einfach nicht funktioniert haben, dann sieht man in dem Thinking von der KI schön, ah, ich habe einen Fehler zurückbekommen, habe ich wahrscheinlich einen Parameter falsch übergeben oder einen Parameter, der fehlt, ich probiere es so und so noch mal, aber die wurschtelt sich so dann ihren Weg da durch und dann hat es tatsächlich in den meisten Fällen nachher funktioniert und am Ende eigentlich immer.

Gil Breth: Mhm.

Nicolas Inden: Ich sag am Ende immer, weil so ein paar Sachen muss man halt fixen. Die KI-Modelle, die ich verwendet habe, die verwenden immer gerne Markdown, um irgendwelche Texte zu formatieren. Jetzt ist Jira leider nicht so der Markdown-Fan, wenn ich jetzt als Issue-Beschreibung Markdown verwende, dann sieht das nachher ganz schrecklich aus und auch mit Auflistungen von Items und so funktioniert das ein kleines bisschen anders. Da muss man der KI jetzt ein bisschen Hilfestellung geben und sagen, hör mal, du sprichst jetzt mit Jira, Jira hat ein eigenes Markup und verwende doch für Überschriften und Auflistungen dieses und jenes Markup. Das kann ich dann in LM Studio in den System Prompt reinschreiben.

Gil Breth: Mhm.

Nicolas Inden: Da sage ich der KI im Prinzip implizit bei jedem Aufruf, den ich übergebe, hier, das sind deine Rahmenbedingungen, die du hast, achte bitte darauf, dass du das Jira Markup verwendest bei der Issue-Beschreibung. Oder in unserem Fall im Projekt, wir haben ein paar Custom Fields in Jira definiert, die man so im Allgemeinen in der Doku nicht findet, da schreibe ich dann auch in den System Prompt rein, es gibt diese und jene Custom Fields, die möchte ich gerne, wenn du genug Informationen hast, schon ausgefüllt haben.

Gil Breth: Ja. Also ein bisschen machst du Vorgaben oder gibst Beispiele, Templates mit, damit das Format, die oder die Erwartungshaltung da, sage ich mal, bestmöglich getroffen wird bei dem Ergebnis, was rauskommt nachher. Ja. Eine Frage, die bei mir da immer so ein bisschen mitschwingt, das läuft ja unter deinem User Account. Also was bedeutet das für deine Aktion? Ist das dann in Jira irgendwie nachvollziehbar gelabelt oder könnte ich dem Eindruck erliegen, dass es alles von Nico ist, was da so zusammengefasst und einformuliert worden ist?

Nicolas Inden: Ich würde es eher andersrum sehen, ich würde es sehen, es kommt von meinem Nutzer-Account, also bin ich auch dafür verantwortlich, ne? Also ich möchte ja jetzt nicht den Anschein erwecken, dass ich jetzt irgendwelche Arbeit geleistet habe, die ich nicht getan habe, sondern ich benutze KI als Tool und stehe dazu, weil es unter meinem Namen da steht und das ist ja auch richtig so. Am Ende des Tages muss man immer wissen, wen muss ich denn fragen, wer hat das verzapft und deshalb finde ich es genau richtig so. Das ist jetzt, ich sag mal in Anführungszeichen, nur eine systembedingte Sache, weil ich halt im MCP Server nachher mein Access Token von meinem Jira User mitgebe. Aber am Ende finde ich es genau richtig so. KI kann eine Hilfe sein oder soll eine Hilfe sein, aber KI nimmt keine Verantwortung ab.

Gil Breth: Ja, ist ein guter Punkt. Ich bin da völlig bei dir: Wenn ich das nutze und so verwende, dann übernehme ich damit auch die Verantwortung. Ich muss natürlich für mich auch ein bisschen abwägen, wie umfangreich ich das nutze oder wie sehr ich es auch einfach vielleicht an der Stelle frei laufen lasse. Ich würde gerne noch mal ein bisschen darüber sprechen, gerade für diejenigen, die zuhören und jetzt vielleicht auch Lust bekommen, das selber mal auszuprobieren und aufzusetzen. Was kannst du noch mal kurz zusammenfassen? Worauf muss man achten? Was lief nicht so „out of the box“? Bei Atlassian, vielleicht um das noch mal irgendwie, warum ich da so nachbohre, herauszustellen: Das sind ja oft gerade die SaaS- oder Cloud-Anbieter, die mit der „Out of the Box“-Lösung kommen. Ich schalte ein Feature an, es funktioniert sofort, es ist alles integriert. Ich tausche hier vielleicht auch oft Komfort gegen Individualität ein, oder gegen meinen vielleicht will ich sagen Anspruch, aber manchmal das Szenario, das ich eigentlich erfüllen möchte. Worauf muss man dann noch mal achten? Was hat vielleicht nicht so „out of the box“ funktioniert, wo wurde es ein bisschen frickelig?

Nicolas Inden: Es ist allgemein etwas, was ich komplett selber zusammenstöpseln muss. Ich glaube, das ist der wichtigste Punkt, wie du sagst: Es ist nicht ein Feature-Toggle, was ich irgendwo im Web-Interface anmache und es ist da, sondern ich stecke ja jede Komponente einzeln zusammen und ich muss auch, wenn ich ein neues Modell zum Beispiel teste, immer noch mal gucken, wie verhält sich das jetzt. So eine KI ist nun mal nicht deterministisch und von Modell zu Modell ist es eh noch mal unterschiedlich. Das heißt, ich kann hier und da auch einfach schon mal ein unerwartetes Ergebnis haben. Das heißt, man muss es immer im Auge haben. Ansonsten, wenn du jetzt konkrete Fälle haben möchtest, sind es wirklich so die Sachen, wie ich eben schon mal erwähnt habe, wie Umlaute verwendet werden sollen, damit Jira das richtig anzeigt, wie Titles oder Listings angezeigt werden sollen, damit Jira es richtig kann.

Gil Breth: Mhm.

Nicolas Inden: Und so Dinge, wie ich meine Custom Fields befülle. Konkretes Beispiel: Wir haben jetzt eine Webanwendung, die aus verschiedenen Komponenten besteht, und mein Gedanke war, statt jetzt selber zu sagen, an welcher Komponente da was gemacht werden muss, könnte die KI das doch aus dem Kontext des Issues schließen und dieses Feld befüllen. Ja, das funktioniert tatsächlich gut, würde ich mal so sagen, in 80, 90 % der Fälle ist das richtig, was dabei rauskommt. Die KI guckt sich dann an, welche Komponenten dieses Jira-Projekt zur Verfügung hat und was dazu passen würde. Jetzt kann man natürlich hingehen und die Trefferquote dramatisch erhöhen, indem man zu diesen einzelnen Komponenten noch irgendwelche Beschreibungen mit in den System-Prompt oder an andere Stelle mit reinpackt, damit das Verständnis einfach noch mal besser wird, mehr als nur ein Keyword. Aber das ging schon recht gut, weil ganz oft zum Beispiel so ein Komponentenname auch dann in der Beschreibung schon mehr oder weniger drin vorkommt.

Gil Breth: Ja, du hast gerade das Stichwort Determinismus angesprochen, und das finde ich gerade, also ich fand das ganz zu Anfang dieser Diskussion über Determinismus auch in der Softwareentwicklung unter Einsatz von KI, ich fand das immer spannend, dass ich dann eine etwas andere Sicht darauf hatte, geprägt durch die lange Zeit, die ich im Service-Umfeld verbracht habe, also im IT Service Management. Was hast du eben gesagt? Ich glaube, 80, 90 % Treffergenauigkeit. Wenn jemand schon mal mit einem Support interagiert hat und Problemstellungen hat, die über vielleicht das Zurücksetzen eines Passworts ein Stück weit hinausgehen, glaube ich, dass die Freude über eine 80 bis 90 % Trefferquote bei dem ersten Lösungsvorschlag, den man bekommt, schon recht groß wäre. Deswegen war für mich immer ganz klar, ich habe hier gar nicht den Anspruch an die Maschine, fehlerlos zu sein, weil gerade im Service, wo ich es in der Regel auch oft mit Menschen zu tun habe, auch da eine gewisse Fehlertoleranz in der Regel erwarte und erwarten kann. Deswegen finde ich das, also bei 80, 90 %, das ist schon echt gut an manchen Stellen.

Nicolas Inden: Würde ich gerne kurz einhaken.

Gil Breth: Ja, gerne.

Nicolas Inden: Wir reden ja gerade über ein Komponentenfeld an der Stelle. Wenn ich jetzt über eine Ticketbeschreibung, sei es fürs Epic oder für eine Story, spreche, würde ich mir schwertun, jetzt zu sagen, das ist zu 80, 90 % richtig. Ich würde auch jetzt nicht sagen, dass es irgendwie zu 20 % falsch ist. Es ist halt einfach, man kann nicht erwarten, dass man ein paar Stichworte in die KI reinschmeißt und dann kommt das perfekte Ticket dabei raus. Also den Zahn muss ich direkt allen ziehen. Es macht vieles einfacher, aber es nimmt dir nicht die Arbeit in dem Sinne ab. Es fällt zum Beispiel oft auf, dass dann eine Beschreibung und auch Akzeptanzkriterien oder eine formulierte User Story dabei rauskommt, die nah dran ist, wo du aber weißt, da fehlen noch ein paar Informationen, da muss ich noch mal ran. Das muss man immer im Hinterkopf haben.

Gil Breth: Ja, guter Hinweis, das stimmt. Es bleibt natürlich bei dem alten Prinzip: Das, was ich reingebe, hat auch Wirkung auf das, was da rauskommt. Wenn ich nur drei Stichworte mitgebe, ich nehme gerne mal das Beispiel mit dem Thema Performance, das kann alles Mögliche betreffen. Ich muss es natürlich schon ein bisschen entsprechend aufwerten. Du hast eben gesagt, im Vergleich zu der Out-of-the-Box-Lösung, dass ich halt etwas mehr manuellen Aufwand habe, oder dass ich mir das zusammenstecken muss. Kannst du dich noch daran erinnern, wie viel Aufwand hattest du so bei deinen Richtungen, wie lange hat das gebraucht für dich, das Setup, was du eben beschrieben hast, so lauffähig zu bekommen?

Nicolas Inden: Das hat sich ja Stück für Stück entwickelt. Das hat ja angefangen, den MCP-Server erstmal selber zusammenzubauen, und bin dann nachher erst auf die fertige Lösung gegangen. Also am Ende des Tages würde ich sagen, dass ich da schon ein paar Tage dran rumprobiert habe, bis ich an dieser letztendlichen Lösung angekommen bin. Wenn man jetzt das Ganze so, wie es im Artikel beschrieben ist, noch mal zusammenbauen würde, dann geht das relativ flott, aber einfach dieser Weg, das zu finden, wie es funktioniert, das hat schon ein bisschen gedauert. Es war aber auch eine Zeit, die Spaß gemacht hat, muss ich ganz ehrlich sagen.

Gil Breth: Ja, das glaube ich, das merkt man dir auch an. Aber so ein guter Hinweis, dafür ist ja der Artikel da, diese, ich sag mal, diese Ramp-up-Zeit oder dieses Experimentieren, das haben wir oder hast du ja an der Stelle schon übernommen. Aber ich finde es immer wieder schön, auch in anderem Kontext zu sehen, was eigentlich schon möglich ist, wo sind so ein bisschen die Grenzen und was funktioniert schon und was kann ich auch so in mein Daily Business überführen. Lass uns mal einen Ausblick wagen: Wenn du jetzt noch mehr Zeit investiert hättest, oder vielleicht hast du es ja auch noch vor, was sind denn die Sachen, die du jetzt noch als Nächstes angehen würdest in dem Setup? Was kommt jetzt neben Jira?

Nicolas Inden: Genau, also das Ganze wird natürlich reicher, wenn ich mehr Informationsquellen anbiete. Typischerweise habe ich in so einem Entwickler-Setup ja nicht nur ein Projektmanagement wie Jira, sondern ich habe wahrscheinlich auch noch ein GitLab oder GitHub oder eine andere Stelle, wo mein Code liegt, wo ich Informationen darüber habe, wann welche Builds gemacht wurden, welche Commits dafür verwendet wurden, und das könnte man alles zusammenbringen. Das kann man lokal an dieser Stelle mit einem weiteren MCP-Server reinholen, man könnte sich die Commits holen, man kann automatisch Release Notes erstellen lassen. Das ist so rein von den Informationen, die da sind, alles möglich, und das wäre auf jeden Fall das Nächste, wo ich jetzt schauen würde. Und das andere ist, was bieten mir jetzt neuere KI-Modelle noch für weitere Vorteile? Ist da was dabei, was mir für diesen Workflow einen Vorteil bringt, oder ist es vielleicht eher so, ja gut, neuere KI-Modelle bringen mir vielleicht bei Agentic Software Engineering was, wenn ich da wirklich Code mitschreiben lasse, aber für diesen Workflow ist da nicht mehr wirklich was dabei, kann auch sein.

Gil Breth: Hast du schon ein konkretes Modell im Blick, was du als Nächstes mal ausprobieren willst?

Nicolas Inden: Ja, wie gesagt, im Moment ist es Gamma 4, was ich teste, was vor ein paar Tagen rausgekommen ist, und ich werde euch da auf dem Laufenden halten.

Gil Breth: Okay, sehr gut. Wunderbar. Ja, im Endeffekt gehört zu jeder Podcast-Aufnahme natürlich immer so ein schöner Call to Action, den hast du ja gerade schon damit auch abgegeben, es ist ja eigentlich im Kern ausprobieren, ne?

Nicolas Inden: Ja.

Gil Breth: Man kann ja mit deinem Artikel beginnen, oder wenn es nicht Jira oder genau dieser MCP-Server sein soll, die anderen Bestandteile, wie man das, also ich glaube, das kann man auch ganz gut mit den anderen Sachen einfach mal ersetzen und ausprobieren, ne? Ich glaube, das Rezept ist schon, kann man auch gut verallgemeinern für andere Dinge.

Nicolas Inden: Absolut, ja.

Gil Breth: Noch mal so ein bisschen vielleicht zum Abschluss, nimm dir mal gerne kurz einen Moment: Wenn du es noch mal machen würdest, gibt es etwas, was du anders machen würdest, außer vielleicht den Teil mit dem Webcoding des MCP-Service, das habe ich jetzt so ein bisschen rausgehört. Gibt es noch mal etwas, wo du sagst, da hätte ich vielleicht irgendwas noch mal anders gemacht?

Nicolas Inden: Gute Frage. Ich glaube, ich würde nicht rückblickend irgendwas anders machen, sondern ich würde eher nach vorne blicken, was kann ich noch machen?

Gil Breth: Mhm.

Nicolas Inden: Was kann ich finden, was mir die tägliche Arbeit noch weiter erleichtert, wie zum Beispiel jetzt den Code-Workflow auf GitHub noch anzuzapfen? Oder weitere Informationsquellen vom Projekt mit einzubeziehen? Also das Thema gibt es ja auch schon reichlich, wie kriege ich jetzt kundenspezifisches oder projektspezifisches Domänenwissen in meine KI rein, und das wäre auch ein Weg, wo ich noch hin denken würde. Das ist zum Beispiel eine Wissensdatenbank beim Kunden oder im Projekt gibt, die ich mit anbinde, die Wissen liefert, um halt Ticketbeschreibungen mit anzureichern und so weiter. Also ich denke da eher nach vorne als nach hinten, weil der Weg nach hinten, das war ab und zu mal mit Kurven versehen, aber das war ja auch gut so, da haben wir ja auch Erkenntnisse draus gezogen.

Gil Breth: Ja, sehr schön. Alles klar, vielen Dank, lieber Nico. Ich habe es schon gesagt, dein Rezept ist in unserem Blog, im INNOQ Blog ja schon am 5.4. erschienen. Die Aufnahme dazu haben wir jetzt ein bisschen später gemacht und ich kann in der Aufnahme auch schon mal anteasern, das nächste Rezept wird auch zum nächsten Digital Independence Day erscheinen, und zwar ist der schon am 3.5., also in wenigen Wochen nach dieser Aufnahme. Und ja, wenn euch das Rezept gefallen hat, ihr Interesse daran gefunden habt, dann schaut gerne am, wie gesagt, 3.5. vorbei, dann werden wir das nächste Rezept veröffentlichen. Schaut doch gerne mal beim D-Day auf der Webseite vorbei. Die ganzen Links zum Rezept vom Nico, zum D-Day, zu der Initiative werden wir in den Shownotes verlinken und ja, dann danke ich dir noch mal Nico für deine Zeit und danke da draußen den Zuhörern fürs Zuhören und je nachdem vielleicht auch über YouTube fürs Zuschauen und sage mal, bis zum nächsten Mal.

Nicolas Inden: Bis dann. Ciao.

Gil Breth: Ciao.

This summary was generated automatically and has not been manually reviewed. It may therefore contain errors. The spoken word in the recording is always authoritative.

Das Gespräch dreht sich um ein “Rezept” für den Digital Independence Day (D-Day), das von Nicolas Inden entwickelt wurde. Es geht darum, KI-Funktionen für Jira Server (oder Data Center) zu nutzen, ohne auf die Atlassian Cloud angewiesen zu sein. Das Ziel ist, die tägliche Projektarbeit zu unterstützen, indem man Informationen aus Slack-Konversationen oder Anrufen mit Kunden mithilfe lokaler KI-Modelle verarbeitet und in Jira-Tickets überführt. Dies ermöglicht eine effizientere Strukturierung und Erstellung von Jira-Issues, während sensible Daten lokal bleiben.

“Im Prinzip habe ich einen Weg gesucht, um auf der einen Seite das, was ich so tagtäglich im Projekt mache, irgendwie zu unterstützen, auf der anderen Seite auch meinen Spieltrieb, was lokale KI Modelle angeht, so ein bisschen auszuleben.”

Allgemeiner Überblick der diskutierten Aspekte

• Motivation für das Rezept: Nicolas Inden wollte seine tägliche Projektarbeit unterstützen und gleichzeitig seinen “Spieltrieb” bezüglich lokaler KI-Modelle ausleben. Er suchte nach Wegen, Kundeninformationen effizienter zu verarbeiten und in Jira zu integrieren, insbesondere unter Berücksichtigung sensibler Daten, die nicht in eine Cloud-KI gelangen sollen.
• Zutaten des Rezepts:
  • Jira Data Center (oder Server/Cloud): Die selbst gehostete Instanz von Jira dient als Zielsystem für die verarbeiteten Informationen. Es ist auch mit Jira Cloud kompatibel.
  • Lokale KI-Modelle: Modelle wie GPT OSS 20B, Qwen 3.5 oder Gemma 4 werden lokal auf dem Rechner ausgeführt, um Daten zu verarbeiten und zu strukturieren.
  • MCP Server (Multi-Component Proxy Server): Dieser Server fungiert als Bindeglied zwischen der lokalen KI und Jira. Er stellt der KI Werkzeuge zur Verfügung, um mit Jira zu interagieren (z.B. Issues auflisten, suchen, erstellen).
  • Diskussion mit der KI: Die Möglichkeit, mit der KI über Features zu sprechen und diese direkt in Jira anzulegen.
• Vergleich mit Jira-Funktionsumfang: Das Rezept bietet eine Alternative zu den Cloud-basierten KI-Features von Atlassian. Es ermöglicht die Nutzung von KI-Funktionen auch für selbst gehostete Jira-Instanzen und bietet Flexibilität bei der Wahl des KI-Modells.
• Vorteile lokaler KI: Hauptvorteile sind die Aktualität der Modelle (sofortiger Zugriff auf neue Modelle wie Gemma 4) und die Kontrolle über sensible Daten, die die eigene Infrastruktur nicht verlassen müssen.
• Herausforderungen und Anpassungen: Die Einrichtung erfordert manuellen Aufwand, da es sich nicht um ein “Out-of-the-Box”-Feature handelt. Anpassungen sind notwendig, um die KI an Jira-spezifische Formate (z.B. Markup für Beschreibungen, Custom Fields) anzupassen.
• Verantwortung: Die Nutzung der KI unter dem eigenen Benutzerkonto in Jira bedeutet, dass der Nutzer die Verantwortung für die von der KI erstellten Inhalte trägt.
• Ausblick: Zukünftige Erweiterungen könnten die Integration weiterer Informationsquellen wie GitLab oder GitHub umfassen, um Release Notes zu generieren oder Code-Workflows zu unterstützen. Auch die Einbindung von kundenspezifischem Domänenwissen aus Wissensdatenbanken ist denkbar.

Aspekte, die für Entwickler interessant sind

• Lokale KI-Modelle und Hardware-Anforderungen:
  • Es wurden Modelle wie GPT OSS 20B, Qwen 3.5 und Gemma 4 getestet.
  • Wichtig ist, dass das KI-Modell Tools unterstützt, da der MCP Server diese der KI zur Verfügung stellt.
  • Hardware-Anforderungen: KI nutzt die GPU und benötigt viel RAM.
    • Faustformel: Für ein Modell mit “20B” (20 Billionen Parameter) werden etwa 20 GB RAM benötigt. In der Realität kann es etwas weniger sein, abhängig von der Quantisierung des Modells.
    • Getestete Modelle (20B, 35B, 26B) lassen sich mit 64 GB RAM oder sogar 32 GB RAM betreiben, da es sich um übersichtliche Diskussionen und nicht um “Agentic Coding” mit riesigen Kontexten handelt.
    • Empfohlene Hardware: Rechner mit dedizierter GPU mit viel RAM (teuer) oder Hybrid-Infrastrukturen wie Apple MacBooks mit Apple Silicon (CPU und GPU teilen sich RAM) oder AMD Strix Halo Systeme (bis zu 128 GB gemeinsamen Speicher).
• MCP Server als API-Gateway:
  • Der MCP Server (Multi-Component Proxy Server) dient als Schnittstelle zwischen der lokalen KI und Jira.
  • Er stellt der KI Werkzeuge (Tools) zur Verfügung, die Jira-API-Aufrufe kapseln. Beispiele sind Funktionen zum Anlegen von Jira Issues, Suchen nach Issues oder Auflisten von Epics.
  • Die KI kann natürliche Sprache in JQL (Jira Query Language) übersetzen, um komplexe Suchanfragen zu formulieren.
  • Es wurde ein selbst entwickelter MCP Server getestet, aber letztendlich wurde MCP-Atlassian als etablierte und gewartete Lösung gewählt.
• Anpassung der KI an Jira-APIs und Datenstrukturen:
  • System Prompt: Entwickler können den System Prompt in Tools wie LM Studio nutzen, um der KI spezifische Anweisungen zu geben.
    • Beispiel: Anweisung zur Verwendung des Jira-eigenen Markups für Überschriften und Auflistungen anstelle von Markdown, da Jira Markdown nicht optimal darstellt.
    • Beispiel: Definition von Custom Fields in Jira und Anweisung an die KI, diese Felder zu befüllen, wenn genügend Informationen vorhanden sind. Dies erhöht die Trefferquote bei der automatischen Zuweisung von Komponenten oder anderen Metadaten.
• Entwicklungsprozess und Iteration:
  • Die Entwicklung des Setups erfolgte schrittweise, beginnend mit einem selbstgebauten MCP Server.
  • Es gab Herausforderungen bei der Interaktion der KI mit den Jira-Tools (z.B. falsche Parameterübergabe), die die KI jedoch durch “Thinking”-Prozesse selbstständig zu korrigieren versuchte.
  • Die Treffergenauigkeit bei der Befüllung von Custom Fields liegt bei 80–90%, was für viele Support-Szenarien als sehr gut erachtet wird. Bei der Erstellung von Ticketbeschreibungen ist die KI eine große Hilfe, ersetzt aber nicht die Notwendigkeit menschlicher Überprüfung und Ergänzung.
• Zukünftige Integrationen (APIs und Libraries):
  • Erweiterung um weitere Informationsquellen wie GitLab oder GitHub. Dies würde die Nutzung von APIs dieser Plattformen erfordern, um Commits abzurufen oder automatische Release Notes zu erstellen.
  • Einbindung von kundenspezifischem Domänenwissen aus Wissensdatenbanken, um Ticketbeschreibungen anzureichern. Dies würde die Anbindung an entsprechende Wissensmanagement-Systeme über deren APIs bedeuten.

Neue oder ungewöhnliche Phrasen oder Begriffe

• Digital Independence Day (D-Day): Eine Initiative, die dazu aufruft, jeden ersten Sonntag im Monat auf “die gute Seite zu wechseln”, im Kontext der IT bedeutet dies oft, sich mit Open-Source-Lösungen oder datenschutzfreundlichen Alternativen zu beschäftigen.
• MCP Server (Multi-Component Proxy Server): Ein Server, der als Bindeglied zwischen einer KI und verschiedenen Systemen (hier Jira) fungiert, indem er der KI spezifische “Werkzeuge” (API-Aufrufe) zur Verfügung stellt.
• GPT OSS 20B: Ein spezifisches, lokal ausführbares KI-Modell, wobei “20B” für 20 Billionen Parameter steht.
• Qwen 3.5 / Gemma 4: Weitere Beispiele für lokal ausführbare KI-Modelle, die in jüngster Zeit veröffentlicht wurden.
• Agentic Coding: Ein Begriff, der sich auf die Nutzung von KI-Agenten bezieht, die selbstständig Code schreiben oder komplexe Software-Engineering-Aufgaben übernehmen. Im Kontext des Podcasts wird betont, dass das hier diskutierte Setup nicht auf Agentic Coding abzielt, was die Hardware-Anforderungen reduziert.
• Quantisierung des Modells: Ein Prozess, bei dem die Präzision der Parameter eines KI-Modells reduziert wird, um den Speicherbedarf und die Rechenzeit zu verringern, oft auf Kosten einer geringfügigen Genauigkeit.
• LM Studio: Eine Software, die es ermöglicht, lokale KI-Modelle einfach herunterzuladen, zu installieren und zu betreiben.
• JQL (Jira Query Language): Die spezifische Abfragesprache von Jira, die für komplexe Suchen verwendet wird. Die KI kann natürliche Sprache in JQL übersetzen.
• System Prompt: Eine Anweisung oder ein Kontext, der einer KI vor der eigentlichen Anfrage gegeben wird, um ihr Verhalten oder die Formatierung ihrer Antworten zu steuern.