I wasted three weeks on Cursor before realising it was the wrong tool for the kind of work I was doing. On April 7, 2026, I switched my spec-writing to Claude Projects, kept Cursor for edits, and moved the messy planning into Linear. That was the first week I started saying, out loud, that opus 4.7 knows the real kelsey.
The problem wasn’t code completion. Cursor was fine there. The problem was that I kept asking it to hold too much context: product notes, user feedback, half-finished prompts, and the weird little constraints that make a side project feel coherent instead of stitched together. My daily setup is Cursor for code, Claude for the spec, Linear for the queue, and a plain text scratchpad for the stuff I don’t trust any model to remember. Everyone says “just use one AI app for everything” — that’s wrong because the workflow breaks the moment you need continuity across more than one session.
Opus 4.7 was the first model that consistently felt like it had met the actual project, not just the prompt. Not magic. Just fewer dumb misses. Good enough for v1, not for the changelog.
April 7–9: The first pass that didn’t collapse
I ran the same long-form drafting brief across three sessions on April 7, 8, and 9. The task was a technical doc rewrite for an internal onboarding flow, about 1,900 words of source material, with three constraints: keep the tone casual, preserve exact API names, and cut the total length by roughly 30%. Cursor kept drifting into code-centric phrasing. Claude Sonnet 4.6, in a plain chat, got the structure right but flattened the voice. Opus 4.7 was the one that kept the vocabulary intact while trimming the fat.
Across those three sessions, I accepted the first output 2 times out of 3. That’s not perfect, but it’s the first time my retry count dropped below two on a doc task this messy. The accepted drafts landed around 1,250 to 1,330 words, which was close enough to ship after one human pass. I’d still edit the opening paragraph. I wouldn’t rewrite the whole thing.
Side note: I’m picky about this stuff because a model can be “correct” and still sound like it was assembled from release notes. Opus 4.7 didn’t do that nearly as often. It knew where the project was going, which sounds vague until you’ve spent an afternoon untangling a spec that keeps forgetting its own nouns.
Where it beat the usual Twitter advice
Twitter loves the idea that the best model is the one with the biggest context window, full stop. I disagree. Context is only useful if the model can keep the threads straight. In my experience, Opus 4.7 was stronger on continuity than on raw breadth. I’d rather feed it 8 focused pages and get a coherent draft than dump 40 pages into a model that starts hallucinating priorities.
Key Takeaway
Opus 4.7 only felt “real” once I stopped using it as a universal assistant and started using it as the spec brain for one project at a time.
April 10–16: What changed in the code workflow
This was the week I tested it on codebase refactor work. The target was a small TypeScript app, about 14 files, with one ugly state-management layer and a couple of brittle tests. I fed Opus 4.7 the repo notes, a short migration plan, and one failing test file. It produced a patch plan I could actually follow, not a fantasy rewrite. That matters because I don’t want a model that writes elegant nonsense. I want one that can survive contact with my code.
Cursor still won on local edits. No surprise there. Its @-symbol context is still the fastest way to point at a file, a function, or a block of text and get a targeted change. But Opus 4.7 was better at deciding what not to change. That saved me from a couple of over-ambitious refactors I would have regretted on Friday night.
| Task | Cursor | Claude Sonnet 4.6 | Opus 4.7 |
|---|---|---|---|
| Local code edit | Fastest | More verbose | Careful, but slower |
| Spec rewrite | Drifts | Solid structure | Best continuity |
| Refactor planning | Too eager | Decent | Most realistic |
| Changelog polish | Okay | Good | Still needs human taste |
My acceptance rate on code-adjacent outputs was 68% over 50 prompts that week. That’s the number I care about, not some benchmark screenshot. If I’m below 50%, the tool is costing me time. If I’m above 65% on a side project, I keep it in the stack.
The part nobody mentions
Most guides treat AI tools like interchangeable vending machines. They’re not. Opus 4.7 knows the real kelsey because it remembers the little project rules: don’t rename the API, don’t invent a new abstraction unless the current one is broken, and don’t make the onboarding copy sound like a startup deck. That kind of memory is what makes the output feel usable.
April 17–22: The workflow I’m keeping
By the third week, I’d settled into a rhythm that actually fits how I ship. Claude Projects holds the long-running spec and decision history. Cursor handles implementation. Linear gets the tasks that need a deadline. Opus 4.7 sits in the middle as the “translate this mess into something I can use” layer. That sequence sounds fussy, but it saves me from context thrash.
I tested this across 18 prompts in one weekend, mostly around long-form drafting and technical doc rewrite. Average turnaround was 41 seconds for a first draft and 74 seconds when I asked for a second pass with tighter constraints. The output wasn’t always perfect. One draft over-explained a migration step I wanted to keep terse. Another missed a nuance in tone. Still, I only had to regenerate twice. That’s a win for me.
Your mileage may vary, especially if you’re doing pure codegen or one-off chat. But if your work looks like mine — side project, scattered notes, a live repo, and a backlog that keeps changing shape — Opus 4.7 is the first model I’ve used that feels built for the real version of the project, not the demo version.
| Workflow piece | What I use it for | Why it stays |
|---|---|---|
| Claude Projects | Spec memory | Holds the narrative across sessions |
| Cursor | Code edits | Fast file-level context with @ references |
| Linear | Queue and priorities | Keeps me from improvising the roadmap |
| Opus 4.7 | Translation layer | Best at turning messy input into usable output |
What I learned
Opus 4.7 isn’t the tool I’d pick for every task. It’s the one I trust when the work has memory, constraints, and a bunch of half-finished decisions attached to it. That’s narrower than the hype, but more useful than the hype too.
Next time I’ll…
Next time I’ll start in Claude Projects sooner, keep Cursor on a shorter leash, and stop wasting days trying to make one tool do three jobs badly. The practical takeaway is simple: use Opus 4.7 for the thinking, not the typing, and let the rest of the stack do what it’s already good at.
Q: Does opus 4.7 replace Cursor?
A: No. I still use Cursor for implementation because its local file context is faster and cleaner. Opus 4.7 is better as the planning and rewriting layer.
Q: What kind of tasks did opus 4.7 handle best?
A: Long-form drafting, technical doc rewrite, and refactor planning. It was less convincing for pure code generation where speed matters more than nuance.
Q: Would you use it for a fresh project from zero?
A: Yes, but only if I pair it with a place to keep state, like Claude Projects. On a blank chat, it’s useful; with project memory, it’s much more dependable.
opus 4.7 knows the real kelsey because it helped me ship the version of the project that actually existed, not the one I wished I had built. Which part of your stack is still pretending to do every job?
Related reading
Sources: theargumentmag.com, sfist.com, techdirt.com, aimlapi.com