After six months with Cursor, here's where the real leverage actually shows up

The "coding agents killed my identity" narrative keeps circulating, and I think it confuses tool misuse with tool capability. I've been full-time on Cursor since January — before that Copilot, before that raw GPT-4 in the browser. My experience doesn't match the burnout spiral at all, but only because I treat the agent as a junior pair programmer, not a replacement architect.

My actual loop (what changed, what didn't)

1. Spec first, generate second — I write a SPEC.md for anything non-trivial: interfaces, error cases, data flow, test scenarios. The agent implements against that spec. If the spec is vague, the code is vague. That's on me, not the model.

2. Small, reviewable diffs — I never accept a 2,000-line PR from the agent. I prompt for one file or one function at a time. Cmd+K for inline edits, @file context for cross-file changes. The review burden stays manageable because the surface area is small.

3. Tests as the contract — I write the failing tests before asking the agent to implement. The agent's job is making them green. If it can't, my spec was wrong or the problem is harder than I thought. Either way, I learn something.

4. Architecture stays mine — The agent proposes directory structures or pattern choices. I approve or rewrite. It doesn't "design the system" — it suggests, I decide. That distinction keeps the chess-game satisfaction intact.

Where the original post has a point

Mental throughput is higher. Context-switching between "write spec," "review diff," "write test," "debug agent hallucination" is a different cognitive load than "think, type, compile." I mitigate this with:

• Strict timeboxes — 90-minute agent sessions, then 30 minutes offline reading code I didn't write. Forces comprehension.
• Local-first context — @codebase indexing in Cursor means I don't need to paste 50 files. The agent pulls what it needs; I verify what it used.

Config that prevents auto-accept mode

// .cursor/rules/agent-behavior.mdc
---
alwaysApply: true
---
- Never create new files without explicit ask
- Prefer editing existing files over creating new ones
- Ask before adding dependencies
- Write tests in the same style as existing test suite
- Max 150 lines per response unless asked otherwise

# .cursor/mcp.json — keeps context grounded
mcpServers:
  postgres:
    command: npx
    args: ["-y", "@modelcontextprotocol/server-postgres", $DATABASE_URL]
  github:
    command: npx
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: $GH_TOKEN

The MCP servers let the agent query the actual DB schema and PR history instead of hallucinating table names. Cuts review cycles in half.

What's still valuable (and always was)

• Reading unfamiliar codebases fast — I can drop into a legacy service, ask "explain the auth flow," get a 90% accurate map in 3 minutes. That used to take hours of grep.
• Refactoring at scale — "Rename userId to accountId across the monorepo, update tests, don't touch migrations" — done in one prompt with verification.
• Throwaway prototypes — Need a quick API mock for a design review? Two minutes. Throw it away after.

The "code has 0 value" claim feels like conflating artifact with understanding. The OS you vibe-coded in a weekend — you still had to specify the scheduler, the memory model, the syscall interface. The artifact is cheap; the specificity isn't.

I still write neovim configs by hand. I still read papers. I still contribute to open source (my last PR was a Cursor-assisted refactor of a CLI flag parser — the agent did the mechanical rename, I wrote the migration guide). The tool didn't kill the craft. It just raised the floor for what counts as "boilerplate."

If you're feeling the identity loss, try this: pick one component this week. Write the spec by hand. Write the tests by hand. Let the agent fill the middle. See if the puzzle-solving feeling comes back.