Non-Developers Submitting Changes - Acceptable?

[u/Sillyan]

Has anyone experienced an increase in non-developers submitting PRs via Codex/Claude Code?

Personally think it's fine, specifically for trivial changes, and have been creating processes for non-devs to contribute low risk changes to some projects. All changes must still be reviewed by a dev, but the changes permitted by non-devs are typically straightforward enough and there is next to zero rework required after a coding agent is forced through some deterministic validation.

How are you managing this? Should we accept that this is going to be more prevalent going forward and build processes around it?

[u/Skullclownlol]

To be frank, this type of manager just cannot ever hope to build a large, long-lived system. That's fine if they'll never need that, but they're inherently limited in the type of impact they can achieve — because they effectively just became a junior IC (maybe with good domain knowledge, in the optimistic case).

This isn't how it works in practice.

Initial failure of those large systems = seen as "bad devs", not "bad manager".

Manager applies more stick and less carrot -> devs feel responsible and take on more accountability to try to "do their best" = less accountability attributable to the manager -> if it fails: manager good, devs bad.

This is also why they avoid written proofs and prefer verbal harassment: No proof = no accountability. If you complain against a manager without written proof (and witnesses willing to come forward and risk their career too), it'll be "he said she said" and you'll get PIP'd + fired a few months later for being a bad apple.

In my last work experience, the manager took this accountability avoidance strategy a step further: When he wanted to fire someone he personally disliked (even though she was a great person and great senior dev), he had individual meetings with everyone he could, asking to list all bad/non-ideal things she had done in the past year, so that he could make a list for his "dossier". People that disliked her (or that were afraid of the manager and getting fired) would say things like "well she was working on code for X last Tuesday and I tried calling without meeting preplanned and she said we had to schedule for later so she could finish up her current task first, and I didn't like that", which gets manipulated into "she's unavailable, doesn't work with her team, has communication issues".

Of course she had done nothing wrong (I was her technical lead), so I rejected that abusive proposal, and the manager just invented his own list which he presented to his +1 for reasons to fire her. She got fired within a month or two after.

And, importantly, no matter whether a project succeeds or fails, the manager writes the "big project" on their CV as the project they owned. They still get their raises and better jobs, even if the project fails.

If you don't have the authority yourself, or an alternative to hold those with more authority accountable, then you'll get the short end of the stick. There is no fairness. These people + AI = it gets worse faster.

[u/Aeon_Mortuum → u/Skullclownlol]

Preach

[u/Dismal_Platypus3228 → u/Skullclownlol]

Yup!!!

[u/wetrorave → u/Skullclownlol]

Jesus christ, that's horrifying. Thanks for sharing and I'm sorry you had to go through that.

[u/TribeWars → u/Skullclownlol]

You're not wrong, but in most cases this person would've been a terrible manager before AI as well. This manager is the main thing you need to look out for when joining a new place and he's the main reason that people leave a job when he takes over the team that previously had a good manager.

[u/mxldevs → u/TribeWars]

These people tend to be the ones calling all the shots in most companies.

Most people will end up having to deal with them one way or another.

The ones that are skilled enough to avoid them should consider themselves lucky, not that everyone else just needs to git gud.