Im Februar haben wir mit der Entwicklung von ITM InMind begonnen, einer internen Geschäftsanwendung, deren gesamter Code von KI-Agenten geschrieben wurde. Fünf Monate später läuft sie produktiv und wird im Unternehmen täglich genutzt. Aus drei konkreten Anforderungen entstand eine zentrale Plattform. Das Projekt hat uns gezeigt, was KI-gestützte Softwareentwicklung leisten kann und wo menschlicher Input unverzichtbar bleibt.
Warum wir InMind entwickelt haben
Für uns kamen drei Themen zusammen. Unsere Asset-Management-Software wurde vom Hersteller abgekündigt und musste ersetzt werden. Gleichzeitig wollten wir unser Kundenmanagement verbessern, und unsere internen Tools für SAP LeanIX waren so nützlich geworden, dass wir sie für Kolleginnen und Kollegen zentral bereitstellen mussten. Jedes Thema hätte sich einzeln lösen lassen. Zusammen sprachen sie für eine zentrale Plattform.
Für Asset Management und CRM prüften wir zahlreiche kommerzielle Produkte. Die Systeme waren leistungsfähig, richteten sich aber an Organisationen mit deutlich größeren Anforderungen. Entsprechend hoch waren Kosten und Komplexität. Für ein Unternehmen unserer Größe stand der Preis nicht im Verhältnis zum Nutzen. Auch die Tools für SAP LeanIX brauchten einen sicheren, zentralen Ort. Deshalb entschieden wir uns für eine Plattform für alle drei Themen, statt zwei Systeme zu lizenzieren und ein drittes Tool separat zu entwickeln.
Das heißt nicht, dass wir drei voneinander unabhängige Produkte in eine Codebasis packen. Kundenmanagement, Asset Management und SAP LeanIX-Tools bleiben getrennte Module mit eigenen Datenmodellen und Nutzergruppen. Geteilt wird die technische Grundlage: Authentifizierung und Rollenverwaltung, Protokollierung, Benachrichtigungen, Backups und kontrollierte Releases. InMind stellt diese Grundlagen einmal bereit. Jedes Use-Case läuft darauf als eigenes Modul. Die Module teilen sich die Plattform, nicht die Geschäftslogik.
Heute unterstützt InMind unser Kundenmanagement, ein Asset-Management-System mit Anbindung an unser Mobile Device Management und betreibt unsere internen Tools für SAP LeanIX.
Bisher 902 Commits, und kein einziger davon stammt von einem menschlichen Entwickler.
Zum Zeitpunkt dieses Artikels umfasst das Repository 902 Commits. Kein einziger wurde von einem Entwickler verfasst. Die KI-Agenten schrieben den gesamten Code. Das heißt jedoch nicht, dass die Arbeit ohne menschliche Entwicklungsarbeit stattgefunden hat. Unsere Entwickler geben die Richtung vor, spezifizieren die Arbeit, prüfen die Ergebnisse und testen jedes Modul, bevor sich unsere Kolleginnen und Kollegen darauf verlassen.
Vibe Coding oder KI-gestützte Entwicklung?
Vibe Coding beschreibt eine bestimmte Arbeitsweise: Man beschreibt einem Modell das gewünschte Ergebnis, übernimmt den erzeugten Code ohne genaue Prüfung und iteriert, bis das Ergebnis richtig wirkt. Für Prototypen, einmalige Skripte und Experimente kann das nützlich sein. Für ein System, das Unternehmensdaten verarbeitet, die tägliche Arbeit unterstützt und im Rahmen von Informationssicherheitsaudits geprüft wird, kam diese Arbeitsweise für uns nicht infrage.
Bevor die Agenten die erste Zeile Code schrieben, erarbeiteten wir klare Anwendungsfälle und dokumentierten funktionale sowie nichtfunktionale Anforderungen. Sie bestimmen, was die Anwendung leisten muss und welche Anforderungen an Sicherheit, Leistung und Wartbarkeit sie erfüllen muss. Für jede größere Funktion arbeiten wir spezifikationsgetrieben: User Stories, Anforderungen und Edge-Cases werden vor der Implementierung ausgearbeitet. Die Agenten entwickeln anhand dieser Spezifikation statt nach einem einfachen Prompt.
KI hat jede einzelne Zeile Code geschrieben. Die Entwicklungsarbeit darum blieb jedoch klassische Softwareentwicklung. Dieser Unterschied wurde wichtiger, als InMind Teil unseres Arbeitsalltags wurde.
Wenn aus einem Tool das digitale Rückgrat wird
Die ersten Module bestätigten das Versprechen der KI-gestützten Entwicklung. Eine fokussierte Anwendung mit begrenztem Umfang ließ sich schnell umsetzen. Die wichtigere Lektion kam später, als wir die Module weiterentwickelten, ausbauten und ihre Funktionen in den Arbeitsalltag integrierten. Unsere TISAX-Anforderungen verlangen umfassende rollenbasierte Zugriffskontrollen. Zudem brauchten wir nachvollziehbare Nachweise in Form von Protokollen, kontrollierten Releases, Backups und dokumentierten Reviews.
Das sind keine Zusatzaufgaben neben dem Produkt. Sie verändern das Produkt selbst. Eine neue Funktion darf nicht nur für sich allein funktionieren. Sie muss Berechtigungen berücksichtigen, die passenden Benachrichtigungen auslösen, korrekt protokolliert werden, in Sicherungs- und Wiederherstellungsprozesse eingebunden sein und mit allen bestehenden Modulen kompatibel bleiben. Mit jeder zusätzlichen Abhängigkeit wurden Aufgaben, die zunächst überschaubar wirkten, deutlich anspruchsvoller. Unsere KI-Agenten benötigen heute für eine neues Feature oft doppelt, in manchen Fällen fast dreimal so lange.
Was wir gelernt haben
- Mit einer klaren Architektur starten und sie verbindlich machen. Vor der ersten Funktion legten wir die Softwarearchitektur und den Technologie-Stack fest, teils selbst und teils gemeinsam mit den KI-Agenten. Diese Entscheidungen dokumentierten wir und behandelten sie als verbindlich. So bleibt die Grundlage stabil, auch wenn der Funktionsumfang wächst. Ohne diesen Rahmen kann jede neue Session zusätzliche Muster einführen, und die Codebasis verliert schrittweise ihre Struktur.
- Wichtige Grundlagen früh richtig umsetzen. InMind setzt rollenbasierte Zugriffskontrolle über alle Module und Datenfelder hinweg durch. Unsere erste Implementierung schien vollständig zu sein. Lücken zeigten sich jedoch in späteren Entwicklungszyklen und waren dann schwer zu finden und zu beheben. Zugriffskontrolle, Benachrichtigungen, Backups und Protokollierung betreffen jedes Modul. Sie nachträglich zu integrieren, ist wesentlich aufwendiger, als sie von Anfang an richtig zu gestalten.
- Größere Funktionen spezifikationsgetrieben entwickeln. Bei umfangreicheren Funktionen arbeiten wir mit spezifikationsgetriebenen Methoden und Werkzeugen wie Spec-Kit. Dieses Vorgehen erfordert viel Planung und Dokumentation. Dafür werden User Stories, Anforderungen und Edge-Cases vor der Implementierung sichtbar, statt erst dann, wenn sie bereits ein Problem verursacht haben.
- Tests gegen die Anforderungen schreiben lassen, nicht gegen den Code. Wir lassen Unit-, Integrations- und End-to-End-Tests aus detaillierten Funktionsbeschreibungen erzeugen. Sie prüfen damit das erwartete Verhalten und nicht das, was der Code gerade tut. Die Agenten nutzen diese Tests, um eigene Fehler lokal zu finden und zu korrigieren, bevor die CI/CD-Pipeline fehlschlägt. InMind hat inzwischen über 2.000 Testfälle. Sie sind wirksam, kosten aber Zeit: Ein vollständiger Lauf der Test-Suite dauert etwa vier Minuten. Werden Fehler gefunden, führen die Agenten die Tests oft mehrfach aus, bis alles behoben ist.
- Generierten Code nie ungeprüft übernehmen. Für die Entwicklung von InMind nutzten wir aktuelle Modelle von Anthropic und OpenAI. Kleinere Fehler treten weiterhin häufig auf. Unsere Code-Reviews zeigen, dass ungefähr jeder dritte Commit einen Logikfehler oder ein Sicherheitsproblem enthielt, etwa bei der Durchsetzung der rollenbasierten Zugriffskontrolle. Deshalb prüfen wir jeden Commit automatisiert und unsere Entwickler testen und validieren den Code, bevor er in die Entwicklungsumgebung übernommen wird. Das kostet Zeit und Rechenleistung, schützt unsere Systeme jedoch vor "AI Slop".
- Für die Compliance zählt nicht, wer den Code geschrieben hat. Wir sind TISAX-zertifiziert und müssen nachweisen können, dass unser Entwicklungsprozess kontrolliert abläuft. Dazu gehören dokumentierte Sicherheitsanforderungen, nachvollziehbare Änderungen, Nachweise über Tests und Reviews sowie geordnete Releases. KI-generierter Code ändert an dieser Pflicht nichts. Im Gegenteil: Review-Protokolle, Testergebnisse und eine vollständige Änderungshistorie sind entscheidend, um menschliche Kontrolle nachzuweisen.
Die Frage, die diese Erfahrung aufwirft
Für uns war die Entwicklung von InMind die richtige Entscheidung. Die Plattform deckt die Anwendungsfälle ab, die den Ausschlag für das Projekt gaben, und bietet unseren internen SAP LeanIX-Tools eine sichere Umgebung. Im Betrieb, bei Wartung und Weiterentwicklung ist InMind langfristig günstiger als kommerzielle Lizenzen für alle Nutzer. Zudem können wir Funktionen jederzeit gezielt erweitern und an unseren Bedarf anpassen.
Aus dieser Erfahrung entstand in Gesprächen mit mehreren Kunden eine naheliegende Frage: Könnten sie ihr eigenes EA-Tool mithilfe von KI entwickeln, anstatt eine kommerzielle Plattform zu lizenzieren? Unsere Erfahrung mit InMind prägt unsere Antwort, die wir in einem eigenen Artikel aufgeschrieben haben: Sollten Sie Ihr eigenes EA-Tool entwickeln?
Wenn Sie KI-gestützte Entwicklung für eine eigene interne Anwendung in Betracht ziehen, teilen wir unsere Erfahrungen gern im Detail, einschließlich der Teile, die nicht reibungslos liefen. Sprechen Sie mit uns.