Core message: During the day we build, in the evening we refine, and at night we clean up systematically. Nightly checks + Ralph loop + shell script bring the code back to the target architecture every night. In practice this often means 30 to 70 files updated per night, and in bigger phases up to ~70% of daytime code reshaped.
This post is the follow-up to Cursor 2025 – My Personal Stats & Open Book. That article showed the numbers: among the top 300 Cursor users worldwide, with 125+ billion tokens and very high activity. The most common question afterwards was not “how many prompts?” but: How does the system stay stable? This workflow is the answer – not more clicks per day, but nightly builds, Ralph loop, and subagents.
Nine sections – from the Cursor 2025 starting point to the final operating model.
After publishing Cursor 2025 – My Personal Stats & Open Book, many people asked: How do you produce so much output with Cursor? How does the architecture stay stable when you ship that much?
The short answer: Speed during the day, quality at night.
During the day I build features and actively check UI and architecture rules. In the evening I run refactoring and tests. At night nightly checks, the Ralph loop, and subagents handle systematic cleanup – often 30 to 70 files per night and in larger phases reshaping up to ~70% of daytime code.
This article is not another stats post; it is the operating manual behind the numbers from the Cursor 2025 article.
When you ship quickly during the day, drift appears naturally: mixed responsibilities, naming inconsistency, and weak boundaries across layers.
Rule of thumb: If many things break at once after broad changes, it is usually an architecture issue, not a single bug.
| Pillar | What it controls | Practical impact |
|---|---|---|
| Briefing First | Target state before implementation | Less ambiguity for all agents |
| Nightly Checks | Deterministic verification chain | No silent quality drift |
| Rules + Skills | Permanent guardrails | Recurring errors become blocked patterns |
| Subagents | Deep focused execution | Higher completion depth per topic |
The Ralph loop enforces sequence and convergence: check, fix, check again until stable.
| Step | Purpose |
|---|---|
| Architecture / Structure Check | Find rule breaks early |
| Service / Orchestrator Checks | Restore execution boundaries |
| Tests | Validate behavior after corrections |
| Re-check | Converge to stable green state |
If broad change causes broad breakage, root-cause analysis is mandatory. Then add the missing guardrail as a new rule, new skill, or targeted subagent flow so the same pattern cannot reappear.
For roughly four weeks, subagents have been integrated into Ralph loops as the primary deep-work engine. The loop keeps orchestration cadence, subagents execute in depth and longer context windows.
| Layer | Typical daytime drift | Nightly correction |
|---|---|---|
| UI | Mixed markup/style/event concerns | Screen checks restore clear separation and responsive consistency |
| Services | Business logic leaks into wrong steps | Orchestrator/service rules reshape execute flows |
| Repositories | Query drift and weak index orientation | Repository checks and tests restore predictable data access |
| Architecture Rules | New failure patterns after broad changes | Analyze cause, then codify as rule/skill/subagent and enforce next night |
The operating effect is simple: less firefighting, more controlled architecture evolution.
Nightly checks are not a report mechanism. With Ralph loop orchestration and subagent depth, they become an architecture-shaping system.
Bottom line: Build fast in the day, refine in the evening, and let the nightly loop plus subagents return the codebase to the target shape while you sleep.