Kernaussage: Tagsüber wird gebaut, abends wird gezielt nachgeschärft, nachts wird systematisch aufgeräumt. Genau darin liegt die Stärke: Nightly Checks + Ralph Loop + Shellscript formen den Code jede Nacht zurück in die Zielstruktur. In der Praxis werden pro Nacht häufig 30 bis 70 Dateien nachgezogen; bei größeren Umbauten wird regelmäßig bis zu ~70 % des Tages-Codes geradegebogen.
Dieser Beitrag ist der inhaltliche Folgeartikel zu Cursor 2025 – Meine persönlichen Stats & Open Book. Dort habe ich die Zahlen offengelegt: unter den Top-300 Cursor-Nutzern weltweit, mit 125+ Milliarden Tokens und sehr hoher Aktivität. Die häufigste Rückfrage danach war nicht „wie viele Prompts?“, sondern: Wie bleibt das System trotzdem stabil? Die Antwort ist dieser Workflow – nicht mehr Klicks am Tag, sondern Nightly Builds, Ralph Loop und Subagents.
Ausgangspunkt: Warum dieser Beitrag existiert
Nach dem Veröffentlichen von Cursor 2025 – Meine persönlichen Stats & Open Book kamen viele Nachfragen: Wie schaffst du so viel Output mit Cursor? Wie bleibt die Architektur stabil, wenn du so viel baust?
Die kurze Antwort: Tagsüber entsteht Geschwindigkeit, nachts entsteht Qualität.
Tagsüber baue ich Features und prüfe Oberflächen sowie Architektur-Regeln aktiv. Abends laufen Refactoring und Tests an. Nachts übernehmen Nightly Checks, der Ralph Loop und Subagents die systematische Nacharbeit – oft mit 30 bis 70 geänderten Dateien pro Nacht und in größeren Phasen einem strukturellen Nachzug von bis zu ~70 % des Tages-Codes.
Genau deshalb ist dieser Beitrag kein Statistik-Post, sondern die Betriebsanleitung hinter den Zahlen aus dem Cursor-2025-Artikel.
Das Problem: Chaos ohne festen Rahmen
Ohne strikte Leitplanken passiert schnell das Gleiche: Dateien werden zu groß, Ordner heißen plötzlich „helpers“, „utils“ oder „misc“, und aus einem klaren Flow wird ein undurchsichtiges Spaghetti-Netz.
Deshalb habe ich mir – und meinen KI-Agents – ein sehr konsequentes Projekt-Framework gebaut: eine Ordnungslogik aus Ordnern, Dateinamen, Briefings, Tests und Workflows, die genau dieses Chaos verhindern soll.
Merksatz: Die KI weiß nur dann zuverlässig, wo etwas hingehört, wenn der Rahmen vor dem ersten Prompt steht – nicht danach.
Das Framework auf einen Blick
Framework
Die vier tragenden Bausteine
| Baustein |
Was es regelt |
Effekt für die KI |
| Ordner- und Dateilogik |
Screen, Orchestrator, Services, Models, Repositories – feste Pfade |
Keine „misc“-Ordner, keine Zufallsablage |
| Briefing First |
Fachliche Vorgabe in `briefing/` vor jedem Code-Schritt |
Die KI folgt dokumentierten Regeln statt Raten |
| Tests (oft 1200+) |
Orchestrator-, Service-, Repository-, UI-Tests |
Jede Änderung ist messbar abgesichert |
| Nightly-Workflow (~35 Steps) |
Shell-Workflow mit Burk-Flow-Steps über Nacht |
Tages-Chaos wird automatisch korrigiert |
Das Prinzip: Kleine Bausteine statt großer Dateien
Die Idee ist simpel, aber gnadenlos in der Umsetzung:
Prinzip
Regeln in der Praxis
| Regel |
Konkret bedeutet das |
| Kleine Dateien |
Keine 800-Zeilen-Monolithen; eine Verantwortung pro Datei |
| Klare Schichten |
Screen → Orchestrator → Step-Services → Repositories |
| Briefing First |
Erst Briefing, dann PHP, Twig, Tests |
| Tests überall |
In kleinen Projekten schnell 1200+ automatisierte Tests |
Wenn man diese Regeln konsequent durchzieht, wird das System robust – auch wenn verschiedene KI-Systeme mit unterschiedlichen Stärken am Code arbeiten.
Der Nightly-Workflow: 35 Steps, die jeden Tag aufräumen
Bei mir läuft nachts ein Shell-Workflow mit rund 35 Burk-Flow-Steps. Der prüft den Tagesstand, findet Regelbrüche und führt oft automatisiert große Umbauten durch.
Nightly
Was der Workflow nachts erledigt
| Nightly-Schritt (Auszug) |
Typische Wirkung am Morgen |
| Regel- und Struktur-Checks |
Verstöße gegen Ordnerlogik und Naming werden gefunden |
| Refactoring / Rebuild |
Oft bis zu **70 %** des Tages-Codes wird angepasst oder neu gebaut |
| Test-Nachzug |
Fehlende oder veraltete PHPUnit-Tests werden ergänzt |
| UI- und Prozess-Checks |
Screens und Flows werden end-to-end validiert |
Das Ziel: Morgens nichts mehr manuell anfassen – das System erledigt die Korrekturen. In der Praxis bedeutet das oft: 30–70 geänderte Dateien im Nightly-Lauf und je nach Ausgangslage ein struktureller Nachzug von bis zu ~70 % des tagsüber erzeugten Codes.
Die Analogie passt perfekt: Tagsüber baut der Entwickler Features und prüft Oberflächen sowie Architektur-Regeln, nachts übernimmt die fleißige KI-Bienen-Armee den Feinschliff – testet, räumt auf, richtet aus und bringt den Code in die gewünschte Form.
Wichtig: Ich fasse keine einzige Zeile mehr selbst an – die KI baut von Anfang bis Ende. Der Nightly-Lauf ist das Qualitätsnetz, nicht mein Tastatur-Feingefühl.
Ralph Loop: Warum Nightly Checks die Kontrolle zurückholen
Der entscheidende Punkt ist nicht, dass „immer noch irgendwas manuell gepusht werden muss“. Der entscheidende Punkt ist die klare Arbeitsteilung: Tagsüber wird Feature-Code gebaut und Oberflächen werden aktiv kontrolliert; abends laufen Refactoring und Tests an; nachts bringt die Ralph Loop alles in einen sauberen, stabilen Zielzustand. Genau dafür ist der Nightly-Lauf da: prüfen, korrigieren, erneut prüfen – bis das Ergebnis stabil ist.
Wenn bei größeren Änderungen plötzlich an mehreren Stellen etwas kaputtgeht, ist das für mich ein klares Signal: Wir haben kein Einzelfehler-Problem, sondern ein Architekturproblem. Dann reicht kein Hotfix. Dann muss man die Ursache analysieren, die fehlende Leitplanke identifizieren und als neue Rule, neuen Skill oder spezifischen Subagent-Flow dauerhaft verankern.
Ralph Loop
Drei Hebel für stabile Nightly-Ergebnisse
| # |
Hebel |
Praxiswirkung im Nightly-Run |
| 1 |
Feste Step-Reihenfolge |
Shellscript läuft deterministisch durch: Architektur-/Struktur-Check → Service-/Orchestrator-Check → Testlauf → erneuter Struktur-Check |
| 2 |
Harte FAIL-Kriterien |
Offene Regelverstöße brechen den Lauf; „Warnung reicht“ ist ausgeschlossen, bis der Code wirklich korrigiert wurde |
| 3 |
Konvergenz statt Einmallauf |
Ralph Loop läuft in Iterationen, bis Checklisten grün und Ergebnisse stabil sind – nicht nur „einmal grün“ |
1) Nightly-Checks als Codestandard, nicht als Report
Ein guter Nightly-Lauf schreibt keine nette Zusammenfassung, sondern setzt den Standard technisch durch. Wenn ein Schritt fehlschlägt (Struktur, Namenskonvention, Orchestrierung, Tests), bleibt der Lauf auf „FAILED“, bis der Ist-Stand wirklich passt. Das ist wichtig, weil tagsüber keine Zeit ist, parallel jeden Refactoring- und Testpfad vollständig durchzuziehen.
2) Ralph Loop über Shellscript macht den Prozess reproduzierbar
Der große Vorteil am Shellscript: Jeder Lauf nutzt dieselbe Reihenfolge, dieselben Checks, dieselben Abbruchkriterien. Damit wird aus „heute hat der Agent gut gearbeitet“ ein reproduzierbarer Prozess, der auch bei wechselnden Modellen konsistent bleibt.
Seit rund vier Wochen stoße ich im Ralf-/Ralph-Loop systematisch Subagents an. Der Loop startet weiter den Prozess, aber die Subagents gehen tiefer in einzelne Themen, arbeiten länger und schließen Teilprobleme vollständiger ab. Deshalb habe ich intern die meisten Korrekturpfade auf Subagents umgestellt und lasse die Loops diese gezielt orchestrieren.
3) Zielbild-Orientierung statt Firefighting
Wenn die Zielstruktur klar in Briefings und Skills beschrieben ist, arbeitet der Nightly-Run immer auf dieses Zielbild. Das spart tägliches Firefighting und verschiebt die Arbeit von „Fehler hinterherlaufen“ zu „System gezielt formen“.
Konkrete Beispiele: Kontrolle zwischen UI, Services und Repositories
Die wichtigste Wirkung der Nightly Checks ist fachliche Kontrolle über die Schichten. Vier typische Beispiele aus dem Alltag:
Kontrolle
Wie der Loop UI, Services und Repositories sauber hält
| Schicht |
Typischer Drift im Tagesgeschäft |
Nightly-Korrektur mit Ralph Loop |
| UI |
Markup, Styles und JS-Logik mischen sich; Inhalte wirken uneinheitlich |
Screen-Checks erzwingen klare Zuständigkeiten, konsistente Strukturen und stabile Darstellung über Breakpoints |
| Service-Layer |
Business-Logik rutscht in falsche Steps oder Methodennamen werden unklar |
Step-Workflow und Orchestrator-Regeln formen Execute-Flows zurück auf die definierte Service-Architektur |
| Repos |
Query-Drift, fehlende Indexorientierung, inkonsistente Datenzugriffe |
Repository-Checks koppeln SQL-/Index-Regeln und Tests, bis Datenzugriffe wieder nachvollziehbar und performant sind |
| Regeln |
Viele parallele Änderungen erzeugen neue Bruchmuster, die vorher nicht abgesichert waren |
Ursache analysieren, danach fehlende Leitplanke als Rule/Skill/Subagent ergänzen und im nächsten Nightly-Lauf direkt durchsetzen |
Genau hier gewinnt man Kontrolle: Nicht durch manuelles Nachpolieren, sondern durch einen Nightly-Prozess, der die gewünschte Architektur jeden Tag wiederherstellt.
Ergebnisse: Seoday-Stack, Community-Tools, Kundenprojekte
Ergebnisse
Was am Ende steht
| Bereich |
Ergebnis |
| Seoday-Stack |
Gesamten Stack inkl. aller Softwaresysteme dahinter neu gebaut |
| Community |
Tools kostenlos bereitgestellt |
| Kundenprojekt |
Großes Projekt erfolgreich; Kunde will IT komplett umbauen |
| Family Offices / PE |
Gespräche zu IT-Umstrukturierung und Anteilen – bewusst gesteuert |
Fazit
Strikte Strukturen plus Nightly Checks mit Ralph Loop sind der Schlüssel: Der Code wird laufend in die gewünschte Form gebracht, statt nur Fehler zu dokumentieren.
Für mich der Unterschied: Nicht „trotz Nightly Checks pushen wir immer noch nach“, sondern: Mit einem guten Ralph-Loop-Shellscript werden UI, Services und Repositories jede Nacht auf das Zielbild zurückgeführt – und genau das macht das System dauerhaft beherrschbar.
