Vom Jira-Ticket bis zur Code-Review: So arbeitet EIKONA mit KI
KI formuliert Texte, gestaltet Bilder, schreibt Programme, wertet Daten aus und unterstützt längst die Arbeit in den unterschiedlichsten Berufen. Doch wie arbeiten eigentlich diejenigen mit KI, die Software selbst entwickeln? Wie viel überlassen sie den Modellen, und an welchen Stellen bleibt der Mensch gefragt?
Bei EIKONA Logistics ist KI kein zusätzliches Werkzeug, das Entwickler nur gelegentlich zurate ziehen. Sie ist in den gesamten Entwicklungsprozess eingebunden: von der Planung eines Projekts über die Analyse eines Jira-Tickets und die Programmierung bis zum Code-Review. Dabei arbeiten spezialisierte Agents, unterschiedliche Modelle und Menschen in mehreren Prüf- und Feedbackschleifen zusammen. Der Mensch gibt die Verantwortung dabei keinesfalls ab. Seine Rolle im Entwicklungsprozess verändert sich jedoch kontinuierlich.
Vom Kundengespräch bis zum Merge: So verändert KI den Workflow
Der Einsatz von KI beginnt nicht erst beim Programmieren. Damit Agents sinnvoll arbeiten können, müssen Anforderungen frühzeitig klar beschrieben und Entscheidungen nachvollziehbar festgehalten werden. Der aktuelle Workflow lässt sich grob in fünf Stationen gliedern:
-
Anforderungen präzisieren
Am Anfang steht weiterhin die Anforderung des Kunden, die vom Projektmanagement aufgenommen wird. Die dazugehörigen Tickets müssen möglichst konkret formuliert sein: Die Geschwindigkeit und die Zahl der Themen, die Entwickler parallel bearbeiten, haben sich durch den Einsatz von KI signifikant erhöht. Fehlende Angaben, Nachfragen zu Details und noch nicht getroffene Entscheidungen bremsen den Prozess aus. KI unterstützt deshalb schon früh im Projekt, indem sie offene Punkte oder unklare Angaben sichtbar macht. -
Ticket analysieren und Lösung planen
Der Entwickler beauftragt die KI damit, in Jira nach einem Ticket zu suchen. Sie ruft die Aufgabe ab, analysiert die vorhandenen Informationen und weist auf offene Fragen hin. Anschließend entwickelt sie auf dieser Grundlage einen Lösungsplan. Bevor die Umsetzung beginnt, prüft der Entwickler diesen Plan und gibt die weitere Arbeit frei. -
Mehrere Agents bearbeiten eine Aufgabe
Für verschiedene Themenbereiche gibt es spezialisierte Agents, unter anderem für Architektur, Planung, Programmierung und Prüfung. Je nach Aufgabe können dabei unterschiedliche Modelle zum Einsatz kommen. Ein Orchestrator-Agent koordiniert die Zusammenarbeit im Hintergrund. So kann ein Entwickler mehrere Agent-basierte Aufgaben parallel betreuen – ein deutlicher Unterschied zum Prä-KI-Ablauf, bei dem er sich meist nacheinander durch einzelne Tickets gearbeitet hat. -
Prüfen, korrigieren, erneut prüfen
Der entstandene Code wird nicht einfach übernommen. Vor einem Merge prüft ihn eine separat eingesetzte KI, die auf Code-Reviews spezialisiert ist. Ihre Hinweise gehen zurück an die beteiligten Agents, die diese bewerten und bei Bedarf Änderungen vornehmen. Danach startet das Review erneut. Diese Schleife wiederholt sich so oft, bis keine relevanten Kritikpunkte mehr offen sind. -
Der Mensch entscheidet
Am Ende bleibt eine klare Grenze: Den Merge in die gemeinsame Codebasis übernimmt ein Mensch. Auch Deployments darf die KI bei EIKONA nicht selbstständig auslösen, obwohl das technisch möglich wäre. Diese Leitplanke gibt es bewusst: Der Mensch entscheidet, wann eine Änderung übernommen und für die nächsten Projektstufen beziehungsweise für ein Deployment bereitgestellt wird. Der Entwickler bleibt schließlich dafür verantwortlich, dass der Code sicher ist, funktioniert und den Qualitätsanforderungen entspricht.
Je mehr Arbeit KI im Prozess übernimmt, desto wichtiger werden damit klare Angaben am Anfang. KI kann einzelne Arbeitsschritte beschleunigen, fehlende Entscheidungen oder unvollständige Anforderungen aber nicht einfach ausgleichen.
Output- vs. Outcome-orientiertes Prompting: Ziel und Kontext statt kleinteiliger Vorgaben
Mit den aktuellen KI-Modellen hat sich auch die Art verändert, wie Entwickler mit ihnen zusammenarbeiten. Statt detailliert vorzugeben, wie eine Aufgabe technisch umzusetzen ist (Output-orientiert), beschreiben Entwickler heute vor allem das gewünschte Ziel (Outcome-orientiert). Die KI erhält dadurch mehr Freiraum bei der Umsetzung. Welche technischen Schritte sie dafür wählt, entscheidet sie weitgehend selbst.
Damit das funktioniert, benötigt sie jedoch deutlich mehr Hintergrundwissen. Eine über Jahre gewachsene Software umfasst Millionen Zeilen Code, zahlreiche Module und komplexe Abhängigkeiten. Selbst aktuelle Top-Modelle tun sich damit schwer, die gesamte Codebasis zu überblicken. Vor allem fehlt ihnen die Historie: Was wurde bereits ausprobiert? Warum wurde etwas auf eine bestimmte Weise gebaut? Was muss bei einem bestimmten Kunden beachtet werden? Manches Wissen steht nicht vollständig im Code oder in einer Dokumentation, sondern steckt in den Köpfen der Entwickler.
Um dieses Wissen digital verfügbar zu machen, hat EIKONA eigene Werkzeuge gebaut und Skills sowie Anweisungen für die KI definiert. Statische Informationen wie Coding Guidelines, Syntaxvorgaben oder Architekturentscheidungen werden direkt in den Repositories hinterlegt. Änderungen am Code und projektbezogenes Wissen werden zusätzlich in einer zentral im eigenen Rechenzentrum betriebenen Vektordatenbank gespeichert und stehen der KI bei späteren Entwicklungsaufgaben wieder zur Verfügung.
Wenn die KI Code verändert, gehört auch die Dokumentation zum Prozess. Sie beschreibt, was geändert wurde, und referenziert die betroffenen Stellen, etwa Methoden oder Klassen. Diese Informationen werden automatisiert in die Vektordatenbank übernommen. Auch die Dokumentation eines Commits erstellt grundsätzlich die KI. Anschließend prüft ein Mensch, ob die Angaben stimmen.
Das reduziert nicht nur die Menge an Kontext, die Entwickler bei jeder Aufgabe neu mitgeben müssen. Die KI kann gezielter nach vorhandenem Wissen suchen, statt große Mengen an Code und Informationen jedes Mal neu zu verarbeiten, und spart so Tokens.
Eigenes Hosting von KI-Modellen? Die Kombination macht’s.
Vor allem für anspruchsvolle Programmieraufgaben braucht es die leistungsfähigsten externen Modelle. EIKONA betreibt jedoch auch eigene Modelle in ihrem Rechenzentrum. Diese kommen gezielt dort infrage, wo Datenschutz eine besonders große Rolle spielt und die komplette Kontrolle über die Serverumgebung erforderlich macht.
Gleichzeitig ist selbst gehostete KI durch die vorhandene Hardware begrenzt und muss entsprechend langfristig geplant werden. EIKONA verfolgt deshalb keinen Entweder-oder-Ansatz, sondern nutzt je nach Aufgabe unterschiedliche Modelle und Betriebsformen.
Wer entscheidet, welche Tools genutzt werden?
EIKONA hat eine AI-Taskforce aufgebaut, die sich mit sämtlichen Neuerungen der KI-Welt beschäftigt. In ihr arbeiten bewusst Menschen mit unterschiedlichen Erfahrungen und Einstellungen zu KI zusammen – von eher skeptisch bis sehr experimentierfreudig.
Dabei gilt: Neue Werkzeuge dürfen nicht einfach eingesetzt werden, nur weil sie technisch interessant sind. Die Entscheidung darüber läuft derzeit bei Sebastian Kremer, Head of Development & Operations, zusammen. Vor einer produktiven Nutzung werden unter anderem rechtliche Fragen, Datenschutz, Datenstandort, Provider und eingesetzte Modelle betrachtet.
Dabei setzt das Unternehmen bewusst auf Flexibilität. Jahres-Subscriptions für KI-Werkzeuge werden derzeit vermieden, weil sich Angebote, Modelle und Schnittstellen innerhalb weniger Monate stark verändern können. Ein Werkzeug, das heute gut funktioniert, kann nach einem Update anders arbeiten oder ein bevorzugtes Modell wird vom Anbieter zurückgezogen.
Neue Technologien, neue Prozesse: Gute KI-Entwicklung beginnt nicht beim Code
Die Veränderung, die KI in der Softwareentwicklung mit sich bringt, reicht weit über das Schreiben von Code hinaus. Entscheidend ist nicht nur, was ein Modell technisch leisten kann, sondern wie gut der Entwicklungsprozess darum herum funktioniert. KI braucht den passenden Kontext, Zugriff auf vorhandenes Wissen und klare Regeln dafür, welche Aufgaben sie übernimmt.
Deshalb gibt es bewusst gesetzte Grenzen. Deployments werden nicht autonom von der KI ausgelöst, der Entwickler entscheidet über den Merge und bleibt letztlich für den Code verantwortlich. Auch vorausschauendes Denken liegt dem Menschen am stärksten: Welche Anforderungen werden später wichtig? Welche Architekturentscheidungen dürfen nicht verbaut werden? Dieses Wissen und diese Verantwortung lassen sich nicht einfach an ein Modell abgeben.
Der aktuelle Entwicklungsprozess ist deshalb kein endgültiges Zielbild. Modelle, Tools und Arbeitsweisen verändern sich dafür viel zu schnell. Entscheidend ist für uns, den eigenen Prozess so flexibel zu halten, dass wir neue Möglichkeiten jederzeit ausprobieren und integrieren können. Kontrolle, Wissen und Verantwortung geben wir dabei nicht aus der Hand.
