It's 2026 and the landscape has settled. The "best" tool isn't the one with the most hype; it's the one you can actually live with. For a Python/React shop, the winner is still Cursor in its agentic mode, but you have to cage it correctly or it'll burn your house down.
My recipe is simple: use it as a hyper-fast intern that needs its output reviewed by a senior engineer (you). Isolate it from your main repo until it passes the sniff test. Here's my project-specific `.cursorrules` to keep it from hallucinating new dependencies or rewriting your entire state management on a whim.
```markdown
# Project Conventions
- Python: Use typing. Use Pydantic V2 for data models. Async where IO-bound.
- React: Functional components only. TanStack Query for server state. Zustand for app state. No class components.
- Testing: pytest for Python. Vitest + React Testing Library for React.
- **CRITICAL**: Do NOT propose changes to `pyproject.toml` or `package.json` without explicit user approval.
- **CRITICAL**: For new features, propose a implementation plan first. Do not generate more than 80 lines of code at once.
```
Pair this with a strict "edit" workflow: never let it open more than two files simultaneously. Its job is to draft. Your job is to architect and verify. The value isn't in autonomous coding; it's in turning a vague requirement into a draft PR in 90 seconds, so you can spend the next 30 minutes making it actually production-worthy.
Prove it.
Totally agree with the "hyper-fast intern" analogy. That's exactly how I've gotten real value from it without chaos.
The edit workflow limit is key. I'd add one more guardrail: run its generated changes through your existing CI pipeline in a feature branch before it even touches a human reviewer. If it breaks the linting, tests, or the container build, the agent gets the feedback automatically. It learns your project's real boundaries faster that way.
Your .cursorrules are solid. I do something similar but also lock down the Dockerfile and terraform modules - learned that the hard way when it tried to "optimize" a multi-stage build and broke caching completely.
Keep deploying!
That "hyper-fast intern" analogy really hits home for me. It makes the risk feel manageable.
Your rule about locking it out of pyproject.toml and package.json is so crucial, maybe even the most important. I've seen it try to "update" a pinned dependency to a version that wasn't even compatible yet, just because it was newer on PyPI. How do you handle that review step? Do you have a checklist for those critical files, or is it just a hard visual inspection every single time?
One step at a time