Can your ops team just vibe-code this automation instead of hiring someone?

Yes, for a first pass — and that's exactly where the risk starts. Vibe coding will get a workflow prototype running in an afternoon: read this inbox, extract these fields, write them somewhere. What it will not do on its own is survive the parts that don't show up in a demo — the malformed PDF, the vendor who leaves the company, the exception nobody thought to test. That gap between "it worked when I tried it" and "it's safe to run on real invoices or real customer data" is where a fast prototype and a production system stop being the same thing.

Why is this suddenly a live question?

Because the cost of trying dropped to near zero. AI coding tools now let someone with no engineering background describe a workflow in plain language and get something that runs — no procurement, no vendor call, no waiting on IT. Coverage this week put a number on how far that's gone: build costs for an internal tool that used to run six figures and six months now land closer to a few thousand dollars and a few weeks. The people doing this building are mostly not developers — surveys aggregated across 2026 put the share of non-developer users of AI coding tools above 60%, and the use case that shows up again and again is exactly this one: a founder, an ops lead, or a COO automating a piece of the back office themselves, because they can.

That's a real option now, not a fantasy. It just isn't the same option as hiring someone to build the same thing properly — and the gap between the two doesn't show up until the workflow has been running for a while.

What actually breaks, and when?

Not on day one. The prototype usually works on day one — that's what makes it convincing. What tends to go wrong shows up later, and it clusters around three things:

• Nobody owns it once the builder moves on. A workflow one person prompted into existence over a weekend has no documentation, no handoff, and no one else who understands why it makes the decisions it makes. When that person changes roles or leaves, the tool keeps running — until it doesn't, and nobody can safely touch it.
• It was never tested against the input it eventually sees. A demo runs on the ten emails or invoices the builder happened to try. Production runs on the one in two hundred that's a scanned photo of a handwritten note, or a duplicate, or in a format the tool has never encountered. Whether that case gets flagged for a person or silently mishandled was never a decision anyone made — it's just whatever the tool defaulted to.
• Failures are invisible. A commercial build logs what it did and why, so a wrong output is something a person catches and corrects. A prototype that was never built with that in mind fails quietly: the wrong number lands in the ERP, the wrong customer gets the wrong email, and the first anyone hears about it is the complaint.

This is the pattern trade press has converged on this week under the label "shadow IT" — not because the AI-generated code is worse than what a vendor would write, but because it arrives with none of the ownership, testing, or visibility that used to come bundled with going through procurement in the first place. The tools changed. The reasons those safeguards existed did not.

So when does it make sense to build it yourself?

When the workflow is genuinely low-stakes and you're using the prototype to answer a question, not to run the business. "Can this even be automated on the systems we actually run?" is a great question to answer with a weekend build. "Will this reliably write correct numbers into our ERP for the next two years without anyone watching it" is not — that answer needs the ownership, exception handling, and review that a prototype was never built to have.

The honest line: a vibe-coded prototype is a good way to find out what you want. It is not, by itself, a good way to run it. Getting from one to the other is not a bigger prompt — it's the engineering discipline of staged rollout, where an automation runs in shadow mode against real inputs with no output reaching production, then with a human checking every action, before it's trusted to run on its own — the same discipline we use for any automation we build, on infrastructure the client owns, at a fixed price agreed before the work starts.

What should you do with a prototype that's already running?

Don't rip it out — audit it. Find out what it's actually touching, what happens when it hits something it hasn't seen before, and who would notice if it started getting things quietly wrong. If the answer holds up, you have a head start, not a liability. If it doesn't, better to find out now than after it's been writing to your ERP for a year.

The free AI Audit does exactly that in about five minutes: it maps what a workflow — vibe-coded or not — is actually doing, and tells you honestly whether it's ready to run unsupervised or needs the engineering a prototype skips. Prefer to talk it through first? Book a call.