Same here. Honestly, there's also a bunch of human friction that goes away. I can tell a junior that a change needs to be significantly refactored (or even thrown away entirely) without the psychological damage of discarding days/weeks of work from them.

Previously, I would need to do the trade-off calculation. How urgently does this need to ship, and do we have time to rework this? What are the deal breakers that need to be addressed, versus what things are best practice/ideal for maintainability? How did their last code review go and do they need a small win right now?

There's no more "nit" comments tagged as nits: just things to fix. It's de-personalized in the sense that we can both at least pretend/have plausible deniability and blame the model for being dumb, as opposed to the person making mistakes. I flat out told someone that a PR was not solving the right problem earlier, and neither of us thought it was a big deal. I could give the technical guidance and suggest a path forward to "help Claude understand better".

▲

dpark 19 hours ago | parent [-]

> It's de-personalized

I had an interesting conversation with a junior engineer who made this observation. She shipped a feature, we gathered data, and based on data we pivoted to a different design. She called out that she wasn’t attached to the code because AI wrote it. Not that she didn’t care about quality or effectiveness of the product, but the personal emotional attachment to the code itself was not there. Probably a healthy thing. I’ve seen senior engineers defend mediocre code because they wrote it and changing it was an ego hit.

▲

supern0va 14 hours ago | parent | next [-]

I have to admit that I'm curious why this is the case. I almost wonder if the pseudo-anthropomorphizing of these models is partially what helps here, similar to how I don't take it personally when I give instructions to a junior engineer and they fuck it up (though, I probably should to at least some degree more than I do).

	▲	dpark 12 hours ago \| parent [-]
		Probably something about the personal time and effort invested in a thing. I would feel much less personally invested if, for example, I created an outline of a story and then paid a ghostwriter to fill it in.

▲

ed_mercer 18 hours ago | parent | prev [-]

So then, why have the junior engineer in the first place?

	▲	supern0va 15 hours ago \| parent \| next [-]
		The same reason we had them before? A few juniors can be productive with oversight and guidance. Half the battle is learning what good work looks like, and figuring out what it is that you should even really be building, and those are skills you develop.
	▲	dpark 4 hours ago \| parent \| prev [-]
		This feels like you just have that retort in your pocket waiting to use it because it didn’t seem relevant here. What does this even mean? Why have the junior engineer if they aren’t irrationally invested in the code the write?