Aus einem schnell gebauten Prototyp eine Plattform gemacht, auf der eine Reederei Buchungen und Frachtbriefe abwickelt.

Ausgangslage

Der erste Kunde ist ein kleiner Seefracht-Carrier, der bisher mit Excel und einer Branchensoftware gearbeitet hat. Mit Standardsoftware dauern selbst kleine Änderungen, etwa eine Klausel im Bill of Lading, oft Wochen.

PASSAG3 entsteht zusammen mit einem guten Freund, der die Schifffahrt seit Jahren kennt. Er hatte die Fachlogik als ausführliche Spezifikation aufgeschrieben und mit Agenten eine erste Version gebaut: Geschäftspartner, Tarife, Angebote mit Freigabe, Buchungen, Transportpläne. Im Juli kam ich dazu, um daraus etwas zu machen, auf das sich ein Betrieb verlassen kann.

Was ich hier baue

Deployment ohne Zeremonie

Am Anfang wollte ich keine Pipeline, auf die man wartet: “Wir bauen lokal und schieben es mit Kamal direkt auf den Server. Sonst warten wir immer auf die CI.” Ein kleiner Server und ein Befehl reichten für die Pilotphase Anfang August. Als im September mehrere Leute und Agenten parallel committeten, kamen automatische Produktions-Deployments dazu. Seitdem geht nur genau die Revision live, die vorher getestet wurde, und alte Releases werden nach erfolgreicher Prüfung aufgeräumt.

Zugänge und Rollen

Bevor echte Nutzer reinkamen, habe ich Pflicht-Zwei-Faktor-Login, ein Rollenmodell für Mitarbeiter, Einladungen mit Erneuerung und einen sauberen Weg für vergessene Passwörter eingebaut. Kundenmodule lassen sich pro Kunde freischalten, damit halbfertige Bereiche im Pilot unsichtbar bleiben.

Datenintegrität bei Preisen und Buchungen

Jedes Ticket beginnt mit einem Test, der das Problem zeigt. Schwerpunkte waren Preise, Freigaben und Ereignisse, die genau einmal verarbeitet werden müssen. Weil Freigebende sich selten einloggen, bekommen sie Ausnahmen jetzt per E-Mail.

Dokumente und E-Mails

Bills of Lading und Angebote sind PDFs, die verschickt werden. Ich habe die Dokumente aus der Datenbank in einen Objektspeicher verschoben, echte PDF-Erzeugung im Container eingebaut, alle E-Mails einheitlich gestaltet und erzeugte Dokumente als Anhang verschickt. Im Pilot gingen alle Mails erst an eine Testadresse, bis der Ablauf stimmte.

Logs, die ein Agent lesen kann

Alle Logs landen zentral in Axiom, mit einem Dashboard für mich und einem Skill, über den Agenten dieselben Daten abfragen. Das macht Dinge wie die tägliche Pilot-Beobachtung möglich: Ein Agent meldet, wenn auf einer Buchungsseite ein Fehlerschub im Browser auftaucht, und legt für alles, was er nicht klären kann, ein Ticket an. Dazu kamen Zeitmessungen pro Request und Alarme, die sich merken, ob sie schon gemeldet haben.

Backups, die wirklich zurückkommen

Der Kunde wollte wissen, wie oft gesichert wird und wie schnell es wieder läuft. Ein Backup, das nie zurückgespielt wurde, ist keine Antwort. Deshalb laufen seit Ende August automatisierte Wiederherstellungsproben: Dateien aus der Sicherung werden gegen Prüfsummen geprüft, die Datenbank wird täglich in eine isolierte Umgebung zurückgespielt und auf Tabellen und Constraints kontrolliert. Ein Recovery-Skill beschreibt jeden Schritt, damit auch ein Agent ihn ausführen kann.

Tägliche Verifikation

Seit September läuft jeden Abend ein Agent mit einem Verifikations-Skill durch die App. Er kennt 16 Feature-Maps, klickt echte Abläufe im Staff-Bereich und im Kundenportal durch und vergleicht sie mit den Änderungen der letzten 24 Stunden. Ist etwas neu, aktualisiert er die Karten per Pull Request. Kann er etwas nicht sauber beweisen, meldet er “blockiert” statt “grün”.

Integrationen und Tempo

Dazu kamen die Anbindung an die Fahrpläne einer großen Reederei über den DCSA-Standard für Fahrpläne, der Import von Bestandsdaten und Tarif-Tabellen aus Excel sowie viel Performance-Arbeit. Listen laden nur noch, was sie brauchen, das Frontend fragt nicht mehr im Leerlauf, und die Testsuite ist an zwei Tagen jeweils rund 30 Prozent schneller geworden.

Wie ich arbeite

Ich schreibe hier wenig Code von Hand. Agenten arbeiten in getrennten Umgebungen, jede Aufgabe hat klare Grenzen, und Schreibzugriffe auf Produktion werden einzeln freigegeben. Tickets liegen in einem gemeinsamen Projekt-Tool, sortiert nach Priorität. Mein Teil sind die Entscheidungen, das Review und die Frage, ob etwas wirklich funktioniert.

Was dabei rauskam

Der Pilot läuft seit August mit echten Nutzern, die Angebote, Buchungen und Frachtbriefe im System abwickeln. Seit Juli habe ich über 120 Pull Requests in die Plattform gemergt, fast alles Fundament, das man von außen nicht sieht. Laufender Betrieb heißt jetzt vor allem: Agenten lesen Logs, prüfen Abläufe und melden sich, wenn etwas auffällt. Ich muss selten eingreifen.