I've been coding professionally for almost 30 years. I use Claude Code heavily, even for larger features. To get that to work half-decent, you have to take on a PM/Tech-lead role, you're no longer a senior engineer.

For large pieces of work, I will iterate with CC to generate a feature spec. It's usually pretty good at getting you most of the way there first shot and then either have it tweak things or manually do so.

Implementation is having CC first generate a plan, and iterating with it on the plan - a bit like mentoring a junior, except CC won't remember anything after a little while. Once you get the plan in place, then CC is generally pretty good at getting through code and tests, etc. You'll still have to review it after for all the reasons others have mentioned, but in my experience, it'll get through it way faster than I would on my own.

To parallelize some of the work, I often have Visual Studio Code open to monitor what's happening while it's working so I can redirect early if necessary. It also allows me to get a head start on the code review.

I will admit that I spent a lot of time iterating on my way of working to get to where I am, and I don't feel at all done (CC has workflows and subagents to help with common tasks that I haven't fully explored yet). I think the big thing is that tools like CC allow us to work in new ways but we need to shift our mindset and invest time in learning how to use these tools.

I’ve arrived at something similar:

* brainstorm all the ideas, get Claude to write docs + code for all them, and then throw away the code

* ask it to develop architecture and design principles based on the contents of those docs

* get it to write a concise config spec doc that incorporates all the features, respects the architecture and design as appropriate

* iterate over that for a while until I get it into a state I like

* ask it to write an implementation plan for the config spec

* babysit it as I ask it to implement phase by phase of the implementation plan while adhering to the config spec

It’s a bit slower to than what I’d hoped originally, but it’s a lot better in terms of end result and gives me more opportunity to verify tests, tweak implementation, briefly segue or explore enhancements, etc.

> To get that to work half-decent, you have to take on a PM/Tech-lead role, you're no longer a senior engineer.

But you’re saying it can be half-decent?

The problem is that about 75% of HN commenters have their identities tightly wound up in being a (genuflect) senior engineer and putting down PM/tech-lead type roles.

They’ll do anything to avoid losing that identity including writing non-stop about how bad AI code is. There’s an Upton Sinclair quote that fits the situation quite nicely.