Referenzprojekt

Agenten in jeder Rolle des Software-Lebenszyklus

Das Referenzprojekt zeigt ein mandantenfähiges SaaS-Produkt für mehrere Kundenmarken und die Arbeitsweise, mit der es entwickelt und betrieben wird. Diese Arbeitsweise deckt den gesamten Software-Lebenszyklus ab – von Anforderungen und Planung über Implementierung, Tests, Review und Dokumentation bis hin zu Release und Betrieb. Für fast jede Rolle gibt es Agenten, die die Arbeit ganz oder zum grössten Teil übernehmen.

Jeder Agent hat eine klar definierte Rolle und arbeitet nach schriftlich festgehaltenen Abläufen. Für seine Arbeit gelten bei jeder Änderung dieselben Prüfungen. Das macht das Ergebnis verlässlich: Es hängt nicht davon ab, welcher Agent oder welche Person die Aufgabe gerade übernommen hat.

Ein Klick auf eine Box erklärt, wozu der Baustein dient und was er jemandem bringt, der die Auslieferung verantwortet.

Wie gearbeitet wird

1Eine Arbeitsweise für alle sechs CodebasenAgentenrollen · festgelegte Abläufe · feste Regeln · automatische Sicherheitsstopps2Anleitungen in jeder CodebasisAnweisungen für Agenten · Dokumentation für Agenten · lokale Abläufe · Checks3Auslieferungautomatische Tests und Builds · Sicherheitsscan · Demo aktualisiert sich selbst · Produktiv-Release startet ein Mensch4Tickets und Release-Protokolldas Backlog · Prozesse · Anforderungen · Release-Protokoll · Betriebsanleitungen

↓arbeitet an

Die sechs Codebasen

die Kerndienste des Produkts

5Konten und Einwilligungenwer ein Konto hat – und wozu eingewilligt wurde6Geschäftsregelnwas angeboten wird, wie es verkauft und wie es bezahlt wird7DateienHochladen · Überprüfen · Ablegen

Anmeldung

8Anmeldungein Login für Web, Apps und Services · ein eigener Auftritt pro Marke · eine separate Admin-Konsole

Apps

9Web- und Mobile-Appseine Web-App für alle Marken · Mobile-Apps · eine einbettbare Version · Dokumentation für Anbieter

Betrieb

10Betrieb und Sicherheitsnachweisedas Verzeichnis aller Services, Umgebungen und Secrets · Betriebsanleitungen · Sicherheits- und Audit-Nachweise

↓läuft als

Was produktiv läuft

11Cloud-HostingMicrosoft Azure · Demo- und Produktivumgebung nebeneinander · verwaltete Datenbank · Monitoring und Alarme12KI im ProduktText · Moderation · Bilder · Recherche13App Stores und App-UpdatesApp Store · Google Play · Updates am selben Tag · Push-Benachrichtigungen14DrittdiensteZahlungen · E-Mail · Adresserfassung · Bot-Schutz · Webanalyse

1. 1Eine Arbeitsweise für alle sechs Codebasen Agentenrollen · festgelegte Abläufe · feste Regeln · automatische Sicherheitsstopps. Die Konfiguration, die sich alle Codebasen teilen, aufgesetzt auf Claude Code: Agenten als Rollen mit einer fest zugewiesenen Aufgabe, schriftlich festgelegte Abläufe für wiederkehrende Arbeit, eine feste Regel dafür, welche Tests sich zu schreiben lohnen, und automatische Stopps, die destruktive Befehle blockieren. Weil es eine einzige Konfiguration ist, gilt eine hier angepasste Regel sofort in allen Codebasen. Die Agenten können die Produktivdatenbanken lesen, aber nicht verändern. Lange, mechanische Arbeit läuft unbeaufsichtigt, bis ein vorher festgelegtes Abschlusskriterium erfüllt ist.
2. 2Anleitungen in jeder Codebasis Anweisungen für Agenten · Dokumentation für Agenten · lokale Abläufe · Checks. Jede Codebasis bringt ihre eigenen Anweisungen für die Agenten mit, die grösseren zusätzlich eine eigens für Agenten geschriebene Dokumentation. Eine Änderung beginnt so mit einer Landkarte und nicht mit der Frage, wie die Codebasis zusammenhängt. In der grössten Codebasis wird auch diese Landkarte selbst geprüft: Eine Änderung scheitert, wenn die Dokumentation einen Pfad oder einen Befehl nennt, den es nicht mehr gibt. Unbemerkt veralten kann die Anleitung damit nicht. Auch Abläufe, die nur eine Codebasis betreffen – etwa das Aufsetzen einer neuen Marke –, liegen hier. Weiterlesen: Architekturgrenzen automatisch prüfen
3. 3Auslieferung automatische Tests und Builds · Sicherheitsscan · Demo aktualisiert sich selbst · Produktiv-Release startet ein Mensch. Jede Änderung durchläuft automatisch Tests, Build und einen Scan auf bekannte Sicherheitslücken, und die Demo-Umgebung aktualisiert sich von selbst. So sieht man eine Änderung laufen, bevor jemand über ihr Release entscheidet. Das Produktiv-Release ist dann ein einzelner Schritt, den ein Mensch startet; alles davor ist schon getan. Die Web- und Mobile-Apps durchlaufen dieselben Stufen, und auch ihr Produktiv-Release startet ein Mensch. Weiterlesen: Ein Agent löst das Jira-Ticket, ein Mensch entscheidet, wo es darauf ankommt
4. 4Tickets und Release-Protokoll das Backlog · Prozesse · Anforderungen · Release-Protokoll · Betriebsanleitungen. Backlog und Dokumentation des Teams sind für die Agenten zugänglich. Ein einziger Ablauf führt ein Ticket von der Analyse über die Umsetzung bis zum Review, und so nimmt jedes Ticket denselben Weg, egal wer es aufnimmt. Ein Produktiv-Release trägt der Ablauf, der es erkennt, selbst ins Release-Protokoll ein. Was wann live ging, wird damit festgehalten, während es geschieht, und nicht nachträglich zusammengesucht. Weiterlesen: Ein Agent löst das Jira-Ticket, ein Mensch entscheidet, wo es darauf ankommt
5. 5Konten und Einwilligungen wer ein Konto hat – und wozu eingewilligt wurde. Hier ist erfasst, wer ein Konto hat und wozu jede Person eingewilligt hat, dazu jeder Kanal, über den die Plattform Nachrichten verschickt. Die Schnittstellen werden als Vereinbarung festgehalten, bevor es Code dafür gibt. Wer auf einer der beiden Seiten daran arbeitet, geht von der Vereinbarung aus, nicht vom Code der Gegenseite. Die einzige Vereinbarung, von der ein anderer Service abhängt, wird bei jedem Build geprüft: Eine Abweichung stoppt den Build, statt erst aufzufallen, wenn beide Services zusammenspielen. Weiterlesen: Architekturgrenzen automatisch prüfen
6. 6Geschäftsregeln was angeboten wird, wie es verkauft und wie es bezahlt wird. Hier stecken die Geschäftsregeln des Produkts, Zahlungen und Rechnungsstellung eingeschlossen. Jede Regel, die über ein Ergebnis oder einen Preis entscheidet, wird in diesem einen Service durchgesetzt; die Apps zeigen nur das Resultat. Ändert sich eine Regel, ändert sie sich an einer Stelle, und alle Apps und Marken ziehen mit. Dass zwei Apps einem Kunden unterschiedliche Beträge nennen, ist damit ausgeschlossen.
7. 7Dateien Hochladen · Überprüfen · Ablegen. Eine einzige Aufgabe: eine hochgeladene Datei annehmen, prüfen, ob sie ist, was sie zu sein vorgibt, sie ablegen und dem Datensatz zuordnen, zu dem sie gehört. Jeder Upload durchläuft hier dieselben Checks, egal über welche App er kommt. Wer versteckten Code in einer Datei einschleusen will, trifft also auf eine einzige bewachte Tür, nicht auf eine pro App. Die Dateien liegen in der Hauptdatenbank, was ein System weniger im Betrieb bedeutet – eine Vereinfachung, die sich die Plattform bei ihrer heutigen Grösse leisten kann.
8. 8Anmeldung ein Login für Web, Apps und Services · ein eigener Auftritt pro Marke · eine separate Admin-Konsole. Ein einziger Anmeldedienst bedient das Web, die Mobile-Apps und die Services dahinter, und jede neue Registrierung wird der Plattform automatisch gemeldet. Die dreizehn Markenauftritte sind Farb- und Logo-Schichten über einem gemeinsamen Design. Eine neue Marke ist damit eine zusätzliche Schicht und kein eigenes Login, das entwickelt und gewartet werden muss. Die Konsole, mit der sich Benutzerkonten verwalten lassen, läuft unter einer eigenen Adresse, die nur aus freigegebenen Netzen erreichbar ist. Was öffentlich erreichbar ist, kann keine Benutzerkonten verwalten.
9. 9Web- und Mobile-Apps eine Web-App für alle Marken · Mobile-Apps · eine einbettbare Version · Dokumentation für Anbieter. Eine Codebasis enthält die Web-App für jede Marke, die Mobile-Apps, eine einbettbare Version und eine aus dem Code abgeleitete Dokumentation für Anbieter, alles aus 23 gemeinsamen Bausteinen zusammengesetzt. Die eigene Mobile-App einer Marke ist ein Theme und ein Konfigurationseintrag, kein neues Projekt, und so bekommt jede Marke dieselben Screens und dieselben Fixes. Bevor hier eine Änderung festgeschrieben wird, prüfen 26 Checks, die eigens für diese Codebasis geschrieben wurden, ob jeder Screen in jeder App vorhanden und jede Sprache vollständig ist. Eine Lücke fällt so in Sekunden auf, nicht erst in einem Review-Kommentar. Weiterlesen: Architekturgrenzen automatisch prüfen
10. 10Betrieb und Sicherheitsnachweise das Verzeichnis aller Services, Umgebungen und Secrets · Betriebsanleitungen · Sicherheits- und Audit-Nachweise. Kein Service, sondern das zentrale Verzeichnis jedes Services, jeder Umgebung und jedes Secrets, dazu die Betriebsanleitungen und Abläufe, mit denen Services und Umgebungen betrieben werden. Secrets sind nur als benannte Referenzen erfasst, ihre Werte liegen in einem Tresor. So lässt sich eine Umgebung aufsetzen, ohne dass jemand einen dieser Werte sieht. Für Sicherheitsfragen gibt es laufend aktualisierte Nachweise: die bekannten Schwachstellen jeder Codebasis, wer Produktiv-Adminrechte hat, und die Unterlagen, die ein Kartenzahlungs-Audit verlangt – auch diese automatisch geprüft. Der Code, der die Daten einer Person löscht, wird aus expliziten Eingaben erzeugt; kein Modell schreibt ihn frei.
11. 11Cloud-Hosting Microsoft Azure · Demo- und Produktivumgebung nebeneinander · verwaltete Datenbank · Monitoring und Alarme. Alles, was für das Produkt läuft, liegt auf einer verwalteten Plattform: eine Demo- und eine Produktivumgebung nebeneinander, die Daten in einer verwalteten Datenbank. Beobachten muss man damit nur eine Stelle. Das Monitoring zeichnet auf, was das System tut, und Alarme schlagen bei den dafür festgelegten Bedingungen an. Tritt eine davon ein, wird jemand benachrichtigt, statt dass es erst zufällig auffällt.
12. 12KI im Produkt Text · Moderation · Bilder · Recherche. Die KI, die das Produkt selbst nutzt – getrennt von der KI, mit der es entwickelt wird. Über die KI-Dienste von Microsoft und Google schreibt sie Texte, moderiert Inhalte, erzeugt Bilder und recherchiert mithilfe der Websuche. Nur der Service mit den Geschäftsregeln ruft ein Modell auf, die Apps nie. Was das Produkt an einen KI-Dienst schickt, lässt sich damit an einer Stelle einsehen und an einer Stelle ändern.
13. 13App Stores und App-Updates App Store · Google Play · Updates am selben Tag · Push-Benachrichtigungen. Beide Mobile-Apps erreichen ihre Nutzer über den App Store und Google Play. Eine Änderung, die keine neue Store-Version braucht, wird nach der Freigabe direkt auf die installierten Apps ausgespielt. Ein Fix ist so noch am selben Tag bei den Nutzern, statt erst nach einer Store-Prüfung. Über eine Fernkonfiguration erfährt eine installierte App, wann sie aktualisiert werden muss. Eine alte Version lässt sich so ausser Betrieb nehmen, statt sie weiter unterstützen zu müssen.
14. 14Drittdienste Zahlungen · E-Mail · Adresserfassung · Bot-Schutz · Webanalyse. Was die Plattform nutzt, statt es selbst zu entwickeln: Zahlungen über zwei Anbieter, Transaktions-E-Mails, Adresserfassung, Bot-Schutz auf Formularen und Webanalyse, die erst nach der Einwilligung des Besuchers läuft. Weil diese Dienste zugekauft sind, bleibt die eigene Arbeit des Teams bei den Regeln, die nur dieses Produkt hat.