Produktentwicklung

Ein gemeinsamer Projektraum für Dienstleister und Auftraggeber.

Ein Produkt, das ich seit April 2026 in eigener Verantwortung baue – Architektur, Entwicklung, Sicherheit und Betrieb. Was es fachlich kann, steht hier nicht. Was hier steht, ist die Bauweise: der Technologie-Stack, die Arbeitsweise, die Prüfkette und der Einsatz von KI-Agenten unter meiner Freigabe.

Stand
In Entwicklung, Stand September 2026
Seit
seit April 2026
Rolle
Architektur, Entwicklung, Sicherheit und Betrieb – allein verantwortet
Stand

Wo das Ganze steht.

Keine Prozentzahl, die niemand nachprüfen kann, sondern drei Aussagen, die sich am Projekt selbst belegen lassen. Was gebaut und abgenommen ist, was als erste Ausbaustufe fertig ist, und woran sich der Stand jederzeit ablesen lässt.

Das Fundament steht.

Anmeldung, Rechte, Prüfspur, Ereignisverarbeitung, Bau- und Auslieferkette, Cluster. Alles gebaut und abgenommen.

Die erste Ausbaustufe ist abgeschlossen.

Grundgerüst der Oberfläche, Einladungen und Zugänge, Anlegen von Organisationen und Projekten.

Es gibt genau eine Tafel für den Stand.

Eine Datei im Projekt sagt, wo jeder Bereich steht – gebaut, belegt oder noch leer. Kein zweiter Fortschrittsbericht daneben, der sich davon löst. Weicht ein Dokument ab, gilt das Projekt.

Technik

Womit gebaut wird.

Nichts davon ist zufällig gewählt. Jede Zeile steht für eine Entscheidung, die aufgeschrieben und begründet ist – und die sich ändern darf, wenn sich die Begründung ändert. Von der Sprache bis zur Beobachtung im Betrieb.

Sprache

  • TypeScript
  • Node.js

Oberfläche

  • React
  • Vite
  • React Aria
  • Tailwind CSS
  • Design Tokens
  • Storybook

Server

  • NestJS
  • Kysely
  • CASL

Daten

  • PostgreSQL
  • Redis
  • BullMQ
  • MinIO
  • ClamAV

Anmeldung

  • Keycloak
  • OIDC
  • PKCE
  • Zwei-Faktor
  • BFF-Muster

Betrieb

  • Docker
  • K3s
  • Helm
  • Terraform
  • Argo CD
  • GitHub Actions

Beobachtung

  • strukturierte Logs
  • OpenTelemetry
  • Prometheus
Arbeitsweise

Wie gearbeitet wird.

Fünf Grundsätze, die nicht in einem Leitfaden stehen, sondern im Code erzwungen werden. Eine Regel, die niemand prüft, ist eine Absichtserklärung – deshalb hat jede hier einen Mechanismus, der sie hält.

Erst die Spezifikation, dann der Test, dann der Code.

Aus der Spezifikation entstehen Abnahmekriterien in zwei Fassungen: eine, die Menschen lesen, und eine, die Maschinen und Agenten lesen. Beide beschreiben dasselbe.

Alles liegt in einem Repository.

Oberfläche, Server, Hintergrundprozesse und geteilte Bausteine. Ändert sich eine Schnittstelle, ist das eine zusammenhängende Änderung – und nicht zwei, die auseinanderlaufen.

Eine Regel ohne Prüfung ist keine Regel.

Bei jeder neuen Regel steht die Frage: Merkt es irgendwer, wenn sich jemand nicht daran hält? Lautet die Antwort nein, ist es eine Absichtserklärung. Also wird die Regel maschinell erzwungen.

Qualität kann sich nur in eine Richtung bewegen.

Für Komplexität gelten harte Grenzwerte. Neuer Code hält sie ohne Ausnahme ein. Die Liste der Altfälle darf schrumpfen, nie wachsen – ein Wächter prüft das automatisch. Auch unter Termindruck.

Nichts wird still überschrieben.

Architekturentscheidungen werden fortgeschrieben statt gelöscht. Ein Jahr später ist noch nachvollziehbar, was früher galt und warum es sich geändert hat.

KI

Agenten bauen. Ich gebe frei.

Ein erheblicher Teil des Codes entsteht durch KI-Agenten. Das ist kein Versuch nebenher, sondern das Arbeitsmodell – und es funktioniert nur, weil die Rollen getrennt sind: Wer prüft, baut nicht, und wer baut, gibt nicht frei.

RolleWerAufgabeFreigabe
Architekt und Prüferein Modell ohne Zugriff auf den QuellcodeAufträge formulieren, Ergebnisse prüfenkeine Freigabe
Bau-Agentein Modell mit Zugriff auf den Quellcodebauen, testen, dokumentieren, zur Prüfung vorlegenkeine Freigabe
Menschichentscheiden, prüfen, verantwortenjede Freigabe

Wer prüft, baut nicht.

Zwei getrennte Modellinstanzen mit unterschiedlichen Zugriffen. Kein Agent gibt seine eigene Arbeit frei. Das ist keine Vorsichtsmaßnahme, sondern der Aufbau – derselbe, den ich unter Arbeitsweise für Kundenprojekte beschreibe.

Ein Auftrag zur Zeit, durchnummeriert.

Jeder Auftrag hat eine Nummer, jede Antwort trägt dieselbe. Die Reihenfolge ergibt sich aus den Nummern, und es ist immer nur einer offen. Inzwischen sind mehrere hundert Runden zusammengekommen.

Erst messen, dann anhalten, dann bauen.

Kein Agent fängt an, ohne vorher den tatsächlichen Stand ermittelt zu haben – Zweig, Versionen, Testlage. Danach wird der Befund berichtet und gewartet. Gebaut wird erst nach ausdrücklicher Freigabe.

Jede Zusammenführung braucht meine Freigabe.

Es gibt keinen Weg, auf dem Code ohne mich in den Hauptstand kommt. Rote Prüfungen lassen sich nicht überspringen.

Prüfung

Was jede Änderung durchläuft.

18 Prüfungen laufen automatisch, sobald eine Änderung vorliegt. Keine davon lässt sich überspringen, und erst wenn alle grün sind, kann zusammengeführt werden. Das sind die Arten von Prüfung, die dabei laufen.

  • Stilregeln und Typen
  • Suche nach versehentlich eingecheckten Zugangsdaten
  • statische Analyse auf unsichere Muster
  • bekannte Lücken in fremden Bibliotheken
  • Einzeltests mit Abdeckungsschwelle
  • Tests gegen echte Datenbank und Dienste
  • Prüfung des fertigen Container-Abbilds
  • Signatur – nur signierte Abbilder dürfen starten
  • automatische Barrierefreiheitsprüfung an jedem Baustein

Fertig heißt nicht „läuft bei mir“. Fertig heißt: Rechte auf dem Server geprüft, Trennung der Organisationen durch Tests belegt, leere Zustände gestaltet, Fehlermeldungen verständlich, Prüfkette vollständig grün, Dokumentation nachgezogen. Und keine KI-Aktion, die ohne ausdrückliche Bestätigung etwas Verbindliches auslöst.

So arbeite ich auch in Deinem Projekt. Wenn Du wissen willst, was das für ein konkretes Vorhaben bedeutet, schreib mir.

Kontakt aufnehmen

Zurück zu den Projekten