Wo AI-gestützte Entwicklung (noch) nicht funktioniert

Ich habe in dieser Reihe einiges behauptet: dass das Codieren nicht mehr der schwierige Teil ist, dass Projekte deutlich günstiger werden, dass die Umsetzung in Tagen statt Monaten passiert. Alles davon halte ich für richtig. Trotzdem wäre die Reihe unvollständig ohne den Beitrag, der die Grenzen benennt. Wer nur die guten Seiten erzählt, wird beim ersten Projekt eingeholt, das nicht funktioniert.

Also: Wo geht es nicht?

Wenn niemand sagen kann, was gebraucht wird

Das ist der häufigste Fall, und er hat nichts mit Technik zu tun.

AI-gestützte Entwicklung setzt eine Beschreibung voraus. Wenn im Unternehmen niemand präzise sagen kann, wie ein Prozess funktioniert – weil ihn drei Personen unterschiedlich beschreiben, weil die Regeln über Jahre gewachsen sind, weil die einzige Person mit dem Überblick vor zwei Jahren gegangen ist –, dann hilft Geschwindigkeit nicht. Sie macht es schlimmer, weil man schnell viel Software bekommt, die einen falsch verstandenen Prozess sauber abbildet.

Die Lösung ist nicht Technologie, sondern Analyse. Aber es ist wichtig, das vorher zu wissen, statt es im Projekt zu entdecken.

Wenn niemand das Ergebnis beurteilen kann

Der zweite Fall ist gefährlicher, weil er lange unauffällig bleibt.

Eine generierte Lösung, die läuft, ist nicht automatisch richtig. Sie ist plausibel. Der Unterschied zwischen plausibel und richtig ist die ganze Fachlichkeit. Wenn im Projekt niemand ist, der eine Berechnung, eine Regel, eine Auswertung fachlich gegenprüfen kann, dann entsteht keine Software, sondern eine Vermutung mit Benutzeroberfläche.

Das ist übrigens der Grund, warum ich die These vom verschwindenden Entwickler präzisiert habe. Was verschwindet, ist das Übersetzen von Anforderungen in Syntax. Was bleibt und wertvoller wird, ist die Fähigkeit zu erkennen, dass etwas technisch korrekt und fachlich falsch ist.

Wenn es kein Ende gibt

Was nicht funktioniert: Eine Person installiert Claude Code und hat das Gefühl, ab jetzt entstehe von selbst gute Software. So einfach ist es nicht.

Es braucht immer eine End-to-End-Betrachtung. Von der fachlichen Analyse über die Umsetzung bis zum Deployment, inklusive der Bestimmung der Zielinfrastruktur – und vor allem Betrieb und Wartung danach. Wer nur den mittleren Teil abdeckt, hat kein Projekt umgesetzt, sondern einen Prototyp gebaut.

Man merkt das nicht am ersten Tag. Man merkt es beim ersten Ausfall, beim ersten Sicherheitsupdate, bei der ersten Änderung, die jemand einbauen soll, der das System nicht kennt. Der Prototyp ist dann immer noch da – nur ist inzwischen ein Geschäftsprozess davon abhängig.

Wenn das Umfeld die Geschwindigkeit nicht mitgeht

Es gibt Projekte, in denen die Umsetzung gar nicht der Engpass war. Eine Systemablösung, bei der der Aufwand in Migration, Schulung und Organisation liegt. Ein reguliertes Umfeld, in dem Abnahme- und Nachweisprozesse den Takt vorgeben. Eine Integration in Systeme, deren Betreiber Vorlaufzeiten von Wochen für einen Testzugang haben.

In diesen Fällen wird die Entwicklung schneller und das Projekt nicht. Das ist keine Enttäuschung, wenn man es vorher weiss – und eine ziemliche, wenn man mit anderen Erwartungen gestartet ist.

Wenn Verfügbarkeit fehlt

Ein unterschätzter Fall: Das Vorhaben ist klar, die Fachlichkeit ist im Haus vorhanden – aber die Person, die die Fragen beantworten könnte, hat einen vollen Kalender. Wenn Rückfragen drei Tage liegen bleiben, taktet das Projekt in Wochen, unabhängig davon, wie schnell gebaut wird.

Deshalb frage ich inzwischen vor Projektstart nicht nur nach dem Ziel, sondern nach der Verfügbarkeit. Ein halber Tag pro Woche von der richtigen Person ist wertvoller als ein grosses Budget.

Wo es technisch enger wird

Auch das gehört ehrlicherweise dazu. Alles, was tief in einer sehr speziellen Umgebung steckt – exotische Altsysteme, undokumentierte proprietäre Formate, Hardware-nahe Schnittstellen –, ist deutlich mühsamer, weil das Wissen darüber schlicht kaum irgendwo steht. Auch sehr grosse, gewachsene Codebasen ohne Struktur sind schwieriger, weil jede Änderung Nebenwirkungen an Stellen hat, die niemand mehr überblickt.

Unmöglich ist das nicht. Es ist einfach nicht der Fall, in dem man die Werbeversprechen einlöst.

Was daraus folgt

Nicht, dass man es lassen soll. Sondern dass man vor dem Start drei Fragen ehrlich beantworten sollte:

Ist klar, was gebraucht wird – und wenn nicht, plane ich die Analyse als eigenen Schritt ein? Gibt es jemanden, der Ergebnisse fachlich beurteilen kann und dafür Zeit hat? Ist geklärt, wer das Ding nach dem Go-live betreibt und verantwortet?

Wer diese drei Fragen mit Ja beantwortet, wird die Geschwindigkeit erleben, von der ich in dieser Reihe schreibe. Wer eine davon mit Nein beantwortet, sollte genau dort anfangen – und nicht beim Code.

Im nächsten Beitrag geht es um die dritte Frage, die am liebsten verschoben wird: was nach dem Go-live passiert.