Cursor's Subagent feature has officially launched. I wanted to try it out in my own repository, so I decided to do some exploratory development.
Motivation
This site (yamotty.me) is a static site that simply hosts Markdown files. It's built on Next.js, but it has no database and no API backend. Simple and easy to maintain — but also a little lacking.
So I decided to add a feature that would require a database and API backend. It's a bit more challenging as an introduction to software engineering, but it felt like the right kind of project to test just how far Cursor could support me.
Specifically, I implemented a newsletter feature. The typical setup: readers register their email address, and when a new article is published or external services (note, Podcast, Shizukana Internet) are updated, they get a notification. At month-end, a digest email goes out. This is a common pattern.
There are plenty of SaaS products that offer this out of the box, but I want to control my own space — so building it myself was a good fit.
Tech Stack
- Supabase: PostgreSQL-based BaaS. Manages subscriber data.
- Resend: A modern email delivery service. Templates are written with React Email.
- Vercel: My existing hosting. The Supabase integration is convenient.
- GitHub Actions: Automates RSS fetching and monthly digest sending.
I'd been wanting to try Supabase and Resend for a while, so I told Cursor about this preference and had the architecture reflect it.
Subagent Configuration
I set up five specialized agents in the .cursor/agents/ directory.
.cursor/agents/
├── pm.md # Product Manager
├── designer.md # UI/UX Designer
├── engineer.md # Frontend Engineer
├── backend.md # Backend Engineer
└── qa.md # QA Engineer
Each agent has a defined role, thought tag, and Definition of Done (DoD).
| Agent | Role | Thought Tag |
|---|---|---|
| PM | Requirements, user stories, prioritization | <pm_thought> |
| Designer | UI design, Tailwind class structure, accessibility | <design_thought> |
| Engineer | React/Next.js implementation, type safety, SOLID | <dev_thought> |
| Backend | DB design, API design, infrastructure | <backend_thought> |
| QA | Test planning, edge case validation, QA | <qa_thought> |
The .cursorrules file defines the orchestration flow: for a given user instruction, the orchestrator first forms a plan via <orchestrator_plan>, then each agent thinks and outputs in sequence.
<orchestrator_plan>
<context_analysis>Identify tech stack and project structure</context_analysis>
<task_analysis>Analyze user requirements</task_analysis>
<workflow>
<step agent="PM">Define requirements and acceptance criteria</step>
<step agent="Backend">DB, API, and infrastructure design</step>
<step agent="Designer">UI component design</step>
<step agent="Engineer">Frontend implementation</step>
<step agent="QA">Test planning and quality assurance</step>
</workflow>
</orchestrator_plan>
With this setup, Cursor behaves with the appropriate persona at each phase and generates output grounded in each role's expertise — at least in theory. I'm still new to this, so I'm not entirely sure I've got it right.
Back-and-Forth in Planning
This was a fairly complex build, so I did a lot of iteration during planning.
As projects get larger, LLMs have a weakness: their task decomposition tends to stay too shallow.
For example, "implement email sending functionality" actually contains multiple templates — confirmation email, welcome email, article notifications, and digest — but the initial breakdown didn't get that granular.
Security concerns (SQL injection prevention, rate limiting, email validation) and scalability also required explicit direction from me.
Here's roughly how the planning iterations went:
- Initial plan presented → I told it I wanted to lock down the UI before building the backend, with a refactoring step planned upfront
- Email template detailed design → I asked for a format easy to edit in Markdown
- Security requirements added → Guards against invalid email addresses and SQL injection
- Scalability considered → Cost optimization given the serverless premise
These were areas where human direction was necessary.
Implementation Was Smooth
Once the planning was solid, implementation was surprisingly smooth.
The orchestrated subagent setup meant the PM, Designer, Engineer, Backend, and QA personas each functioned appropriately. A few standout moments:
- Supabase initial setup: Generated SQL including RLS policies and triggers in one shot
- React Email templates: Produced working code including styling
- GitHub Actions configuration: Cron jobs and secret handling were both done correctly
Of course there were small adjustments needed. An image sizing issue broke the email layout, and there was a bug in the token expiry logic. But both were caught and fixed through Bugbot alerts and test runs.
Reflections
Cursor Subagent proved fully practical even for complex builds. That said, these human responsibilities remain:
- Clarifying requirements: Articulating what you want to build and what the constraints are
- Architecture decisions: Technology choices and tradeoff judgments
- Setting quality standards: Security, performance, and UX expectations
If you can communicate these clearly, we're entering an era where most of the implementation can be handed off to AI.
Many AI tools continue to appear and evolve rapidly. But tools only become second nature when you put in the time to use them deeply.
I've been using Cursor for about a year now, and I've gradually built a sense for "if I explain it this way, it works" and "here's where I need to decide myself." This project is a direct extension of that. There are things you can only see by using something continuously over time.
