Drei Projekttypen. Drei unterschiedliche Beziehungen zur KI. Eine Frage, die sich gerade jedes Produktteam stellt.

Fast jede Woche stellt mir jemand, mit dem ich über ein neues Produkt spreche, eine Variante derselben Frage: Können wir das mit KI entwickeln? Manchmal heißt das „Geht es schneller?“, manchmal „Geht es günstiger?“ und in der Medizintechnik oft „Gefährdet das unsere Zertifizierung?“. Mit Ja oder Nein lässt sich das selten beantworten, auch wenn genau das erwartet wird.

Bevor ich ins Business Development gewechselt bin, habe ich mehr als 13 Jahre im Delivery-Bereich von RomSoft gearbeitet: QA, Product Ownership, Projektmanagement, Personalführung. Jede dieser Rollen brachte dieselben grundlegenden Fragen mit sich: Was braucht es wirklich, damit Software gelingt, und wo laufen die Dinge unbemerkt schief?

Statt Interessenten also gleich meine eigene Antwort zu geben, habe ich mit drei Kolleginnen und Kollegen gesprochen, die sich dieser Frage jeden Tag stellen, aus ganz unterschiedlichen Positionen. Nicht, um sie abschließend zu klären – ich glaube nicht, dass sie sich abschließend klären lässt –, sondern um zu verstehen, wo sie jeweils die Grenze ziehen und warum nicht alle an derselben Stelle.

George arbeitet in einem Forschungsteam innerhalb einer langjährigen Produktpartnerschaft und bringt Ideen so schnell vom Konzept zum Prototyp, wie es die Werkzeuge erlauben. Sebastian arbeitet in regulierten Softwareprojekten, in denen eine einzige ungeprüfte Codezeile zum Compliance-Risiko wird. Cristina arbeitet dazwischen: in einem Projekt, das nicht unter die IEC 62304 fällt, aber trotzdem denselben KI-Regeln folgt. In den Gesprächen mit allen dreien zeigte sich ein Muster, das keiner von ihnen allein so beschrieben hätte. Die wichtigste Fähigkeit ist nicht der Einsatz von KI-Agenten. Entscheidend ist zu wissen, wie viel Autonomie eine bestimmte Aufgabe verträgt und wie viel Disziplin sie umgeben muss. Wer einen Entwicklungspartner auswählt, sollte genau darauf achten.

Wie die Wette auf KI in einem forschungsorientierten SaaS-Entwicklungsteam aussieht

George arbeitet in einem Team, das sich über mehr als ein Jahrzehnt zu etwas deutlich Ambitionierterem entwickelt hat, als es zu Beginn war. Dieses Wachstum hat die Art der technischen Herausforderung verändert: Für immer weniger Dinge gibt es heute eine offensichtliche Lösung. Deshalb hat sich das Team rund um das Erkunden neu aufgestellt – den Problemraum definieren, mögliche Ansätze identifizieren, Prototypen bauen und bewerten und erst dann entscheiden, was es wert ist, in die vollständige Entwicklung überführt zu werden.

George ist überzeugt, dass jedes Projekt KI in die tägliche Entwicklungsarbeit einbinden kann, und zwar unter denselben Grundregeln, die für jeden gelten, der Code schreibt: geistiges Eigentum, Vertraulichkeit von Daten und freigegebene Unternehmenswerkzeuge. Über diese Grundregeln hinaus kann das Team KI breiter einsetzen, mit einer Aufsicht, die auf die Aufgabe und die Anforderungen des Kunden abgestimmt ist.

KI breit einzusetzen heißt allerdings nicht, sie vom ersten Tag an überall einzusetzen. In Georges Welt taucht ein Begriff ständig auf: der KI-Harness, der technische Leitstern für jeden Agenten. Er beschreibt den Zweck des Bereichs, in dem der Agent arbeitet, was er tun darf und was nicht, und wie weit er gehen kann, bevor er bei einem Menschen nachfragen muss.

George spricht offen darüber, wie das Team zu seinem heutigen Prozess gekommen ist. In einem Projekt erstellten sie den Architekturplan, begannen auf dieser Grundlage mit KI zu entwickeln und gaben dem Agenten Regeln vor. Doch der Harness war nicht streng genug, und die Regeln wurden nicht durchgehend konsequent befolgt. Die Entwicklung beschleunigte sich, und eine Zeit lang sah das nach einem Gewinn aus. Dann stellte das Team fest, dass die Codebasis vom Plan abgedriftet war, und musste zurückgehen und sie korrigieren: mit von Menschen erstellten Schichtmustern, Regeln pro Schicht, kleineren Aufgaben für den Agenten und Review-Checkpoints.

Dass ein Agent abdriftet, liegt, wie sich zeigt, zum Teil am Kontext – oder daran, dass er fehlt. Bei einer umfangreichen Codebasis mit vorhandenen Mustern neigt die KI dazu, das Bestehende zu respektieren und zu übernehmen. In einer leeren Greenfield-Schicht, in der es nichts nachzuahmen gibt, wird sie stattdessen „kreativ“, und Fehler schleichen sich ein.

Diese Erkenntnis fließt heute in jedes neue Projekt ein. Das Fundament entsteht nach dem Human-in-the-Loop-Prinzip: Die technische Analyse, das Konzept und die Kernarchitektur bleiben bei Menschen, und die KI bekommt eine Struktur, gegen die sie validieren kann, statt eines leeren Blattes, das sie füllen soll. Erst wenn die Architektur steht, wird der Agent eingerichtet, mit expliziten Regeln und einem Harness für jede Architekturschicht, der festlegt, wofür er dort zuständig ist und was er nicht anfassen darf. Beschleunigt wird erst, wenn das Fundament trägt, und keinen Moment früher.

George weist auch bewusst auf die Grenzen seiner eigenen Beobachtung hin: Die Werkzeuge ändern sich schnell, deshalb müssen Teams ihre Praktiken überprüfen, sobald die Fähigkeiten zunehmen. Drei bis sechs Monate sind, wie er betont, in der KI ein langer Zeithorizont.

Unverändert bleibt dagegen die wirtschaftliche Logik hinter dem Testen von Ideen. Wenn sich eine Idee in sechs Wochen statt in sechs Monaten verwerfen lässt, kann man in der Zeit, die früher für eine einzige nötig war, vier Ideen testen. Die echte Nutzung des Produkts – mit integrierter Telemetrie – liefert zusätzliche Belege, die Interviews und Marktforschung allein nicht bieten können.

Für ein Produktteam zahlt sich KI hier zuerst aus: nicht darin, mehr Code zu schreiben, sondern darin, früher herauszufinden, welche Ideen es verdienen, gebaut zu werden.

Wenn jede Zeile einen Verantwortlichen braucht

Wenn Ihre Software eines Tages vor einem Auditor bestehen muss, ist dies der wichtigste Teil. Ein Partner, der KI einsetzt, ist nur dann ein Gewinn, wenn sich jede Zeile, die die KI berührt, weiterhin nachvollziehen und verantworten lässt.

In regulierten Projekten wie medizinischer Software nach IEC 62304 beruhen die Normen auf einer Prämisse, die aus der Zeit lange vor der KI stammt: Jede Codezeile soll sich auf eine Anforderung zurückführen lassen. Jede Designentscheidung soll eine dokumentierte Begründung haben. Jedes Review soll eine Spur hinterlassen, der ein Auditor folgen kann. Dieser Mechanismus erlaubt es einem Team, die eine Frage zu beantworten, auf die Regulierungsbehörden immer wieder zurückkommen: „Wer hat das entschieden, und auf welcher Grundlage?“

Sebastians Welt zeigt, warum regulierte Teams die Grenze dort ziehen, wo sie sie ziehen – und das liegt nicht in erster Linie an einer technologischen Lücke. Wie er sagt, können Agenten zu einem breiten Spektrum von Entwicklungsaufgaben beitragen; dass Projektverantwortliche zögern, hat zwei Gründe.

Der erste ist die Unsicherheit darüber, was mit dem Code geschieht, den ein KI-Modell liest, und mit dem Kontext, auf den es dabei Zugriff hat. Unternehmenskonten sollen diese Lücke schließen – über freigegebene Tools, Vertragsbedingungen, Einstellungen zur Datenverarbeitung und projektspezifische Regeln –, aber reicht das aus?

Der zweite betrifft die Softwareklassen mit höherem Risiko nach IEC 62304 (Klassen B und C) und lässt sich genauer benennen. Jedes Werkzeug, mit dem die Software erstellt wird, muss validiert sein: getestet, mit bekannter Herkunft und mit vorhersehbarem Verhalten in jedem Szenario, dem es begegnen wird. Das wirft eine Frage auf, auf die bislang niemand eine saubere Antwort hat: Wie validiert man ein Werkzeug, das von Natur aus nicht deterministisch ist? Die Unvereinbarkeit, so Sebastian, ergibt sich aus dem, was die Norm von Werkzeugen verlangt – nicht daraus, dass Ingenieure, Management oder Projektverantwortliche der Idee gegenüber verschlossen wären.

Deshalb ist der Werkzeugeinsatz bewusst genau geregelt. Das freigegebene Tool darf nur mit der Unternehmenslizenz verwendet werden – und sein Agent-Modus kommt nicht in Frage: Der Assistent beantwortet Prompts im Chatfenster, darf aber keine Aufgaben eigenständig ausführen. KI-Vorschläge werden einzeln geprüft und angenommen – Inline-Vervollständigungen oder ein einzelner Frage-Antwort-Austausch –, wobei ein Mensch jeden Vorschlag einzeln freigibt.

Und jedes Repository, mit dem der Assistent arbeitet, enthält eine eigene Anweisungsdatei, sodass selbst ein eng begrenzter Vorschlag an den Standards genau dieses Projekts ausgerichtet bleibt statt an allgemeinen Best Practices.

Diese Datei dient zugleich als Datenschutzfilter. Sie legt fest, was mit dem Assistenten geteilt werden darf und was nicht, damit proprietärer Code und vertrauliche Kundendaten niemals die Server des Anbieters erreichen oder in künftiges Modelltraining einfließen. (Patientendaten waren nie im Spiel – sie liegen verschlüsselt in der Datenbank.)

Innerhalb dieser Grenzen hat der Assistent dennoch seinen festen Platz: bei der Definition von Anforderungen, in der Projektdokumentation und bei der Suche nach Lösungen für konkrete technische Probleme. Und Sebastian sieht deutlich Raum für mehr – bei Code-Reviews, technischen Spikes, Proofs of Concept und beim Aufspüren von Problemen in bestehendem Code –, alles Bereiche, in denen am Ende weiterhin ein Mensch das Ergebnis freigibt.

Fragen zur KI, die Sie jedem Entwicklungspartner stellen sollten

• Welche KI-Tools nutzen Ihre Ingenieure, und unter welchen Lizenz- und Datenverarbeitungsbedingungen?
• Können unser Code oder unsere Daten im Modelltraining eines Anbieters landen?
• Wer entscheidet, wie viel Autonomie die KI in unserem Projekt bekommt, und wer gibt die Ergebnisse frei?
• Wie gehen Sie mit KI bei Modulen um, die unter die IEC 62304 oder unter die Vorgaben unseres Auditors fallen?
• Wo haben Sie einen echten Gewinn gemessen, und wo hat KI nicht geholfen?

Strenge Regeln, messbare Gewinne

Cristinas Team zeigt, wie strenge Regeln in einem Projekt aussehen, das sie streng genommen gar nicht bräuchte. Ihr Projekt fällt nicht unter die IEC 62304 und kommt nicht mit Patientendaten in Berührung, ist aber für die Verwaltung medizinischer Labore bestimmt. Deshalb wendet das Team trotzdem dasselbe KI-Verfahren an, auch dort, wo sich manche Schritte vermutlich überspringen ließen.

Das ist Georges Argument zum Kontext, von der anderen Seite betrachtet: In einer ausgereiften Codebasis hat der Assistent Muster, denen er folgen kann.

Cristinas eigene Regel ist einfach: jeden Vorschlag von Hand übernehmen und keine Codezeile ungeprüft lassen. Auch den Zielkonflikt beschönigt sie nicht. Der Assistent hilft weniger erfahrenen Entwicklern, schneller voranzukommen, doch je mehr Code dabei entsteht, desto aufwendiger wird das Review: KI greift gern zu Lösungen, die komplexer sind, als das Problem es verlangt, und irgendjemand muss trotzdem jede Zeile lesen.

Es gibt aber Bereiche, in denen der Nutzen messbar ist.

Eine Testerin aus Cristinas Team arbeitete mit dem Assistenten an automatisierten Tests, unter denselben Anweisungsregeln, erhielt von ihm einen Vorschlag zu deren Verbesserung und setzte ihn dann mit seiner Hilfe um. Die nächtliche Regression – mehrere hundert Selenium-Tests, die früher rund acht Stunden liefen – ist jetzt zwei bis drei Stunden früher fertig.

Dasselbe Verfahren, dasselbe Review Vorschlag für Vorschlag, und trotzdem ein Gewinn, den jeder messen kann. Wo die Grenze liegt, entscheiden der Kunde und die Art des Projekts, nicht das, was das Werkzeug technisch könnte.

Was ich ins nächste Gespräch mitnehme

Wenn Sie sich bei Ihrem eigenen Produkt fragen: „Können wir das mit KI entwickeln?“, dann kommen Sie mit dieser Frage zu mir. In einem kurzen Gespräch schauen wir uns an, welche Teile Ihres Projekts mehr KI-Autonomie vertragen, welche eine engere Aufsicht brauchen und was das für Ihren Zeitplan und Ihren Audit-Trail bedeutet. Schreiben Sie mir hier eine Nachricht oder erreichen Sie mich per E-Mail.