Veröffentlicht am 26. August 2026

Vier Wochen, zwei Senior Software Engineers, ein reales Backend-Projekt: In unserem AI Lighthouse wollten wir herausfinden, was KI-gestützte Softwareentwicklung in der Praxis leistet.

Nach der ersten Woche war unsere Bilanz noch gemischt. Das mit KI-Unterstützung erzeugte Backlog hatte gut funktioniert, die eigentliche Entwicklung war aber noch nicht annähernd so schnell, wie man es angesichts vieler Versprechen rund um AI Coding vielleicht erwarten würde. Das Team musste zunächst die richtigen Werkzeuge finden, sich in die Cloud-Technologie einarbeiten und lernen, wie es die KI sinnvoll in den eigenen Entwicklungsprozess integriert.

In der zweiten Woche begann sich das zu ändern – und zwar ausgerechnet bei einem Thema, bei dem wir vorher eher skeptisch gewesen waren.

Wir hatten bis dahin die Hypothese, dass KI zwar Code generieren kann, bei einem guten User Interface aber schnell an ihre Grenzen kommt. Unsere UI-affine Kollegin widerlegte diese Annahme ziemlich deutlich. Mit KI-Unterstützung entstanden funktionale und optisch ansprechende Oberflächen in einer Geschwindigkeit und Qualität, die uns überrascht haben.

Dass dieser Eindruck nicht nur einzeln entstanden war, zeigte sich später in unserer Retro. Auf dem Board stand ganz schlicht:

Eine unserer ersten Hypothesen konnten wir damit ziemlich eindeutig abhaken.

Dabei ging die Unterstützung über die reine Umsetzung unserer Vorgaben hinaus. Die KI machte Vorschläge für zusätzliche Auswertungen und Funktionen, die ursprünglich nicht Teil unserer Spezifikation gewesen waren. Nicht alle davon waren sinnvoll, einige aber durchaus.

Das führte zu einer interessanten Veränderung im Entwicklungsprozess: Wenn der Aufwand, eine Idee auszuprobieren, sehr klein wird, verändert sich auch der Umgang mit solchen Ideen. Aus einem Feature, das man früher vielleicht für einen späteren Sprint ins Backlog aufgenommen hätte, wurde häufiger etwas, das man einfach kurz ausprobieren konnte.

In der dritten Woche hatte das Team zunehmend seinen Rhythmus gefunden. Die Kollegen wussten besser, welches Werkzeug sich für welche Aufgabe eignete, hatten sich tiefer in die Technologie eingearbeitet und gleichzeitig gelernt, der KI den richtigen Kontext zur Verfügung zu stellen.

Gerade dieser Kontext erwies sich als entscheidend. In der frühen Phase eines Projekts war die KI besonders hilfreich. Einer der Kommentare aus der Retro bringt es gut auf den Punkt:

„Using AI is very helpful in the early stage of a project."

Neue Themen ließen sich schnell erschließen, und bei überschaubaren Problemen konnte beispielsweise auch das Debugging erheblich beschleunigt werden. Das Team stellte außerdem fest, dass man mit KI sehr schnell neue Technologien ausprobieren und verstehen kann. Oder, wie es auf einem unserer Zettel hieß:

„You can learn new topics very fast because AI can explain it to you on high and low level."

Ganz so einfach blieb es allerdings nicht. Mit wachsender Komplexität des Systems wurde auch die Zusammenarbeit mit der KI anspruchsvoller. Je mehr Zusammenhänge berücksichtigt werden mussten, desto größer wurde die Gefahr, dass relevanter Kontext fehlte. Auch das wurde in der Retro sehr deutlich formuliert:

Das zeigte sich beispielsweise bei Änderungen an bestehenden Funktionen. Eine vermeintlich kleine Anpassung konnte an einer anderen Stelle unerwartete Auswirkungen haben, weil das Modell den Gesamtzusammenhang nicht vollständig berücksichtigt hatte. Ein Kollege beschrieb genau diese Erfahrung:

Auch die technischen Vorschläge selbst mussten kritisch geprüft werden. Teilweise wurden veraltete Bibliotheken oder ältere Versionen vorgeschlagen, obwohl aktuellere Alternativen verfügbar waren. Hinzu kommt ein Aspekt, der gerade für den professionellen Einsatz nicht unterschätzt werden darf: Eine KI-generierte technische Lösung ist nicht automatisch auch lizenzrechtlich geprüft. Die Bewertung der verwendeten Bibliotheken und ihrer Lizenzen bleibt eine Aufgabe des Teams.

Mit zunehmender Erfahrung wurde das Team im Umgang mit diesen Grenzen besser. Die Konsequenz war nicht, weniger KI einzusetzen, sondern bewusster zu entscheiden, wann und wie sie eingesetzt wird.

Gleichzeitig begann das Team, über die ursprünglichen Anforderungen hinauszudenken. Für eines unserer Reviews generierten die Kollegen beispielsweise kurzerhand ein Interface, mit dem sich das komplette System auf Knopfdruck mit Daten befüllen ließ. Diese Funktion war weder spezifiziert noch Teil einer User Story. Für die Entwicklung und die Reviews war sie aber ausgesprochen hilfreich.

Solche Situationen waren für uns eine der interessantesten Beobachtungen des Experiments. Wenn die technische Umsetzung einer kleinen Idee nur noch einen geringen Aufwand verursacht, kann ein Team viel häufiger ausprobieren, statt zunächst lange darüber zu diskutieren, ob sich eine Umsetzung lohnt.

In der vierten Woche war der Unterschied zum Projektstart deutlich spürbar. Das Team hatte alle Must-haves umgesetzt und darüber hinaus einige sinnvolle Erweiterungen realisiert, die sich erst während der Entwicklung ergeben hatten.

Natürlich waren diese vier Wochen keine vier Wochen störungsfreier Feature-Entwicklung. Das Team musste sich in neue Themen einarbeiten, technische Sackgassen korrigieren und KI-generierte Lösungen hinterfragen. Trotzdem war in sehr kurzer Zeit erstaunlich viel entstanden. Das Feedback aus der Retro war entsprechend deutlich:

Interessant war aber auch, dass die emotionale Bewertung der Arbeit mit KI keineswegs nur positiv war. Ein Kollege schrieb:

Das trifft unsere Erfahrung ziemlich gut. Wenn innerhalb weniger Minuten etwas funktioniert, für das man früher Stunden gebraucht hätte, kann das enorm motivierend sein. Wenn man dagegen feststellt, dass man einer überzeugend klingenden, aber falschen Lösung gefolgt ist, entsteht genauso schnell Frust.

Ein weiterer Kommentar aus der Retro bringt deshalb vielleicht die wichtigste Einschränkung des gesamten Experiments auf den Punkt:

Das klingt zunächst paradox. Schließlich soll KI gerade dabei helfen, Wissenslücken zu schließen. Und genau das tut sie auch. Aber je besser der Software Engineer selbst versteht, was technisch passiert, desto besser kann er die Vorschläge der KI einordnen, korrigieren und gezielt weiterentwickeln. KI macht Expertise damit nicht überflüssig – sie erhöht vielmehr den Hebel, den Expertise hat.

Für uns war Geschwindigkeit allein ohnehin noch kein ausreichendes Erfolgskriterium. Deshalb kam die entstandene Lösung abschließend in ein technisches Review durch unseren CTO Bernd Seidenspinner.

Auch dieses Ergebnis war interessant. Manches hätte er anders umgesetzt, Architektur und technische Entscheidungen bewertete er aber als gut und nachvollziehbar. Das stärkte eine unserer ursprünglichen Hypothesen: Seniorität und solides Software-Engineering-Know-how können mit KI-Unterstützung möglicherweise einen Teil der tiefen Erfahrung in einer ganz bestimmten Technologie kompensieren.

Das bedeutet nicht, dass technisches Fachwissen unwichtiger wird. Im Gegenteil: Wer die Vorschläge einer KI beurteilen will, muss erkennen können, wann sie falschliegt, wann eine Architektur nicht trägt oder wann beispielsweise eine vorgeschlagene Library technisch oder lizenzrechtlich nicht geeignet ist.

Nach vier Wochen hatten wir damit nicht nur eine funktionierende Lösung. Wir hatten auch eine neue Frage: Wenn die eigentliche Implementierung plötzlich erheblich schneller werden kann – sind die Prozesse rund um die Entwicklung überhaupt auf diese Geschwindigkeit vorbereitet?

Genau darum geht es in Episode 3. [Link auf Episode 3]

• KI in der Medizinsoftware-Entwicklung – Wie wir Hersteller bei Entwicklung, Validierung und MDR-konformer Zulassung KI-gestützter Medizinprodukte begleiten.
• Softwareentwicklung für Medizinprodukte – Unser Leistungsspektrum für MedTech, Pharma und Life Science: von der Beratung bis zur Marktreife.