Five Signs Your Vibe-Coded Tools Are Going Wrong, and What to Do Before They Do

Most businesses now have vibe-coded tools running somewhere, and most leadership teams cannot say with confidence which ones, what data they touch, or who is responsible when one breaks. A May 2026 survey of 307 CTOs, CIOs, and CISOs found 93% at least somewhat concerned about vibe-coded tools running in production, and only 8% described their governance as strong. That gap between how much is being built and how much is understood is the actual problem.

The useful question is not whether to allow vibe coding. Staff are already doing it, and the productivity case is real. The useful question is how to tell, tool by tool, whether a given build is heading somewhere safe or somewhere expensive. Below are the five places that go wrong most often, a way to check whether it is happening to you, and what to do about each one.

01The tool never quite reaches "done"

Agentic coding runs as a loop: read the files, plan a change, edit, run the tests, read the error, try again. Every turn re-sends the accumulated context as input, so cost tracks the number of attempts, not the size of the result. A tool that resists a solution racks up the same per-turn charges as one that ships cleanly, and nobody notices until the bill arrives.

The signal

Ask whoever built the tool how many sessions it took to get to a working version, and whether they know what it cost. If the honest answer is "a lot" and "no idea," the tool was built inside an unmonitored loop, and the same pattern will repeat on the next feature request.

What to do

• Set a per-user or per-project spend cap before granting access to an agentic coding tool, not after the first surprising invoice.
• Route routine subtasks to a cheaper model and reserve the expensive one for genuinely hard reasoning steps.
• Ask for prompt caching to be enabled where the platform supports it; repeated system context is often the largest line item on the bill.
• If a build is still not working after a handful of sessions, treat that as a signal to bring in someone who can read the code, not a reason to keep prompting.

A tool that runs on the builder's laptop is not yet an asset. It becomes one when somebody other than the builder can run it, audit it, and change it.

Skaleminds Advisory Team

02It works, but only on one machine

Prompt-to-app tools are optimised for time to first working screen. Hosting, backups, access control, and logging are separate problems that a local demo does not surface, and the person who built the tool often has no way to know those pieces are missing until something breaks in front of a customer or an auditor.

The signal

Ask where the tool actually runs. "On my laptop," "in a free-tier account nobody else has the login for," and "I'm not sure" are the same answer. If the person who built it is the only one who can restart it, it is not deployed, it is borrowed time.

What to do

• Require a named, shared hosting environment before a tool touches real data, even a modest one, rather than a personal account under someone's own credentials.
• Assign an owner of record for every tool in writing. Almost half of technology leaders surveyed in 2026 had no default answer for who is accountable when an AI-built tool fails, or hadn't decided.
• Confirm the source code can actually be exported. Some prompt-to-app platforms only produce a deployed service with no retrievable code, which means the only way to fix a bug later is to regenerate the whole thing and hope the same bug doesn't reappear.
• Put basic operational plumbing, authentication, backups, and logging, on a checklist that has to be completed before a tool is called finished, not treated as optional polish.

03It was never checked against your actual obligations

Compliance rules attach to what data an application touches, not to how it was built. A tool handling customer, health, payment, or employee data carries the same regulatory exposure whether it came from a formal engineering process or a weekend prompt session. The difference is that the formal process usually includes a review step, and the prompt session usually does not.

The signal

Ask what data the tool can reach, and whether anyone outside the person who built it has looked at that access. If a SOC 2, HIPAA, or GDPR-relevant workflow is running through a tool that has never had a security review, that is not a hypothetical risk, it is an open one right now.

What to do

• Sort every internally built tool into one of three tiers: handles nothing sensitive, handles regulated or personal data, or calls external AI services and acts on its own. Apply review proportional to the tier rather than one heavyweight gate that people learn to route around.
• Run secrets scanning and dependency checks on anything in the second or third tier before it goes live, not after an incident prompts the question.
• Put access controls at the platform level rather than inside each individual tool. In the 2026 survey, 55% of leaders wanted security controls to live in a governed layer underneath every app; only 7% thought each builder should configure them app by app.
• Check row-level security and permission scoping specifically on anything with a database behind it. This is the single most common gap found in scans of AI-generated backends.

04It doesn't talk to anything else

A tool built in isolation usually stays isolated. It gets its own login, its own export button, and its own copy of data that already lives somewhere else, because connecting to an existing system properly is harder than prompting a new interface on top of a spreadsheet.

The signal

Ask how data gets into and out of the tool. If the answer involves someone exporting a CSV from one system and importing it into another on a schedule, the tool has solved the interface problem and left the integration problem for a person to keep solving by hand.

What to do

• Before approving a new tool, check whether the data it needs already has an owner elsewhere in the business, and connect to that source rather than re-entering it.
• Treat manual export and import steps as a defect to fix, not a workaround to tolerate, since each one is a place the two records can silently drift apart.
• Where a proper integration is not yet feasible, at least document the manual step so it's visible to more than the one person currently doing it.

05Nobody knows this already exists

Each vibe-coded tool tends to get built independently, by whoever hit the pain point first. The result is multiple tools with their own definition of the same customer, order, or employee record, and the same business rule reimplemented slightly differently in each one. None of this shows up until two departments disagree about a number that should have come from the same source.

The signal

Ask two different teams how they track the same thing, whether that's active vendors, open deals, or approved headcount. If they give different numbers, or describe different tools doing roughly the same job, duplication has already happened; you just haven't found all of it yet.

What to do

• Keep a simple, low-friction registry of internally built tools: what it does, who owns it, what data it touches. This does not need to be a heavyweight approval process to be useful; visibility alone catches most duplication.
• Before a new tool is built, check the registry for something that already does most of the job. Extending an existing tool is usually cheaper than a new one, and it avoids creating a second source of truth.
• When duplication is found, consolidate deliberately rather than leaving both versions running. Two tools that disagree are worse than one tool that is merely incomplete.

A starting point, not a full audit

None of the five checks above requires new tooling or a big governance programme to begin. They require someone to ask five direct questions about each tool already running: how much did it cost to get working, where does it actually live, what data can it reach, does it talk to other systems properly, and does something like it already exist. Most organisations have never asked all five about most of their tools.