> write code to do this in this file

I haven't had to micromanage to this level. I usually start with a spec for a feature, which will be as detailed as I am opinionated about the feature. But it's usually on the level of a high-level context, plus some key implementation details (technology choices, key requirements, maybe an interface/API specification to 80% detail), and then the project already has high-level policies documented about e.g. how to structure files within the project.

Then I do a planning phase, task breakdown, and implementation of subtasks all within the model. I do read through it, but mostly the quality is good and I might make a couple notes. Then I do a review phase, which usually picks up a couple things. I'm moving towards less manual review of results and more automation as I learn what I can and can't trust the model with.

There's definitely a capability gap vs. larger models, but honestly I kind of prefer this workflow, as I stay more in touch with how the codebase is structured.

And it's great to be able to experiment as much as I want without worrying about how many tokens I'm burning or how close I am to a usage limit.

Some people like it better when they direct the solution because they walk away with a better understanding of it.

This has emotional/psychological aspects (it feels less like LLMs are replacing you), as well as practical ones (overall complexity is bounded by what the dev brain can understand/grasp).

A dev work becomes more and more about reliability, signing off safe software with a litmus test: “I will be on to handle this code failure as if I had written it”.

All the above points towards keeping tight control over some level of abstractions and delegating others.