Experimenting with existing CRM applications to build a custom product took an 18-hour run using sub-agents to turn the idea into a working codebase at a cost of $200. We properly utilized skills, Model Context Protocol (MCP) servers, tested MCP tools, and used auto-smart mode.
The main blocker occurred while wiring the backend connection to the front-end. Reconnecting the system’s scope and business logic proved extremely difficult, making it the hardest part of this experimental journey.
I am looking for suggestions and best practices, especially regarding large codebase design, as well as your thoughts on where things might have gone wrong.
Suggestion if the actual spend is accurate and if the metric calculations are correct.
@venkatesan_r The part that usually breaks long MCP + subagent runs isn’t generation speed — it’s that architectural decisions stay in scrollback. By hour 12 the model still has files, but not “why this contract / what we rejected / who owns the boundary,” so BE↔FE reconnect feels like starting cold.
What tends to work on large codebases:
Phase gates with a durable handoff file (e.g. docs/decisions.md or per-topic ADRs). Before each new subagent wave, force a short write: decision, rationale, rejected alternatives, interface owners, open risks. Next chat must @ that file first.
Don’t dump the whole brain into rules. Keep .cursor/rules for invariants only; put evolving decisions in markdown (or an MCP memory tool) and pull selectively (read / recall the topic you need). Full dumps blow tokens and dilute attention — same failure mode as stuffing everything into .cursorrules.
Subagent briefs need contracts, not vibes. For wiring FE↔BE, include OpenAPI/types path, auth assumption, error shape, and “do not invent a parallel API.” If that isn’t on disk, a fresh agent will re-invent it.
Checkpoint before the expensive reconnect. After backend is “done,” run a dedicated short chat whose only job is to extract the living contract into the handoff file — then start FE against that, not against chat memory.
On $200 / 18h: rough ballpark for a multi-subagent greenfield is plausible if models + tool loops ran hot; the metric that usually matters more is how many times you re-explained the same decision. If that number is high, the spend is mostly context-tax.
If you share how you split subagents (one mega-run vs staged waves) and whether anything was written to disk mid-run, people can suggest a tighter stage checklist.
Huge thanks for helping me break this down , how context degradation happens over long runs.
Your analysis was extremely insightful. We ran a staged process, but our final stage ended up running far more subagents than the earlier steps, with zero mid-run writes to disk. By the time that final wave hit the BE↔FE reconnect, it was acting on pure context drift across too many agents.
Going forward, I am establish a solid operational playbook. What are your recommended best practices for these two main scenarios.
Greenfield Projects: What is the best strategy for structuring initial architecture, phase gates, and subagent waves right from scratch
Brownfield Projects (Improving Existing Apps): How do you safely run subagents on an existing codebase without having them break existing patterns, introduce regression bugs, or waste tokens re-analyzing the entire legacy context
@venkatesan_r — glad the diagnosis matched. Zero mid-run writes plus a fat final wave is exactly how BE↔FE reconnect becomes pure drift.
Greenfield (from scratch)
Day-0 skeleton before any coding wave: one always-on note (current goal, hard invariants, and “before X, retrieve Y”), plus an empty decisions folder. Architecture lives in short Decision / Rejected / Status / Supersedes notes, not in the orchestrator chat.
Phase gates are file writes, not vibes. After each phase (domain model → API contract → backend → frontend → integration), run a dedicated short chat whose only job is to extract the living contract onto disk. The next wave starts by @-ing that file; chat memory is not the handoff.
Cap subagent fan-out per phase. Prefer a few agents with a written brief (OpenAPI/types path, auth assumption, error shape, owners, “do not invent a parallel API”) over a late mega-wave. If a phase needs more agents than the prior one, that usually means a checkpoint was skipped.
Make integration its own phase against a frozen contract. Point every reconnect agent at the same contract file and ban parallel shapes in the brief.
Brownfield (existing apps)
Do not re-analyze the whole legacy tree. Before any subagent, write a thin “current truth” note: patterns to preserve, modules in scope / out of scope, known landmines, and the Decision ids that already cover this area. Briefs @ that note plus the few files the agent may touch.
Prefer amend-over-append. When a pattern changes, mark the old Decision Superseded and point to the new id — otherwise agents happily re-apply last year’s choice after you moved on.
Add a regression gate before merge: a short verify chat whose only job is “did we violate the invariants or touch out-of-scope paths?” — not more feature work. Fail closed if the agent cannot cite the pattern note.
Token waste on legacy usually means the brief asked for discovery. Replace “understand the codebase” with “read these three files and the pattern note; do not expand scope.”
Happy to compare notes once a first gate checklist is on disk — especially how you size the final integration wave versus earlier phases.