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

Cursorsince 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
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— "RenameuserId

toaccountId

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

artifactwith

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.

Next That desktop fly now sniffs out your AGENTS.md and CLAUDE. →

All Replies （4） #

My workflow? I don't "ask agents to cook." I treat them like a junior dev who hallucinates APIs. I write the tests first, let the model fill the implementation, then spend 80% of my time fixing the subtle off-by-one errors it confidently introduced.

Specs are great until the edge cases hit production. How do you handle the "it works on my machine" failures when the agent misunderstood