Eine Plattform, gesteuert — nicht abgegeben.

Die Kurzfassung vorweg, weil sie meine Haltung ist: Die Maschine hat den Großteil der Arbeit erledigt. Aber sie hat sie nicht allein erledigt. Ich habe sie gesteuert, geprüft und immer wieder eingefangen. Wer den Menschen wegdenkt, baut kein Produkt — sondern Chaos in Rekordzeit.

Wie es ablief

Ich habe am 4. Dezember 2025 angefangen. Die ersten Wochen waren dichtes Zusammenspiel: Ich beschrieb, die KI baute, ich korrigierte. Im Dezember und Januar entstand das Fundament in hoher Schlagzahl — Hunderte, dann über tausend Commits im Monat.

Im Februar kam ein großer Bruch: ein umfangreicher Umbau, bei dem mehr Code bewegt wurde als in jedem anderen Monat. So etwas passiert, wenn eine frühe Architekturentscheidung sich als zu eng erweist — und es ist einer der Momente, in denen sich zeigt, ob man das Projekt noch versteht.

Ab dem Frühjahr verschob sich die Arbeit: weg vom ständigen Mittippen, hin zum Orchestrieren. Ich richtete eine Automatik ein, die plant und umsetzt, und einen „Automatic Tester" — ein eigenes Werkzeug, das die Oberfläche selbstständig durchklickt, Fehler findet und meldet. Aus diesen Meldungen wurden automatisch Fix-Aufträge, die wieder umgesetzt und geprüft wurden. In April und Mai lief das System zum großen Teil von selbst — und ich wurde vom Tipper zum Dirigenten.

Das ist, nebenbei, genau die Reise über die drei Stufen, die ich sonst beschreibe: von manuell über teilautomatisiert zu orchestriert. Ich habe sie nicht theoretisch gelernt, sondern an RAMP.

Was RAMP ist

RAMP ist eine mandantenfähige Plattform zur Automatisierung von IT-Betriebsabläufen — Teams bilden wiederkehrende Runbooks ab und führen sie kontrolliert aus. Das Unsexy-aber-Harte daran: Sie spricht vier Identity-Welten gleichzeitig (Native, LDAP, OIDC/Keycloak, Windows), pro Mandant konfigurierbar. Echtzeit-Updates und eine vollständige End-to-End-Test-Suite gehören dazu. Kurz: kein Demo-Spielzeug, sondern Enterprise-Realität.

• .NET-Backend, React-Frontend (TypeScript)
• mehrschichtige, rollenbasierte Rechte
• SQL/SQLite über einen Daten-Layer, Redis für Echtzeit
• mehrere Mandanten auf einem Produktionsserver, plus Docker-Cluster
• Backup/Restore, Datenbank-Migrationen, eigene Hilfswerkzeuge

Den Rest — die eigentliche Betriebslogik — lasse ich hier bewusst weg. Das ist der Teil, für den man mich bucht.

Was die KI alles gemacht hat

Bemerkenswert ist nicht, dass die KI Code geschrieben hat. Bemerkenswert ist, dass sie an der ganzen Kette Hand angelegt hat:

• Deployment — vom Build bis zum wiederholten, sauberen Neuaufsetzen des Produktionsservers.
• Server-Konfiguration — Identity-Provider, Verzeichnisdienste, Zertifikate, Mehr-Mandanten-Setup.
• Git — fast 3.900 Commits über mehrere Arbeitszweige, koordiniert.
• Builds & Tests — Backend, Frontend, Unit- und End-to-End-Tests.
• Skripte — die ganze Automatisierung drumherum.
• Automatic Tester — der autonome Oberflächen-Tester, der Fehler findet.
• Weitere Seiten — auch die Produktseite (run-book.de) und die Doku (doc.run-book.de) sind mit Claude gebaut und deployed.

Meine Rolle dabei: entscheiden, was gebaut wird, Leitplanken setzen — und prüfen, prüfen, prüfen.

Wie ich die Maschine geführt habe

Ein Beispiel, das viel über die Zusammenarbeit sagt. An einem Tag wollte ich den kompletten Produktionsserver (run-book.de) neu aufsetzen — inklusive Löschen aller Daten. Mein Auftrag war knapp und destruktiv. Die KI tat es nicht sofort. Sie antwortete sinngemäß:

„Bevor ich etwas Unwiderrufliches auf der Produktion anfasse, will ich den Scope bestätigen — ich fasse nichts an, bis wir uns einig sind."

Und legte einen Phasenplan vor, mit allen Fragen, die ich nicht gestellt hatte. Genau so soll es sein: Die Maschine ist schnell, aber die Verantwortung bleibt beim Menschen — und gute Steuerung heißt, ihr Raum für Rückfragen zu lassen, bevor etwas kaputtgeht.

Die unbequeme Wahrheit über Produktivität

Hier kommt die Erkenntnis, die mich am meisten gelehrt hat. In meinen interaktiven Sitzungen habe ich gemessen, wie lange die Maschine auf mich wartete — und wie lange ich auf sie.

Das Ergebnis: Die Maschine wartete rund 17-mal länger auf meine Antwort als ich auf ihre. Sie rechnet in Minuten. Die meiste Uhrzeit verbringt sie damit, auf eine Entscheidung von mir zu warten.

Das ist die Hälfte der Wahrheit, die in den Hochglanz-Versprechen fehlt: KI macht nicht einfach schneller. Sie verschiebt den Engpass — von der Tipparbeit zur menschlichen Verfügbarkeit und zur Prüfung. Wer Produktivität nur am Tempo des Modells misst, misst die falsche Größe.

Wie das Repo wuchs

Ein Tag fällt völlig aus dem Rahmen: Am 17. Februar 2026 wurden an einem einzigen Tag rund eine Million Zeilen eingefügt und fast ebenso viele gelöscht — ein einmaliger Massen-Umbau. (Rohe Zeilenzahlen überzeichnen das: bei einer großen Umstrukturierung zählt verschobener und generierter Code mit.) Dieser eine Tag staucht die ganze Grafik. Nimmt man ihn heraus, wird das eigentliche Muster sichtbar:

Über sechs Monate sind fast 3.900 Commits und eine Codebasis im sechsstelligen Zeilenbereich entstanden — in Wellen: ein dichter Aufbau zum Start, der große Umbau im Februar, dann der ruhigere, von der Automatik getragene Dauerbetrieb.

Wo es gehakt hat

Damit es ehrlich bleibt — die Stellen, die wehtaten:

• Der große Umbau. Eine frühe Entscheidung trug nicht weit genug; im Februar musste viel umgebaut werden. Mit KI geht das schnell — aber es ist genauso ein Risiko wie von Hand.
• Der Überblick. Nach Monaten saß ich vor meinem eigenen Projekt und kannte es streckenweise so wenig wie geerbten Fremdcode. Verständnis entsteht nicht mehr nebenbei beim Tippen — man muss es sich aktiv zurückholen.
• Hygiene. Ohne Aufsicht landen Temp-Dateien im Projekt und Ballast in der Git-Historie. Aufräumen gehört dazu.
• Die Grenze der Maschine. Es gab Fehler, die die KI lange nicht fand — am Ende musste ich sie selbst suchen. Genau dafür braucht es jemanden, der das Handwerk beherrscht.

Was ich daraus gelernt habe

Vieles von dem, was ich heute über das Arbeiten mit KI erzähle, habe ich an RAMP gelernt: dass man der Maschine eine Geschichte erzählen muss statt eines Pflichtenhefts. Dass Prüfen keine Kür ist, sondern das Fundament. Dass man den Überblick aktiv halten muss. Und dass der Senior zum Engpass und zur eigentlichen Wertschöpfung wird — nicht das Tool.

Resümee

RAMP ist mein Beweis, dass mit Claude Code etwas Ernsthaftes entstehen kann — eine produktionsreife Plattform, in sechs Monaten, größtenteils maschinengetrieben. Und es ist mein Beweis, dass das einen erfahrenen Menschen am Steuer braucht. Tempo und Maßstab sind real. Der Preis ist Steuerung, Prüfung und Überblick — bewusst eingeplant, nicht überrascht.

Gesteuert, nicht abgegeben.