Surprise! Everyone at Your Company Suddenly Became a Developer (Kind Of)

# Strategy

# Team Structure

# Culture

# AI

# AI tools

AI didn't just change your engineering team. It erased the line between "I have an idea" and "I have working code."

June 2, 2026

Jason Meltzer

Something shifted in the last year or so and I'm still figuring out what to do about it. People at my company, at every company, who are not engineers are writing code. And it's not bad code. It's not a joke. It's working software that solves real problems, and it's showing up as real code that engineering teams have to review.

I'm not talking about a CEO who insists on micromanaging technical decisions. I'm talking about people who genuinely want to build things, and now they can. AI tools got good enough that the barrier between "I have an idea" and "I have working code" basically disappeared. And I don't think most engineering leaders have caught up to what that means for how we run our teams.

This isn't new, but the scale is

Technical founders building things on the side has been a pattern forever. Klarna's CEO talked about this in Fortune last year. He'd never been a programmer, but AI tools let him start prototyping his own ideas. His take was generous: "Rather than disturbing my poor engineers and product people with what is half good ideas and half bad ideas, now I test it myself." He admitted he'd gotten a bit obsessed with it. Coding every night after his kids went to bed.

That works because he's filtering ideas before they hit the engineering team. But the pattern is broader than CEOs now, and it's accelerating.

Who's building things now

The founder or CEO is the most visible version. They know a feature matters. They don't want to wait for the prioritization process. So they build it. If you ask why they didn't just move it to the top of the backlog, the honest answer is usually impatience, not urgency. They're already thinking about the next thing before the team has finished the last thing.

But there's a more generous read. Building something yourself is faster than explaining what you want, waiting for it to get prioritized, waiting for it to get built, and then discovering it wasn't quite what you meant. For a CEO who used to be an engineer, AI just gave them their hands back. They're not trying to undermine the process. They're moving at the speed they think in.

Then there's the product person who prototypes. This one is newer. Product managers used to hand off wireframes and user stories. Now some of them are handing off working code. "Here's a prototype, just finish it." The gap between a prototype and production software is enormous, but it's invisible to someone who just watched AI build the thing in twenty minutes. The fact that it works on a laptop doesn't mean it works at scale, handles edge cases, or fits the architecture. Good luck explaining why it needs two more weeks of work after they saw it running.

And then there's the person who was never technical at all. Ops, customer success, sales. They had a pain point, they described it to an AI tool, and it built them something. It works. It solves their problem. Now they want engineering to put it in production. "Hey, I built this thing! Can you ship it?" I'm having that conversation more and more.

Underneath all of these is the same thing. Some of these people used to be engineers and they miss building. Some never were engineers and they're discovering they can build for the first time. Either way, they're not doing this to cause problems. They're doing it because they care about the product and now they can do something about it directly.

Why this is actually good

I want to be clear about something. I think this is a net positive.

For most of the history of software companies, the only people who could build things were engineers. Everyone else had ideas, but ideas had to go through a pipeline: describe it, justify it, wait for it, hope it comes out right. That pipeline exists for good reasons. But it also means a lot of good ideas die in the queue, or come out months later looking nothing like what the person imagined.

When your CEO or your ops lead or your product manager can build a working version of their idea, that's signal you didn't have before. It's a faster feedback loop than any product process ever designed. You get to see what people actually want to build when there's no friction stopping them.

That energy is worth protecting.

Managing it

But someone has to manage what happens next. And that someone is the VP of Engineering.

When code shows up from outside engineering, it still needs code review. It still needs QA. I have to decide if it fits the architecture or if we're building a second system for the same problem. I own maintenance after the person who built it moves on to their next idea.

The prioritization question gets real. When a feature gets built over the weekend and a PR shows up on Monday, what happens to the sprint? Right now, at a lot of companies, the honest answer is: the team drops what they're doing and takes it on, if the person who built the feature is important enough in the org chart. That works when it happens once. It doesn't work when it becomes a pattern.

There's also the quality question. AI-generated code can be solid. It can also be a mess that looks good on the surface. The person who built it might not know the difference, because they're evaluating it by whether it works, not by whether it's maintainable. My team's the one who has to live with it after the demo is over.

None of this is a reason to shut it down. But you need rules for it.

What I'm actually doing

I'll be honest: I don't have this fully solved. This is new enough that I think most engineering leaders are still improvising. But here's where my head is at.

The instinct to gatekeep is wrong. If your first reaction is "non-engineers shouldn't be writing code," you've already lost. They're going to keep doing it whether you like it or not. The tools are only getting better. Your job isn't to stop it. Your job is to build a process that channels it.

That means answering some questions most engineering orgs haven't had to answer before. What's the path for code that originates outside engineering? Does it go through the same review process? Who owns it once it's merged? If it breaks in production at 2am, whose phone rings? (Spoiler: it's still going to be yours, not the vibe-coding marketing director.) If it conflicts with something already on the roadmap, who decides which version wins?

It also means being honest with the people building things about what happens between "it works on my machine" and "it's in production." That gap is real, and naming it isn't disrespectful. A prototype that took twenty minutes to build might take two weeks to productionize. That's not engineering being slow. That's engineering doing the part that AI skipped.

And the hardest version of all of this is when the code is coming from above you. I can tell an ops lead that their weekend build needs two more weeks of engineering work before it ships. I can't tell a CEO that as easily. The dynamic changes when the person who built the feature is also the person who decides your budget, your headcount, and whether you're doing a good job. I don't think there's a clean answer for that one. But pretending the power dynamic doesn't exist is worse than naming it.

Protecting the roadmap without killing the energy is where it gets tricky. If every outside PR jumps the queue, you don't have a roadmap anymore. If you push back on every one, people stop building and you lose the signal. I'm somewhere in between. Some PRs skip the line. Some wait. It depends on who built it and what it does.

The job just changed

The VP of Engineering role used to be about leading engineers. You hired them, organized them, pointed them at the right problems, kept the system healthy.

That's expanding. You're still doing all of that. But now you're doing it while code is coming in from outside your team, from people who don't know the architecture, don't know the codebase, and don't know what they don't know. You're the one who has to build the process for absorbing outside contributions without letting the system degrade. You're the one who has to stay open to the signal while protecting the roadmap.

I don't think this is temporary. AI tools are going to keep getting better. The number of people at any company who can produce working code is going to keep growing. The question isn't whether this happens at your company. It's whether you build a system for it or just react to each PR as it comes in.

I'm still building the system. But I think naming the dynamic is the first step.

Jason Meltzer is VP of Engineering at LeadSimple. He has spent over 15 years leading engineering teams from startups to enterprise, including GoDaddy, American Express, and Choice Hotels. He writes about engineering leadership at itsnotthecode.substack.com.

Comments (0)

Popular