Your Vibe Coders Are Not Building Tools

July 23, 2026 SupportTrenches Systems, Processes & Resilience 5 minutes

They Are Filing Bug Reports Against Your Company

A while back I met an old colleague for cocktails. We do this every so often - two people who have seen enough server rooms and steering committees to know that the best incident reviews happen over a Negroni.

He was in a great mood. His company's vibe coding (quickly developing software using AI like Claude without writing (or sometimes even understanding) the code itself) adoption was through the roof. And not just among developers - consultants, architects, support engineers, basically anyone with a pulse and a Claude license was building tools. Management was celebrating. They threw around numbers like trophies: one engineer burned through 100 dollars a day in tokens. Applause. High fives. Slide decks.

And honestly? Fair enough. If a 100-dollar-a-day token bill produces a tool that saves ten hours of engineering time per week, that's the cheapest employee you ever hired. I am not here to rain on token budgets. Fun fact on the side: "vibe coding" went from a casual Karpathy tweet to Collins Dictionary Word of the Year within roughly twelve months. That's faster adoption than most companies manage for a new expense tool.

But while my colleague was celebrating, I was doing what 20+ years in support trenches trains you to do: listening for the alarm underneath the applause.

Because here is what nobody in that celebration meeting asked: "why are your support engineers building internal tools in the first place?"

Let's peel this onion. It has three layers, and each one is worse than the last.

Layer one is the obvious stuff everyone already knows and politely ignores: security, code quality, no reviews, no tests. Non-developers generally don't know what they don't know. Annoying, but survivable. Not my point today.

Layer two is shadow IT with a fresh coat of paint. Every one of those vibe-coded tools is a small, undocumented, unmaintained system. Some of them will quietly become load-bearing. They will run on some forgotten VM, touching real data, long after their creator has left the company. Then one day the tool breaks, the process it silently powered breaks with it, and nobody even knows the tool existed until the postmortem. I have personally watched a "temporary" script outlive three reorgs and two of the managers who never knew it ran. Shadow IT doesn't announce itself. It just accumulates, like plaque.

But layer three is the one that should keep leadership up at night, and it's the one my colleague's management completely missed while popping the champagne:

Every internally vibe-coded tool is an unfiled bug report against your organization.

Think about what actually happened. An employee needed a tool to do their job efficiently. Your company did not provide it. So they stopped doing the work you pay them for, taught themselves just enough to be dangerous, and built it themselves. In a five-person startup, that's Tuesday, and it's beautiful. In a company that sells stock to shareholders and has an IT department, an innovation budget, and a tooling roadmap, that's a confession. It means your internal tooling function failed quietly enough that nobody escalated and loudly enough that your people took matters into their own hands.

And here comes the part that gets filtered out before it ever reaches the SLT: guess who builds these workarounds? Not your coasters. Your power horses 🐎. The exact people who care enough to fix broken workflows are the ones burning their energy compensating for your tooling gaps. They are also the first ones who get demotivated when they realize they are patching the ship instead of sailing it. Nothing burns out a top performer faster than being structurally unable to do good work through official channels.

And there's a wall at the end of this road anyway. Vibe coding only reaches what the employee has access to. The really expensive inefficiencies - the CRM that needs three integrations, the deployment pipeline, the systems behind proper permissions - cannot be duct-taped from a support engineer's laptop. So your most motivated people fix everything within reach, hit the wall, and then sit there staring at the actual problem with no way to touch it. That's not a productivity story. That's a resignation letter with a six-month delay.

So what should you actually do? Not banning vibe coding - that would be punishing the messenger, and frankly the message is a gift. Do this instead:

👉 Inventory what your people have built. Every internal tool that touches real data or real processes. Yes, the list will be embarrassing. Better you find it than the auditor, or worse, the outage.

👉 Read the map. Sort the tools into two piles. Pile one: horizontal convenience - personal scripts, small helpers, quality-of-life stuff. Great, encourage it. Pile two: tools that patch gaps your IT or innovation team should own. That pile is not a tool list. It's your real internal roadmap, written by the people who live in the pain daily, with fidelity no requirements workshop will ever achieve.

👉 Treat prototypes as specifications, not as production systems. A vibe-coded tool proves the need and demonstrates the workflow. Then engineering rebuilds it properly, with ownership, monitoring and a maintenance plan. The difference between "evidence" and "production" is the difference between a cheap dashboard and a very expensive incident.

👉 Promote your best vibe coder into the tooling team, or hire dedicated internal tooling developers. Someone in your org just demonstrated initiative, domain knowledge and builder instinct - for free, on their own time, against your process. That person is telling you what they want to do with their career. Listen before a competitor does.

👉 Fund internal tooling like it's a product, because it is. Its customers just happen to sit inside your building. Nothing compounds more expensively than neglected internal tools: it slows everyone down, breeds shadow IT, and demotivates exactly the people you can least afford to lose.

My colleague's management celebrated the token bills. What they should have celebrated is the free, brutally honest audit their employees just handed them - and then acted on it.

Vibe coding didn't create a problem at that company. It exposed one. There's a difference, and the companies that understand it will eat the ones that don't.

Have you seen vibe-coded shadow IT taking root in your org yet - or are you still in the champagne phase? 👇

This article is also available in German.

AICustomer ServiceIncentivesManagementRetentionSoftware EngineeringTechnologyBurnoutProductivityCorporate CultureShadow ITVibe Coding