# Mission 007: AI verändert Software Engineering

> Wie ändern sich Entwicklung, Review, Testing, Plattformen und Software-Lieferketten?

**Ergebnis:** Produktive AI-Unterstützung mit überprüfbaren Artefakten und sicherer Supply Chain.

Veröffentlicht 24.06.2026 · zuletzt geändert 25.06.2026 · fachlich geprüft von Markus Berg (25.06.2026) · für Entwicklung, Plattform, Security.

## In 30 Sekunden
Mehr generierter Code ist nur dann ein Fortschritt, wenn Plattform, Tests, Architekturregeln und Software-Lieferkette Schritt halten. AI-native Entwicklung verschiebt Aufwand von Tippen zu Spezifizieren, Prüfen und Absichern.

## Warum das wichtig ist
Wenn Code schneller entsteht, als er geprüft werden kann, verlagert sich das Risiko in Reviews, Tests und Supply Chain. Geschwindigkeit ohne Quality Gates erzeugt schneller technische Schulden.

Specification-driven Development, automatisierte Quality Gates und Provenienz der Artefakte halten die Qualität, wenn die Menge des generierten Codes steigt.

_Redaktionelle Einordnung:_ Der Engpass verschiebt sich von „Code schreiben“ zu „Code verantworten“. Architecture Fitness Functions und eine AI-SBOM sind dann kein Overhead, sondern das, was Tempo überhaupt erst sicher macht.

## Zentrale Architekturfragen
- Wie wird generierter Code automatisiert auf Qualität und Sicherheit geprüft?
- Sind Architekturregeln als ausführbare Fitness Functions hinterlegt?
- Kennen wir die Herkunft (Provenance) unserer Artefakte und Modelle?
- Wie sicher sind die eingesetzten Coding-Agenten selbst?
- Halten Plattform und Golden Paths mit dem Tempo Schritt?

## Typische Muster
- **Specification-driven Development:** Spezifikation vor Generierung.
- **Quality Gates:** automatisierte Tests und Checks als Pflichtschranke.
- **ADRs & Golden Paths:** dokumentierte Entscheidungen und sichere Standardwege.
- **Provenance & AI-SBOM:** nachvollziehbare Herkunft von Code, Modellen und Daten.
- **Architecture Fitness Functions:** Architekturregeln automatisiert geprüft.

## Anti-Patterns
- Generierter Code geht ohne Review oder Tests in Produktion.
- Architekturregeln existieren nur als PDF, nicht als Check.
- Keine Herkunftsinformation zu Modellen und Abhängigkeiten.
- Coding-Agenten mit weitreichenden Rechten ohne Absicherung.

## Praktische Prüffragen
- Durchläuft generierter Code dieselben Gates wie handgeschriebener?
- Sind unsere zentralen Architekturregeln automatisiert prüfbar?
- Haben wir eine AI-SBOM für kritische Systeme?
- Sind die Rechte unserer Coding-Agenten begrenzt und auditierbar?

## Bezug zum Praxisbeispiel (Service-Agent)
Wie wird der Agent entwickelt, getestet und versioniert — und wie sicher ist seine Lieferkette?

- Prompts, Tool-Definitionen und Modellversionen sind versioniert und durchlaufen Reviews und Freigaben.
- Generierter Code durchläuft dieselben Quality Gates wie handgeschriebener.
- Die Herkunft von Code, Modellen und Daten ist nachvollziehbar (Provenance / AI-SBOM).
- Architekturregeln sind als ausführbare Fitness Functions hinterlegt, nicht nur als Dokument.

[Zum durchgehenden Praxisbeispiel](https://agent-007.ai/praxis/service-agent.md)

## Bezug zur Referenzarchitektur
Diese Mission betrifft die Plattform-Ebene und die Supply Chain. Sie sorgt dafür, dass die in den anderen Missionen entworfenen Systeme überprüfbar gebaut und sicher ausgeliefert werden.

## Primärquellen
- [SLSA — Supply-chain Levels for Software Artifacts](https://slsa.dev/) — OpenSSF (Spezifikation), geprüft 24.06.2026. Integrität und Provenienz der Software-Lieferkette.
- [CycloneDX ML-BOM](https://cyclonedx.org/capabilities/mlbom/) — OWASP / CycloneDX (Spezifikation), geprüft 24.06.2026. Maschinenlesbare Stückliste für ML-/KI-Bestandteile (AI-SBOM).
- [MITRE ATLAS](https://atlas.mitre.org/) — MITRE (Primärquelle), geprüft 24.06.2026. Bedrohungen gegen KI-fähige Systeme — relevant für sichere Coding-Agenten.



---
Quelle (kanonisch): https://agent-007.ai/missionen/007-ai-native-software-engineering/