> I use LLMs for exploration and for review, but I write the code myself. I find it hard to believe why so many engineers try to avoid it. It’s not consuming much of my time. And it’s actually the most enjoyable part.

At my workplace, there is more work to be done than there is engineers, and approximately 2 engineers per service. I can spin off multiple Claude Code instances on unrelated work, steering them occasionally, and then finally reviewing the output. After I have reviewed it, I post it for team review.

You're absolutely right that my depth of familiarity is lesser with this code, but we are absolutely shipping more as a result of increased parallelization.

The bottleneck now is typically reviews - both pre-push and team reviews.

▲

M0r13n an hour ago | parent [-]

This seems to assume more code shipped equals more work done. I am still not convinced that this is necessarily the case. Sometimes it is. Sometimes it is not. You mentioned that reviews are now the bottleneck and that your familiarity with the code has decreased. That tradeoff might eat into the parallelization gains over time.

▲

radlad an hour ago | parent | next [-]

Definitely not - the biggest risk with this increased speed is going full-bore in the wrong direction. A product mindset (and a critical eye to architecture) matters more now than ever.

▲

leptons an hour ago | parent | prev [-]

Most people hyping their AI use mention the short-term gains without taking into account how it affects overall long-term success. We are creatures of convenience.

	▲	radlad an hour ago \| parent [-]
		Considering most teams have only switched to heavy AI use in the past few months, the verdict is still out on this. That said, I've had lots of success using AI to learn, refactor and clean up codebases. I notice another trend were a lot of AI naysayers haven't really spent a ton of time getting intimately familiar with AI.