Plenty of developers have had to deal with vibecoders lately. Product people or business stakeholders who keep yelling that you should just vibecode it real quick, or, worse, who dump their slop on you and ask if you can "just push it live real quick."
Now you expect me to launch into a whole rant about why this is a bad development. Sorry to disappoint. I say: let's embrace these people instead.
Vibecoded-spaghetti-slop-code
At a lot of companies, programmers are seen as wizards. Nobody knows exactly what they do. But they hold all the power, because they're the ones who ultimately decide how the end product works. Back in my early years I'd regularly just make the UX worse because I didn't really know how to do it cleanly in code. I had the power to decide what got shipped. "Nope, sorry. That's not possible like that, so I did it this way."
That power is slowly crumbling now. Because business folks are vibecoding, they actually know now that stuff is possible that developers always used to push back on. When Henk from marketing shows up with a working feature, you can't really tell him it can't be done.
As a UX engineer, I love this. But developers do have the right to push back. They're the ones ultimately on the hook, and if you just let vibecoded-spaghetti-slop-code through, you'll have problems in no time. And who are they going to text at night when the site goes down because of Henk's new slop feature? Right, you're the one who's screwed.
But as far as I'm concerned, it's time to flip the roles. Because Henk knows much better what needs to get built. It's time developers started listening to him.
Promotion
Every developer has been promoted by AI to a senior who constantly gets code handed to them by juniors (aka the agents). As far as I'm concerned, the job of a developer in 2026 is: how do you make sure you can roll this out well and safely?
First off, I think your company needs a bit of a mindset shift. If we allow Henk's features to roll out to production, you're going to give up some stability no matter what (for now). It's a trade-off: you agree to a faster verification loop for features, and with that, the fact that things will occasionally have bugs or break.
This is also the strategy the AI labs use themselves. I use Codex and Claude Code every day. Everything about them tells you these companies are vibecoding hard. Their workflows are entirely focused on one thing: shipping and validating new features fast. To head off problems, they've made the turnaround time for rolling out new updates as short as possible. Something breaks regularly, but because they're constantly pushing updates, things get fixed again super fast. This is why you get an update button popping up almost daily in Claude or Codex. Sometimes even several times a day.
The Claude Code codebase leaked once, and a lot of senior developers said the code wasn't very good. But hey, parent company Anthropic was valued at nearly a trillion dollars last week. You have to wonder whether it even matters that your codebase isn't all that tidy.
I'm a big fan of this strategy. Release a workable version as fast as possible and let your audience test it, then push improvements super fast, or even rip the whole feature back out and move on to the next feature you want to validate.
I once read on X about a company that came up with something during a product meeting in the morning, rolled it out before lunch, and had validated and pulled it again by the end of the afternoon. This is possible now.
So does Henk get free rein?
No. What you want is to create an environment where Henk can vibecode safely. You want to set up guardrails that make sure certain things just can't ever go wrong.
I mostly do this by setting up the most important components myself, and structuring them so that during a code review I can very easily see whether things are implemented correctly. You want to set it up so that agents basically can't make mistakes. Then I have a handful of homemade "Skills" that check the AI agents against this and force them to work within this pattern. At the end, a code review agent runs over it, validating the feature and going through everything one more time.
So before a pull request reaches a human at our place, multiple AI prompts have already run over it, minimizing the slop and pulling out the common mistakes. That way, reviewing becomes more a matter of: is this safe to ship, are the security and quality basics in order, and are we making choices here that we can easily iterate on later, or roll back quickly?
This isn't flawless. Some things coding agents keep getting wrong. They're just not deterministic. In the beginning you'll often feel like you're playing whack-a-mole.
Accept it. Because you've got the wind at your back. Every month a better model comes out. Sure, token prices will go up at some point, but for now there's still plenty of VC money subsidizing it for you. Learn to work with the models. That way you'll quickly figure out where the flaws are, and where to look when you're reviewing.
Because one thing is certain: these models aren't going to get worse anymore. Even if only half of what all these AI labs promise us is true, this is still a radical change in how software developers work.
Programmers are losing their power, and that's good news for end users.