AI Software Development – Wie AI Agents unser Engineering verändern

Wer Software entwickelt und dabei Code schreibt, hing früher ständig in Dokumentationen, Stack Overflow & Co. fest. Heute sind diese Tabs bei uns meistens geschlossen – nicht, weil wir plötzlich jede Library auswendig kennen, sondern weil sich die Art, wie wir Software entwickeln, fundamental verändert hat.

In der Logistics-Domäne entwerfen und betreiben wir Event-Driven Microservices auf AWS: Lambda, API Gateway, DynamoDB, SNS, SQS, Kafka und S3 – vollständig serverless, auf Laufzeit optimiert und nah an den AWS SDKs. Um eine Größenordnung dieser Architektur-Herausforderung zu verdeutlichen: Allein über eine unserer synchronen HTTP-APIs verarbeiten wir monatlich mehrere Milliarden Updates. Diese werden in der API rudimentär validiert (Kennen wir die ID? Liegt der Wert im gültigen Bereich?) und direkt mit qualifiziertem Feedback quittiert. Anschließend fließen die Daten asynchron in unsere tieferliegende Domain-Logik und werden in wenigen Millisekunden weiterverarbeitet.

Wie wir diese Systemlandschaft skalieren und ausfallsicher betreiben, könnte einen eigenen Cloud-Architecture-Artikel füllen. Hier soll es um etwas anderes gehen: Wie wir als Engineering-Organisation diese Services entwickeln.

Das reine AI Software Development hat sich bei uns dabei zu echtem AI-Assisted Engineering weiterentwickelt – und auf diesem Weg ist AI vom Werkzeug zum Partner geworden.

Der erste echte Wandel war subtil. Wir entwickelten klassisch im Pair: zwei Entwickler*innen, ein Problem, ein Bildschirm. Irgendwann gesellte sich ein dritter Partner dazu. Aus dem Pair wurde ein Mob – Mensch, Mensch, AI.

Die unzähligen Browser-Tabs für SDK-Dokumentationen verschwanden, weil es schlicht effizienter war, die Frage direkt in den Copilot-Chat zu tippen. Die kognitive Unterbrechung durch ständigen Kontextwechsel fiel weg. Allein das beschleunigte unsere Entwicklungsgeschwindigkeit spürbar und verkürzte die Time-to-Market erheblich.

Mit GitHub Copilot und dem bei uns standardmäßig aktivierten Agent Mode kam das, was heute oft „Vibe-Coding“ genannt wird und damit die nächste Stufe des AI Software Development. Wir arbeiten iterativ und explorativ mit der AI und wählen das LLM (ChatGPT, Gemini, Claude etc.) je nach Aufgabe direkt in der IDE aus: Ein Modell überzeugt mehr beim System Design, ein anderes eignet sich besser für das Schreiben von Skripten.

Anfangs galt bei uns eine klare Regel: AI Ergebnisse blind zu übernehmen ist keine Option. Daran hat sich auch nichts geändert – unsere Unternehmensrichtlinien sind hier eindeutig. Doch durch immer leistungsfähigere Modelle verschiebt sich unser Fokus spürbar: vom Selberschreiben hin zum kritischen Reviewen. Der entscheidende Hebel liegt dabei nicht im Code, sondern in der Art, wie wir der AI unsere Anforderungen übermitteln.

Vibe-Coding stieß irgendwann an Grenzen. Die Erkenntnis: AI ist nur so gut wie der Kontext, den wir ihr geben. Hier setzt Spec-driven Development an. Für uns bedeutet das mehr als „erst ein Ticket, dann Code“. Es ist das verbindende Element zwischen Architektur, Code und AI.

Um diese Standards skalierbar zu machen, haben wir ein historisches Problem gelöst: Architekturentscheidungen waren früher über Confluence verteilt – ohne Versionierung, ohne Integration in den Review-Prozess. Heute liegt unsere Architektur vollständig in Git. Sie ist nicht mehr Dokumentation über das System, sondern Teil des Systems selbst.

Ein entscheidender Faktor dabei: All diese Dokumente – insbesondere unsere Architecture Decision Records (ADRs), C4 Modelle und ACCs – folgen einer harten Struktur und einer festen Nomenklatur. Nur wenn Begriffe und Formate konsistent bleiben, kann die AI den Kontext ohne Spielraum für Fehlinterpretationen verarbeiten.

Unsere Architektur ruht auf fünf Säulen:

Im Zentrum unseres Architektur Repositories liegt die basis-constitution.md: unser verbindliches Grundgesetz. Sie definiert globale Architektur und Security-Standards wie Serverless-First oder die Einhaltung der OWASP Top 10. Ihre wichtigste Regel: Schreibe die Spezifikation, bevor du Code schreibst. Jede Service-Constitution darf dieses Grundgesetz erweitern, aber niemals abschwächen.

Jede signifikante Entscheidung – sei es die Migration von SNS zu Kafka oder ein Technologie-Wechsel – wird nach einem strikten Template als Markdown im Git dokumentiert. Durch diesen identischen, strukturierten Aufbau der ADRs liest der AI-Agent den fachlichen Kontext und die Trade-Offs fehlerfrei aus. Jedes Prinzip in der Constitution verweist direkt auf diese zugrunde liegenden ADRs – für Entwickler*innen wie für AI transparent.

Unsere Architektur visualisieren wir mittels C4 und haben diesen Schritt mittels PlantUML und der Pipeline auf Context-, Container- und Component-Ebene automatisiert. Dabei trennen wir bewusst zwischen Current und Vision: Die Diagramme zeigen nicht nur, wo wir stehen, sondern auch, wohin wir uns entwickeln wollen. (Lese-Tipp: Wie wir C4-Modelle bei OTTO generell nutzen, liest du in diesem Techblog-Artikel.)

Nicht jeder Stakeholder möchte Diagramme lesen. ACCs übersetzen technische Systeme in Business-Mehrwert: Value Proposition, Qualitätsanforderungen, Stakeholder. Durch dieses einheitliche Template weiß der AI-Agent bei jedem Service exakt, wo er den fachlichen Kontext findet.

Bevor Code geschrieben wird, werden Features über detaillierte Service-Specs beschrieben: User Stories, Akzeptanzkriterien, Datenmodelle und Tasks. Die Abfolge ist verbindlich: Tests first, dann Implementierung. Erst auf dieser strukturierten Grundlage generiert die AI produktiven Code – ohne raten zu müssen.

Auf dieser strukturierten Basis arbeiten wir inzwischen nicht mehr nur mit einem generischen Assistenten, sondern mit einem kleinen Ökosystem spezialisierter Agents.

Ein Architecture-Agent prüft Architekturentscheidungen gegen Constitution, ADRs, C4 Modelle, ACCs, AWS Well-Architected-Säulen und Domänengrenzen. Ein Implementation-Agent setzt darauf aufbauend Spec-driven Development um und begleitet den Weg von Specify über Clarify und Plan bis zur Implementierung. Ein Review-Agent prüft den erzeugten Code gegen Spezifikation, Plan, Architektur und Sicherheitsanforderungen, bevor ein PR entsteht. Und ein allgemeiner Story-Agent kann aus bestehendem Wissen neue Jira Stories formulieren oder bestehende Stories verbessern.

Der Gewinn liegt nicht nur in Automatisierung, sondern in der klaren Aufteilung von Verantwortlichkeiten. Architektur, Umsetzung, Review und Story-Formulierung sprechen dieselbe Sprache, arbeiten aber in spezialisierten Rollen. Genau dadurch steigt die Qualität, ohne dass der Workflow schwerfälliger wird, und Wissen lässt sich besser wiederverwenden und skalieren.

Abbildung: Ein Blick in unser Architecture Repository: Constitution, ADRs, C4-Modelle und ACCs leben versioniert als Code in Git

Wie verzahnt sich das im Alltag? In jedem Service Repository greifen die Agents über copilot-instructions.md, Constitution, C4 Modelle und ACCs auf denselben strukturierten Wissensraum zu. Dadurch wird nicht nur Spec-driven Development mit besseren Eingaben versorgt, sondern die Agents selbst können Architektur, Implementierung und Review in einem gemeinsamen Regelwerk ausführen.

Unser Regelwerk ist klar: Wenn grundlegende Änderungen vorgenommen werden – etwa an der Infrastruktur via Terraform oder an Domain-Grenzen im Sinne von Domain-driven Design, müssen die entsprechenden Architekturartefakte aktualisiert werden. So bleibt die Architektur nicht nur dokumentiert, sondern auch konsistent mit der tatsächlichen Implementierung.

GitHub Copilot kann dabei als Reviewer agieren. Fehlt eine Spezifikation oder Dokumentation, blockiert die AI nicht stumpf, sondern erzeugt im Idealfall direkt einen Entwurf. Governance wird dadurch nicht zur Bremse, sondern zum integrierten Bestandteil des Entwicklungsflusses.

Ein Live-Incident wurde durch Auffälligkeiten im API-Verhalten entdeckt: Im AWS API Gateway traten erhöhte 4xx-Raten auf. Unser Ziel war es, das Monitoring zu verstärken und künftig proaktiv über die bestehenden Kanäle alarmiert zu werden, falls dieser Fall erneut auftritt. Mehr Kontext gab es zunächst nicht.

Ab hier übernahmen die spezialisierten Agents im Zusammenspiel:

• Analyse: Der Story Agent nutzte den Architecture Agent und den Code Agent, um die bestehende Architektur und die Metriken zu prüfen.
• Lösungsvorschlag: Die Agents erkannten, dass das API Gateway bereits passende Standard-Metriken liefert, und schlugen zwei CloudWatch-Alarme vor (einen für 4xx, einen für 5xx).
• Fachliche Klärung: Die passenden Schwellwerte wurden gemeinsam mit den Experten geklärt und direkt im Ticket dokumentiert.
• Umsetzung & Freigabe: Die fertige Story ging an den Implementierungs-Agenten inkl. AI Review. Ein abschließendes menschliches Review gab die Änderungen für das automatische Deployment frei.

Das Ergebnis: Vom Live-Incident bis zum produktiven Deployment inklusive Dokumentation dauerte es weniger als 30 Minuten – sämtlicher Code wurde von der AI erstellt.

Abbildung: KI-gestützter Workflow für die Reaktion auf  einen Live-Incident

Während wir mit Git-basierter Architektur-Governance etabliert haben, steht die nächste Automatisierungsstufe bereits heute im Blickfeld: nicht mehr ein einzelner Allzweck-Agent, sondern ein kleines Ökosystem spezialisierter Agents, die in der Praxis schon erprobt werden.

Ein Agent kennt das vollständige Architekturwissen und kann ADRs, C4-Modelle und ACCs sicher zusammenführen. Ein anderer ist darauf spezialisiert, aus fachlichem Input saubere Jira-Stories und Spezifikationen zu formulieren oder bestehende Stories zu verbessern. Wieder ein anderer kann auf dieser Basis den technischen Plan ableiten und dabei unsere Architektur-Leitplanken berücksichtigen.

MCP ist dabei eine mögliche Integrationsschicht, um diese Agents strukturiert mit unseren Wissensquellen zu verbinden. Entscheidend ist für mich aber nicht die einzelne Technologie, sondern dass die Agents vernetzt auf die richtigen Quellen zugreifen und im Zusammenspiel bessere Ergebnisse liefern als ein allgemeiner Assistent.

Über den vernetzten Kontext passiert dann die eigentliche Arbeit im Hintergrund:

1. Der Agent liest das Ticket und springt zum Parent-Ticket, also zum Epic, um den fachlichen Rahmen zu verstehen.
2. Er zieht bei Bedarf verlinkte Confluence-Seiten heran, um Business-Value, KPIs oder Diagramme mitzunehmen.
3. Gleichzeitig berücksichtigt er die relevanten Architektur-Artefakte aus Git: Basis-Constitution, service-spezifische Constitution und ADRs.
4. Aus diesem Wissen erzeugt oder verbessert er die formale Spezifikation.
5. Auf dieser Grundlage kann anschließend der technische Plan entstehen, bei dem wir als Entwickler und Architekten nur noch dort eingreifen, wo echte Entscheidungsspielräume bestehen.

Abbildung: KI-Agenten-Architektur mit Orchestrator, Architektur-Agent, Code-Agent, Review-Agent und Jira-Integration

Die wichtigste Erkenntnis: Die Ära des reinen Code-Schreibens ist vorbei. AI Software Development wird zum neuen Standard – und entwickelt sich zu echtem AI-Assisted Engineering.

• Vom Implementierer zum System-Designer und Reviewer. Der Fokus verlagert sich: Es geht darum, fachliche Probleme zu durchdringen, Systemgrenzen sauber zu definieren und den von der AI generierten Code als kritische Qualitätsinstanz zu prüfen.
• Präzise Spezifikationen als wichtigste Programmiersprache. Wer vage Anforderungen stellt, bekommt vagen Code - oder im schlimmsten Fall KI-Halluzinationen (Lese-Tipp: wie gutes Technical Writing dagegen hilft, haben wir hier beschrieben). Nutzt eure Jira-Tickets und Architektur-Entscheidungen aktiv als Input für eure LLMs.
• Etabliert klare Leitplanken. Verlasst euch nicht darauf, dass die AI Unternehmensrichtlinien oder Security-Standards von allein kennt. Dokumentiert eure Architektur-  und Security-Regeln maschinell lesbar, sodass sie für Entwickler*innen und Agenten gleichermaßen als verlässlicher Rahmen dienen.
• Investiert in automatisierte Test-Pipelines. Egal ob ihr striktes Trunk-based Development nutzt oder andere Wege geht: Ein hohes Maß an Testautomatisierung und verlässliche CI/CD-Pipelines sind der beste Weg, um das Tempo der KI sicher auf die Straße zu bringen.

Abbildung: Kein Vertrauen in AI-Code ohne Netz und doppelten Boden