Steigende Lizenzkosten, zunehmender Cloud-Zwang und das Gefühl, für ein Werkzeug immer mehr Bedingungen akzeptieren zu müssen, die nicht zu meinen Ansprüchen passen: 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. Dennoch bot die Wahl eines Ticketsystems die ideale Balance: Es war komplex genug, um tiefgreifende technische und organisatorische Fragen zu provozieren, aber gleichzeitig präzise genug, um es als definiertes MVP (Minimum Viable Product) zu starten und organisch, Schritt für Schritt, wachsen zu lassen.
Den Namen Lutions bekam das Projekt ohne große Geschichte: Mir fiel schlicht nichts Besseres ein, und da ein Name her musste, blieb es dabei. Warum es ausgerechnet dieser wurde, kann ich heute gar nicht mehr sagen – es war einfach der pragmatische Arbeitstitel für ein MVP, das eigentlich nur funktionieren sollte.
Im Laufe der Zeit hat sich der Fokus von Lutions deutlich verschoben: Was als reines Ticketsystem begann, ist für mich mittlerweile zum zentralen Arbeitskontext geworden. Das System ist somit weit mehr als nur das Werkzeug, das ich ursprünglich bauen wollte – es ist heute mein Ankerpunkt für die Experimente, über die ich in den nächsten Beiträgen schreiben werde. Das Ticketsystem war also der Anfang – aber keineswegs die Pointe.
Was Lutions heute ist
Wie funktioniert agentenbasierte Softwareentwicklung, wenn sie nicht nur aus Demos, Prompts und isolierten Beispielen besteht? Diese Frage ist der Kern von Lutions.
Lutions ist keine bloße Auflistung von Funktionen, sondern eine webbasierte Anwendung, die durch die Abbildung klassischer Projekt- und Ticketprozesse – von komplexen Workflows und Rechtesystemen bis hin zu API-Integrationen und Sicherheitsanforderungen – organisch herangereift ist. Es ist längst kein Spielzeugprojekt mehr. Mit einer gewachsenen Architektur, UI-Standards und einer tiefen Dokumentationshistorie bietet es genau die ‚innere Reibung‘, die für echte Entwicklungsentscheidungen nötig ist.
Genau diese Komplexität macht Lutions als Erfahrungsraum wertvoll. Agentic AI entfaltet ihr Potenzial nicht in vorab geglätteten Vorführungen. Spannend wird es dort, wo ein System Kontext verlangt: Ein Agent muss hier bestehende Konventionen interpretieren, Anforderungen gegen Risiken abwägen, Test-Szenarien orchestrieren und Wissen konsistent halten.
Im Rückblick erweist sich der ursprüngliche Ticket-System-Ansatz als idealer Glücksgriff: Das Projekt ist für den KI-Agenten nicht bloß Ziel der Entwicklung, sondern gleichzeitig Werkzeug, Testumgebung und Protokollfläche.
Vom Ticketsystem zum Entwicklungsprozess
Am Anfang stand die simple Frage: Kann ich ein Ticketsystem bauen, das meine Anforderungen erfüllt und mir die volle Kontrolle lässt? Heute hat sich der Fokus deutlich verschoben: Die zentrale Frage ist nicht mehr das „Ob“, sondern das „Wie“ der Zusammenarbeit – wie muss ein Entwicklungsprozess aussehen, damit Mensch und KI-Agent zuverlässig an einem gewachsenen System arbeiten können?
Dieser Wandel ergab sich organisch. Als die Agenten begannen, nicht mehr nur punktuell Code zu erzeugen, sondern als aktive Akteure im Repository zu agieren – vom Anlegen von Tickets bis zur Anbindung von MCP-Servern –, änderte sich der Charakter des Projekts. Lutions wurde zum Testlabor für zentrale Fragen der Agentic AI:
- Anforderungsqualität: Wie formuliert man Vorgaben, damit ein Agent fachlich präzise statt nur syntaktisch korrekt agiert?
- Wissensmanagement: Wie verhindern wir, dass architektonisches Wissen oder Sicherheitskonventionen im Chatverlauf verloren gehen?
- Governance & Review: Ab wann wird menschliche Kontrolle zur Bremse, und wann ist sie als „Reviewer-Agent“ oder manueller Check zwingend notwendig?
Lutions dient mir heute als Live-Experiment unter realistischen Bedingungen – inklusive Requirements-Klärung, Knowledge-Layer und Release-Governance. Dass mein Verständnis für diesen Prozess kein bloßes Theoriegebäude ist, zeigen die Zahlen: Die 1.049 Tickets im Produkt-Kontext (LUMVP) und 170 Tickets im Prozess-Kontext (AIDEV) sind keine Erfolgsmetrik, sondern ein direktes Protokoll dieses Lernprozesses. Das Projekt ist bewusst gewachsen, oft unbequem und durch reale Prozessfragen geformt – genau das macht es zu einer ehrlicheren Datenbasis für Erfahrungsberichte als jedes künstliche Demo-Repository.
Was dieser Kontext nicht ist
Um eines vorwegzunehmen: 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 – im Gegenteil: Ein eigenes Ticketsystem zu bauen, will angesichts von Wartungsaufwand und Sicherheitsanforderungen sehr nüchtern abgewogen sein. Was sich daraus in Zukunft entwickeln könnte, ist heute noch nicht absehbar; für den Moment liegt der Fokus jedoch voll auf dem ‚Experimentierbetrieb‘.
Diesen Aufwand nehme ich bewusst in Kauf, da Lutions die ideale „Goldlöckchen-Zone“ für meine Experimente bietet. Kleine Demo-Projekte verzeihen zu viele Fehler, große Produktionssysteme sind zu starr für radikale Versuche. Lutions liegt genau dazwischen: komplex genug, um echte Probleme zu erzeugen, aber kontrollierbar genug, um als Labor für Agentic AI zu dienen.
Warum ich darüber schreibe
Die Diskussionen um Agentic AI sind oft hochtrabend: Agenten, MCP, Autonomie und Governance – die Theorie ist laut, doch der konkrete Arbeitsalltag bleibt meist unscharf.
Lutions gibt meinen Beobachtungen einen Ort. In den vergangenen Monaten ist viel Energie in Tickets, Prozessänderungen und das mühsame Zusammenspiel zwischen Mensch und KI-Agent geflossen. Ich schreibe über Lutions, um genau diesen Arbeitsstrang – abseits der abstrakten Demos – transparent zu machen. Wenn ich über Requirements-Grilling, Knowledge-Layer oder Ticket-Workflows schreibe, dann nicht als akademisches Dogma, sondern als belastbare Einzelfälle, aus denen wir Muster ableiten können.
Dass dieser praktische Kontext relevant ist, zeigt auch die Forschung rund um Software-Engineering-Agenten. Der Benchmark SWE-bench nutzt reale GitHub-Issues als Prüfstein für KI-Systeme in gewachsenen Codebasen (Jimenez et al., 2024). SWE-agent argumentiert, dass KI-Agenten eigene Arbeitsoberflächen und Rückmeldeschleifen brauchen, um Softwareentwicklungsaufgaben zuverlässig auszuführen (Yang et al., 2024). Und neuere Einordnungen aus der Software-Engineering-Forschung betonen, dass Agentic AI nicht bei Codegenerierung endet, sondern Requirements, Tests, Architektur, Wartung und die Klärung von Entwicklerabsichten berührt (Roychoudhury, 2025).
Agentic AI wird nicht verständlicher, wenn wir sie künstlich überhöhen. Sie wird begreifbar, wenn wir die Stellen zeigen, an denen sie hilft, stolpert oder neue Disziplin einfordert. Lutions ist mein Bezugspunkt für dieses Lernen – mein Versuch, zu zeigen, wie Softwareentwicklung mit KI-Agenten in der Praxis tatsächlich aussieht.
Datenbasis & Einordnung
Die Einblicke in diesem Beitrag stützen sich auf den laufenden Entwicklungs- und Dokumentationsprozess von Lutions: Tickets, Architekturentscheidungen, interne Notizen, Audits und die Projekthistorie. Die quantitativen Angaben stammen aus der Lutions-Ticketliste und wurden am 17. Juni 2026 abgerufen.
Dieser Text ist ein persönlicher Erfahrungsbericht aus der Praxis – keine offizielle Produktdokumentation und keine Roadmap. Er soll den Kontext liefern, auf den ich mich in kommenden Beiträgen beziehen kann.
Quellen:
- Jimenez et al. (2024): 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