Steigende Lizenzkosten, zunehmender Cloud-Zwang und das Gefühl, für ein Werkzeug immer mehr Bedingungen akzeptieren zu müssen, die nicht zu meinen Vorstellungen passten: Der Wunsch nach digitaler Souveränität war der eigentliche Auslöser für dieses Projekt. Statt mich nur darüber zu ärgern, wollte ich es wissen: Wie schwer kann es eigentlich sein, ein modernes Ticketsystem selbst zu entwickeln?
Mir war von Anfang an klar, dass dies kein bloßes Wochenendprojekt sein würde. Trotzdem hatte ein Ticketsystem die richtige Größe: komplex genug, um technische und organisatorische Fragen zu provozieren, aber präzise genug, um mit einem definierten MVP (Minimum Viable Product) zu beginnen und Schritt für Schritt zu wachsen.
Den Namen Lutions bekam das Projekt ohne große Geschichte. Mir fiel schlicht nichts Besseres ein; es war der pragmatische Arbeitstitel für ein MVP, das zunächst einfach funktionieren sollte.
Im Laufe der Zeit hat sich der Fokus verschoben. Lutions ist heute nicht mehr nur das Werkzeug, das ich ursprünglich bauen wollte. Es ist mein Arbeitskontext für Experimente mit agentenbasierter Softwareentwicklung, Knowledge Layern, Review-Governance und der Frage, wie Mensch und KI-Agent an einem realen Codebestand zusammenarbeiten können. Das Ticketsystem war der Anfang, aber nicht die Pointe.
Was Lutions heute ist
Lutions ist heute eine webbasierte Anwendung für Projekt- und Ticketprozesse. Dazu gehören Projekte, Vorgänge, Workflows, Rechte, UI-Standards, API-Integrationen, Release-Abläufe, Audits und eine gewachsene Dokumentationshistorie. Das klingt zunächst nach klassischer Verwaltungssoftware. Für meine Experimente ist aber genau diese Nüchternheit hilfreich.
Lutions ist längst kein Spielzeugprojekt mehr. Es hat gewachsene Konventionen, Altentscheidungen, UI-Regeln, Sicherheitsgrenzen und Prozessdokumentation. Wer daran arbeitet, muss mehr tun, als eine einzelne Datei zu ändern. Ein Agent muss verstehen, warum bestimmte Dinge so gebaut sind, welche Regeln gelten und welche Änderung an anderer Stelle wieder Fragen auslöst.
Genau dadurch wurde das Ticketsystem im Rückblick zu einem idealen Erfahrungsraum für Agentic AI. Der KI-Agent arbeitet nicht nur an Lutions, sondern auch mit und in Lutions: Anforderungen werden formuliert, als Tickets angelegt, Arbeitsschritte dokumentiert, Reviews festgehalten und Prozessentscheidungen nachvollziehbar gemacht.
Dazu kommt eine Umgebung, die nah genug an echter Softwareentwicklung liegt: lokale Entwicklungsumgebung, Testsystem mit gespiegelten Daten und produktive Instanz. Neue Entwicklungen entstehen lokal, werden zuerst im Testsystem gegen realistische Daten geprüft und landen erst danach in der produktiven Instanz, in der jede Anforderung wiederum als Ticket angelegt und bearbeitet wird.
Für mich liegt das Projekt damit in einer passenden Zwischenzone. Kleine Demo-Projekte sind oft zu glatt, große Produktionssysteme zu schwerfällig oder zu riskant. Lutions ist komplex genug, um echte Probleme sichtbar zu machen, aber noch nah genug an meinem eigenen Arbeitskontext, um daraus ohne große Abstimmungsmaschinerie lernen zu können.
Vom Ticketsystem zum Entwicklungsprozess
Aus gelegentlicher Codeunterstützung wurde nach und nach die Frage, wie ein Entwicklungsprozess aussehen muss, wenn ein KI-Agent regelmäßig an einem gewachsenen System mitarbeitet.
Damit rückten Fragen in den Vordergrund, die ein einfaches Ticket-MVP noch gar nicht beantworten musste:
- Anforderungsqualität: Wie formuliert man Vorgaben so, dass ein Agent fachlich präzise statt nur syntaktisch korrekt arbeitet?
- Wissensmanagement: Wie verhindern wir, dass architektonisches Wissen, Sicherheitskonventionen oder Produktgrenzen im Chatverlauf verloren gehen?
- Governance und Review: Wann hilft menschliche Kontrolle, wann bremst sie, und wann braucht es zusätzliche Rollen wie Reviewer-Agenten, Testagenten oder manuelle Checks?
An diesem Punkt wurde Lutions für mich vom Ticketsystem zum Entwicklungsprozess. Die Anwendung macht sichtbar, wo die Zusammenarbeit zwischen Mensch und KI-Agent noch unklar, brüchig oder erstaunlich produktiv ist.
Der Stand vom 24. Juli 2026 ist dafür ein brauchbarer, historischer Blick auf die Projektspur: 1.049 Tickets im Produkt-Kontext (LUMVP), 34 Tickets für den Aufbau des MCP-Servers (LUMCP), 173 Tickets für die bis dahin erstellten Releases (LTNRLS) und 170 Tickets für den Aufbau des KI-basierten Entwicklungsprozesses (AIDEV). Diese Zahlen sind keine Erfolgsmetrik. Sie zeigen nur, dass hier über längere Zeit ein Arbeitszusammenhang entstanden ist, in dem Anforderungen, Umsetzung, Test, Review und Prozesslernen gemeinsam dokumentiert wurden.
Warum dieser Kontext für Agentic AI interessant ist
Auch in der Forschung zu Software-Engineering-Agenten verschiebt sich der Blick weg von reiner Codegenerierung. SWE-bench nutzt reale GitHub-Issues und Pull Requests, um zu prüfen, ob Sprachmodelle Aufgaben in gewachsenen Codebasen lösen können (Jimenez et al., 2023). SWE-agent argumentiert, dass Sprachmodell-Agenten eigene Arbeitsoberflächen und Rückmeldeschleifen brauchen, um Repositories zu navigieren, Dateien zu bearbeiten und Tests auszuführen (Yang et al., 2024). Neuere Einordnungen aus der Software-Engineering-Forschung betonen außerdem, dass Agentic AI Requirements, Architektur, Tests, Wartung, Vertrauen und die Klärung von Entwicklerabsichten berührt (Roychoudhury, 2025).
Lutions ist natürlich kein Benchmark und keine wissenschaftliche Studie. Für mich berührt es aber dieselbe Grundfrage aus der Praxis heraus: Was passiert, wenn Agenten in einem System arbeiten, das Konventionen, Historie, Risiken, Testdaten, produktive Abläufe und soziale Abstimmung mitbringt?
Gerade diese Alltäglichkeit macht den Kontext interessant. Ein Agent muss hier nicht nur eine elegante Lösung finden. Er muss auch erkennen, welche Lösung in dieses Projekt passt, welche Nachweise nötig sind und wann ein scheinbar kleiner Schritt Folgen im Prozess hat.
Was dieser Kontext nicht ist
Lutions ist aktuell weder als öffentliches Open-Source-Projekt noch als kommerzielles Produkt konzipiert. Es ist primär mein privates Entwicklungslabor. Auch als universelle Blaupause für andere Organisationen ist es nicht gedacht. Ein eigenes Ticketsystem zu bauen, muss angesichts von Wartungsaufwand, Sicherheitsfragen und langfristiger Pflege sehr nüchtern abgewogen werden.
Der Wert des Projekts liegt für mich nicht darin, dass andere diesen Weg nachbauen sollten. Er liegt darin, dass Lutions einen konkreten Rahmen schafft, in dem agentenbasierte Entwicklung unter realistischen Bedingungen beobachtbar wird.
Für mich liegt der übertragbare Teil deshalb nicht im Ticketsystem selbst, sondern im Kontext: Agenten arbeiten hier mit gewachsenen Regeln und überprüfbaren Konsequenzen. In meinem Fall erfüllt Lutions genau diese Rolle.
Was daraus langfristig entsteht, ist offen. Im Moment geht es vor allem um den Experimentierbetrieb: Anforderungen besser stellen, Wissen zugänglicher machen, Reviews ernst nehmen, Tests gezielter auswählen und herausfinden, welche Aufgaben ein Agent sinnvoll übernehmen kann.
Warum ich darüber schreibe
Die Diskussionen um Agentic AI sind oft laut. Agenten, MCP, Autonomie, Tool-Use und Governance werden schnell zu großen Begriffen. Mich interessiert eher, wie sich das im Arbeitsalltag anfühlt, wenn Anforderungen unvollständig sind, bestehende Regeln beachtet werden müssen und ein Ergebnis am Ende wirklich geprüft werden soll.
Lutions gibt meinen Beobachtungen einen Ort. In den vergangenen Monaten ist viel Energie in Tickets, Prozessänderungen, LLM-Wiki-Arbeit und das Zusammenspiel zwischen Mensch und KI-Agent geflossen. Ich schreibe darüber, um diesen Arbeitsstrang sichtbar zu machen: nicht als allgemeingültige Methode, sondern als Reihe belastbarer Einzelfälle, aus denen sich Muster ableiten lassen.
Wichtig ist mir dabei auch zu sehen, wie sich der Entwicklungsprozess im Arbeitskontext Schritt für Schritt verbessert. Nicht durch einen großen Entwurf, der plötzlich alles richtig macht, sondern durch viele kleine Korrekturen: bessere Anforderungen, klarere Prüfungen, passendere Rollen, weniger Reibungsverlust. Jedes dieser Details macht den Prozess ein kleines Stück verlässlicher.
Wenn ich künftig über Requirements-Grilling, Knowledge Layer, Ticket-Workflows, Review-Rollen oder Release-Governance schreibe, ist Lutions der gemeinsame Hintergrund. Nicht, weil dieses Projekt die eine richtige Antwort enthält, sondern weil es genug Widerstand bietet, um die praktischen Fragen nicht zu überspringen.
Agentic AI wird für mich dort praktisch, wo sie Teil eines Entwicklungsprozesses wird, der Anforderungen, Kontext, Tests, Reviews und Grenzen ernst nimmt.
Lutions ist mein Versuch, diesen Prozess sichtbar zu machen.
Datenbasis und Einordnung
Die Einblicke in diesem Beitrag stützen sich auf den laufenden Entwicklungs- und Dokumentationsprozess von Lutions: Tickets, Architekturentscheidungen, interne Notizen, Audits und Projekthistorie. Die quantitativen Angaben stammen aus der Lutions-Ticketliste und wurden am 24. Juli 2026 abgerufen. Sie bleiben in diesem Text bewusst auf diesem historischen Stand.
Dieser Text ist ein persönlicher Erfahrungsbericht aus der Praxis, keine offizielle Produktdokumentation, keine Roadmap und keine allgemeine Empfehlung zum Bau eigener Projektmanagementsoftware. Er soll den Kontext liefern, auf den ich mich in kommenden Beiträgen beziehen kann.
Quellenverzeichnis
- Jimenez et al. (2023): SWE-bench: Can Language Models Resolve Real-World GitHub Issues?
- Yang et al. (2024): SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering
- Roychoudhury (2025): Agentic AI for Software: thoughts from Software Engineering community