KI in der Softwareentwicklung: Vom Coding Agent zum Engineering-Prozess

Die Diskussion über KI in der Softwareentwicklung leidet an zwei Extremen. Auf der einen Seite die Erwartung, ein Agent schreibe demnächst das komplette Produkt. Auf der anderen Seite die Abwehrhaltung, KI erzeuge grundsätzlich unbrauchbaren Code. Beides geht am realen Projektalltag vorbei. Interessant ist die mittlere Frage: Welche Teile eines Entwicklungsprozesses verändert KI tatsächlich – und welche nicht?

1. Was KI in der Entwicklung heute zuverlässig leistet

Sprachmodelle sind stark, wenn eine Aufgabe drei Eigenschaften hat: Sie ist sprachlich beschreibbar, sie folgt wiederkehrenden Mustern, und ihr Ergebnis ist maschinell überprüfbar. Trifft alles drei zu, ist der Produktivitätsgewinn real und messbar.

Typische Aufgaben in dieser Kategorie:

• Übersetzungsarbeit: Datenstruktur zu DTO, DTO zu Formular, Formular zu API-Aufruf, API-Antwort zu Tabellenansicht.
• Frontend-Implementierung gegen eine bekannte Schnittstelle, inklusive Zuständen, Validierungsmeldungen und Randfällen der Darstellung.
• Testgerüste für vorhandenen Code: Parametrisierung, Randwerte, Fixtures, Mocking-Boilerplate.
• Migrationen entlang klarer Regeln: Framework-Versionen, Namenskonventionen, Import-Umbau, Deprecation-Ersetzungen über viele Dateien.
• Erklärung fremden Codes – ein unterschätzter Anwendungsfall in der Wartung von Altsystemen.
• Erster Entwurf von Dokumentation, Commit-Nachrichten, Changelogs oder Review-Zusammenfassungen.

Was diese Aufgaben verbindet: Es gibt eine externe Instanz, die das Ergebnis beurteilen kann – ein Compiler, ein Typsystem, ein Test, ein Linter, ein Schema. Genau dort ist KI stark, weil Fehler schnell sichtbar und billig korrigierbar sind.

2. Codegenerierung ist nicht Software Engineering

Software Engineering besteht nicht nur aus dem Erzeugen von Quelltext. Es besteht aus einer Kette von Entscheidungen, die vor und nach dem Code liegen: Anforderungen klären, Fachlichkeit modellieren, Architektur festlegen, Schnittstellen vereinbaren, Qualität prüfen, ausliefern, betreiben, ändern. Codegenerierung adressiert einen einzigen Punkt dieser Kette.

Das ist kein Detail, sondern der entscheidende Unterschied für die Kalkulation. Wenn ein Agent die Implementierung um 60 % beschleunigt, die Implementierung aber nur 30 % des Gesamtaufwands ausmacht, liegt der Nettoeffekt bei knapp 20 %. Wenn gleichzeitig der Review-Aufwand steigt, weil mehr Code in kürzerer Zeit geprüft werden muss, kann der Effekt sogar negativ werden. Beschleunigung ohne Prozessanpassung erzeugt Rückstau an der nächsten Engstelle.

Drei Eigenschaften, die generierter Code nicht mitbringt

• Absicht. Der Code zeigt, was passiert, nicht warum es so entschieden wurde. Die Begründung – Alternativen, Trade-offs, fachliche Randbedingung – existiert nur, wenn sie jemand festhält.
• Verbindlichkeit. Ein Modell kann dieselbe Anforderung in zwei Läufen unterschiedlich lösen. Ohne explizite Regel gibt es keinen Grund, warum Projekt A und Projekt B dieselbe Struktur haben sollten.
• Nachweis. Dass etwas funktioniert, ist eine Behauptung, solange kein Test, kein Review-Vermerk und kein Build-Artefakt das belegen.

Deshalb ist der produktivste Umgang mit KI nicht „mehr Prompting“, sondern mehr Explizitheit außerhalb des Prompts: Modelle, Verträge, Regeln und Prüfungen, an denen sich generierter Code messen lassen muss.

3. Architekturkontext: Das Modell kennt Ihre Entscheidungen nicht

Ein Coding Agent sieht einen Ausschnitt: geöffnete Dateien, gefundene Treffer, vielleicht ein Projekt-Handbuch. Er sieht nicht die Diskussion aus dem letzten Architektur-Meeting, nicht die Mandantenfähigkeit, die in drei Modulen anders gelöst wurde, und nicht den Grund, warum eine bestimmte Bibliothek verboten ist.

Was nicht explizit vorliegt, wird plausibel erfunden. Das ist der Mechanismus hinter den meisten „seltsamen“ Agent-Ergebnissen – kein Modellfehler, sondern fehlender Kontext. Praktische Gegenmittel:

• Architekturentscheidungen schriftlich führen (ADRs) und im Repository ablegen, nicht im Wiki eines anderen Systems.
• Schnittstellen als Vertrag behandeln: OpenAPI, JSON Schema, Protobuf. Ein Vertrag ist für Menschen und Werkzeuge gleichermaßen lesbar.
• Fachliche Struktur modellieren statt sie nur zu implementieren: Entitäten, Relationen, Pflichtfelder, Validierungsregeln, Rollen und Rechte als Modell, nicht verstreut über Controller-Code.
• Projektregeln maschinenlesbar hinterlegen – Verzeichnis­konventionen, erlaubte Abhängigkeiten, Namensschemata –, damit sie sowohl im Review als auch im Agent-Kontext gelten.

Der Nebeneffekt ist bemerkenswert: Dieselbe Explizitheit, die einen Agent produktiv macht, macht auch die Einarbeitung neuer Entwickler und jedes Audit leichter. Kontext ist keine KI-Sonderaufgabe, sondern gute Engineering-Hygiene, die durch KI nur endlich einen unmittelbaren Nutzen bekommt.

4. Tests und Quality Gates: Der Flaschenhals verschiebt sich

Wenn Implementierung günstiger wird, wird Prüfung relativ teurer. Teams, die KI ernsthaft einsetzen, merken das nach wenigen Wochen: Nicht das Schreiben, das Verantworten von Code ist der Engpass.

Drei Konsequenzen für die Teststrategie:

1. Tests brauchen eine unabhängige Quelle. Ein Test, der aus demselben Kontext generiert wurde wie die Implementierung, bestätigt oft nur das Verhalten, nicht die Anforderung. Testfälle sollten aus der fachlichen Anforderung abgeleitet werden – notfalls in einem getrennten Schritt, bewusst ohne Blick auf die Implementierung.
2. Coverage ist ein schwaches Signal. Generierter Code erreicht hohe Zeilenabdeckung mühelos. Aussagekräftiger sind Grenzfälle, Fehlerpfade, Nebenläufigkeit, Berechtigungsprüfungen und – wo der Aufwand vertretbar ist – Mutationstests.
3. Gates gehören in die Pipeline, nicht in die Absprache. Eine Regel, die nur im Team-Handbuch steht, ist unter Zeitdruck keine Regel.

Ein sinnvoller Minimalsatz an automatischen Gates vor dem Merge – unabhängig davon, ob Code von Menschen oder Agents stammt:

# Minimal set of gates that must pass before merge.
# Applies to every change, regardless of who or what produced it.

build            # compiles / packages without warnings that matter
unit-tests       # deterministic, fast, no external services
contract-tests   # implementation still matches the published API contract
lint + format    # no style discussion inside code review
sast             # static application security testing
dependency-scan  # known vulnerabilities and license policy
secret-scan      # no credentials in the diff

Der Punkt ist nicht die konkrete Werkzeugliste, sondern die Verbindlichkeit: Was nicht durch das Gate kommt, wird nicht gemergt. Diese eine Regel entscheidet darüber, ob KI-Geschwindigkeit im Team ankommt oder ob sie sich in Nacharbeit auflöst.

5. Security: neue Fehlerklassen, bekannte Prüfmittel

Generierter Code bringt keine grundsätzlich neuen Schwachstellen hervor – die Klassiker aus den OWASP-Listen bleiben die Klassiker. Verändert hat sich die Verteilung: Fehler treten häufiger dort auf, wo das Modell plausibel raten muss.

• Autorisierung. Authentifizierung wird meist korrekt umgesetzt, die feingranulare Rechteprüfung pro Datensatz dagegen oft nur angedeutet. Objektbezogene Berechtigungen gehören ins Modell, nicht in den Prompt.
• Abhängigkeiten. Vorgeschlagene Pakete können veraltet, unerwünscht oder schlicht nicht existent sein. Ein Paketname, den es im Ökosystem nicht gibt, ist eine offene Einladung an Angreifer, ihn zu registrieren. Abhängigkeiten deshalb gegen eine kuratierte Quelle prüfen.
• Geheimnisse. Beispielkonfigurationen mit Platzhaltern landen erstaunlich oft mit echten Werten im Repository. Secret Scanning ist Pflicht, nicht Kür.
• Datenabfluss über die Werkzeugkette. Was ein Agent lesen darf, kann er auch verarbeiten. Das ist weniger ein Modellproblem als eine Frage von Rechten, Netzgrenzen und Betriebsmodell – siehe MCP und Berechtigungsgrenzen für AI-Agents.

Für Teams mit erhöhten Anforderungen kommt eine zweite Ebene hinzu: nicht nur ob geprüft wurde, sondern ob sich das später belegen lässt. Genau an dieser Stelle beginnt regulierte Softwareentwicklung.

6. Human Review: von der Zeilenprüfung zur Absichtsprüfung

Klassisches Code Review geht implizit davon aus, dass jemand über jede Zeile nachgedacht hat. Bei generiertem Code gilt das nicht. Ein Review, das weiterhin Zeile für Zeile Stil und Syntax prüft, bindet viel Zeit und findet wenig.

Wirksamer ist eine verschobene Prüffrage:

• Löst die Änderung die tatsächliche Anforderung – oder eine plausible Nachbarversion davon?
• Passt sie zur bestehenden Architektur oder führt sie ein zweites Muster für dasselbe Problem ein?
• Sind Fehler- und Berechtigungspfade behandelt, nicht nur der Erfolgsfall?
• Ist der Umfang prüfbar? Ein Diff über 4.000 Zeilen wird nicht wirklich gelesen, unabhängig von der Zusage im Review-Kommentar.

Formales – Formatierung, Import-Reihenfolge, Namenskonventionen – gehört vollständig in die Automatisierung. Menschliche Aufmerksamkeit ist die knappste Ressource im Prozess und sollte für Absicht, Architektur und Risiko reserviert bleiben. Kleinere Änderungssätze sind dabei kein Stilthema, sondern die Voraussetzung dafür, dass Review überhaupt funktioniert.

7. Traceability: „Wer hat das entschieden?“ wird schwerer

In einem klassischen Team beantwortet die Historie diese Frage recht gut: Ticket, Commit, Pull Request, Freigabe. Mit Agents entsteht eine Lücke – der Commit-Autor hat den Code nicht geschrieben, sondern beauftragt und geprüft. Das ist kein Problem, solange es sichtbar ist.

Praktisch heißt das: Die Verbindung zwischen Anforderung, Änderung, Prüfung und Release muss aus den Artefakten rekonstruierbar sein – nicht aus der Erinnerung der Beteiligten. Ein leichtgewichtiger Anfang sind strukturierte Commit-Trailer:

feat(billing): add dunning level to invoice model

Implements the escalation rules agreed in REQ-1042.
Generated with an AI coding assistant, reviewed and adjusted manually.

Requirement: REQ-1042
Reviewed-by: a.beck
Assisted-by: ai-coding-assistant

Das ersetzt kein Traceability-Konzept, macht die Frage aber beantwortbar. Wie eine durchgängige Kette von der Anforderung bis zum Release technisch aussieht, behandelt der Deep Dive Traceability: Requirement bis Release.

8. CI/CD: der Ort, an dem Regeln real werden

Jede Regel, die nicht in der Pipeline steht, ist eine Bitte. Das galt schon vorher, fällt aber stärker ins Gewicht, sobald Änderungen schneller entstehen, als ein Team sie diskutieren kann.

Eine Pipeline, die AI-gestützte Entwicklung trägt, unterscheidet sich weniger in den Schritten als in ihrer Verbindlichkeit und ihrer Nachweisführung:

• Reproduzierbarer Build aus einer versionierten Projektdefinition – gleicher Input, gleiches Artefakt.
• Automatische Gates als Merge-Voraussetzung, nicht als nachgelagerter Report.
• Signierte, versionierte Artefakte inklusive Stückliste der Abhängigkeiten (SBOM).
• Deployment in Ihre Zielumgebung – eigenes GitLab, Jenkins, On-Premise, Private Cloud oder Kubernetes –, nicht in eine fremde Blackbox.
• Auswertbare Protokolle: Welcher Stand wurde wann, von wem, mit welchem Ergebnis ausgeliefert?

Wie CodamAI diesen Schritt konkret abbildet, steht auf der Feature-Seite: Projektdefinition laden, Anwendung bauen, Container-Image erzeugen, Quality Gates ausführen, deployen.

9. Governance: Regeln statt Verbote

Der verbreitetste Fehler im Umgang mit AI Coding ist das pauschale Verbot. Es verhindert die Nutzung nicht, es verlagert sie nur an Orte, an denen niemand hinschaut. Eine belastbare Regelung beantwortet stattdessen vier Fragen:

1. Wo darf KI eingesetzt werden? Nach Projekt- oder Datenklassifikation, nicht pauschal.
2. Welche Daten dürfen das Unternehmen verlassen? Quellcode, Kundendaten, Betriebsgeheimnisse und personenbezogene Daten sind unterschiedliche Kategorien – das Betriebsmodell (Cloud, Private, On-Premise) folgt daraus.
3. Was muss geprüft werden, bevor es produktiv geht? Idealerweise identisch zu den Regeln für handgeschriebenen Code, ergänzt um die Besonderheiten aus Abschnitt 5.
4. Was wird dokumentiert? Minimal: dass KI eingesetzt wurde, wer geprüft hat und woran geprüft wurde.

Wie sich diese vier Fragen zu einer knappen, durchsetzbaren Regelung zusammenfassen lassen, beschreibt der Deep Dive AI Coding Governance.

Für Organisationen mit Managementsystem lässt sich das an vorhandene Strukturen andocken – etwa an ein Qualitätsmanagement nach ISO 9001, an ein Informationssicherheits-Managementsystem nach ISO/IEC 27001 oder an ein KI-Managementsystem nach ISO/IEC 42001. Wichtig ist die nüchterne Einordnung: Diese Normen zertifizieren Managementsysteme und Organisationen, nicht ein einzelnes Softwareprodukt und erst recht nicht ein eingesetztes Werkzeug.

10. Einsatzmuster für Softwarehäuser

Softwarehäuser haben eine Besonderheit: Sie bauen dieselbe technische Basis in jedem Kundenprojekt erneut – Benutzerverwaltung, Rollen und Rechte, Mandanten, Stammdaten, Berechtigungslogik, Reporting-Grundlagen. Dieser Anteil ist fachlich uninteressant, aber wartungsintensiv und haftungsrelevant.

Daraus ergibt sich eine klare Dreiteilung:

Der wirtschaftliche Hebel liegt selten im schnelleren Tippen. Er liegt darin, dass wiederkehrende Basisarbeit aus der Projektkalkulation verschwindet und dass Qualitätsanforderungen nicht in jedem Projekt neu verhandelt werden müssen. Wer KI einführt, ohne diese Basis zu standardisieren, bekommt vor allem eines: schneller erzeugte Vielfalt.

Checkliste: KI im Entwicklungsprozess

Fazit

KI verändert die Softwareentwicklung nicht dadurch, dass sie Engineering ersetzt, sondern dadurch, dass sie den unstrukturierten Teil der Arbeit billig macht. Was übrig bleibt, ist genau das, was Software zu einem verantwortbaren Produkt macht: explizite Modelle, geprüfte Schnittstellen, belastbare Tests, nachvollziehbare Entscheidungen und eine Auslieferung, die man wiederholen kann.

Teams, die diese Struktur vorher hatten, gewinnen durch KI deutlich. Teams, die sie nicht hatten, bekommen ihre Lücken schneller präsentiert. Der sinnvolle nächste Schritt ist deshalb selten „mehr KI“, sondern mehr Explizitheit an den Stellen, an denen Kontrolle gebraucht wird.