If churning out boilerplate is what your employers sees as product, does it really matter? Coding udeals are valuable in a vacuum but most companies want those PRs merged, technical debt be damned.

If this is the case they need to up their abstraction game.

Isn't most code boilerplate belts out the choir.

what?

"Isn't most code boilerplate?" belts out the choir/peanut gallery/greek chorus

Churning out boilerplate is a large part of the job. The quality of that boilerplate is part of what makes great engineers great engineers.

Knowing when and how to use dependency injection, making code testable, what to instrument with logs and stats, how and when to build extensible interfaces, avoiding common pitfalls like race conditions, bad time handling, when to add support for retries, speculative execution, etc. are part of parcel of what we do.

If ChatGPT can help raise the quality of work while also increasing its quantity, that'll be a huge leap in productivity.

It's not all there yet, but I've been using it to write some simple programs that I can hand out to ops / business people to help automate or validate some of their tasks to ensure the smooth rollout of a feature I've developed.

The resulting ChatGPT code--I chose Go because I can hand over a big fat self contained binary--avoids certain subtle pitfalls.

For example, the Go HTTP client requires that you call Close() on a response body, but only if there's no error.

The code it spat out does indeed do that correctly. And it's well documented.

It's far from perfect; I've seen a subtle mistake or two in my playing around with it.

I'm now no longer so much an author but an editor for basic stuff. I now have my own dedicated engineer with a quality level that oscillates wildly between fresh intern and grizzled veteran.

It'll only get better over time.