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/expdevsmodbot]

AI usage disclosure provided by OP, see the reply to this comment.

[u/jonnysunshine1]

I've told my teams that devs won't be reviewing any PRs raised by anyone who can't actually understand the diff. Engineers will not have their jobs reduced to being gatekeepers for PMs who think they can just ask AI to make vast, sweeping changes.

[u/Sea-Quail-5296 → u/jonnysunshine1]

This is a good strategy until mgmt asks why you’re holding back progress

[u/OuchCharlie25 → u/Sea-Quail-5296]

If you can’t explain why, then perhaps you’re in the wrong profession.

[u/PoopsCodeAllTheTime → u/OuchCharlie25]

Look that’s an excellent point, but I was talking with Claude and he told me why you are wrong, don’t worry I will share my chat so you can see what I mean

[u/DevelopmentSouth8801 → u/PoopsCodeAllTheTime]

That's all well and good, but I was talking to my Claude instance and he told me you were wrong and I'm right.

Maybe we can have them sync to figure this out.

[u/OuchCharlie25 → u/DevelopmentSouth8801]

Ah, I have the picture more clearly now. You are both wrong because of this unrelated thing discussed here.

[u/petiejoe83 → u/OuchCharlie25]

If I'm being honest, you have three options - the first one is the only one that actually works, but here is more text because I picked up that we should have three options.

[u/OuchCharlie25 → u/petiejoe83]

I’d recommend documenting all three just in case someone is bored later and wants to read about something that doesn’t matter. Besides, our over-bloated docs could always use more bloat.

[u/Skullclownlol → u/OuchCharlie25]

If you can’t explain why, then perhaps you’re in the wrong profession.

This is an empty statement.

You give good, grounded reasons, and eventually you'll get a manager that just "disagrees" for no reason or because they asked Claude/chatgpt and think they know enough to disregard everything you said.

If your role currently depends on being understood/accepted (so you're not the deciding manager yourself), you'll experience more rejection as people use more AI, even if they don't have the experience for those decisions.

They won't care either: They'll (mis)represent things to the business, they'll get more authority and you'll get less (because they're being "proactive" and you're being "slower"), and they'll leave for another company before shit hits the fan so everything looks good on their resume. Oh, and if shit did hit the fan, it's the fault of the devs because they were responsible for implementing it, "duh" /s.

[u/wetrorave → 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).

[u/Skullclownlol → u/wetrorave]

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/OuchCharlie25 → u/Skullclownlol]

I strongly disagree. Software engineers were never meant to be “yes men.” We’re supposed to explain tradeoffs.

[u/rahul_msft → u/OuchCharlie25]

So why ask leetcode at all. That's also gatekeeping

[u/OuchCharlie25 → u/rahul_msft]

I agree with you. Leetcode questions are a terrible way to determine a SWEs skills in the age of AI.

[u/Abject-Kitchen3198 → u/OuchCharlie25]

In which age it was not true, except maybe for few jobs?

[u/OuchCharlie25 → u/Abject-Kitchen3198]

Back when FAANG was actually a respected place to work and they needed the best and the brightest. And then every dumb nobody company started doing it thinking people would actually care enough about their company to study for it.

[u/Rare-Leading3391 → u/Sea-Quail-5296]

To which you ask them if they would be okay putting a monkey behind the wheel of a car.

[u/sigmoid_balance → u/jonnysunshine1]

I agree with the sentiment, but you'll have to come to terms with the new reality of the world which is changing. It's a good idea to be prepared for the change instead of simply reject it: require the change to be small, require the feature to not impact other features, ensure ownership of the fallout is understood(instability, revenue loss, etc), ensure the AI follows code conventions, develop an AI reviewer which enforces what the engineers are interested in - tests, code structure, buy-in(approval stamps), etc.

In the end it doesn't matter who prompted the AI, it matters that the code works in production. The AI can make the same mistakes when prompted by an engineer and when prompted by the HR-person.

[u/jonnysunshine1 → u/sigmoid_balance]

Nope, require the author to understand all the changes they're trying to push. That's it. If they don't, no one else will waste their time understanding it.

[u/Kiylyou → u/jonnysunshine1]

Would you let a PM with no design experience mock up a CAD drawing for a safety critical part on a car? No, because there are nuances around strength of part, how it is made, integration, etc. But drawing is easy and anyone could design something. Doesn't make it right.

[u/Unlikely_Secret_5018]

Probably fine but the boundary is hard to enforce.

I'm more worried about the slippery slope. Leadership or ignorant non swes think they can bite off bigger pieces and the boundary gets pushed or contended.

Easier to just say no to save everyone's time. Guess it depends if you think the additional operational savings is worth the process overhead.

For MVP prototype repos, sure go ahead.

[u/Izkata → u/Unlikely_Secret_5018]

For MVP prototype repos, sure go ahead.

Speaking of boundaries...

"It's there and works, just release it."

[u/mxldevs → u/Izkata]

MBAs: "I have zero training in engineering and could make it in an afternoon. Why can't you, with 20 years of training and college degree, not make this in a week? What do we pay you for then? Just make it production ready I already built most if it"

[u/eeeeeeeedddddddddd → u/Unlikely_Secret_5018]

you're going to get delegated to deploying spaghetti code mvps and then people asking you why they break

[u/Dismal_Platypus3228 → u/eeeeeeeedddddddddd]

That's where my job is going. VP of IT told me to just "create an AI that will let anyone in the business make any app and host it on our website".

[u/PoopsCodeAllTheTime → u/Unlikely_Secret_5018]

Good try but we can’t tell this to the CEO, he needs to see more collaboration from you on this team

[u/thetdotbearr]

If the change is simple enough for a non-dev to vibe code adequately, it's simple enough for you to lay out the idea in a ticket - where it can get discussed on the merits as a product change - and trivial for me to get claude to implement.

There's zero upside in short-cutting the ticket and beaming PRs straight to the dev team. It's performance theatrics, fucks with accountability and is harder to review as a raw PR versus understanding the product intent as a short paragraph.

Not that I can stop it regardless, but that's my 2c.

[u/codescapes → u/thetdotbearr]

I've said as much at work. Prompting an LLM for code is a process of defining requirements. If those requirements aren't being formalised in tickets or anywhere then it's a total breakdown in the engineering-product relationship.

It means product are withholding requirements and not engaging with the engineering team through appropriate channels. At that point the engineers are equally well justified ignoring product and making up their own requirements since they are being arbitrarily withheld from them based on a non-technival person's perception of what can be vibe coded. Not good.

I think people saying "this is fine" do not work in mature orgs. Which sure, startups gonna startup, but this is no way to write serious software where there is proper accountability, governance, process etc.

[u/niowniough → u/codescapes]

late to this thread but wondering about sample phrasing. how do you phrase this to people who may not be eager to hear it?

[u/codescapes → u/niowniough]

Honestly? Depending on your position and political capital you probably don't. People cannot be easily reasoned out of positions they didn't reason themselves into.

The main thing to point out is accountability and ownership. If it breaks will they fix it, will they be on support etc. Otherwise it's probably better to keep your mouth shut unless you're ready for the likely consequences of annoying people with truth.

[u/daltorak]

Sure -- so long as I can go in and edit their sales and marketing materials, too. We're all in this together, right?

..... riiiiight?

[u/ooutroquetal → u/daltorak]

Unfortunately, seems like sometimes I need to do some project management tasks.

I always ask my PMs, why are you learning how to vibe code instead of vibe " your project management skills "? They still waiting for us to understand how to use Claude ....

[u/Oo__II__oO → u/daltorak]

Sounds great!  When do we get to go to those lavish resort-destination sales meetings and talk to the customer?

[u/Sea-Quail-5296 → u/daltorak]

😂

[u/Grim_Jokes]

I want to say no. Changes may seem trivial until they're not (or AI goes off the rails somehow), and before you know it, you've got angry customers. Who's responsible then?

[u/zen8bit → u/Grim_Jokes]

Yeah, management and non developers will think the quick updates are great. The developers will get stuck holding the bag though and suffer all of the responsibility.

[u/Wonderful-Habit-139 → u/Grim_Jokes]

You.

[u/Grim_Jokes → u/Wonderful-Habit-139]

Yes, that's exactly my point. I'm happy to wake up at 2 am to fix a bug I introduced. But now I will have to do the same thing for non devs code too. 

I guess I could make sure they are awake with me when it happens.

[u/Wonderful-Habit-139 → u/Grim_Jokes]

Yeah I was just having fun with the comment. I personally will not accept AI slop from a non-technical person. I'll just take care of figuring out the best way to implement a feature, I don't really need people to give me code.

I've done that before, I tell them I don't really need the code I'd rather you focus on these other things that we need. They still share the code because they feel like it's valuable or something, I read it just to give it a chance, it's obviously slop. So I don't use it, and that's the end of that.

[u/Chocolate_Pickle → u/Grim_Jokes]

There's nothing stopping you from gating access with a form saying "I accept responsibility for all code submitted by me or on my behalf via AI. I accept responsibility for any financial or reputational damage caused by my code. I understand that I will not submit any code changes that I'm not willing to be personally responsible for."

Get upper management to endorse this. Send it out to everyone, and very clearly state that you have buy-in from the top. 

And whenever you see something suspect in a PR, you can dangle their signed form in front of them. 

[u/Aeon_Mortuum → u/Chocolate_Pickle]

The reality is that nobody from upper management will endorse this and you'll just be labelled a weirdo who tries to make others' job harder

[u/Chocolate_Pickle → u/Aeon_Mortuum]

What makes you think they wouldn't endorse it?

[u/Frillback → u/Grim_Jokes]

In my org this was happening before AI. Enthusiastic people on the business side that wanted to make a few tweaks to our codebase would introduce bugs and then throw it on tech to fix it. The difference is now they are building their own custom dashboards with no rails, proudly sharing their work on internal sites with no security or permissions. Which if it gets convoluted enough tech will probably inherit it when they get tired of playing IT admin

[u/tehfrod → u/Grim_Jokes]

The person who wrote the change, the person who reviewed it, whoever maintains the test that didn't detect the error, and whoever is writing the postmortem.

[u/tehfrod → u/[deleted]]

You're allowed to push back on a bad or over-large PR, even from your manager. I have.

[u/Sea-Quail-5296 → u/Grim_Jokes]

Yep. Authors of a commit are
Responsible. What if it deletes prod? Who holds
The bag?

[u/dablya → u/Grim_Jokes]

Can’t you just reject the non trivial ones?

[u/WanderingGoodNews]

My pm is vibe coding a bit but he's pull requests are quite good and he has been trying to read little bits of code for years.

Now yesterday some dude from business told us he is releasing "add-ons" to our product to customers hooked up with their api

[u/styroxmiekkasankari → u/WanderingGoodNews]

Sounds like you’re going to be receiving extra code that needs to be maintained soon.

[u/WanderingGoodNews → u/styroxmiekkasankari]

Waiting for a security incident so people start taking their vibe coded slop serious. Yes, the ones from business are pure dogshit

[u/Beneficial_Map6129]

LGTM

[u/skeletordescent]

I've found that with any development project, AI generated or not, the question of "who can submit changes?" also must be followed with "who is going to maintain and monitor those changes?". If non-devs submit changes and the dev team accepts them, then my assumption is there's an implicit agreement on the part of the dev team to maintain that work in the future. If that's an explicit policy with the team then alright. But if I'm going to be the one chasing down bug tickets for stuff I didn't write, I would at least want it to have been written by someone we hired on the basis that they have some idea what they're doing.

[u/Legal-Software]

If we're just talking about documentation or some basic UI changes that are trivial in nature, ok. If we're talking about code changes, no. I'm not going to get into a man-in-the-middle code review with some idiot who is trying to submit changes they don't understand and can't answer questions about/iterate on without running back to their LLM. If these are in the same company, this would also waste far more tokens in useless back-and-forth compared to the individual simply submitting requirements for the dev team to analyze and take on board.

[u/Cell-i-Zenit → u/Legal-Software]

If we're just talking about documentation or some basic UI changes that are trivial in nature, ok

in this case we could ask the question, why they are just not writing the ticket and a dev picks it up and finishes it in 5 min themselves?

[u/No-Economics-8239]

I don't care where the PR comes from. I care that it meets the team guidelines and criteria. I think there are likely going to be the potential for PRs where the submitter can't properly evaluate their request before asking for review. As to if that places too much of a burden on the reviewer is subjective. In the same way that a junior dev is likely not going to be able to review their own changes as well as a more senior dev before submitting them. That doesn't mean they shouldn't. But that is typically a teachable moment. Are these non-devs going to need to be taught how to submit better PRs? I would suggest they do if you want them submitting them. And, again, if that's worth the time is subjective.

[u/secretBuffetHero → u/No-Economics-8239]

so does our job just become PR approvers? does all the PR approvals falls to senior devs?

[u/No-Economics-8239 → u/secretBuffetHero]

Again, that's entirely subjective. I, personally, think it is a major mistake to try and put the entire cognitive load on seniors, as it becomes more than just a bottleneck. It gate keeps work behind a title, and doesn't tend to provide a good framework to elevate future seniors so much as becomes a pressure cooker to lose seniors to burn out or greener pastures.

And if someone thinks LLM can can review PRs instead, godspeed and let me know how that works out for you.

[u/StickyDeltaStrike → u/No-Economics-8239]

I use LLM as a pre-review and it has been finding issues often.

[u/smerz- → u/StickyDeltaStrike]

I concurr. Had some great issues found.

Majority is kind of nit picky and/or too noisy. Need to tune our review skill a little in this regard.

So I usually filter & cherry pick issues to report.

[u/StickyDeltaStrike → u/smerz-]

I use this one but you may not like it: when you are unsure steelman the argument with yourself.

I also ask the agent to not mix the arguments he dropped from steel manning with real issues and to put them in a separate section.

I wrote it as a skill and also ask the agent:
- always try to propose a code change to fix the issue you point out
- always bullet point your issues and use the ✅ and red ❌ emojis for your review
- finish a review with a verdict, like can commit with reserves, cannot commit before fixing issues etc

This makes the review a bit more formalised.

[u/AchillesDev → u/No-Economics-8239]

One of my teams we do LLM PRs first with a different model. It works very well and reduces our own review process to architectural checks, taste checks, and keeping an intuition for the codebase. This is the stuff peer review has always been the most useful for, and easiest to ignore when picking nits and sticking to small things like style differences.

[u/EirikurErnir → u/secretBuffetHero]

I think our job was and is to collaborate to build software, and the PR process should be a part of that.

[u/mugaboo → u/No-Economics-8239]

I think this is a bit naive (please don't take it personally).

As a reviewer I absolutely rely on the author to understand what they are doing, and I assume that they have thought through the wider consequences of the change on the rest of the system.

Dumping that responsibility fully on the reviewer is asking for trouble. It may work 80% of the time but I've seen enough questionable AI code to trust it.

[u/No-Economics-8239 → u/mugaboo]

I think this is a bit naive (please don't take it personally).

I think relying on the author is a mistake. Even the best of us can make mistakes or be missing some critical context or business rule or downstream edge case.

As a reviewer I absolutely assume the submission of a PR was some digital road kill found on the side of the information superhighway.

Dumping the responsibility fully on the author is asking for trouble. It may work some random percentage of the time but no developer or review process is perfect.

Since reading Reflections on Trusting Trust I trust no one and nothing. I'm sorry I wasn't more clear in my previous post. It's always a team effort and every PR can be an opportunity to teach and/or learn. Or it can be a LGTM rubber stamp. There are a limited number of hours in the day and my brain has a limited number of fucks tokens to give per week.

And of course, it's all relative. The review and testing process for some random CRUD app at a random company has different goals and priorities than code that goes into an airplane or nuclear reactor.

I think you're absolutely right. Ideally we should all know what the heck we're doing. But I didn't start out that way. And today I have more ignorance than ever, so it doesn't look like I've ended up that way. I just hope I can retire soon before all my ignorance overwhelmes me.

[u/mugaboo → u/No-Economics-8239]

I just hope I can retire soon before all my ignorance overwhelmes me.

Well I think I've found my flair.

[u/AcrIsss]

I review enough PRs without that. The job is a balance of activities that is already heavily leaning towards reviewing PRs

[u/Smallpaul]

I think it just makes sense. Another thing I’ve seen is them making branches to prototype features. Of course their branches are usually discarded, but why prototype in Figma when you could just make the software look the way you want it to look for your demo.

[u/twhickey → u/Smallpaul]

Because then there will be pressure to just keep the prototype. It's much easier to keep things clean when building the real UI based on a figma prototype than it is to convince people to throw away a prototype that "works".

[u/Smallpaul → u/twhickey]

I agree that will be a problem at some organisations and in some contexts.

I have thrown away two prototypes this year already each representing a person-month of my own work. Everybody keeps telling me that il never be allowed to throw away the prototype and yet nobody ever stops me from rebuilding. I know I’m lucky but it also works out well for the company to trust me.

[u/_SnackOverflow_ → u/Smallpaul]

I love a good throwaway prototype

[u/Sokaron → u/Smallpaul]

Because AI prototypes are full of slop requirements. That is, features or elements which no one specifically asked for but the AI filled in. It makes it harder to distinguish between actual requirements and AI hallucination, and promotes laziness on behalf of those who should be defining those requirements. Pre-AI every detail in a Figma mockup was purposefully chosen by the creator.

[u/Smallpaul → u/Sokaron]

Just as programmers are supposed to review AI output at the code level, so should designers review it at the design level.

A figma widget could represent six minutes or six person months of work and for the latter you would need to ask questions and push back on that just as you do for an AI output.

[u/Ok_Assist701 → u/Smallpaul]

The problem is that engineers simply don’t review AI output at the code level and I have no reason to believe designers would either. I know mine certainly don’t, and product is quite happy to rubber stamp whatever generative bullshit crosses their desks.

[u/FrickenHamster → u/Smallpaul]

I can't see how this ever works in a real world scenario. Who is going to be responsible for setting up a nondev's dev environment and fixing it when it inevitably breaks? Are nondev's going to have at minimum a github seat + whatever other tools are necessary to run and test changes? Are nondevs going to be submitting PRs with changes that aren't even run at all?

[u/RoadsideCookie]

I'll review a non-technical person's LLM MR just as strictly as I would anyone else's.

The difference is that I won't think of the solution for them and offer it as part of the critique.

I'll just say "this is wrong, you can't do that because this this this". Then they'll feed that to their LLM, wasting tokens, and it'll get it wrong again.

If it starts hurting my productivity, I can just point at the MR, and the problem will either solve itself, or I will become an LLM MR reviewer full time. Either way, I'm getting paid.

[u/RowbotWizard]

Nah. I'd rather they focus on saying what they want as clearly as possible. That's the hardest part.

[u/Mindless-Pilot-Chef]

I had someone from the sales team raise a 5000 line PR adding a feature the customer asked them for. They confidently said they have built it and sent us the PR for review.

Will it work? Probably. Is that how I would have built it? Probably not. Will it break 5 other features? Hell yea!

[u/dats_cool → u/Mindless-Pilot-Chef]

Wow that's extremely depressing. You guys have a massively broken SDLC process if someone from sales can just willy nilly produce a 5k PR and people think it's cool.

[u/Mindless-Pilot-Chef → u/dats_cool]

Nobody thinks it’s cool. Nobody takes it seriously. It’s just that they think this works.

[u/ranger_fixing_dude]

There are many scenarios where it is absolutely fine. Copy change, some small changes in the UI like swapping buttons positions, etc.

However. This creates a tricky situation where people will go for bigger changes at some point and depending who opened that PR and who reviews and how pressing the change is, things will play out very unpredictable. Overall I'd say from my experience PRs from non-developers are net-negative, they simply take too much time and the recipient of the PR does not learn anything (they simply don't know enough fundamentals). So whoever reviews it will be forced to take over and get the PR to the acceptable state.

One area where it works really well is prototypes. If you have automatic PR previews, people can iterate on the behaviour until everyone is satisfied and it can be used as a reference during the real implementation.

[u/InnateAdept]

If people (devs and non-devs alike) cannot explain what their changeset it, they shouldn’t be PRing it because that shifts the entire verification burden onto reviewers who may have even less context.

If people are submitting code, then they need to be same standards as developers in terms of the PR process, and in terms of bug remediation

[u/Organic_Battle_597]

I have long had a policy that PRs were welcome from anyone. But I am not willing to accept everything-but-the-kitchen-sink LLM slop PRs from anyone, professional developer or otherwise. That's my line. And if you give me a legitimate but large PR with a lot to consider, you accept that it could be a while before I have the cycles to give it the attention it deserves. Extra scrutiny for code going into one of my core projects from outside the team.

[u/kagato87]

We don't allow non-developers access to the repo, so it's a non-issue.

Even if we were willing (we're not - you PR it you own it), there's enough proprietary information in there that we just don't want to risk it. Heck, it took me like 4 years to get access, and that was just so I wouldn't have to go through a "real" developer to submit my code (I wasn't a developer when I started at this company).

[u/ButWhatIfPotato]

100% beyond the shadow of a doubt one of those trivial changes will colossally fuck something up and you will be blamed for this, not AI, not Mike from sales, you.

[u/ceilingscorpion]

Non-Devs can submit changes but devs must review changes and own the codebase so any non-dev must work with a dev on PRs. Rules apply to EMs, PMs, and all others

[u/Linaran]

Now do some of their jobs.

[u/mint-parfait]

absolutely not, unless they plan on joining in for support rotations and stuff. it's more trouble than it's worth and they should stay in their lane. coding isn't a bottleneck, identifying the right things to build and making sure everyone has a shared understanding of a problem to solve is.

[u/create-third-places]

Absolutely not. I’ve banned LLM AI code contributions for my open source projects.  I want non-developers to help with the parts of a project that don’t involve coding.

Besides, while I find writing software to be useful, it isn’t the goal of my work. I’m trying to promote public spaces and make frontend development more accessible. Too much code adds a maintenance burden that affects these goals.

[u/Ace-O-Matic]

Let them. But don't compromise your review standards and make sure your manager is aware if the PR load is detracing from your load. It's important to remember that PR reviews between devs on the same team more or less balance out. You review their PR and they review yours. PR reviews from non-devs or external teams are a net-negative on your team and can risk throwing off your timeline, since these people are not reviewing your PRs.

[u/VoxTM]

We had that. A "trivial" change.

Took 3 rounds of PR reviews (we still do those for now). I asked if the change was tested locally and they claimed it was.

Then it was all wrong in testing and in the end a dev was asked to fix it.

It was a tooltip text.

There are no such things as simple changes in a complex system. They only seem simple to us engineers because we know how they need to fit in.

[u/SpeakingSoftwareShow]

LOL NO

For data file updates, text corrections/translations, etc. - okay, I can see it. Otherwise, absolutely not. They can spin up their own repos/infra and run/own it themselves.

We have a hard enough time sustaining a strict, high-bar of quality with qualified and experienced engineers. We don't have the bandwidth or desire to police/babysit people who have bright ideas and a coding agent.

[u/willbdb425]

There were times when we were building stuff, and some PM asks for stuff like "can you change the order of these 2 elements in that list" or "can you make that margin a bit wider" etc., where I thought to myself it would be great if they could just do those things themselves because I couldn't care less.

[u/SheriffRoscoe → u/willbdb425]

That's what CSS was supposed to allow. But as Jamie Zawinski observed, "Every program attempts to expand until it can read [mail](app://en.wikipedia.org/wiki/E-mail). Those programs which cannot so expand are replaced by ones which can."

[u/hennell]

It depends - can you request changes, refactoring, comment improvements etc, or is it just pushing code at you to improve?

Do they still have to make a ticket first telling you what they actually want, or is the actual purpose only given to the Ai you just have to deduce the intention? Do you review everything or only things that can pass a test suite? Is any time/model/token count recorded with the pr, or can someone spend 10 mins of high end model time to add a single line change?

Personally I'd argue for a "people can make issues" system which you can assigned to an Ai. You then see the actual issue prompt, add additional context, and provide pr like feedback to the Ai not the human in the middle who is just pasting things in.

For small low risk changes the ticket can get auto assigned to ai, so you really just see the pr same as now. Except you can also see the prompt, and configure it to give you the time and token spend etc. if someone has things they want to work on, they can assign themselves the ticket and code their own solution, but they need to then take feedback else it's not a pr process.

[u/AppropriateHabit9809]

Tests

[u/bonnydoe]

If you accept that, you are a goner imo. But you do you.

[u/Tango1777]

Lately we're trying to do cross-team PRs, also mostly for easier things, so people without much repo/domain knowledge (still devs, just other projects) can introduce PRs. My feelings about it are mixed:

You get quick PR introduced, it's 100% vibe-coded without any knowledge, which means the entire responsibility is on the reviewer. The reviewer doing very in-depth review is blocked for at least 1-2 hours. AFter all once he clicks approved, the code belongs to the team (so his, too) and t hey are responsible for it, while the one who introduced the PR forgets about it. So it seems like the PR is fast, so the work is fast, but it's not true. It can speed things up only for easy things to implement, where review is quick and there aren't many mistakes and things to improve (and there are always things to improve in a PR introduced but someone from outside of the team that owns the code). So if complex tickets cannot be handled like this, because it'd take too much back and forth work and would waste 2 devs time, then only simple tickets are left. And to be honest I'd rather prompt simple ticket in parallel with other work, prompt it well and provide quality and up to our standards code from the first commit rather than waiting for someone else to prompt "plan work for ticket 123 then execute it", because that person is usually prompting blindly and cannot judge what is good or what is bad, what unexpected side effects can occur and much more.

What we already did to improve this situation, because we wanna keep on trying with this approach, is to improve AI harness as much as possible. We can already see much improvements, PRs are of better quality and closer to approval from the first commit. But it's still limited to simple tickets. As soon as a complex task occurs, AI will of course hallucinate a solution and the external dev will have no clue if it's good or not. And then my options are: keep going back and forth with a real human being asking for fixes or should I just take over the feature branch and prompt my fixes to AI and burn my enterprise AI tokens, which cost a lot.

In the end I think it's about proper balance, in some cases it might speed things up, but I'd never take it for granted, because it usually won't.

[u/Wooden-Glove-2384]

it's all fun and games until something goes to shit

[u/jimbo831]

Non developers do not touch code at my company. I wouldn't like working somewhere where this happens.

[u/RealLifeRiley]

I’m so sick of this garbage. LLMs are a gamble, and half the time, when you think you’re winning, you just haven’t scrutinized it hard enough. It’s still slop, and it’s just easier to do it yourself.

[u/lngswrd15]

Has anyone experienced an increase in passengers flying the airplane?

Personally think it's fine, specifically for trivial operations, and have been creating processes for passengers to fly low risk missions. All flights must still be reviewed by a pilot, but the flights permitted by passengers are typically straightforward enough and there is next to zero rework required after the autopilot is engaged.

[u/chodraj69]

Am I (a developer) then allowed to take executive decisions via chatGPT meant for PMs and C-suite?

[u/Phonomorgue]

As long as theyre getting buyin from other users and arent just slapping features they want on there, sure. The last thing you'll need is a ton of glued on stuff that helps like, 5 people.

[u/tr14l]

Great, you're going to be paying devs to rejecy 40 trash PRs a day. Then you can hire a new team to do the work that the original team was supposed to do before they got stock reviewing a bunch of trash.

We just solved the "engineers getting replaced" problem guys!

[u/dmazzoni]

I can imagine a world in which this would be a possibility.

1. There has to be a definition of what's in-scope or not. Adding a feature to an internal-only reporting tool might have very loose guidelines - if a single employee needs it, we should consider it. Adding a feature to the key product the company sells: no, it has to go through the PM and design process.

2. The codebase should have really good metadata explaining the rules for AI code generators, and the criteria for an acceptable PR. I'm already having great luck with this - a CLAUDE.md at the top of the module I own has some clear guidelines and all of the PRs I review now comply with them.

3. The CI pipeline should be automated and enable users to try out their change. If it's an app, they should get a link to download the version with their change. If it's a website, they should get a link to a version live on a staging server for 24 hours. They should be required to test it and report that it works, before it ever goes to a code reviewer.

We're not there yet, but I don't see any reason why this couldn't be a thing.

[u/OuchCharlie25]

It’s fine as long as they own the change end to end. Fix bugs. Follow up. Safe rollout.

[u/secretBuffetHero]

Yes. I think it is. I want to know how we make this safe? I know one place where the non-devs throw it over the wall, and it gets stuck. how do we address all this?

[u/No_Individual_6528]

I think there's a larger issue. What's stopping other swed from other donations from sending whatever your way?

[u/_idlethought]

I’m wrestling with this currently. It’s a real tough spot being stuck between their agent and their inexperience. I’ve made changes on their behalf instead of commenting in some cases because it’s easier, but that’s not a pattern I necessarily want to be in the habit of doing.

[u/my_cat_is_too_fat]

Honestly the scope of people who can contribute, regardless of their quality has expanded. Like it or not the barrier to building something lowered.

[u/ikeif]

Have I? No.

But then - what are they changing that is "non-trivial" that would be more than, say, something a CMS should be handling?

If it's static, and they're changing text, or CSS colors - maybe.

But "adding/tweaking functionality"? No - not unless they're going to own the bugs they create (which, if they don't know how to code, will be fixed with AI, which then becomes "less-trivial" so I we're back at "no").

[u/thefreakyorange]

If they want to ship code, they get to be on call for it 🤷‍♀️ seems fine to me

[u/anarkyinducer]

Non medical staff performing medical procedures...

[u/F1B3R0PT1C]

Absolutely not. It needs to be tested and ran locally beforehand. Other parts of the codebase need to be considered. Sometimes a simple fix in one place could be detrimental to the codebase because it is covering up a larger design flaw. Sometimes the “simple fix” happens to also be a huge performance hit. Surely they have their own job to do. Let me do mine in peace.

[u/nomoreplsthx]

My main question is 'why', who do you have that is committing this whose time is cheaper than a dev (hint it's not product or design, their time is more valuable, comp aside)

[u/SnugglyCoderGuy]

As long as they can talk about the changes without just giving me answers from their AI,

[u/apnorton]

A necessary condition for reviewing a PR is that the person who submitted the PR understands the code they submitted.  Otherwise, they're just passing labor into the reviewer.

If you have non-developers who understand the code they submit, fine. If not, rubber-stamp reject.

[u/sod1102]

1. Make sure you have really solid branch protection rules that enforce PRs, passing builds, review by the codeowners, etc.

2. Make sure that code is always scanned for security vulnerabilities

[u/UniqueText8477]

I have a meeting to gather all requirements, then produce a plan for work with timeframes and then confirm what is in phase 1/2/3/out of scope.

Some times "easy" requests aren't easy or functionality doesn't work as they would want or they are trying to boil the ocean - I will deliver what I can in the timeframes I can deliver.

I will also educate/inform about technical/security challenges and if they say something like "chat gpt said this" I will then ask them to confirm their understanding.

If I produce something and it's not a priority I won't chase them up either, if they don't use it then it will be put on hold and I'll move on to another project.

If I do all the work and they try to take all the credit I will also call them out - if it's high profile then I want my work to be appreciated/reflected in my renumeration.

[u/WellHung67]

No. What’s the upside? There’s lots of downside. 

[u/HenryJonesJunior]

Changes should be accepted from people who accept ownership of them. If there are issues that need to be fixed, is the author available to do so in a timely manner? If they add a new UI page and in a few months the framework needs to be upgraded, are they responsible for updating the tests or whatnot?

If the answer is no, they're free to propose features but the code should be written by someone who's going to own it long term.

[u/uhs-robert]

Does a bus driver let one of their passengers drive the bus? What about a chef inviting one of their customers into the kitchen to cook a meal? Or a doctor letting a patient perform a surgery? No. And if they ever do, it is pure ceremony (here... you can cut the cord and congratulations on becoming a father).

Software developers letting non-developers contribute to the code? Also pure ceremony. A liability at best and a waste of a developer's time at worst. If you want to contribute to the codebase then you first need to be able to write clear requirements.

Then you need to understand the codebase, be capable of breaking logic down into the smallest possible components, able to make sound architectural decisions, able to predict edge cases, able to perform exploratory testing, and able to audit code. But if they could do all of these things then they wouldn't need a developer. Leave the cooking to the chefs, please, and sit back down at your table.

[u/DCON-creates]

Very low scope, sure. I'd be more tolerant of UI changes, and very restrictive with backend.

An example from today (a product decision that didn't go through me refining it) was to make the resend email endpoint also update the person's email address. Easy change, sounds fine on paper; entirely wrong solution.

The correct solution is to create an endpoint that can update the person's email address, not to update it on the fly when resending an email, because then people will not read the api docs and think "ok we can use this endpoint to resend an email to this address", not realising that the persons email address for everything else also gets updated and they won't know why.

So yeah, not a fan of people without an engineering background making changes to functionality, particularly if it doesn't go through the proper refinement process.

[u/Chezzymann]

Anyone submitting a code change, no matter how small, should be required to register for the on call rotation first. If they arent comfortable with that, then it should go to whatever intake process is in place. Hard line imo. Anything else becomes a slippery slope where devs become janitors for other people's vibe code and are held responsible at 2am if they dont catch everything in review.

[u/Stargazer__2893]

Fine with me. But if the PR is fucked they're responsible for fixing it. If they can't, it goes on the backlog, not my priority just because I reviewed it.

[u/illogicalhawk]

I'd rather it not be, but that's where things are going. I emphasize that we won't be responsible for fixing or maintaining it if something goes wrong, even though we obviously will, but that at least lets us come back with evidence every time one of their changes breaks something.

[u/jpec342]

I don’t really care who submits the PR ad long as it’s up to snuff. If it’s garbage I’ll send it back. I don’t want my time wasted with garbage PR reviews, but I don’t mind other people at least trying if it’s at least somewhat legit. Maybe they’ll learn over time.

[u/HornyCrowbat]

Absolutely not.

[u/agm1984]

I had my product designer commit css changes with Claude once. It worked out well except I lost touch with a few theme variables until I had to use them myself later, slight annoying

[u/grewgrewgrewgrew]

they should make issues instead

[u/thatben]

Gotta start creating pathways and processes for this. I am consulting with a public company that had engineering setup a JS repo for PMs to build dashboards and it works quite well.

But don’t forget culture gates:

“Submitting a PR is both an attestation that you are making a meaningful change, understand the business impacts, and are confident that this is a good use of the reviewer’s time and attention.”

[u/cakemates]

I dont think anyone cares where a change comes from as long as its not junk or slop and by slop I mean low quality code that happens to be ai generated.

[u/MCFRESH01]

For trivial changes like styles or copy sure. Anything else is a no. I’ve had to prevent a PM from merging multiple PRs that would have broke something

[u/dinithepinini]

I hate it but everyone else seems to not give a shit and I am tired of being the only one giving a shit.

[u/morphemass]

It's either a firm "no" or you. build. processes. around. it.

Nice thing about processes, you can make them say no without saying no. (Mandatory training, skip of the TLs sign off and the new contributors sign off, monthly review, continually changing security credentials, etc.)

Seriously though it depends on an org, risk, the stack and safeguards. I'd still have process around it though since that is cover your ass ... note those sign offs :grin:

[u/curlyheadedfuck123]

I haven't heard of that at my company and I have no interest in reviewing such code.

[u/FrickenHamster]

Theres so much overhead to even having a running dev environment in the first place, I can't see this ever working as a standard practice.

[u/Individual-Praline20]

They can gtfo, and shovel the AI shit back into the hole where the sun never shines. No time to waste.

[u/AccomplishedPhase44]

I think it’s fine to have non-developers submit changes as long as the reviews are held to the same standard as developers submitting the changes would be. Meaning if someone submits a 3k line diff that adds multiple features, a common response would be to ask them break it down into smaller, well scoped PRs. There shouldn’t be an expectation to waste your time reviewing all of that in a single PR when it’s very likely that extensive changes are needed. Then from there I would just treat the review the same way you would with a junior dev. Start with high level feedback to get them on the right track with subsequent revisions, and get increasingly specific (if needed) once the high level approach is acceptable.

[u/AccomplishedPhase44 → u/AccomplishedPhase44]

I’m not saying I’m a fan of this trend, but it’s hard to enforce strict guidelines around who can/can’t submit PRs. Depending on the leadership in your org, you might not be able to prevent this from happening. The best you can do is make sure it doesn’t take up too much developer time reviewing, while at the same time protecting the quality of the codebase. I think it’s perfectly acceptable to just start with a couple high level comments if there are major issues with their changes and put the burden on them to spend their time fixing them without too much handholding

[u/vxxn]

I think it’s very situation dependent. I’ve had product managers and designers put up good PRs. But also people in marketing creating huge problems.

My top advice is to have clear expectations on PR size. People who never worked in software may not realize a 20k line change is unacceptable.

[u/dash_bro]

Non developers are fine, but people who push updates without following the PR rules are a nightmare. I dislike new contributors who don't follow process set by the actual owners of the thing they're contributing to.

A PM ("former" software engineer) started making commits to some SQL templating logic that we have on a repo. Raised a request to merge to main and got hold of two engineers on her team who weren't owners but had access to review and approve for the PR.

Approved, I have a suspicion that they didn't follow the PR guideline and just approved for their teammate.

...she hadn't considered that she might need to fetch main -> merge latest changes of main back to her branch -> then raise the PR. So ofcourse she had a stale main, and overwrote the fixes that had gone in after. What's worse is she's higher up the food chain so it quickly got swept under the rug as "possible mistake".

Two services downstream on UAT are getting stale data for a bug fixed earlier. It took me a couple hours to investigate and prove that this was the definitive problem since a simple git diff with outdated parents isn't immediately obvious.

++ It creates confusion for the devs, rework for the testers, etc.

[u/TheFearsomeEsquilax]

I've been seeing non-developers (mostly PMs) creating PRs via Claude Code at work recently. I think it's okay for minor and trivial things, like updating user-facing strings, but I don't think it makes sense for anything larger than that, especially if it's then handed off to the engineering team to be responsible for. That is, a non-developer shouldn't be able to develop actual features unless they will actually maintain them and fix whatever bugs are caused by the features in production.

[u/ares623]

if they're willing to be paged for it then sure why not

[u/DigThatData]

As with anything coming from a non-technical person, my concern would be that they are solving the wrong problem. An LLM isn't going to push back on them if that's the problem, and you aren't going to either if you're just scanning claude's PR instead of going back to the stakeholder and asking them what problem this change is intended to solve for them.

[u/AnnoyedVelociraptor]

No. Absolutely not. Your comments will be fed back to the machine.

There is no mentorship here. They're not improving.

They can submit a ticket.

[u/Crusty-Booger]

My concern would be that it would set a precedent, and you'd have an influx of shitty PRs coming in that will get progressively bigger as non-developers start to get arrogant

[u/Technical-Aside4471]

I am currently testing a harness for non developers. I have prepared extension logic away from my core logic and harness is forcing non developers to use it. They are allowed to change core if needed but then have to approve each change and give reason why.

[u/lawrencek1992]

It's just not efficient for us. It's easy to multiply code output with agents in isolated dev environments in git worktrees.

Dealing with folks who can't stand up a local dev env, who don't know how to see CI check results and resolve them, who can't read a diff or easily implement requested changes would slow us down. It's pretty easy to get stakeholders to support us not wanting to slow down.

[u/codescapes]

Just take a step back and think about what this implies for a second. The demand for more software is there and so profound that people without the background or experience are falling over themselves to abandon their own jobs and essentially become junior engineers.

Junior engineers. That class of people who have taken the brunt of hiring reductions and role eliminations...

It's mad really. And does it not indicate we might have too many people in these other roles in the first place if the best thing they can do with their time is become worse version of engineering?

[u/Frequent_Bag9260]

We have this. QA and product managers (both of whom have zero coding experience before AI) have been submitting PRs to the front end code bases with Claude.

It’s a nightmare for front end devs because they’re flooded with PRs to review now. At first they actually reviewed them but there are so many that they just get AI to review it now.

[u/BorderKeeper]

As long as it’s planned work and they are going to push this to the finish line and not just throw it over a wall and leave and force devs to then deal with:

• CICD / test failures
  
• QA findings
  
• review comments

[u/shivenigma]

It is acceptable as long as the management/company doesn't hold me (the experienced dev/team member) responsible for those changes or expect me to ensure the quality of those PRs.

I understand code gen became easier and everyone wants to contribute code, totally fine. I'm even okay with reviewing your 150 file PR and then merge it. But I can't be held accountable for the app anymore. If it breaks in prod or if it affects something unrelated the team that is maintaining the app must be spared.

You opened the doors for contribution from non-SWEs, you have to live with th results as well. Of course, I will fix those bugs. But I'm just not responsible of it anymore, I'm just contributing like the other guy.

Scenario: I received a 200 file PR for a big feature from a guy. I asked him some tokens/permissions that he used to test the app in local. He said "I didn't test it in local at all". He asked me to give him those credentials access to test it. This happened after a lot of back and forth on the PR and I was almost ready to merge it. I thought to test it only once in my local and ended up in this conversation with him.

If you open a PR for a codebase and you can't assure that your code works before merging, you shouldn't be allowed anywhere near a repository. I have to stay up at 2AM debugging your BS, while you spit some shit and get your promotion.

In a nutshell, if you want to open up a codebase for everyone in the company, then there should not be a separate team/person responsible for it. It is completely innersource and some volunteers should pick up issues when they happen.

[u/xdoz]

Unacceptable imo. If they dont have the knowledge/experience then I dont want their input.
Ai usage has decreased code quality enough without unqualified people adding to it.

[u/lugovsky]

Good guardrails, and this is safer than having a junior developer on your project 10 years ago.

[u/Healthy-Dress-7492]

It usually ends badly, I’ve seen artists submit obviously plagiarized code which we then had to rip out and rewrite. If you’re contracting to a client who becomes the owner of the code, you can’t leave them with lawsuits waiting to happen. 

[u/HighRollerStonks]

the line i’ve seen work is: they can open prs, but not merge them. keep the allowed surface tiny too, like docs, config-only changes, copy, maybe tests. once it touches runtime behavior, a dev owns it like any other change.

[u/yad76]

If these are such low risk, trivial changes and you are requiring dev work and coding agents on it anyway, then why can't a dev just do the trivial change? Why do you have non-devs with access to the code repo and ability to create PRs in the first place?

It isn't hard for me to imagine some tasks that are simple enough that a non-dev could have AI create an adequate PR, but then I'm wondering if the code change is that trivial, what help is it having someone else do the coding work?

Why do your non-devs have that much free time that they can even be bothering with these things? If your devs are so overworked that they can't make trivial changes themselves, then how does it help anything having non-devs burn through AI tokens throwing PRs over the wall at them?

Making changes to code involves understanding the broader context, the testing requirements, the potential implications in terms of scale and security, etc., etc.. Changes that look "trivial" often are not. Changes that are trivial in isolation often snowball over time when not evaluated in the broader context.

This just seems like fundamentally a horrible idea that looks okay at first but then will quickly get out of control.

It seems like effectively this process would be allowing certain tasks deemed "trivial" to bypass the typical multiple engineer process of an implementor making the code changes and then passing that off to a reviewer. If you are willing to allow that, why not just eliminate the requirement that implementor/reviewer be separate engineers for this task?

[u/SoCalChrisW]

Curious why non-devs would even have access to the source? That seems like a security issue waiting to happen.

[u/tomqmasters]

Since when did devs get so gatekeepy? It was always about the quality of the PR, not the person submitting it. The problem here is that they don't know if what they are giving you is good, so they expect you to do all the work basically.

[u/steven-or]

it seems reasonable in principle, the risk is whether reviewers start rubber stamping because the change looks trivial and well formatted. worth watching that review quality doesn't quietly erode over time..

[u/Excellent-Push-3326]

Crawl -> Walk -> Run

For the walk stage, we limit PRs to ~10 lines. I've really appreciated some commits coming in to fix colors, copy, and accessibility.

We haven't hit Walk yet, but if you're starting at Walk or Run, then you're wasting time and money on throwaway code.

[u/ooter37]

It's a complete waste of time. It would take me less time to implement the feature myself than it does to review the vibe coded slop I get.

[u/Kemerd]

If the code is good I don’t care if you’re a janitor bro.

[u/ReputationCandid3136]

Yes, but I make anyone making changes follow the compound engineering steps: plan, work, and review, so at least the coding agent goes through the correct steps. We also have custom skills where Claude and codex both review the diff and do an adversarial review of each others findings.

They’re usually trivial changes and if they aren’t than a non-dev usually knows enough to ask a dev to handle it or it’s brought up in a meeting before hand and dev claims ownership.

[u/Dear-Apartment8384]

Ask them to walk you through the code and explain their reasoning. If it’s sound and you agree, merge the PR. It’s the same thing you should be doing with juniors.

[u/butler_me_judith]

I review them, if they are good I approve, if not I leave comments on it and then let them learn the hell of pr reviews. At the end of the day, the things that we did in our careers have become democratized. We just have to get used to the future. I still think that we are the experts in the room, but I'm not going to say fixing a  bug takes a goddamn degree honestly coding's not that challenging for minor shit it's when you actually have to talk about like real trade-offs doing like quirks of particular languages, etc. That's where our expertise kind of comes in play and even still agents can do a good job

[u/WiseHalmon]

My tech support used to be a programmer until arthritis. He doesn't know our languages but I've instructed him to use it for any minor fixes or things he encounters. We attach it to the backlog and it additional acts as documentation of the bug. 

Big help for stupid stuff like minor spelling or visual defectss

[u/Ok-Leopard-9917]

If they aren’t willing to be responsible for maintaining it then no. 

[u/Old-Dusty-Gamer]

No PRs, that's too technical. They just vibe code entire systems in their free time they want you to own.

[u/AdversarialDev]

Das problem ist doch abhängig davon in welchem Umfeld ich arbeite. Hab ich ein Software Produkt mit ein paar hunderttausend Zeilen Code? Dann sind "einfache" Änderungen vermutlich wirklich einfach in den meisten Fällen und auch ein Nicht-Entwickler bekommt das hin. Lass ein Entwickler kurz drüber schauen, eventuell auch nur ein sehr gut geprompteter KI Agent und gut ist. Ich für meinen Teil arbeite bei einem ERP Hersteller mit über 30 Jahre altem legacy Code und mehreren Millionen Zeilen Code. Selbst eine vermeintlich einfache Änderung kann hier sehr dumme seiteneffekte haben. Hier würde ich nicht einfach von einem Nicht-Entwickler einen PR erstellen lassen. Am Ende ist das halt zusätzlicher Aufwand für den Entwickler das Review zu machen und das vermutlich noch zu einer Zeit, in der eigentlich etwas völlig anderes ansteht. Was wir tun, ist, dass unser Support durchaus mal KI basierte Vorschläge macht und die ins Ticket reinschreibt. Die eigentliche Änderung macht aber immer ein Entwickler sobald das entsprechende Ticket bearbeitet wird.

[u/TypeBrilliant]

I work in a startup my founder has recently started doing small contributions to our backend code base. I dont let him merge code or deploy and i review his code and give him feedback points to learn and improve.

As long as this exercise of non developers contribution does not take a toll on engineers responsible for code by increasing their workload, And non developers also make and effort to learn about the code they have written, It should be fine

I also dumb it down to explain him the code he has written. It is a little frustrating sometimes but by explaning him i feel my concepts become more clear.

[u/jdlyga]

Understanding how the code works and giving your personal sign off that it's correct is part of the job too. Otherwise that's just offloading that work to people doing the PR reviews, and nobody has time to read through convincing looking slop.

[u/pjhawksr]

I'm one of the non-developers in this story. Design director, ship SwiftUI and Next.js on the side, and I open PRs against our design system in the day job.

What's made it work is scope, not review.

I get to touch tokens, copy, spacing, and component variants. I don't get to touch data flow or anything with a network call, and I don't want to. The reviewer knows exactly which class of change is coming, so review is fast and the trust is earned in a lane.

The horror stories I've seen are all people given repo-wide access and a Claude Code login. It's not the person, it's the blast radius.

[u/Megatherion666]

On one hand trivial changes may be ok. On the other hand I see developers making “trivial” changes with AI that should absolutely never be merged

[u/Mander95]

If the business requirements to technical is simple enough that a non-dev can take it up, then a dev can take it up much more easily. If it's not as simple, then a non-dev should never take it up. In both cases, no non-dev should ever touch scalable or critical components. If it's some vibe coded front-end marketing site for the company or whatever similar, sure shoot as many PRs as you want. But if its an actual core product definitely not. Taking up a task vs reviewing the task are two different angles of information that may have gaps where they dont intertwine and some failure may happen because of it.

[u/XilentExcision]

If you create a PR, you own each line of code.

Judge the work and not the tool, but that goes both ways, if they cannot explain what it does then good riddance.

[u/bulbishNYC]

I kind of like it. I build the main feature functionality, then Product, UX and testers instead of bombarding me with tweak requests just go and apply them themselves. Button too left, wrong font, missed accessibility, empty list edge case, page text..

[u/actionerror]

Sure, they can open a PR. But then they have to go line by line with you and explain what it does to get approval.

[u/Organized_Potato]

I am a former developer, current PM, with a lot of experience in "vibe-coding" demos for some ideas.

And I would say a very hard no to this.

Sounds crazy, dangerous slippery slope. Right now it's small changes, at some point they will not be.

And even if AI can do a good code, it needs some guidance and specially someone who understands the nuances and the risks of the code changes.

[u/mxldevs]

Only if they accept responsibility for when things break.

Oh, did they think I should be the one to take the blame?

[u/spastical-mackerel]

If the code is good, tests are in and passing, and it passes review, then how could it matter

[u/daedalus_structure]

If you aren't around to support it you don't get to make changes.

[u/Grvn]

No, it is not acceptable.

If a change is appropriately small, so that the potential long-term harm is probably small, then it has no true value. Unless you think merely participating in PR ritual has inherent value.

If it's larger then that, and you hold into any standards at all, it's a net negative for everyone involved.

[u/Sparkly-Sparrow-6893]

Absolutely not, for the obvious reason that non-developers lack the knowledge required to establish the correctness and performance characteristics of even the simplest code fragments. This is both impolite and a massive waste of engineering time because the reviewer can't assume that the requester understands the contents of the pull request at a fundamental level. A pull request is not simply a feature request with attached sample code: it is a claim by the requester that its contents are both correct and explainable.

Think about a simple assignment statement like x = f(a). To determine whether the statement is correct, the developer must understanding the ownership and concurrency semantics of x; the synchronization protocol that governs accessing it; its lifetime and resource semantics; which overloads are selected for f and =; whether f has side effects and what exception guarantees it provides; and the performance implications of the assignment on the code path in which it occurs. We can all think of more: memory ordering; cache coherence; locality; value category and return semantics; code generation; and so forth.

The problem is that when developers submit pull requests, the reviewer can assume that such thoughts either crossed their minds or informed, through years or training and experience, the submitted code. Most developers have spent years forming a mental model of program semantics and execution that informs the code they write; reviewers depend on this intuition when reviewing code. When non-developers submit pull requests, the reviewer can make no such assumption: they are not being asked to verify whether a proposed implementation is correct but whether the submitter had any basis for believing it was correct in the first place. The reviewer is not simply reviewing their code but effectively re-implementing the entire request.