It's a tool. You get used to new tools. These days I can easily process "did something interesting appear" in the peripheral vision at the same time as continuing to type. But the most useful things don't happen while I write. Instead it's the small edits that immediately come up with "would you also like to change these other 3 things to make your change work?" Those happen in the natural breaks anyway, as I start scanning for those related changes myself.

A tool that forces me to shift from creating solutions to trying to figure out what might be wrong with some code is entirely detrimental to my workflow.

Is that your actual experience or expectation? If you're just making assumptions, I'd encourage you to give it an actual try. Talking about using Cursor is a bit like talking about riding a bike with someone who never did it. (But yeah, it's totally not for everyone, and that's fine)

Very early on I took pains to figure out what toolchains gave me traction and which tools produced waste complexity.

I think a lot of the excitement about using LLMs to code is because a lot of teams are stuck in local optima where they need to use noisy tools, and there's a lot of de-noised output available to train LLMs.

This is progress in searching and mitigating bad trade-offs, not in advancing the state of the art.

The latter is usually much easier than the former on a small scale, so your statement is very surprising.

You find revising correctly looking but potentially wrong code easier than just writing correct code?

Obviously, yes. For the exact same reason it's true for math homework, too!

Most code most people write is trivial in terms of semantics/algorithms. The hard bit is navigating the space of possible solutions: remembering all the APIs you need at the moment - right bits of the standard library, right bits of your codebase, right bits of third-party dependencies - and holding pieces you need in your head while you assemble some flow of data, transforming it between API boundaries as needed. I'm totally fine letting the AI do that - this kind of work is a waste of brain cycles, and it's much easier to follow and verify than to write from scratch.

When I’m writing code, I often switch between an high-level mental description and the code itself. It’s not a one way interaction. The more I code, the more refined my mental solution becomes until they merge together. I don’t need to hold everything in my memory (which is why there are many browser tabs opened). The invariant is that I can hand over my work any time and describe the rest of my solution. And the other advantage is the growing expertise in the tech.

> in the peripheral vision

this seems physiologically unlikely.

We do it all the time. I can type while talking to people. I can also read/process the text ahead while saying out loud what I read a few words back. We do a lot of things concurrently when dealing with text - I'm not staring at the cursor when writing code either.

I did mean it literally. the solid angle covered by the fovea is tiny.

The eye also doesn't literally stay 100% static when you look at something.

You can create markdown files containing all the planning you did and Cursor will have all of that as context to give you better suggestions. This type of prompting is what gives amazing results - not just relying on out of the box magic, which I think a lot of people are expecting.