The war on vibe coding – What belongs in the enterprise toolkit?

This might surprise you, but the biggest risk to enterprise AI isn’t slow adoption, it’s assuming vibe coding can survive contact with regulated reality: audit trails, approval gates, and data controls.

Seasoned CTOs know that the promise of unimaginable productivity the board is being sold is a fantasy - especially once governance and production constraints show up. What these fake promises look like on the ground is the ‘pilot graveyard’. You might have been there once or twice – it’s where exciting AI projects go to die, as the proof of concept looks great in a demo, but the moment it hits the real world, it stalls. What can you do? I’d say treat AI as an operating model upgrade, not a tooling rollout.

You don’t have an AI problem. You have a governed software delivery problem.

Vibe coding works great – for what it’s supposed to do: lightweight experiments, demos and pilots. But turning that into production at scale, with evals, monitoring, access controls, and audit-ready evidence, is the hard part.

If you’re a startup with a blank slate, it’s easier to design clean paths. Regulated incumbents have to ship change on live systems, under scrutiny, with zero tolerance for surprises. But for older organisations it can be brutally difficult. Let's say you’re an enterprise bank. Rather than starting from scratch, you’re grappling with decades of legacy technology, a workforce with mixed skill sets, and the fear of (high-profile) failure.

And that points to the problem. The real work isn't the AI model, it's the multitude of other fronts you're fighting at the same time, including model risk management, data lineage, access controls, approvals, and proving compliance at every step. Redefining talent, your partner ecosystem, and the workflow between humans and agents, (including who can approve changes, how exceptions are handled, and where audit evidence is captured), are all initiatives that never stop. You’re avoiding experience design missteps, and building trust frameworks that stick rather than check a box. Reality is messy and that’s what makes true AI adoption so hard.

AI-native engineering allows those teams to build software when AI is embedded across the delivery lifecycle - including discovery, design, build, test, and release, inside a single product or domain. The point isn’t speed (although we can get that), it’s repeatable, governed delivery. But an AI-native production model takes that same discipline and scales it across the enterprise, applying it to hundreds or even thousands of applications. Think of it as an organisation operating its own AI-native engineering factory.

It works by connecting three layers: foundations (platform + data), governance (policy-as-code, lineage, audit trails), and security (threat modelling, access controls, monitoring). These enable your teams to build your actual products - mortgage tools, wealth management platforms, etc for users (who may be your developers, employees, and/or customers) . And all of this ties directly to business value, including improving release cycle time, reducing audit prep effort, and speeding compliance sign-off without increasing risk.

This approach is designed to solve the scaling problems I see in regulated enterprises, where progress dies unless you can evidence controls, not just ship code. I'm talking about everything that happens outside the code. How do you manage an approval feedback loop when your AI agents move at machine speed, but your compliance team is human? How do you build a reusable library, approved prompt patterns, agent permission templates, secure connectors, and eval suites, instead of rebuilding one-off assets for every pilot?

You solve this by codifying what can be pre-approved (controls-as-code and eval gates in CI), and reserving humans for true exceptions, with a clear, traceable workflow for sign-off.I know it works because our own team learned it the hard way. When we started integrating AI at Nearform years back, we tried the top-down rollout. We shipped the tools, ran training, and expected behaviour to change. And it didn’t work. There were pockets of productivity, but no durable adoption, because workflows, incentives, and governance hadn’t changed, so teams reverted back to old habits. We didn’t get the internal buy-in, as we gave everyone the tools, but hadn’t changed the system they were working in.

What did work was an entirely different approach, one that was process-led. We picked two lighthouse programmes, a customer onboarding flow and a fraud operations workflow, and staffed lean, senior teams to ship production outcomes with full traceability. That’s what moved the needle,creating shorter lead times, fewer approval bottlenecks, and evidence that stood up in review.

By redesigning the workflows end‑to‑end - embedding controls as code, automating pre‑approvals, and making decision ownership explicit - we removed the invisible friction that had been slowing everything down. Compliance and security were involved upfront, not as late‑stage gatekeepers, which meant approvals moved at machine speed where they could, and surfaced cleanly to humans only when judgment was genuinely required. That clarity changed behaviour. Teams began to have more trust in the system, adoption increased, and cycle times collapsed from weeks to hours. Most importantly, we stopped debating whether AI was ‘allowed’ and started measuring results in production with human oversight, which is when momentum really began to drive results.

Thinking of it as a tooling upgrade, licences, copilots, prompt tips, got us nowhere. The real gains came when we treated AI as a change programme with new ways of working, new governance, and new SDLC gates, instead of ‘new tools’. We assessed the tech and the system around it, skills like spec writing and evaluation design, processes including approvals and release, and clear ownership across engineering, product, and risk.

You want safe change, fewer incidents, and auditability you can prove, not just claim. Enterprises win with small, senior, business-literate teams who own outcomes end-to-end, because judgement, close collaboration with end users for context, and accountability matter more than raw capacity.

It requires time on the ground, understanding the domain, the risk posture, and the approvals that actually govern change. And in the end, it’s about real-time decisions, clear accountability and observability (eval results, traces, and audit logs you can pull on demand), as much as coding speed. You've got to understand business goals and navigate within constraints of legacy systems, including brittle integrations, fixed release windows, and messy data of legacy systems without breaking what already works. This enables near-term and sustainable outcomes.

To CTOs, be prudent. Standing still is its own risk, pilot sprawl grows, delivery debt piles up, and competitors harden their operating model while you debate tooling. But not taking any action may be the biggest risk; all the market hype can distract you from the real issue, which is one of structural change. The organisations that come out on top won’t be chasing such speed. They’ll be building sustainable AI-native delivery models that improve measurable outcomes quarter after quarter, resulting in lead time to change, approval latency, and change failure rate.

At Nearform, we discipline engineering under real constraints. This is not a hype or fantasy - just good engineering and how we actually transform an enterprise. Interested in hearing more? Get in touch.