When Everyone Can Code: Managing PRs from Non-Technical Teams

Someone outside of engineering opened a PR the other day. Not a typo fix in a README—actual code changes. They’d used Claude to make a small update they needed. The code worked. The tests passed. And I sat there staring at my screen thinking, “Well, this is new.”

Not long ago, this would’ve been a ticket in Jira that sat in the backlog for three sprints. Now it’s a PR ready for review before lunch.

This Is Happening Everywhere

I’ve been talking to other engineering leads, and it’s the same story. Non-engineers are making code changes. AI coding tools have basically given everyone a junior developer on demand.

And honestly? A lot of this is great. That change? It would’ve taken me 30 minutes to context-switch into, understand the requirement, implement, and deploy. They did it in 10 minutes because they already understood exactly what they needed.

But here’s the thing—they don’t know what they don’t know. The code worked, but there were side effects that weren’t obvious unless you knew the system. Things that looked fine in isolation but had implications elsewhere.

The Real Problem Isn’t the Code

The code quality from AI tools is usually fine. It passes linting, follows patterns, even adds tests sometimes. The problem is context. Non-technical folks don’t know:

• Which services are connected to what
• Where the security boundaries are
• What “working” actually means in production
• The subtle differences between “this runs” and “this is safe to deploy”

It’s easy to imagine PRs that technically work but would cause real problems down the line. Not because the code is bad—because the person writing it doesn’t have the full picture.

CODEOWNERS Is Your Safety Net

One thing that’s helped us manage this: GitHub’s CODEOWNERS file. If you haven’t used it, it’s dead simple. You create a file called CODEOWNERS in your repo root (or .github/ directory), and you specify who needs to approve changes to which files.

# Default owners for everything
* @engineering-team

# Sensitive areas need senior review
/src/services/critical-stuff/ @senior-engineers

# Infrastructure changes need ops approval
/infrastructure/ @platform-team

# Some areas can have shared ownership
/src/less-risky-area/ @other-team @engineering-team

The key setting is enabling “Require review from Code Owners” in your branch protection rules. Now it doesn’t matter who opens the PR—the right people have to approve it before it merges.

What This Looks Like in Practice

We went pretty granular with ours. Sensitive areas require senior engineers. But we also created shared ownership zones—certain parts of the codebase have joint ownership between a non-engineering lead and the engineering team. Someone from another team can still move fast, but an engineer always has eyes on the technical implications.

The other thing we did: folders with relaxed ownership for lower-risk changes. Typo fixes in documentation don’t need the same scrutiny as changes to core services. Let people contribute where the risk is low.

Things I Learned the Hard Way

Creating explicit “safe zones” for non-engineering contributions matters more than I thought. When people know where they can work without heavy review, they feel empowered instead of blocked.

One thing that’s helped: automatically creating PRs as drafts when they come through an AI agent like Devin. Gives engineers a heads-up that this needs extra attention before it’s ready to merge. Also sets the right expectation with whoever opened it—this isn’t going straight to production without review.

We’re going to have to add a bot that explains the rules when someone creates a PR. Just a simple comment explaining why engineering review is needed and who’ll review it. Should save us from answering the same questions constantly.

And honestly, talk to your team about what this means. It’s fair for engineers to have concerns about reviewing AI-generated code from non-engineers—it’s a new responsibility that wasn’t part of the job before. The way I see it, these folks are doing work that would’ve landed on engineering anyway. Reviewing a PR is usually faster than context-switching into building it yourself, but it’s worth discussing as a team what this shift means for everyone’s workload.

The Bigger Picture

We’re in this weird transition period where the line between who can and can’t contribute code is blurring. I think that’s mostly good—means engineers can focus on harder problems while others handle straightforward changes.

But it only works if you’ve got guardrails. CODEOWNERS is one piece. Good CI/CD that catches obvious issues is another. Clear communication about what needs review and why is probably the most important.

The goal isn’t blocking non-technical people from contributing. It’s making sure the right expertise is involved for the right changes. Someone from another team absolutely should be able to make straightforward updates. They just shouldn’t deploy those changes without someone checking for unintended consequences.

We’re still figuring this out, but people are moving fast and the safety net’s catching what it needs to catch. Which is all you can really ask for.