Miriam Schulze, CEO BAYOOMED

Miriam Schulze
CEO
Digital Health & Innovation
LinkedIn

Veröffentlicht am 26. August 2026

Über KI in der Softwareentwicklung wird gerade viel gesprochen. Fast täglich erscheinen neue Tools, Erfolgsgeschichten und Prognosen darüber, wie grundlegend KI unsere Art, Software zu entwickeln, verändern wird. Uns interessierte irgendwann weniger der nächste Hype als eine ganz praktische Frage: Was davon funktioniert eigentlich wirklich schon in einem echten Softwareprojekt, wenn man es drauf anlegt?

Um das herauszufinden, haben wir bei BAYOOMED unser AI Lighthouse gestartet. Dabei wollten wir bewusst kein künstliches Demo-Projekt entwickeln, sondern eine Aufgabe wählen, für die wir einen Vergleich hatten.

Der Vergleich: neun Monate mit sechs Personen

Eine ähnliche Lösung hatten wir bereits einige Zeit zuvor als Software in einem FDA-regulierten Kontext umgesetzt. Die damalige Lösung bestand aus App und Backend; beteiligt war ein klassisches Projektteam mit rund sechs Personen und verschiedenen Rollen aus Architektur, Entwicklung, Verifizierung, Quality und Product Ownership. Die Dauer betrug damals neun Monate.

So viel Zeit hatten wir jetzt nicht. Für unser Experiment änderten wir die Rahmenbedingungen. Diesmal sollte ein etwas anderer fachlicher Scope ausschließlich als Cloud Lösung umgesetzt werden. Vor allem aber wollten wir herausfinden, wie weit wir kommen, wenn wir möglichst wenige technologische Vorgaben machen und KI konsequent in die Entwicklung integrieren.

KI in der Softwareentwicklung: zwei Senior Engineers, keine Spezialisten

Bei der Auswahl der Technologien ließen wir dem Team deshalb weitgehend freie Hand. Programmiersprachen, Frameworks, KI-Assistenten und auch Werkzeuge, die größere Teile einer Anwendung generieren können, durften ausprobiert werden. Die Lösung musste lediglich in der Cloud laufen.

Gleichzeitig galten einige nicht verhandelbare Rahmenbedingungen: Die eingesetzten Tools mussten für den kommerziellen Einsatz geeignet sein und unsere Anforderungen an den Umgang mit Daten erfüllen. Insbesondere durfte mit unseren Daten kein Weiterlernen der Modelle stattfinden.

Was wir bewusst vereinfacht haben

Auch den Entwicklungsprozess haben wir für das Experiment bewusst reduziert. Unit Tests waren Teil des Scopes, eine umfangreiche Dokumentation und Verifizierung zunächst nicht. Uns war damit von Anfang an klar, dass wir KI in der Softwareentwicklung unter vereinfachten Bedingungen erproben und das Ergebnis nicht eins zu eins auf ein reguliertes Medizinprodukt übertragen können.

KI nicht nur für die Entwicklung

Wenn wir schon untersuchen wollten, wie weit uns KI in einem Projekt bringen kannWenn wir schon untersuchen wollten, wie weit uns KI in der Softwareentwicklung bringen kanWenn wir schon untersuchen wollten, wie weit uns KI in der Softwareentwicklung bringen kann, wollten wir nicht erst beim Coding anfangen. Auch klassische Aufgaben des Product Owners sollten Teil des Experiments werden.

Als fachliche Grundlage hatten wir die SRS des ursprünglichen Projekts, die wir für den neuen Scope angepasst hatten. Zusätzlich standen zwei UI-Designs und ein erster mit Lovable erstellter Prototyp zur Verfügung. Dieses Material haben wir in einem ChatGPT-Projekt zusammengeführt und daraus ein Backlog generieren lassen – einschließlich User Stories, Abgrenzungen, Akzeptanzkriterien und Verlinkungen zu den jeweiligen Anforderungen. Anschließend überführten wir das Ergebnis über Excel in Azure DevOps.

Das funktionierte besser, als wir zunächst erwartet hatten. Natürlich musste das Ergebnis überprüft und an einigen Stellen nachgeschärft werden. Aber es war eine belastbare Grundlage für den Projektstart.

Die erste User Story war bewusst keine fachliche Funktion, sondern beschäftigte sich mit Architektur und Software Design. Schließlich wollten wir nicht nur wissen, wie viel Code KI erzeugen kann. Uns interessierte, ob zwei erfahrene Software Engineers mit KI-Unterstützung eine für sie relativ neue Technologie so einsetzen können, dass am Ende trotzdem eine tragfähige Architektur entsteht.

Ein-Wochen-Sprints statt zwei oder drei

Auch unseren üblichen Projektrhythmus änderten wir. Statt zwei- oder dreiwöchiger Sprints arbeiteten wir in Ein-Wochen-Sprints, jeweils mit Planning und Review am Montag. Auf ein formales Daily verzichteten wir. Bei einem Team aus zwei Entwicklern war der direkte Austausch ohnehin gegeben; offene Fragen konnten jederzeit über einen Teams-Chat geklärt werden.

Die kurzen Sprints waren eine bewusste Entscheidung. Wir gingen davon aus, dass sich ein solches Experiment nur begrenzt im Voraus planen lässt. Wir wollten schnell lernen, regelmäßig neu priorisieren und unsere eigenen Hypothesen korrigieren können.

KI in der Softwareentwicklung, erste Woche: schneller – aber noch nicht schnell

Schon in der ersten Woche zeigte sich, dass das von ChatGPT generierte Backlog überraschend brauchbar war. Im Planning mussten wir einige Fragen klären und Details präzisieren, aber die User Stories waren bereits so feingranular, dass das Team auf einen zusätzlichen Task Breakdown weitgehend verzichten konnte.

Parallel begann die Suche nach dem passenden Toolset. Claude und GitHub Copilot wurden zu wichtigen Werkzeugen in der Entwicklung. Lovable wurde ebenfalls ausprobiert, für unseren konkreten Anwendungsfall aber wieder verworfen, weil die Möglichkeiten für die anschließende individuelle Weiterentwicklung nicht ausreichend waren.

Das erste Review brachte dann eine gewisse Ernüchterung. Die erhoffte enorme Beschleunigung war zunächst nicht zu erkennen. Das Cloud-Setup erwies sich als komplexer als erwartet, und an einigen Stellen führte die KI das Team zunächst in die falsche Richtung. Gleichzeitig mussten die Kollegen herausfinden, welches Werkzeug sich für welche Aufgabe eignete. Und sie wollten zu Recht verstehen, was die KI erzeugte, statt generierten Code einfach zu übernehmen.

Dabei zeigte sich bereits eine Erkenntnis, die später auch in unserer Retro eine wichtige Rolle spielte: KI in der Softwareentwicklung erleichtert den Einstieg in neue Technologien enorm, sie macht Fachwissen aber nicht überflüssig. Gerade wenn man selbst wenig über ein Thema weiß, wird es schwieriger zu erkennen, wann die KI falschliegt oder eine unnötig komplizierte Richtung einschlägt.

Nach der ersten Woche war deshalb noch keineswegs klar, ob unsere Hypothese aufgehen würde. Wir hatten aber bereits gelernt, dass KI-gestützte Entwicklung etwas anderes ist als möglichst viel Code generieren zu lassen.

Und in der zweiten Woche begann sich die Dynamik des Projekts deutlich zu verändern.

Was Du dazu auf unserer Website findest