AI Made Everyone a Coder. Why That's a Problem

With tools like Claude Code, Cursor, and Copilot, generating working code has never been easier. Hand the assistant a Jira ticket or a requirements doc, give it some context about the codebase, and it will produce code that runs. That’s genuinely powerful.

Everyone Can Ship Code Now. Should Everyone?

I’ve increasingly seen people who aren’t part of a feature team (product managers, designers, people in leadership roles, stakeholders from adjacent teams) contribute code directly to a codebase they don’t normally work in. Because AI makes it fast and low-effort to produce something that works, the barrier that used to keep non-developers out has mostly disappeared.

In one sense, this is great. You’re no longer bottlenecked on a developer’s time to ship a small feature or fix. But there are real problems hiding underneath “it works.”

Problem 1: Code needs an owner, and drive-by contributors can’t be one

When you write code, you become its primary owner. Not exclusively, since the team shares responsibility too, but you’re the person best placed to fix it fast when something breaks. You understand why it was written the way it was.

When someone outside the team contributes a feature, the code might be structurally fine. It runs, it passes review, it ships. But that person typically doesn’t have the broader context of the application, and they’re usually not going to be the one on call when it breaks two months later. They have other responsibilities pulling them away.

So who ends up debugging it? The team that actually owns the application: the people who never wrote it, don’t have the original context, and now inherit the maintenance burden anyway. The more this happens, the harder it becomes for the owning team to keep a coherent mental model of their own codebase.

Example: Imagine a stakeholder outside the dev team ships a moderately complex feature using an AI assistant. It works in testing, gets merged, and the stakeholder moves on to their next priority. Three months later, a bug surfaces in that feature. The engineering team now has to reverse-engineer the intent behind unfamiliar code, with no one available who actually understands why certain decisions were made.

Problem 2: The person who wrote it may not understand it either

This compounds the first problem. If someone isn’t actively working in the codebase day to day, there’s a good chance they didn’t read the AI-generated code line by line either; they just checked that it worked. So when it does eventually break, not only is the owning team unfamiliar with it, but the original author may also lack the intuition to fix it without leaning on AI again, essentially guessing.

Problem 3: It distorts team velocity and expectations

When outside contributors add story points to a sprint for a few weeks, team velocity looks artificially high. Then, when that person moves on to other priorities and stops contributing, velocity appears to crash.

From a metrics standpoint, this makes the team’s performance look inconsistent or unpredictable, when in reality, the core team’s actual throughput never changed at all. Worse, it creates artificial management pressure on the core team to sustain a development pace they never actually set themselves.

Where I land on this

I’m not trying to gatekeep the codebase. People outside the immediate team contributing code isn’t inherently bad, but there’s a meaningful difference between:

• Small, well-scoped fixes: A straightforward bug fix that doesn’t require deep context, and
• Full features or large PRs: Code changes that touch significant parts of the system.

The former is a reasonable way to unblock things. The latter tends to create the ownership and maintenance problems above.

The issue isn’t the AI tool. It’s that lowering the barrier to writing code didn’t lower the barrier to owning it. Those two things have always been separate, and AI hasn’t changed that.

---

There’s a related problem that compounds all of the above: even when the right person is writing the code, AI makes it dangerously easy to skip the review step. I wrote about that separately: AI Didn’t Kill Code Review. We Did.