Die erste Version ist erst der Anfang
Die erste Version einer Anwendung sieht vielversprechend aus. Die Anmeldung funktioniert, Kundendaten lassen sich speichern und ein Angebot ist mit wenigen Klicks erstellt. Ein Programmierassistent hat einen großen Teil des Codes geliefert.
Dann kommt die nächste Anforderung: Mehrere Unternehmen sollen dieselbe Anwendung verwenden, ihre Daten aber strikt getrennt bleiben. Ein Mitarbeiter darf Angebote bearbeiten, jedoch keine Benutzer verwalten. Gleichzeitig muss eine neue Schnittstelle angebunden werden.
An diesem Punkt interessiert mich weniger, wie schnell die erste Oberfläche entstanden ist. Entscheidend ist, ob die Anwendung so aufgebaut wurde, dass diese Änderungen kontrolliert möglich sind.
Funktionierender Code ist ein Anfang. Eine wartbare Anwendung braucht darüber hinaus einen nachvollziehbaren Aufbau.
Die Zeitersparnis endet nicht beim Schreiben
Das Forschungsprogramm DORA veröffentlichte am 10. März 2026 eine Auswertung von 1.110 offenen Antworten von Google-Softwareentwicklern, erhoben im dritten Quartal 2025. Darin beschreiben Entwickler sowohl Vorteile bei der Codeerstellung als auch zusätzlichen Aufwand für Überprüfung, Korrektur und die Einbindung in bestehende Systeme. Die Untersuchung beruht auf qualitativen Rückmeldungen; sie ist keine allgemeine Messung des Produktivitätsgewinns sämtlicher Entwicklungsteams. [1]
Für mich liegt darin ein wichtiger Hinweis: Wer nur die Zeit bis zum ersten Entwurf betrachtet, bewertet lediglich einen Teil der Arbeit.
Zu einer fertigen Änderung gehören auch ihre Prüfung, die notwendige Dokumentation, die Veröffentlichung und die Beobachtung im Betrieb. Wenn eine schnell erzeugte Funktion später mehrere unübersichtliche Abhängigkeiten hinterlässt, ist die Rechnung noch nicht abgeschlossen.
KI würde ich deshalb weder pauschal ausbremsen noch nach der Menge ihres erzeugten Codes beurteilen. Interessant ist, ob sich eine Aufgabe insgesamt zuverlässiger erledigen lässt.
Architektur beginnt mit klaren Zuständigkeiten
Softwarearchitektur beschreibt unter anderem, wie eine Anwendung in Bestandteile gegliedert ist, welche Aufgaben diese übernehmen und wie sie miteinander zusammenarbeiten. Microsoft erläutert in seinen am 9. Oktober 2026 geprüften Architekturgrundsätzen die Trennung von Verantwortlichkeiten: Oberfläche, fachliche Regeln und technische Datenzugriffe sollten nicht beliebig ineinanderlaufen. [2]
Für eine kleine Kundenverwaltung würde ich beispielsweise diese Aufteilung prüfen:
Anmeldung und Berechtigungen: Identitäten prüfen und erlaubte Zugriffe durchsetzen.
Kundenverwaltung: Stammdaten und Ansprechpartner verwalten.
Auftragsbearbeitung: Leistungen, Bearbeitungsstände und Zuständigkeiten abbilden.
Dokumentenerstellung: Aus freigegebenen Informationen die vorgesehenen Dokumente erzeugen.
Diese Aufteilung ist ein Planungsbeispiel, keine vorgeschriebene Architektur.
Wichtig wäre mir, dass eine Änderung an der Dokumentengestaltung nicht gleichzeitig die Anmeldung beeinflusst. Ebenso sollte eine neue Importfunktion nicht eigene, abweichende Regeln für den Zugriff auf Kundendaten einführen.
Die KI darf dabei Vorschläge machen. Welche Grenzen gelten, muss das Entwicklungsteam jedoch bewusst entscheiden.
Ein kleineres System braucht nicht automatisch Microservices
Mehrere Module bedeuten nicht, dass jedes davon als eigener Dienst auf einem anderen Server laufen muss.
Bei einem modularen Monolithen bleibt die Anwendung eine gemeinsam ausgelieferte Einheit, ist intern aber in nachvollziehbare Bereiche gegliedert. Microservices verteilen Funktionen dagegen auf eigenständig betriebene Dienste. Microsoft weist in seiner am 9. Oktober 2026 geprüften Architekturübersicht auf die zusätzlichen Herausforderungen verteilter Systeme hin, darunter Kommunikation zwischen Diensten, Datenkonsistenz und komplexere Tests. [2][3]
Für die kleine Kundenverwaltung würde ich deshalb zunächst eine überschaubare, sauber strukturierte Anwendung bevorzugen. Einzelne Dienste würde ich erst dann auslagern, wenn ein konkreter Bedarf besteht.
Ein solcher Bedarf könnte beispielsweise entstehen, wenn eine rechenintensive Verarbeitung unabhängig vom restlichen System betrieben werden soll. „Die KI hat es so vorgeschlagen“ wäre für mich dagegen keine ausreichende Begründung.
Eine gute Architektur muss zur Aufgabe und zur betreibenden Mannschaft passen. Sie muss nicht möglichst kompliziert aussehen.
Die Aufgabe muss feststehen, bevor die KI sie umsetzt
Die Aufforderung „Baue eine Kundenverwaltung“ lässt sehr viel offen. Ein Assistent muss dann Entscheidungen treffen, die möglicherweise niemand ausdrücklich beauftragt hat.
Ich würde einen Arbeitsauftrag enger fassen. Welche Funktion wird ergänzt? Welche vorhandenen Module müssen verwendet werden? Welche Dateien dürfen geändert werden? Welche Bedingungen muss das Ergebnis erfüllen?
Ein geeigneter Auftrag könnte beispielsweise so beginnen:
Beispielauftrag: Ergänze im bestehenden Auftragsmodul eine Suchfunktion. Verwende die vorhandene Berechtigungsprüfung und Datenzugriffsschicht. Die Suche darf nur Aufträge des angemeldeten Unternehmens zurückgeben. Füge keine neue Bibliothek hinzu. Ergänze Tests für erlaubte und verweigerte Zugriffe.
Damit ist noch keine korrekte Umsetzung garantiert. Aber die anschließende Prüfung bekommt einen Maßstab.
Auch wichtige Architekturentscheidungen würde ich kurz festhalten: Was wurde entschieden, welche Alternative wurde verworfen und weshalb? Einige verständliche Absätze im Projekt können dafür ausreichen.
Diese Dokumentation sollte nicht erst entstehen, wenn niemand mehr weiß, warum eine ungewöhnliche Lösung eingebaut wurde.
Tests müssen die Anforderungen prüfen, nicht nur den erzeugten Code
Ein Programmierassistent kann Tests vorschlagen. Ich würde diese jedoch nicht allein deshalb akzeptieren, weil sie zusammen mit der Implementierung erzeugt wurden.
Wenn beide auf derselben falschen Annahme beruhen, kann ein grünes Testergebnis täuschen.
Bei unserer Beispielanwendung würde ich deshalb zuerst fachlich festlegen, was stimmen muss. Ein Benutzer darf keine fremden Kundendaten sehen. Eine fehlende Berechtigung muss zur Ablehnung führen. Eine ungültige Eingabe darf keinen unvollständigen Auftrag hinterlassen.
Erst anschließend würde ich prüfen, ob die Tests genau diese Anforderungen abdecken.
Als Orientierung für technische Sicherheitsprüfungen bietet OWASP den Application Security Verification Standard, ASVS, an. Die am 9. Oktober 2026 geprüfte Projektseite stellt Version 5.0.0 bereit und beschreibt den Standard als Grundlage für überprüfbare Sicherheitsanforderungen an Anwendungen. Er ersetzt keine individuelle Risikobewertung, hilft aber dabei, Sicherheitsprüfungen konkreter zu formulieren. [4]
Ein ausgeblendeter Schalter in der Oberfläche wäre in unserem Beispiel noch kein ausreichender Zugriffsschutz. Die Berechtigung muss auch dort geprüft werden, wo die Daten tatsächlich angefordert oder verändert werden.
Gerade solche Zusammenhänge würde ich nicht ausschließlich durch eine oberflächliche Vorführung beurteilen.
Auch eine automatische Codeprüfung braucht Kontrolle
Eine zweite KI über den ersten Entwurf schauen zu lassen, kann weitere Hinweise liefern. Es ist für mich aber kein Ersatz dafür, die entscheidenden Änderungen selbst zu verstehen.
GitHub empfiehlt in seiner am 9. Oktober 2026 geprüften Dokumentation ausdrücklich, die KI-gestützte Codeprüfung als Ergänzung menschlicher Prüfung zu verwenden. Die Rückmeldungen sollen überprüft werden, statt sie ungeprüft als richtig zu übernehmen. [5]
Ich würde deshalb überschaubare Änderungen bevorzugen. Eine sauber abgegrenzte Suchfunktion lässt sich leichter beurteilen als ein Paket, das nebenbei Anmeldung, Datenbankstruktur und Benutzeroberfläche umschreibt.
Bei der Freigabe möchte ich erkennen können, welche Anforderung erfüllt wurde, welche Risiken geprüft wurden und welche Änderungen bewusst nicht Teil des Auftrags waren.
Auch Zugriffsrechte des Programmierassistenten gehören zu dieser Entscheidung. Für gewöhnliche Entwicklungsaufgaben würde ich ihm keine produktiven Kundendaten oder umfassenden Administrationszugänge bereitstellen. Eine getrennte Arbeitsumgebung mit geeigneten Testdaten ist mein bevorzugter Ausgangspunkt.
Zur Architektur gehört der spätere Betrieb
Eine Anwendung muss nicht nur gestartet werden können. Sie muss sich auch aktualisieren, beobachten und bei Problemen wiederherstellen lassen.
NIST veröffentlichte im Februar 2022 das Secure Software Development Framework, Version 1.1. Der Leitfaden behandelt sichere Entwicklung als Bestandteil des gesamten Entwicklungsprozesses und zielt darauf, Schwachstellen zu reduzieren, ihre Auswirkungen zu begrenzen und Ursachen wiederkehrender Probleme zu bearbeiten. [6]
Für die Beispielanwendung würde ich vor der Veröffentlichung unter anderem einen Versionswechsel testen. Was geschieht, wenn sich die Datenbankstruktur ändert? Können vorhandene Daten korrekt übernommen werden? Wie erkennen wir, dass eine neue Version unerwartete Fehler verursacht?
Ein Rückweg muss ebenfalls vorbereitet sein. Einfach den vorherigen Programmstand einzuspielen, genügt möglicherweise nicht, wenn die neue Version bereits Daten verändert hat. Deshalb würde ich Wiederherstellung und Datenmigration gemeinsam planen.
Ebenso möchte ich Fehler nachvollziehen können, ohne unnötig vertrauliche Informationen in Protokollen abzulegen. Eine hilfreiche Fehlermeldung muss nicht den vollständigen Inhalt eines Kundendokuments enthalten.
Woran ich gute KI-Unterstützung erkennen würde
Für die Bewertung eines Programmierassistenten würde ich nicht zählen, wie viele Dateien er verändert oder wie viele Vorschläge übernommen werden.
Mich interessieren die Folgen: Sind Änderungen verständlich? Werden Fehler vor der Veröffentlichung entdeckt? Kann eine andere Person die Arbeit übernehmen? Bleiben Erweiterungen möglich, ohne jedes Mal große Teile der Anwendung anzufassen?
Ein sinnvoller Vergleich müsste deshalb auch Prüfaufwand, Nacharbeit und Probleme nach der Veröffentlichung berücksichtigen.
Wenn eine KI eine wiederkehrende Aufgabe zuverlässig vorbereitet und das Team anschließend mehr Zeit für fachliche Entscheidungen hat, ist das ein nachvollziehbarer Nutzen. Wenn sie vor allem mehr ungeprüfte Änderungen erzeugt, wurde zunächst nur Arbeit verlagert.
Mein Fazit: Verantwortung lässt sich nicht mitgenerieren
Ich halte KI für ein nützliches Werkzeug in der Softwareentwicklung. Sie darf beim Entwerfen, Erklären, Testen und Umsetzen unterstützen.
Die Verantwortung für die Anwendung bleibt jedoch bei den Menschen, die sie entwickeln und veröffentlichen. Sie müssen entscheiden, welche Daten geschützt werden, welche Fehler hinnehmbar sind und wie das System langfristig betreut wird.
Dazu braucht es kein besonders aufwendiges Architekturdiagramm. Es braucht klare Entscheidungen und eine Umsetzung, die sich daran prüfen lässt.
Gute Software entsteht nicht dadurch, dass möglichst schnell möglichst viel Code vorhanden ist. Sie entsteht, wenn nachvollziehbare Lösungen zuverlässig zusammenarbeiten.
Einordnung und Recherche
Recherchestand: 9. Oktober 2026. Die Beispiele dienen der allgemeinen Orientierung und ersetzen keine individuelle Architektur- oder Sicherheitsprüfung. DORA-Rückmeldungen sind qualitative Einschätzungen, keine allgemeine Produktivitätsmessung.
Quellen und weiterführende Informationen
Quellenprüfung am 09.10.2026. Abrufdaten sind keine Veröffentlichungsdaten. Hersteller-, Forschungs- und Behördenquellen wurden direkt geprüft.
[1] DORA: „Balancing AI tensions: Moving from AI adoption to effective SDLC use“
Quelle lesen ↗
[2] Microsoft Learn: Architekturgrundsätze und verbreitete Webanwendungsarchitekturen
Quelle lesen ↗
[2] Microsoft Learn: Architekturgrundsätze und verbreitete Webanwendungsarchitekturen
Quelle lesen ↗
[3] Microsoft Learn: „Microservices architecture style“
Quelle lesen ↗
[4] OWASP: „Application Security Verification Standard“
Quelle lesen ↗
[5] GitHub: „Application card: GitHub Copilot Agents“
Quelle lesen ↗
[6] NIST: „Secure Software Development Framework, Version 1.1“, SP 800-218
Quelle lesen ↗