My New Org Chart: Me → Cursor → A Whole AI Product Team

 

A few days ago I had one AI “developer” wired up via a tiny codex.sh script.

Now I apparently manage an entire AI product organisation.

• Cursor is the engineering manager.

• Under Cursor I have:

  • an AI Product Manager (product-manager.sh)

  • an AI Architect (architect.sh)

  • an AI Developer (codex.sh)

  • an AI Tester (codex-test-coverage.sh)

• And I… am apparently manager of managers.

So yes, AI has officially upgraded my career. I’ve skipped straight to “VP of Bots”.

Let me walk through how the team works.

---

1. Cursor as my mini-EM

Cursor is the control tower. I open a workspace, point it at the repo, and give it a clear mission:

• which story ID from the backlog (A1 / B5 / C49)

• which worker script we’re “running” (PM / Arch / Dev / Tester)

• and any constraints (“no infra changes”, “docs only”, etc.)

Cursor keeps the context warm, applies project rules, and lets each worker operate in a tight loop:

1. Read story file (with YAML status + lock).

2. Grab a lock if it’s free.

3. Do focused work.

4. Update docs, status, acceptance criteria, and hand back.

It’s like having a very disciplined EM who never forgets the process doc.

---

2. AI Product Manager: shaping the work

product-manager.sh is the AI PM.

Its job isn’t to write code; it works on the edges of the product:

• Refines stories in docs/backlog.md into clearer, testable items.

• Splits big “epics” into smaller, shippable slices.

• Adds business context and constraints directly into each story file.

A typical PM story file might start life like this:

---
id: A21
epic: A
title: Membership plans page
status: todo
priority: high
area: frontend

lock:
  owner: ""
  locked_at: ""
  expires_at: ""
---

## Summary

Create a membership plans page where admins can view, create, edit, and
deactivate membership plans.

## Business context

Clubs need a simple way to see “who’s paying what” without exporting to
a spreadsheet. This is the core admin surface.

## Acceptance criteria

- List all plans with name, amount, currency, interval, active/inactive.
- Create form validates required fields and positive amount.
- Deactivating a plan does NOT break existing subscriptions.
- Mobile layout works for a club treasurer on their phone.

I ask the PM worker to:

• tighten language

• add edge cases

• clarify acceptance criteria

Once that’s done, the Architect and Dev workers have a nice, sharp target.

---

3. AI Architect: keeping the shape clean

architect.sh plays the Architecture / Staff Engineer role.

Given a story, it focuses on:

• domain boundaries (e.g. where membership logic really belongs)

• data model changes and migration implications

• API surface design and consistency

• “what will this break in six months?”

For example, before we implemented the membership subscription endpoints, the Architect worker would take A3/A4/A5 and sketch a design:

## Design notes for A3/A4/A5

### Data model

- Table: membership_subscriptions
  - id (uuid, pk)
  - club_id (fk)
  - member_id (fk)
  - plan_id (fk)
  - status (enum: active, cancelled, paused)
  - start_date, end_date, next_billing_date
  - created_at, updated_at, deleted_at

### API

- POST /api/membership-subscriptions
  - body: { member_id, plan_id, start_date? }
  - 201: returns subscription object
- GET /api/membership-subscriptions?member_id=
- PATCH /api/membership-subscriptions/{id}
  - body: { status, end_date? }

### Multi-tenant rules

- All operations are scoped by authenticated club_id.
- member.club_id and plan.club_id must match the token’s club_id.

### Risks / open questions

- How do we handle proration if plan amounts change?
- Do we need a separate “subscription events” log for future analytics?

The Dev worker then uses this as a guardrail. Less yak-shaving, more implementing.

---

4. AI Developer: focused implementation

codex.sh is the Developer.

Its instructions are roughly:

• You own this one story.

• Respect the architecture notes and backlog acceptance criteria.

• Touch only the files you need.

• When behaviour changes, add or update tests.

• At the end, summarise what changed and what still needs doing.

The YAML lock at the top of the story file might look like this mid-work:

---
id: A3
epic: A
title: Membership subscription creation endpoint
status: in-progress
priority: high
area: backend

lock:
  owner: "ai-dev-1"
  locked_at: "2025-11-30T11:05:00Z"
  expires_at: "2025-11-30T15:05:00Z"
---

That’s the AI equivalent of “this card is assigned to Alice and she’s currently working on it”.

---

5. AI Tester: the quality cop

Finally, codex-test-coverage.sh is the Tester / SDET.

I point it at:

• specific packages (e.g. internal/domain/membership, internal/http/handlers)

• or areas of concern (“test the new subscription endpoints”)

Its instructions emphasise:

• improving test coverage for critical flows

• using integration tests to cover vertical slices

• not changing production code unless absolutely necessary

It might emit tests like:

func TestCreateMembershipSubscription_Success(t *testing.T) {
    // Arrange: create club, member, plan
    // Act: POST /api/membership-subscriptions
    // Assert: 201, status=active, correct dates, correct club_id
}

func TestCreateMembershipSubscription_WrongClub(t *testing.T) {
    // Arrange: member and plan in another club
    // Act: POST with mismatched IDs
    // Assert: 404 or 403, no subscription created
}

And once it’s done, it updates the story or adds a new “Testing” story with status/lock info.

---

6. Managing the whole circus

From my chair, the org chart basically looks like this now:

• Me – manager of managers / product owner of the whole experiment

• Cursor – mini EM / orchestrator inside the IDE

• AI PM – keeps backlog sharp

• AI Architect – keeps design sane

• AI Dev – writes the code

• AI Tester – makes sure it actually works

I still review critical changes, decide priorities, and handle the genuinely gnarly bits — but a surprising amount of “glue work” is handled by scripts and markdown.

The honest joke is: I haven’t automated my job away; I’ve given myself a promotion.
I went from “Dev + PM + Architect + Tester” to “Director of Tiny Robot Teams” and I’m weirdly okay with that.