The Project Nursery

Giving Cursor your own patterns to copy from

AI is pretty good at copying patterns. It’s not as good at inventing them. Give it a blank slate and ask for “a service layer,” and you’ll get something generic... probably fine, but not how you’d do it yourself. Point it at code that already works the way you like, and it’ll copy that instead.

This is obvious in hindsight, but it took me a while to discover. I kept starting new projects from scratch, describing what I wanted, getting okay-ish results. Meanwhile I had several working projects with patterns I’d refined over time just sitting there.

The Setup

The trick that made this click for me was symlinking my existing projects into the same parent folder as my new one:

mkdir ~/projects/nursery
cd ~/projects/nursery
ln -s ~/projects/flow-myna/mono flow-myna
ln -s ~/projects/leveloh/mono leveloh
ln -s ~/projects/auth-router auth-router
mkdir spikelog # new project

Then I opened that folder in Cursor. Now when I say “build the auth context like flow-myna does it” or “use the same alembic migration setup as leveloh,” Cursor can see those folders/files. I’m not sure about other coding agent setups, but this trick made things easy to manage within Cursor.

One nice thing about symlinks specifically: Cursor will ask for confirmation before editing files in a symlinked folder. So your reference projects are protected... the AI can read them but won’t accidentally modify them, and if you do want them modified, you can just accept.

Your Projects as a Style Guide

I think of this folder as a nursery for new projects. The other projects aren’t templates... they’re just real working code that happens to be visible. They’ve diverged in different directions based on what they needed. Some have auth, some don’t. Some have payment processing, others are just static sites.

This is different from maintaining a boilerplate repo. With a boilerplate, you’re trying to anticipate what you’ll need and abstract it into something reusable. That’s a lot of upfront work, and six months later your preferences have changed anyway.

Here, there’s nothing to maintain. Each project is just itself. When I start something new, I tell the AI “look at how this other project handles X and do something similar.” It handles the copying, adapted to what I actually need this time.

Staying in Your Own Stack

I’ve found this works better than pointing the AI at some popular starter template. When it’s my code, I already know the patterns. I know why things are structured the way they are, where to look when something breaks.

With someone else’s boilerplate, you’re learning their conventions while trying to build something. The AI doesn’t know which parts are load-bearing and which are just preferences. It’s easier when everything is already familiar.

My stack for context: Next.js 14 with Tailwind on the frontend, FastAPI with PostgreSQL on the backend. Nothing unusual... just things I’ve used before and have working examples of.

The Result

I’d been sitting on a domain for a simple metrics service idea for years. A service where users POST a chart name and value, and charts appear automatically. It felt like a multi-week project, so I kept putting it off.

With this setup it took about 8 hours spread across a few days. The service is at spikelog.com if you want to take a look.

I don’t know if this generalises to everyone’s workflow, but the main idea seems sound: the patterns you’ve built up over time are worth reusing, and making them visible to the AI is an easy way to do that.

I'll be starting my new projects this way from now on.

--
More like this → dsmurrell.com