> Please write a manual on how to cleanup after AI rockstar managers who think they can code.

Why are you allowing AI rockstar managers to (I assume) push without code review? Why are you cleaning up the fallout? It's not AI issue, it's people issue

▲

piva00 6 hours ago | parent | next [-]

It's the mandate from top-down. Of course it's a people issue, the problem is that the people creating this issue are exactly the ones paying us.

My manager got the mandate she needs to start coding, she doesn't want that, no one in our team wants that, she's a great manager exactly where she is right now. Nonetheless, we are helping her to code to show something for the higher-ups so she can keep her job, we really don't want to lose one of our best managers because some C-level is anxious about AI...

▲

eithed 5 hours ago | parent | next [-]

Even if it's a mandate top-down, you can:

- show increase in errors and outages caused by this approach

- integrate manager changes into your CI pipeline (coding / reviewing / testing / documentation)

- discuss how your manager can do the changes they need to do without sidetracking all other work

Make it indeed about the money: coding by PM + fixing what was coded + dealing with fallout is greater expense than coding by PM + automated guidelines + reviewing what was coded.

That is - if the environment you're working in is reasonable and it's not a power play by your PM

▲

piva00 4 hours ago | parent [-]

I don't know why you assumed it was a PM thing, the mandate is for EMs to be more "hands-on".

On your points:

Manager changes are always going to go through the usual pipeline, we are 10k+ people so there's not even a way to go all gung-ho pushing stuff. They need to be reviewed, approved, etc.

But we don't want our manager to code, nor does our manager, so we are just helping to cross the bare minimum expected from higher ups. For my team it's not an issue with our manager's code (those will be at max small fixes, well-defined, the most trivial stuff), the issue is they are mandating managers to do it.

I don't know what size of company you work at, where I am at there is simply no incentive for me to do all the extra work to show execs/higher management the issues cropping up.

I don't even have access to them, I have to pass through other channels, those might compile reports from many people to try to present a case, if they get to present a case then there's a whole other discussion to happen at director/VP/C-level about what they want to do, and since it goes against their big mandate it most likely will just be thrown out.

In this structure I have no motivation at all to go out of my way to perform data gathering/analysis, wrapping it all in a nice concise document explaining what the data means, potential remediation, etc. just to become a footnote in someone else's document that ultimately will not change anything from the VP/C-level mandate.

	▲	eithed 3 hours ago \| parent [-]
		I assumed that as it was hitting too close home (both PMs and EMs were expected to use AI, with PM trying to code in solutions that they didn't have expertise nor domain knowledge to deal with; EM was prototyping solutions that had access to prod DB that were shut down as soon as we found out). I can only symphatize nonetheless and thank you for giving your PoV.

▲

nuggetdm 4 hours ago | parent | prev [-]

[dead]

▲

Sharlin 6 hours ago | parent | prev | next [-]

Because most people, in most parts of the world, are not allowed to question whatever their superiors do? And, yes, unfortunately are also expected to clean up after said superiors' messes. Of course it's a people issue. AIs just make people issues worse in new and entertaining ways.

▲

wccrawford 6 hours ago | parent | prev | next [-]

100%. You don't "clean up after them." You make them clean up their own mess. You refuse to let a mess into the system in the first place.

Same as it ever was.

The only difference now is that if you let it happen, it'll happen 100x as fast.

When I was mentoring junior devs, I would start by fully reviewing their code. If they had a ton of mistakes more than a few times, I would only review until the first mistake, and then reject it. Repeat, repeat, repeat, until they got the picture that I wasn't going to let mistakes through, and handing me a ton of mistakes was going to waste more of their time than mine.

I let the pain be their pain, instead of mine.

But good developers, I'd help them by doing a more thorough review and not wasting their time. Good developers were the ones that made an honest effort to follow the requirements to the letter and test their own work.

We further emphasized this by having a very simple coding test during the interview, and the only thing we cared about was whether they followed the requirements to the letter. There wasn't a lot left to the imagination, and the requirements were very clear. Anyone who missed them wasn't someone who would do well with us.

That very same test will help filter out a lot of AI-braindead candidates that don't check the AI's work as well.

Actually, I wish I still had the exact test so I could throw it against an AI and see what happens. I'm a little afraid that it would pass it too easily now. I'm not sure how I'd fix it to prevent them from just using AI.

▲

elzbardico an hour ago | parent | prev [-]

The code is AI reviewed, and I was ordered to change repo setting so a single AI review is enough. I've tried suggesting a lot of things, but it is not on my paygrade to allow or disallow something, only recommend.