When non-devs open PRs

Thanks to Linear for sponsoring manager.dev and for sharing the data behind this article. I'm also in the process of migrating my own team from Jira to Linear (it’s already the best call I've made this year).

Last week I read this post on r/ExperiencedDevs: “Non-Developers Submitting Changes - Acceptable?”

The most popular comment was (not surprisingly) to not allow it:

That’s one approach… But assuming you can’t really stop it (if you haven't encountered it yet, it's just a question of time), what CAN you do?

I’ve been dealing with it since April, and it’s a difficult one to solve.

So far, I haven't found anyone with a system that works at scale - it can quickly become a real mess. Who reviews that code? Who's responsible when it breaks? Where do you put the boundary of what’s allowed and what’s not?

Hopefully in a couple of months I’ll follow up with a better ‘playbook’, but today’s article is about sharing some frustrating experiences and failed tries. Very curious to hear if anyone has better answers.

It’s happening everywhere

So first of all, some data to back up my claims, from Linear’s 2026 AI usage patterns in software teams report.

From June 2024 to June 2025, the numbers barely moved. 1-3% of PMs and designers attached a PR to a Linear issue assigned to them. In June 2026, the number is up to 8-10%(!).

And that of course is just the floor, as many PRs are opened without being attached to issues.

An even bigger challenge comes with executives being more involved: the % of CPOs and CEOs who used an AI feature in Linear (including both writing code and read-only agent sessions) rose over 6 months from <10% to 30%+, even at large companies.

With PMs and designers, you could just not allow it, but when your CPO gets involved in the day-to-day, it’s very hard to resist. They have their ‘magical moment’, and suddenly there is a demand to allow non-engineers to contribute to the codebase directly.

The benefits

Let’s start with the positive, shall we? Even with the (many, many) challenges it creates, I can’t deny there are some benefits:

1. It reduces communication cycles

In the old world, very often the PM would write one thing in the PRD, but after experiencing the feature in production, change their mind and request a different behavior. Sometimes you need to see the full system at work.

Well, now instead of receiving a Notion doc, or even a prototype, you can open the preview link of the PR your PM opened and see exactly what they want accomplished.

I don’t agree with the thesis that ‘there’s zero upside in short-cutting the ticket and beaming PRs straight to the dev team’:

In some cases (not all), it’s very convenient and can save everyone time.

2. It lets engineers focus on the bigger problems

Keeping up a high level of design for your products can be endless. You get a Figma, implement it, and then you get ‘just one small tweak here’, or ‘let’s move the copy there’.

Giving our designers the ability to take care of the smaller things themselves is very freeing (assuming they know where to put the boundary, we’ll get to it). No need for you to deal with annoying CSS tweaks or button color changes.

3. It gives non-engineers autonomy

Up until this year, almost every function in the org depended on us. PMs, designers, support, customer success - in many cases, they worked ‘through’ the engineers. If we didn’t prioritize what they asked for, they were stuck. We on the other hand could always ‘solo’ - no design or no PRD? We can just do our best.

3 weeks ago, we wanted to test a new go-to-market angle for a product my team is building. We wanted it connected to our real onboarding and existing design, and not start from scratch on Lovable.

A user researcher, with no coding experience, was able to iterate on it almost completely solo. Got the landing page running, oversaw the paid marketing campaigns, made tweaks to the copy/design, and led the decision to kill it. I helped a bit in connecting it to our sign-in functionality, and did sanity reviews on the PRs, but that’s it.

Why it’s so hard to implement right

So why is almost every engineer (and EM) on earth having a heart attack when thinking about it?

It’s like having 2-3 VERY opinionated junior engineers join your team at the same time. And not only did they not study software engineering even for a day, but they also don’t plan to pursue that career. It’ll get messy very fast.

5 questions that I haven’t been able to solve so far:

1. How will all those PRs get reviewed?

My V0.1 of this was ‘whoever wants to’. A designer would drop the PR in a Slack channel, hoping someone would pick it up. Mostly, they didn’t, and the PRs stayed open and forgotten.

The next logical try is to have the hotfixer engineer responsible for those. It’s possible, but I don’t believe such an approach works over time. They already have enough on their plates, and those PRs will always be the lowest priority, and a slow review means a higher chance of conflicts.

My current bet is on pairing each non-dev with a dev who’ll be responsible for it. I’m paired with our PM, and another engineer with the designer.

2. Who’s going to teach the 'new juniors’?

A recipe for disaster: “Here’s our GitHub repo URL, give it to Claude and start working, good luck!”

I’ve done something like that. The result was a 10k-line PR from our designer that was a complete mess. It involved copy tweaks he wanted to do, and some CSS changes, but also a big new feature that required backend work (which Claude solved by mocking everything, and of course the designer didn’t understand that was problematic).

Many of those ‘new engineers’ don’t even understand what a PR is. Until now, we solved it ad hoc, with engineers slowly explaining the new concepts and how to work better.

Tomorrow I’m holding the first organized session, teaching a content designer and a UX researcher the very basics. Here’s what I plan to cover:

• Shipping one trivial PR end to end - branch, change, PR, I approve, they merge, watch it deploy.

• Go over what just happened and what each part meant.

• How to check the change is the right one - understanding file diffs, and how to figure out you got what you asked for and nothing else. Testing in preview before requesting a review.

• How to keep PRs small, some good and bad examples.

• What happens after merge - testing it in production. How a revert works.

I have no idea if that's the right syllabus, but my answer to that question is that I see it as my job (at least for now).

3. Where do you put the boundary?

How do we enforce the boundary between a UI change, frontend logic, and something that needs a backend change?

I believe we should start very simple, and let non-engineers open PRs only in the following areas:

• Copy changes

• Pure UI changes that don’t change any logic

• Prompt changes (where they are responsible for running evals)

Currently, the enforcement of the PRs’ scope happens manually.

2 amazing PMs in my company went deep into engineering work. They actually read the PR comments, improved over time, and generated not-so-bad code, both frontend and backend.

But in the end, they both understood it’s just not the best use of their time. The PRs had lots of comments, and it just didn’t make sense for them to waste their time learning proper software engineering when there was also lots of PM work to do.

4. Who’s on call for it?

When something a non-engineer wrote breaks at 2am, does the reviewing engineer own it, does the team own it, or does the author?

I haven’t solved this one yet. The current answer is the team in general. We’ve had one such incident so far, where a PR touched something it wasn’t supposed to, and I missed it during review. I saw it in the monitoring and fixed it myself.

I believe that if we stick to the right boundary, such cases should be minimal, but will still happen.

5. How is it prioritized against other work?

Everything above takes A LOT of time:

• Mentoring the non-devs

• Creating dedicated skills for them

• Reviewing the PRs

And in the end, the credit goes to the non-dev, who is praised for being ‘AI-native’. I’ve seen it happen - and the engineer who spent time supporting it all never got mentioned. If you are not careful, it’ll start a slippery slope, which your engineers will suffer from.

It's our job to make the cost of this clear.

Final words

In my team, it’s still quite low volume. The designer was the first one who started opening PRs back in April, and the PM joined just a couple of weeks ago. So far, it’s manageable, but I expect it’ll only get harder.

The org's expectations from non-devs also rise, and they are very encouraged to push the boundaries. I believe it’s my role as an Engineering Manager to not avoid this situation, but to figure out the right solution.

I'd really love to get a reply from other EMs who've tried different things. What worked for you?

What I enjoyed reading this week

1. The Big Management Lie: Overpromising. That one is so hard for me to avoid. It’s very tempting to break good news early (even if it is not final), to get that initial 3-point bump (see the article) and the satisfaction from it.

2. Titles Are More Expensive Than They Seem. On title inflation and the harm it causes.

3. The Year of Side Projects.