Managing Vibe Coders

Peter Mawhorter (pmawhort@wellesley.edu)

October 18th, 2026

What Vibe-Coding Looks Like to Your Manager

This post is one of my advice & arguments pages about the harms and hazards of the AI Hype Movement.

I saw a post on social media a while ago about someone who was annoyed with a coworker. Since a company-wide mandate/encouragement to use AI, they’d been really phoning it in, just relying on the AI to write all their code, asking their co-workers to review very low-quality pull-requests (proposed changes to the code), and using the AI to do their review work as well. As annoying this behavior was to their co-workers, it was probably something like the positive dream of AI that the hype movement promises workers: get your work done “more efficiently” using AI, and use the extra time to kick back and relax! Of course, clogging up everyone’s time with low-quality work was also unproductive to the company, but if the company was measuring productivity-per-worker by amount of code produced, amount of pull requests made/reviewed, and/or how heavily each worker was leaning into AI use, this employee would look better than their peers.

Now note that this person was undoubtedly introducing bugs into the product software, some of which would slip by their colleagues in review (especially if colleagues were also acting the same way). They also weren’t learning or internalizing anything about the code they were producing: if asked to explain their own code, they’d likely stumble over a basic explanation and be unable to explain details or design choices, since they had outsourced that thinking to the AI. They might be able to ask an AI to explain the code and come up with something that sounded cogent, but they wouldn’t be able to do it on their own. If asked to fix a bug that their code had introduced, they’d again have to rely on AI, since having outsourced all understanding to the AI, they wouldn’t have the deep understanding of systems and interactions necessary to even understand subtler bugs, let alone fix them.

Putting aside the issue of poor productivity signals, I asked myself: what would I do if I were this person’s manager and fully understood the situation? I think that the first time I asked them to fix a bug that their code had introduced and found out that instead of learning the architecture and tech they’d left that job to the AI and they actually had not developed any of the understanding of the codebase needed to fix bugs beyond what AI could do on its own, I’d fire them on the spot. Then I’d either:

  1. Hire some teen for a very low salary if I really just wanted someone who would point AI at bug reports and say “go” without any understanding.

or

  1. Hire someone else with actual programming skills and turn off the AI so I end up with an employee that actually knows the system they’re working on.

As it turns out “look I can do my job without relying on any of the technical skills I’ve spent years learning” is a very dangerous flex under capitalism.

If we really think this person’s skill is needed to guide the AI to success here, the third option is:

  1. Oh you can do two week’s worth of work in 8 hours? Cool I’m increasing your workload by a factor of 5. Have fun.

The observation here is that AI coding “assistants” structurally cannot be a win for developers when they’re a commercial product available to everyone. In the end, any “efficiency gains” due to AI will be felt only by the owners of the company (if they’re actually real); they won’t actually make employee’s lives any better (and in fact will most likely make them much worse).

Here’s an article about a companion of this phenomenon, where even without explicit management instruction workers try to do more and more given AI “assistance”. The result: burnout.

One might reasonably ask: why would management mandate AI use if they also saw that use as a weakness? There are two answers:

  1. Management is also enamored of AI and doesn’t see use as weakness. The hypothetical employee in this example gets promoted instead of fired, and its their co-workers who are actually diligent that quit. Software quality dribbles through the floorboards until the company fails.
  2. There’s no contradiction here: management is really just asking each employee to provide a roadmap for how to replace themselves, and they’re going to end up firing the ones who lean in the hardest (clearly their jobs will be easy to automate) and probably also the ones who resist the hardest (they’re too resistant to company mandates and won’t be cooperative enough to be good employees, even though they’ve recognized and avoided the trap). The later group may also just quit, which saves paying severance.