Vibe Coding Gets Software Off The Ground. Fractional Teams Bring The Expertise To Scale.

In mid-October, an internal dashboard at the South African coffee franchise Bootlegger turned up online holding data its login screen didn't actually protect. MyBroadband, which described the tool as vibe-coded, verified that it exposed names and contact details linked to 132 Bootlegger locations, plus some performance and financial data. Months earlier, CEO Ricky Ruthenberg had posted on LinkedIn about building software with AI on nights and weekends.

Ruthenberg said the exposure involved a legacy version of BOS, an internal operations dashboard. The company had migrated BOS to a more secure environment, but "historical data remained on the previous platform, which had not been fully decommissioned." He maintained that no customer data was collected on that platform, which went offline on October 15. His statement doesn't say whether the legacy version was built with AI. The episode shows how a tool can work well for its users while carrying security and maintenance obligations its creators haven't fully closed out.

Wael Sabra, Founder and CEO of the AI delivery and technical talent platform SiiRA, points to the incident as an example of software outgrowing the way it was built. "Whether the software is working is one thing. Whether it's working for hundreds or thousands of users, that's something else completely," he notes.

In Sabra's view, supporting software at that scale takes several different kinds of technical expertise, each often needed in amounts too small to justify a full-time hire. But a light workload doesn't shrink the obligation. Once a business depends on a tool, someone still has to secure it, maintain it, and fix it when it breaks, whether or not there's a full-time role's worth of work in any one specialty. That mismatch, between the breadth of expertise a system needs and the workload it generates, is the staffing problem AI-built software is creating.

Building was never the hard part

Bootlegger is one example of a broader shift in who builds software. Sabra expects easily replicated, standalone software products to struggle while deeply integrated platforms hold their ground, because "the value of software is not the code." Alongside those platforms, he expects "a ton of custom-built software" that businesses build for themselves.

That shift is already underway. In EY's latest US AI Pulse Survey, 87% of senior leaders at organizations investing in AI say they have programs in place or in pilot to build software with AI.

Owning that software is a different job from building it. Sabra calls it an open secret in the industry that building is the least challenging part. Rather, it's resolving the friction that arises with use at scale. "The more usage you get, the more friction a user has with the product, the more they're going to uncover things no one has thought of," he says.

Vibe coding comes with risks

For many companies, the move from side project to critical system isn't a decision anyone makes on a set date. It happens as colleagues, customers or partners come to rely on a tool, and that reliance can grow faster than the support around it.

When OpenAI co-founder Andrej Karpathy coined the term "vibe coding" in early 2025, he set modest expectations for it. "It's not too bad for throwaway weekend projects," he wrote. But not every project stays throwaway. "If you vibe code something that's going to get two or three users, that's fine, but if you get thousands of users, very often that's unexpected," Sabra says. In his view, scale "is going to come forced." He offers an illustration: an e-commerce brand launches its own mobile app and adds 1,000 users. "The next thing they know, their data is not secured."

At that point, the person who built the tool can become the constraint. Sabra imagines the moment a company realizes it: "Our founder continuing to vibe code is hamstringing our growth." Many of these businesses, he notes, "have historically not hired software developers. They've historically not managed software developers. It's not their business." Leaning harder on AI tools doesn't close the gap. "Agents may fix something, but then break 10 other things," or they fix the reported problem without "finding the issue right next to it that a trained developer would be able to see."

Richard Horne, CEO of the UK's National Cyber Security Centre, framed the trade-off in a March keynote: "The attractions of vibe coding are clear, and disrupting the status quo of manually produced software that is consistently vulnerable is a huge opportunity, but not without risk of its own."

The next question is who the business brings in, and that's where the staffing math gets hard.

Inherited decisions, unintentional consequences

A business that inherits AI-built software also inherits technical decisions no one on staff made deliberately. "The agent made the technical choices along the way, so they may not be the best choices," Sabra points out. Simon Willison, co-creator of the Django web framework, has explained why that inheritance matters. "Most of the work we do as software engineers is about evolving existing systems, and for those the quality and understandability of the underlying code is crucial," he wrote.

Those choices can span several environments, so a single hire rarely covers the whole system. "You need an engineer who knows all the different environments that agent has developed within," Sabra says. The obvious fix creates its own problem: "Do you go out and hire another engineer, another engineer, another engineer, and each of them has a fraction of a job?"

Leaders already feel the shortfall. In the EY Pulse survey, 31% named a lack of in-house talent as a barrier to building their own software with AI. Security follows the same pattern. "Very often hiring a cyber expert full-time is an overkill," Sabra says. "What you need is oversight."

Match the expertise to the work

Sabra's alternative is to staff the system the way it actually behaves: several specialists, each engaged in proportion to the work in their domain. He expects many companies to arrive at some version of the same admission: "We have this piece of custom software, we actually don't know how it works, but it's a critical part to our business."

That admission is where his model starts. Before anyone decides which specialists a system needs, someone has to establish what it does and where its weaknesses are. "Everything starts with an audit, and then you build on it from there," Sabra says. After that, the relevant specialists in support, development or security are available as needed rather than on payroll full time, and the system is reassessed periodically. "You set the rules and you ensure those don't get broken along the way, and then you audit every once in a while."

Fractional work, fractional roles

Sabra sees the staffing mismatch as an early sign of a broader shift. "I think the world is quickly moving toward everything being fractional," he says. "What was a full-time job may end up a job done 50% by an agent, 50% by a human."

That outlook is still a prediction, but the obligation behind it is already here. Making sure an old platform is fully shut down after a migration, for example, is rarely anyone's full-time job, and it still has to get done. For technical leaders supporting software their business already depends on, the immediate question is concrete: which specialties the system needs, and how much of each.