You will have to decide how you like to work, some people are trying to go all in on how agents work: let them run long sessions, set constraints through /skills, evals and context but then trust them to fully implement the code (dont even bother reading any code, reading code is an anti pattern). Others use AI like a junior developer, giving clear discrete tasks, monitoring and steering for architectural and coding style course correction and working on teaching it better practices through context management and rules. I am in the treat it like a junior camp but have also had products where I end up reading less code than I would expect.
You'll notice the tools push different perspectives, coding in VS will probably push more of the discrete task, AI as a junior dev approach, claude code/codex/pi/opencode etc can be more "autonomous, dont even show the diff" vibes with long running tasks that spit out 10,000 lines of code without even asking for any feedback or review.
What I have found is that planning documents are critical, start with an agile roadmap that links to epics files outlining large features. They should have clear acceptance criteria that act as gates to close out stories/sprints/epics. Every document should say "follow red/green TDD" so that testing discipline is a firm requirement.
I have also found that AI will go rogue no matter how good your context, planning, evals or TDD, so always work on a clean git branch so you can blow it up if the AI does something wrong. Treat AI sessions as experiments and prototypes and be careful of feeling sunk cost fallacy. Code gen is cheap so do implementations 4 times until you get "good" code/ui/ux architecture etc.
I would be happy to do a pair programming session to show how I do things. I built www.propelcode.app an agentic IDE so I can experiment with ways of coding and not be dependent on the frontier labs or big company products.
https://calendly.com/ryanwmartin/open-office-hours