Vibe Coding Brings New Builders In, and Rebuilds What You Already Have

More people are building software now than at any point I can remember. Many of them don't call themselves developers. An operations manager describes a tool to an AI assistant and has a working dashboard by Friday. A founder with a strong product idea and no engineering background ships a prototype that real customers use. That's mostly good news. Ideas that used to die in a slide deck now get tested against reality.

But there's a pattern I keep seeing in the systems I'm asked to look at, and it's worth naming plainly. A lot of AI-assisted "vibe coding" isn't building new things. It's rebuilding things that already exist: login systems, job schedulers, retry queues, file importers, notification services, MQTT clients, half a payment flow. Each rebuilt copy works well enough on the day it's demoed. Each one is also a new thing someone has to secure, patch, monitor and eventually untangle.

This post isn't a case against newcomers or AI tools. It's about the cost that lands on the people who run the systems afterwards, and what a small or mid-sized company can do to keep the energy without the sprawl.

Why AI assistants tend to rebuild rather than reuse

If you ask an assistant to "add user login" or "send an alert when the temperature goes over 80°C", it will happily write the code from scratch. It usually has no idea your company already has a single sign-on provider, an alerting pipeline, or a shared library that does exactly this. Even when it can see more of the codebase, writing fresh code is the path of least resistance. It's fast, it runs, and it looks complete.

Someone with years of experience pauses at that point and asks: don't we already have this? Someone new to the field often doesn't know there's a question to ask. That's not a criticism. It's the knowledge that used to arrive slowly, through code reviews, mistakes and colleagues, and that the tools now let people skip.

There's some evidence the pattern shows up at scale. GitClear's 2025 code quality research analysed 211 million changed lines from 2020 to 2024. It found that lines associated with refactoring (code being moved and reused) fell from 25% of changed lines in 2021 to under 10% in 2024. Copy-pasted lines rose from 8.3% to 12.3% over the same period, and 2024 was the first year copy/paste outpaced moved code. GitClear sells code analytics, and its data shows a correlation with the rise of AI assistants, not proof of cause. The direction still matches what I see in practice: more new code, less consolidation.

What "overloading the system" actually looks like

In a company that builds connected products or runs integration-heavy software, duplicated components don't just sit there. They put load on people and infrastructure in specific ways.

More things to secure. Every hand-rolled login screen, API endpoint or file upload is another place a security mistake can live. Veracode's 2025 GenAI Code Security Report tested more than 100 language models on 80 coding tasks, and in about 45% of cases the generated code introduced a vulnerability from the OWASP Top 10. Failure rates for cross-site scripting and log injection were 86% and 88%. A company with one well-maintained authentication service has one place to get right. A company with six AI-generated ones has six.

More dependencies, some of which don't exist. AI assistants sometimes recommend packages that were never published. A study accepted at USENIX Security 2025 generated 576,000 code samples with 16 models and found that, on average, at least 5.2% of the packages recommended by commercial models and 21.7% of those recommended by open-source models did not exist: 205,474 unique made-up names in total. Attackers have noticed. If they register one of those names, someone who installs it without checking pulls in the attacker's code. Experienced developers tend to notice an unfamiliar package. Newcomers often install whatever the assistant suggests.

More load on shared infrastructure. Picture a company where three teams have each vibe-coded their own small service to read sensor data from the same MQTT broker. Each one opens its own connections, subscribes to wildcard topics, and polls a database every few seconds "to be safe". None of them is wrong on its own. Together they triple the broker's connection count and add database load nobody budgeted for. Six months later, someone is asked why the cloud bill went up.

More surface for the people on call. Each new component brings its own logs (or none), its own error handling (often none), and its own way of failing. The operations team inherits all of it, usually without documentation, and often after the person who built it has moved on to the next idea.

More work for reviewers. When building is cheap, reviewing becomes the bottleneck. A senior engineer who could review a few careful changes a day is now handed many large ones, generated quickly by people who can't always explain why the code is the way it is.

The answer isn't to slow people down

It's tempting to respond with a ban or a heavy approval process. In my experience that just drives the building underground, onto personal accounts and unsanctioned cloud services, where it's even harder to see.

A better goal is to make reuse easier than reinvention. The newcomer with an idea should find the existing building blocks faster than the AI can write new ones.

What to do this month

1. Write down your building blocks. Make a short, plain list of the components your company already has and wants people to use: identity and login, notifications and alerting, file storage, the message broker and topic conventions, the job scheduler, logging and monitoring, the approved database. One page is enough. For each one, name an owner and say how to use it.

2. Put that list where the AI will see it. Most AI coding tools read project instruction files or system prompts. Add a short instruction along the lines of: "Use the company's existing services for login, alerts, storage and messaging. Do not write new ones. Ask if unsure." It costs nothing and changes what the assistant reaches for first.

3. Add one question to your intake. Before a new internal tool or service goes live, ask: "What existing component does this replace or duplicate, and why isn't that component good enough?" Sometimes the answer is a real gap worth fixing centrally. Often it's "I didn't know we had one."

4. Check every new dependency. Require that new packages exist, are actively maintained, and come from the publisher you think they do before anything is installed in a shared environment. A lockfile and a dependency scanner in CI catch most of this automatically.

5. Set a minimum bar for "running in production". It doesn't need to be heavy. Something like: it has a named owner, it logs to the central system, it uses company login, it has been reviewed by someone who has run production software before, and there's a written note saying how to turn it off. Anything below that bar stays a prototype.

6. Pair the newcomers with a reviewer, not a gatekeeper. Give people who are building with AI a named engineer they can ask: "Is there already something for this?" Half an hour of guidance at the start saves weeks of consolidation later, and it's how the missing know-how actually gets passed on.

7. Run a duplication audit once a quarter. List the internal tools and services that have appeared in the last three months. Group them by what they do. Where you find three versions of the same thing, pick one, migrate the others, and retire them. Retiring code is work too, and it deserves the same credit as shipping it.

Keeping the good part

The best thing about AI-assisted building is that people closest to a problem can now try to solve it themselves. Operations staff know where the friction is. Founders know what customers will pay for. Engineering teams should want those people building.

What they're missing isn't intelligence or effort. It's context: what already exists, what it costs to run something for years rather than days, and which parts of a system shouldn't be reinvented. That context can be written down, put in front of the tools, and taught. A company that does that gets the speed without paying twice for every component.

Sources

If you suspect your company is running three versions of the same thing, a two-week discovery and audit sprint will find them and say which one to keep. Book a discovery call.