# Local AI Integration for Secure Project Workflows

**Podcast:** INNOQ Podcast
**Published:** 2026-05-01

## Transcript

Herzlich willkommen zu einer neuen Ausgabe des InnoQ Podcasts.
Mein Name ist Jill Breed 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 Nikolas Inden, eingeladen.
Lieber Nikolas, magst du dich einmal kurz vorstellen, was du bei der InnoQ so machst?
Hi Jill, 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.
Hab da auch sehr viel damit zu tun, wo will der Kunde eigentlich hin, was soll genau umgesetzt werden und wie kriegen wir das für uns in verdaubare Häppchen formuliert und umgesetzt, sodass wir dann nachher ein richtig cooles Produkt draus kriegen.
Genau.
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?
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 geht heute?
Was kann ich mit lokaler KI machen?
Wie kann sie mir helfen?
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 so 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 und jetzt über dieses Thema.
um über dieses Thema zu sprechen.
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, da musst du das noch formalisieren, du musst das irgendwie in Jira oder auch in ein anderes Ticketsystem reinkippen.
Und das ist natürlich ganz charmant, wenn man das mit einer KI lösen kann.
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.
Das hat auch 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 hast und mir dann mal 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?
Genau, also die Zutaten richten sich so ein bisschen danach, was habe ich an Tooling?
In diesem Fall ist das Jira.
Und was habe ich an Informationen und wie kriege ich die da rein?
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 refined werden.
Da war halt der Gedanke, wie kriege ich das wunderbar in dieses Jira rein?
Das ist also die Senke, das Jira.
Aber die Informationen, die ich auf der anderen Seite kriege, möchte ich natürlich jetzt ein bisschen strukturieren.
Deshalb Thema KI.
Mein naiver Gedanke war, schmeißen wir doch einfach unsere Slack-Konversationen, unsere Calls, so wie 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, 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 vier, 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.
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 nochmal 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 bzw.
Data Center, also mit einer eigenen Instanz?
Geht es auch mit der Cloud-Instanz?
Also was ist so die Mindestvoraussetzung?
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.
Wenn jemals kein Jira hat, dann brauche ich im Prinzip für diese andere Projektmanagement-Software in Anführungszeichen nur den passenden NCP-Server finden, der die Kommunikation zwischen der KI und dem Projektmanagement herstellt.
Und dann dürfte das auch funktionieren.
Okay.
Ich hatte in meiner Vorbereitung auf die Aufnahme heute auch nochmal recherchiert zum Thema Lizenzen.
Das ist ja immer wieder ein Thema, gerade wenn es um sage ich mal, On-Prem oder auch Cloud-Lösungen geht an der Stelle, dass, wenn ich, das ist jetzt gerade noch richtig im Gedächtnis, glaube ich, seit dem 30.03.26, also diesen Jahres, gibt es keine neuen Lizenzen mehr.
Das heißt jetzt nicht, dass die alten nicht mehr funktionieren, also ich glaube, für das Datacenter, 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.
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.
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.
Okay.
Reden wir nochmal ein bisschen über das lokale KI-Modell.
Also für welches hast du dich denn entschieden?
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.
Und GPT-OSS kann das gut.
kann vor allen Dingen auch gut genug, sag 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 QEN 3.5-Modell oder jetzt vor ein paar Tagen gerade erst rausgekommen, das Gamma 4-Modell.
Das waren tatsächlich auch jetzt meine letzten Experimente, dass ich mal geschaut habe, funktioniert das auch mit Gamma 4?
Und ja, klar, funktioniert auch mit Gamma 4.
Wo 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, auf den man eingeht, wenn man sagt, man möchte keine Cloud-KI benutzen.
Dann brauchst du halt einen Rechner, der gut genug ist, um das lokal machen zu können.
Ja, wenn du das ein bisschen mehr Dampf hast, mach mal konkret, worüber reden wir da?
Also hast du ein paar Zahlen für diejenigen, die sich vielleicht keinen neuen Rechner konfigurieren müssen?
Genau, also grundsätzlich KI benutzt die GPU und braucht sehr, sehr viel RAM.
Das heißt, entweder habe ich einen Rechner mit einer dedizierten GPU, die sehr viel RAM hat.
Das ist aber meistens die sehr, sehr teurere Variante.
Also 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.
Und wenn ich dann in Grafikkarten, in GPUs gehe, die jetzt in der Cloud für KI verwenden, 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.
Und 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 es auch mit bis zu 128 GB gemeinsamen Speicher.
So, 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 viele Parameter dieses Modell gerade benutzt.
GPT-ORS 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 Gigabyte 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 nochmal 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-USS, 35B bei dem QEN 3.5 Modell und 26B beim Gamma 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 nochmal 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 auch auskommen.
Ja, das ist spannend, weil je nachdem, was ich denke, in so Support-Szenarien, wenn du ein 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 Software-Anwendung.
Das ist immer sehr vielschichtig, mehrdimensional.
Ich glaube, dann wird der Kontext auch sehr 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 Gigabyte RAM pro Milliarde Parameter.
Das finde ich 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, was für einen und für seine Szenarien irgendwie gut klappt.
Ein Punkt, den ich gerne mal dich fragen würde, ja, 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?
Aus meiner Sicht der größte Vorteil bei der lokalen Anwendung ist tatsächlich die Aktualität der Modelle.
Wir haben es jetzt gesehen, Google hat Gemma 4 rausgebracht vor ein paar Tagen 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 Quen3Coder Next, wenn ich jetzt mal deutsche Anbieter betrachte, angekommen.
Zumindest noch keinen deutschen Anbieter gesehen, wo ich ein Qen 3.5 habe.
Deshalb ist das definitiv der Vorteil und natürlich das persönliche Empfinden, wo möchte ich gerne meine Daten haben.
Okay, danke einmal für die Einschätzung und Abgrenzung.
Dann lass uns doch mal über die dritte Zutat, das Thema MCP, sprechen.
Genau, der MCP bietet mir ja dann für die KI die Welt meines eigenen Wissens, in diesem Fall Jira.
Und ich habe es eben schon mal ein bisschen angeteasert.
Der MCP-Server sagt bei einer 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.
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, sage ich jetzt mal, 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 es damit automatisch das JQL, kann es reinschmeißen und bekommt die Ergebnisse für mich zurück.
Ja.
Jetzt ist das ja bei den MCP-Servern so, es gibt ja oft nicht nur den einen.
Also für welchen hast du dich nochmal konkret entschieden und was waren ein bisschen deine Kriterien?
Also woran hast du es festgemacht, dass das die beste Lösung ist?
Okay, also ich habe zwei verschiedene probiert.
Angefangen hat es tatsächlich mit einem Selbstgeweibten, wo ich einfach mal losgerannt bin und dachte mir, das kann doch so schwer nicht sein.
Und tatsächlich war das auch innerhalb von ein paar Stunden getan, dass ich einen MCP-Sawa 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 du möchtest 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 minus Atlassian als MCP-Server.
Link gibt es auch unten in den Shownotes nachher sicher.
Der ist maintained, der ist etabliert, funktioniert und die Wahl, die wir jetzt letztlich getroffen haben.
Okay.
Ja, sehr gut.
Guter Hinweis.
Sowohl D-Day als auch den Server und die anderen Sachen werden wir natürlich in den Shownotes verlinken.
Genau.
Lass uns ein bisschen mal über die technische Einrichtung sprechen.
Also vielleicht kannst du das nochmal ein bisschen so Schritt für Schritt durchgehen.
Was war notwendig?
Was hat gut geklappt?
Was hat nicht funktioniert?
War es ein bisschen gehakt?
Hat es überhaupt irgendwo gehakt?
Oder lief das smooth durch?
Klar, man tastet sich da immer so ein Stückchen voran.
Erstmal möchte man das natürlich lokal probieren.
Dann muss man 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.
Als ich es ausprobiert habe, es waren ein paar Tage.
vor dem Datum, wo AdLashin gesagt hat, so ab jetzt gibt es 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.
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 Tool-Aufrufe 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 nochmal.
Aber die wurstelt sich so dann ihren Weg dadurch.
Und dann hat es tatsächlich in den meisten Fällen nachher funktioniert und am Ende eigentlich immer.
Ich sage 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, 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 Systemprompt reinschreiben.
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 das System prompt rein.
Es gibt diese und jene Custom-Fields, die möchte ich gerne, wenn du genug Informationen hast, schon ausgefüllt haben.
Ja.
Also ein bisschen machst du Vorgaben oder gibst Beispiele, Templates mit, damit das Format oder die Erwartungshaltung da bestmöglich getroffen wird bei dem Ergebnis, was rauskommt nachher.
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 erlegen, das ist alles von Nico, was da so zusammengefasst und einformuliert worden ist?
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.
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 sage mal in Anführungszeichen, nur eine systembedingte Sache, weil ich halt dem MCP-Server nachher meinen 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.
Ja, das ist ein guter Punkt.
Also ich bin da völlig bei dir.
Wenn ich das nutze und so verwende, dann übernehme ich damit auch die Verantwortung.
Da muss ich ja natürlich für mich auch ein bisschen nachher abwägen, wie umfangreich nutze ich das oder wie sehr lasse ich es auch einfach vielleicht an der Stelle frei laufen.
Ich würde gerne nochmal ein bisschen...
nochmal da, gerade für diejenigen, die zuhören und jetzt vielleicht auch die Lust bekommen, das selber mal auszuprobieren, aufzusetzen, nochmal ein bisschen drüber sprechen.
Kannst du nochmal kurz zusammenfassen?
Worauf muss man achten?
Was lief nicht so ein bisschen out of the box?
Weil bei Atlassian, vielleicht um das nochmal irgendwie, warum ich da so nachbohre, das nochmal ein bisschen herauszustellen, das sind ja oft, gerade die SaaS- oder Cloud-Anbieter kommen ja mit der out of the box-Lösung.
Ich schalte Feature an, es funktioniert sofort, es ist alles integriert.
Ich tausche hier vielleicht auch oft Komfort ein gegen Individualität oder gegen meinen, vielleicht will ich nicht sagen Anspruch, aber manchmal das Szenario, das ich eigentlich erfüllen möchte.
Worauf muss man da nochmal achten?
Also was hat vielleicht nicht so out of the box funktioniert?
Wo wird es ein bisschen frickelig?
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 Webinterface anmache und es ist da, sondern ich stecke jede Komponente einzeln zusammen.
Und ich muss auch, wenn ich ein neues Modell zum Beispiel teste, mal nochmal gucken, wie verhält sich das jetzt.
So eine KI ist nun mal nicht deterministisch und von Modell zu Modell ist es eh nochmal unterschiedlich.
Ich kann hier und da auch einfach schon mal ein unerwartetes Ergebnis haben.
Das heißt, du musst 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.
Und so Dinge wie ich meine Custom-Fields...
Konkretes Beispiel, wir haben jetzt eine Web-Anwendung und die besteht aus verschiedenen Komponenten und mein Gedanke war ja gut, 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 mir dieses Feld befüllen.
Ja, das funktioniert tatsächlich gut.
Ich würde mal so sagen, in 80, 90 Prozent der Fälle ist das richtig, was dabei rauskommt.
Die KI guckt sich dann an, welche Komponenten hat dieses Jira-Projekt zur Verfügung und was würde da dazu passen.
Jetzt kann man natürlich hingehen und da 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 dann nochmal 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.
Ja, du hast gerade das Stichwort Determinismus angesprochen und das finde ich gerade, also ich fand das ganz zu Anfang, sag ich mal, dieser Diskussion über Determinismus auch in der Softwareentwicklung unter Einsatz von KI.
Ich fand das immer spannend, dass ich da eine etwas andere Sicht drauf hatte, geprägt durch lange Zeit, die ich im Serviceumfeld verbracht habe, also im IT-Service-Management.
Weil, was hast du eben gesagt, ich glaube 80, 90 Prozent Treffergenauigkeit.
Wenn jemand schon mal mit einem Support interagiert hat und Problemstellungen hat, die, sag ich mal, über vielleicht das Zurücksetzen eines Passworts ein Stück weit hinausgeht.
glaube ich, dass die Freude über eine 80-90%ige 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 einfach zu tun habe, auch da eine gewisse Fehlertoleranz in der Regel erwarte und erwarten kann.
Und deswegen finde ich das bei 80-90% schon echt gut.
An manchen Stellen.
Würde ich gerne mal kurz einhaken.
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 schwer tun, jetzt zu sagen, das ist zu 80, 90 Prozent richtig.
Ich würde auch jetzt nicht sagen, dass es irgendwie zu 20 Prozent 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.
Also 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 nochmal ran.
Das muss man immer im Hinterkopf haben.
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.
Absolut.
Wenn ich nur drei Stichworte mitgebe.
Ich nehme gerne mal das Beispiel mit dem Thema Performance.
Das kann alles Mögliche immer 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 es mehr zusammenstecken muss.
Kannst du dich noch daran erinnern?
Also wie viel Aufwand hattest du so bei der Einrichtung?
Wie lange hat das gebraucht für dich, das Setup, was du eben beschrieben hast, so lauffähig zu bekommen?
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, nochmal 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 auch eine Zeit, die immer Spaß gemacht hat, muss ich ganz ehrlich sagen.
Ja, das glaube ich, das merkt man dir auch an.
Aber es ist ein guter Hinweis, dafür ist ja der Artikel da, 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 im anderen Kontext zu sehen, was eigentlich schon möglich ist.
Wo sind ein bisschen die Grenzen und was funktioniert schon und was kann ich auch so in mein Daily Business überführen.
Lassen Sie mal den 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?
Also was kommt jetzt neben Jira?
Genau, also das Ganze wird natürlich reicher, wenn ich mir Informationsquellen anbiete.
Typischerweise habe ich in so einem Entwicklersetup 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.
Das könnte man alles zusammenbringen.
Das kann man lokal an dieser Stelle mit einem weiteren NCP-Server reinholen.
Man könnte sich die Commits holen.
Man kann automatisch Release-Nodes 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.
Ja.
Hast du schon ein konkretes Modell im Blick, was du als nächstes Mal ausprobieren willst?
Ja, wie gesagt, im Moment ist es Gamma 4, was ich teste, was vor ein paar Tagen rausgekommen ist.
Ich werde euch da auf dem Laufenden halten.
Okay, sehr gut.
Wunderbar.
Ja, im Endeffekt zu jeder Podcast-Aufnahme gehört 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.
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.
Ich glaube, das Rezept ist schon...
Kann man auch gut verallgemeinern für andere Dinge.
Absolut, ja.
Nochmal so ein bisschen vielleicht zum Abschluss.
Nimm dir mal gerne kurz einen Moment, wenn du es nochmal machen würdest, gibt es was, was du anders machen würdest?
Außer vielleicht den Teil mit dem Vibe-Coding des MCP-Services, das habe ich jetzt so ein bisschen rausgehört.
Gibt es nochmal was, wo du sagst, da hätte ich vielleicht irgendwas nochmal irgendwie anders gemacht?
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?
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?
kundenspezifisch oder projektspezifisches Domänenwissen in meine KI rein.
Und das wäre auch ein Weg, wo ich noch hindenken würde, dass es 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.
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 Independence Digital.
Mein Gott.
jetzt habe ich mich versprochen, 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 auch gerne mal beim D-Day auf der Webseite vorbei.
Die ganzen Links zum Rezept von Nico, zum D-Day, zu der Initiative werden wir in den Shownotes verlinken.
Und ja, Dann danke ich dir nochmal, Nico, für deine Zeit.
Danke dir.
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.
Bis dann.
Ciao.
Ciao.