I manage half a million lines with a monorepo and overnight Copilot agents.
I'm a solo founder sitting on more than half a million lines of code. In an October 2025 video I walked through what was working for me after GitHub Spec Kit fell short on speed, and what I was still wrestling with.
The business case
I want to vibe-code new features faster without breaking the code that already ships. The pitch for AI is more productivity. On a codebase this size, the hard part is keeping that speed without a pile of new bugs.
Spec Kit looked like the answer: a constitution, a specification, and a TDD-style path meant to keep models on track on large projects. I have a deeper Spec Kit run on my Nuxt 2 contractor app on this site. In this video I said it has potential, and I respect the GitHub team, but it hadn't lived up to what I needed for speed. Context ended up everywhere, and I couldn't structure Spec Kit to get the gains I was after.
What I care about is shipping features on an existing production stack as a solo founder. If Spec Kit isn't giving you velocity, a monorepo plus layered GitHub Copilot instructions and overnight agent PRs may. Copilot's UI, Spec Kit, and the models I named (including Claude Sonnet 4.5) change fast, so treat this as where things stood in October 2025.
Half a million lines
I measured the monorepo with a Rust-based line counter on camera. Roughly 250,000 lines of C#, about 12,000 of TypeScript, about 23,000 of JavaScript, around 628,000 lines of actual code, and about 900,000 lines overall. It's not the biggest codebase in the world, but it's large for one person.
I showed two products on dummy data: a management system, and a lead management system (LeadScore AI) that automates outbound leads. The whole stack was vibe-coded. Once the code got this large, managing the complexity got hard, which is why I kept looking at Spec Kit and then at alternatives.
Why Spec Kit fell short
Spec Kit is GitHub's approach to large codebases: spell out requirements up front through a specification and a constitution, then iterate so the model stays aligned. On my stack I ended up with lots of context and no clear path to faster feature work. I said on camera that I hadn't figured out how to make it deliver the speed I wanted.
I stopped waiting on Spec Kit and documented what was working for me as a solo developer on half a million lines.
Jump to
- 0:00 The solo founder challenge
- 1:56 Application overview
- 4:54 Transitioning to a monorepo
- 6:25 Monorepo structure and workflows
- 8:30 Leveraging AI for context
- 13:08 Automated task management
I walk through the monorepo, Copilot instructions, and overnight agents on screen in the full video on my channel: Spec Kit alternative for a large codebase on YouTube.
One repo instead
The codebase started as a monolith, then split into microservices across dozens of GitHub repos. That became a nightmare. I moved everything into one monorepo so front end and back end share one context. Big companies do this for shared libraries and tools. For me the win was simpler: stop hopping machines and pasting context between projects.
The layout is APIs (containers, Azure / AWS Lambda functions, and Cloudflare Workers), apps, databases, docs, scripts, and packages. Apps stay small so I can vibe-code them fast, then stitch them with iframes or URLs and deploy independently.
Before the monorepo I often vibe-coded the front end in VS Code, then switched to a Windows PC and Visual Studio for the C# back end, carrying field extracts as context. One repo killed that copy-paste loop.
Copilot instructions
Each project gets its own Copilot agent instructions. In VS Code I open the project, use Generate agent instructions, and let Copilot write a project-specific instructions file from the code. Since then, VS Code has added an /init command in chat that writes the same file. Either way, that file is still generic on architecture and file layout, so I add a docs folder with real feature notes and link it back into the instructions.
I did that for most projects. At the root I keep a master Copilot instructions file plus a docs index that points at every app. The hierarchy lets me work inside one app's context or ask for a change that spans front end and back end from the root.
My daily driver in the video was Claude Sonnet 4.5. The same docs context also worked when I jumped to the Copilot agent CLI. When the model fixes something, I have it update the project docs and the root docs so the chain stays current.
Overnight agent PRs
The bigger gain came from task management. With the monorepo in place I can open a board item, comment which apps and APIs the work touches, and assign it to Copilot against the monorepo branch. Copilot sees the task, the front end, and the back end in one place.
Back then, before bed, I was kicking off five or six non-conflicting tasks so I wake up to PRs. It isn't perfect. Sometimes the agent works the wrong project. Because the output is a PR, I close the bad ones and keep moving. That overnight loop is what was giving me the productivity I couldn't get from Spec Kit in October 2025.
Test it on your stack
This setup is what was working for me then, not a claim that Spec Kit is dead. I said on camera it isn't revolutionary. It's a home base: monorepo, layered instructions, docs that the model updates, and agents on the board overnight.
I also called out the BMad Method as another Spec Kit alternative I planned to evaluate in a later video. If you're trying to get AI speed on a large existing codebase and want a second set of eyes on your next move, that's what I cover in a 1:1 strategy call.
About Dwain
I'm Dwain Browne, Founder of LeadScore AI and SnapSuite. I'm a Toronto-based software architect with 25+ years across software, sales, operations and entrepreneurship. SnapSuite helps contractors and trades teams get paid faster, and LeadScore AI shows you which leads deserve your next call. I also run Vibe Code to Profit, a community helping people build software with AI.