Zum Inhalt springen
peterengineers.ai

Referenzprojekt

Deine Sichtweise

Ein laufendes SaaS-Produkt, das ich entwickelt habe und betreibe – KI-Agenten erledigen den grössten Teil der Arbeit, von der Anforderung bis zum Betrieb.

Das Referenzprojekt zeigt ein laufendes SaaS-Produkt für Web und mobile Geräte sowie die Arbeitsweise, mit der es entwickelt und betrieben wird. Die Arbeitsweise deckt den gesamten Software-Lebenszyklus ab, von den Fachanforderungen bis zum Betrieb. In jeder Phase übernehmen KI-Agenten den grössten Teil der Arbeit. Dadurch kann ein sehr kleines Team das Produkt entwickeln, weiterentwickeln und betreiben.

Die Regel

zieht eine klare Grenze: Ein Mensch muss jeden Schritt freigeben, der sich nicht rückgängig machen lässt – etwa eine Änderung an Live-Daten, einen destruktiven Befehl oder ein Release in Produktion. Die Agenten machen Vorschläge; ein Mensch entscheidet.

Jede Änderung, die ein Agent vornimmt, wird automatisch anhand von Regeln geprüft, die speziell für dieses System festgelegt wurden.

Ein Klick auf eine Box erklärt, wozu der Baustein dient und warum er so aufgebaut ist.

6 Codebasen28 Agenten64 Skills10 Workflows

Gezählt am 22. August 2026 in den sechs Codebasen und der gemeinsamen Agenten-Konfiguration; dasselbe gilt für jede Zahl in der Grafik darunter. Archivierte Agentenrollen nicht mitgezählt.

arbeitet an
läuft als
Diagramm – Oben die Arbeitsweise, unten das Produkt, das mit ihr entsteht; dazwischen verbinden die sechs Codebasen beide.
  1. Eine Arbeitsweise für alle sechs Codebasen KI-Agenten als Rollen definiert · festgelegte Abläufe · feste Regeln · automatische Stopps. Eine gemeinsame Konfiguration definiert jeden KI-Agenten als Rolle mit einer fest zugewiesenen Aufgabe und wendet in allen sechs Codebasen dieselben festgelegten Abläufe und festen Regeln an. Das Unternehmen hat damit einen Standard statt sechs, und das Wissen bleibt, wenn jemand geht: Jede Codebasis hat eine Spezialistenrolle, die jede Antwort mit der genauen Stelle im Code belegt. So hängt keine Änderung davon ab, was jemand über einen benachbarten Teil noch im Kopf hat.
  2. Anleitungen und Checks in jeder Codebasis Anweisungen für die Agenten · Dokumentation für sie · Checks, bevor etwas festgeschrieben wird. Jede Codebasis bringt ihre eigenen Anweisungen für die Agenten mit, die grösseren zusätzlich eine eigens für sie geschriebene Dokumentation. Dazu kommen die Checks, die jede Änderung dort bestehen muss, bevor sie festgeschrieben wird. Eine Änderung beginnt so mit einer schriftlichen Landkarte der Codebasis, nicht mit dem Wissen einer einzelnen Person. Fällt eine Änderung durch einen Check, wird sie so früh wie überhaupt möglich gestoppt – Sekunden nachdem sie entstanden ist, lange bevor ein Kunde darauf stossen könnte. Weiterlesen: Architekturgrenzen automatisch prüfen
  3. Auslieferung in die Produktion automatische Tests und Builds · Sicherheitsscan · Demo-Release · 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. Das Produktiv-Release ist ein eigener Schritt, den ein Mensch startet. Diese Trennlinie ist gewollt. Was sich rückgängig machen lässt, läuft, ohne auf jemanden zu warten, und die Arbeit stockt nicht. Was die Kundschaft erreicht, wartet auf eine Entscheidung, hinter der jemand steht. Weiterlesen: Ein Agent löst das Jira-Ticket, ein Mensch entscheidet, wo es darauf ankommt
  4. Tickets und Dokumentation das Backlog · Anforderungen · Betriebsanleitungen · das Release-Protokoll. Backlog und Dokumentation des Teams – Prozesse, Anforderungen, Betriebsanleitungen, das Release-Protokoll – sind für die Agenten zugänglich. Ein einziger Ablauf führt ein Ticket von der Analyse bis zum Review. Ein Produktiv-Release trägt der Ablauf, der es erkennt, selbst ins Protokoll ein. Was live ging, ist damit belegt, wenn ein Auditor oder ein Kunde nachfragt, und muss nicht nachträglich rekonstruiert werden. Weiterlesen: Ein Agent löst das Jira-Ticket, ein Mensch entscheidet, wo es darauf ankommt
  5. Konten und Einwilligungen wer ein Konto hat – und wozu eingewilligt wurde. Hier ist erfasst, wer ein Konto hat und wozu jede Person eingewilligt hat: Konten, Einwilligungen, Verifikation und jeder Kanal, über den die Plattform Nachrichten verschickt. Die Einwilligungen bilden einen einzigen Bestand, auf den das Unternehmen verweisen kann, statt über mehrere Apps verstreut zu sein. Die Schnittstellen werden schriftlich vereinbart, bevor es Code dafür gibt. Die einzige Schnittstelle, von der ein anderer Service abhängt, wird bei jedem Build geprüft. Eine Abweichung stoppt den Build, bevor sie die Kundschaft erreicht. Weiterlesen: Architekturgrenzen automatisch prüfen
  6. Geschäftsregeln und Zahlungen was an wen zu welchem Preis verkauft wird · Zahlungen und Rechnungsstellung. Hier stecken die Geschäftsregeln des Produkts, Zahlungen und Rechnungsstellung eingeschlossen. Jede Regel, die entscheidet, was ein Kunde bekommt und was er bezahlt, setzt ein einziger Service durch; die Web- und Mobile-Apps zeigen nur das Ergebnis. Eine Preis- oder Zahlungsregel wird damit an genau einer Stelle geprüft, geändert und verantwortet. Keine App kann sie anders anwenden als eine andere.
  7. Hochgeladene Dateien Hochladen · Überprüfen · Ablegen. Eine einzige Aufgabe: eine Datei annehmen, prüfen, ob sie ist, was sie zu sein vorgibt, und sie beim Datensatz ablegen, zu dem sie gehört. Eine Datei, die versteckten Code einschleusen oder den Server dazu bringen soll, im Auftrag eines Angreifers zu handeln, wird hier abgewiesen – an einer Stelle, statt dass sich jede App selbst verteidigen muss. Die Dateien liegen in der Hauptdatenbank statt in einem separaten Speicherdienst, eine Vereinfachung, die sich die Plattform bei ihrer heutigen Grösse leisten kann.
  8. Anmeldung ein Login für Web, Apps und Services · ein eigener Auftritt für jede Marke. Ein einziger Anmeldedienst bedient das Web, die Mobile-Apps und die Services dahinter, und das Login jeder Marke verlinkt deren eigene Nutzungsbedingungen und Datenschutzerklärung. Die dreizehn Markenauftritte sind Varianten eines gemeinsamen Designs; eine neue Marke braucht also kein neues Anmeldesystem. 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. Web- und Mobile-Apps alle Marken aus einer Codebasis · Mobile-Apps · eine einbettbare Version · Dokumentation für alle, die die Plattform betreiben. Aus einer Codebasis entstehen die Website jeder Marke, die Mobile-App der Plattform und die eigenen Apps einzelner Marken. Eine neue Marke oder ein neuer Kunde baut deshalb auf dem auf, was schon da ist: Die eigene Mobile-App ist ein Farb- und Logopaket und ein Konfigurationseintrag, kein neues Projekt, weil die Ansichten gemeinsam genutzt werden. Die Dokumentation für alle, die die Plattform betreiben, entsteht aus dem Code. So hält sie mit dem Produkt Schritt, ohne dass jemand daran denken muss, sie nachzuführen. Weiterlesen: Architekturgrenzen automatisch prüfen
  10. Betrieb und Audit-Nachweise alle Services, Umgebungen und Zugangsdaten · Betriebsanleitungen · Sicherheits- und Audit-Nachweise. Ein Verzeichnis jedes Services, jeder Umgebung und aller Zugangsdaten. Zugangsdaten sind nur mit ihrem Namen erfasst, ihre Werte liegen in einem Tresor. Eine Umgebung lässt sich so aufsetzen, ohne dass jemand einen dieser Werte sieht. Die Sicherheitsnachweise werden laufend nachgeführt, statt nur in einzelnen Köpfen zu existieren: die bekannten Schwachstellen pro Codebasis, aus den Scans aktualisiert; wer Produktiv-Adminrechte hat; und die Verantwortungsmatrix, die ein Sicherheitsaudit für Kartenzahlungen (PCI DSS) verlangt und die selbst automatisch geprüft wird. Will jemand die eigenen Daten löschen lassen, erzeugt ein Programm aus den Angaben des Antrags genau die nötigen Löschbefehle; ein KI-Modell formuliert sie nie selbst.
  11. Cloud-Hosting Microsoft Azure · eine Demo-Umgebung neben der Produktion · verwaltete Datenbank · Monitoring und Alarme. Die Services laufen in der Microsoft-Cloud Azure, mit einer Demo-Umgebung neben der Produktion. In der Demo-Umgebung laufen sie, bevor ein Mensch sie für die Produktion freigibt. Die Daten liegen in einer verwalteten Datenbank. Das Monitoring zeichnet auf, was das System tut, und schlägt Alarm, sobald eine festgelegte Bedingung eintritt – bevor es jemand selbst bemerken muss.
  12. KI 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. Nur ein Backend-Service ruft ein Modell auf, die Apps nie. Alles, was das Produkt an einen KI-Dienst schickt, läuft über diese eine Stelle, und dort lässt es sich prüfen und steuern.
  13. App Stores und App-Updates App Store · Google Play · Fixes am selben Tag · Pflicht-Updates. Die Mobile-Apps erreichen die Kundschaft über den App Store und Google Play. Ein Fix, der keine neue Store-Version braucht, wird direkt auf die installierten Apps ausgespielt, sobald ein Mensch ihn freigibt – noch am selben Tag statt nach einer Store-Prüfung. Über eine Fernkonfiguration lässt sich einer installierten App ausserdem sagen, dass sie aktualisiert werden muss. So bleibt die Kundschaft nicht auf einer Version hängen, die das Unternehmen nicht mehr unterstützen will.
  14. Drittdienste Zahlungen · E-Mail · Adresseingabe · Bot-Schutz · Webanalyse. Was die Plattform nutzt, statt es selbst zu entwickeln: zwei spezialisierte Zahlungsanbieter, Transaktions-E-Mails, Adresseingabe, Bot-Schutz auf Formularen und Webanalyse. Die Webanalyse startet erst, wenn der Besucher eingewilligt hat; vorher wird niemand erfasst.