👋 Hey, it’s Stephane. I help engineers become great engineering managers - whether you want to become one or are already leading a team.
Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.
Nowadays, asking engineers questions about how things work can be perceived as being lazy. Anyone can point their claude to the collection of codebases the team owns and ask their question.
What happens though when non-technical people decide that some answers they get back shouldn’t be like that?
They can either ask an engineer to make changes to this part, or… ask claude to make these changes and then get an engineer to review them. The latter feels much more efficient.
I was talking to a friend of mine recently who’s PM had recently gone on this journey, of trying to work on their codebase. They started with small changes, got engineers to review them, they got merged & deployed, and landed to customers’ hands. One day, at a strategy meeting, the CEO had a crazy idea which excited the Product Manager so much so that he spent his weekend trying to vibe code it.
He generated tens of thousands of lines of code and got something that seemingly worked! That was enough to convince him that his team would be able to get it in a good place and ship it quite quickly, so he went back to the CEO and demo’ed his POC.
Everyone very excited agreed to get the team to “productionise” it and then ship it to customers. After all, the hard part of proving it could work was done already.
When the PM brought it to the engineering team, the Tech Lead took agreed to look into the code to see what was done to implement that feature. He thought that it would take a few hours to untangle what claude had done.
Pretty quickly he saw that he’d reimplemented several of their core functions, some of them subtly wrong (breaking other parts of the system), and connected the whole thing to the demo he was showing people.
After a couple of days he basically said: “we can’t implement this, and here’s why…”
That was not an emotional response. It was going to take far more time trying to “productionise” this thing, compared to taking a step back, thinking from first principles and architecting a design that could actually work.
The PM was not happy. So he escalated this to the VP of Engineering.
The VP was far removed from the day-to-day (and is not a particularly good one) so he just asked the team to find a way to get it done, since now this has started being promised to customers.
The bad code is probably the least interesting part
I bet this is not the first time you hear a story like that. And the natural follow up conversation becomes about how crap is AI-generated code.
I’m not sure that’s the interesting conversation to have here. We already know it gets things wrong.
When a model has a choice between a secure and insecure implementation, it chooses the insecure one about 45% of the time. Models are getting much better at producing code that looks right. Not necessarily code that is right.
Even if the code that PM produced with claude was right, you’d still have a team being handed a massive system they’d never seen before and having to maintain it from now on.
It’s not about how you contain your PM
Reading this story, you probably are feeling a certain type of way against that PM.
Why did he do that? Why didn’t he consult with the team first? How could he possibly think that it’s that easy to build such a complex piece? etc etc etc.
The reality is, that it’s easy to get carried away after you see you can build things.
Simon Willison, has described the meaning of vibe coding very sensibly.
Vibe coding means generating code without reviewing it.
If you’re reading the output, understanding it and testing it, you’re basically doing software development with AI.
Collins made vibe coding its word of the year for 2025.
Lenny’s Newsletter has articles about getting paid to vibe code as a full-time job, including people without traditional coding backgrounds building customer-facing products.
Your CEO has heard about vibe coding. Your PM has Claude or Cursor or whatever. And they can now build something that looks surprisingly close to working software. That was not the case a couple of years ago.
Retool surveyed 307 CTOs, CIOs and CISOs and found 93% were at least somewhat worried about vibe-coded tools running in production. Only 4% had governance covering AI-generated code regardless of who wrote it. Now, they sell governance tooling, so obviously take that into account.
19% had already confirmed a production incident caused by an AI-built internal tool in the previous year. One person they surveyed said:
“When anyone can ship a tool in an afternoon, nobody signs up to maintain it.”
And I think that’s the bit we need to pay attention to.
What you’re actually getting
When you have an enthusiastic PM (or any non-technical person) vibe coding ideas and asking you to make them ready to ship, I think it’s important to name what you’re actually being asked to do.
You’re not fixing some bad code.
You’re adopting a system where no context has been built on it and nobody will be able to fully own it.
“Vibe slop is the symptom. Context debt is the disease.” ~Matt Burns in The New Stack
Normally, even when you’re handed a terrible legacy service, somebody understood it at some point. There was an engineer who made the decisions.
With vibe-coded software, that person never existed. The person generating it wasn’t even a person 🤖. AI obviously doesn’t understand your system in the way an engineer does.
So when someone says:
“Can the team spend a sprint cleaning this up?”
...that’s not really what needs doing.
You’d need to understand tens of thousands of lines of code and work backwards to figure out what it was supposed to do. And maybe some of that intent was never properly decided in the first place.
Will Larson has said this which I think about quite a lot when someone asks someone else to “finish off” some existing work: partial work has no value. The expensive part is often finishing the thing. Getting 80% there, especially now with AI is the easy part.
Four things to do
A similar thing has happened to one of my teams and there are four things I did which I would recommend considering if you’re wondering how to tackle it. Just “push back” is obviously not one of them.
👇👇👇 (access with a paid subscription)