BLOG / OPINION
Vibe coding builds islands. Operations must be unified.
Russell Bishop
8th July 2025
BLOG / OPINION
Russell Bishop
8th July 2025
The cost and velocity of building this way is so low, you can freely build new work tools with less overheads and oversight.
Skip the requirements gathering, no procurement, no IT bottlebeck, just prompt as we go.
The challenge arises when these tools stop being throwaway and start becoming load-bearing and make up part of your operational infrastructure.
At that point, they inherit a familiar set of problems. The same ones, in fact, that organisations have spent two decades managing with spreadsheets.
Let's revisit the humble spreadsheet for a moment. A spreadsheet that runs a critical process is an island. It works well, but it lives in isolation.
Vibe-coded tools suffer the same hurdles.
The data inside it doesn't connect to anything else. Only one or two people (and a few datacentres in the US) understand how it's structured. Modifying it carries risk, because the downstream effects of a small change are unknown.
A vibe-coded internal tool has the same structural limitations. It may have a proper interface and act just like production software, but it lives apart from your other systems.
It's difficult to share, difficult to scale, and adoption typically stalls at the boundary of one team because there's no clear path for others to access it.
And if you overcome the adoption barrier, you now have more technology to maintain. How does this fit in with the rest of our operational workflows? Whose strategy can we follow here?
A capable tool, built in isolation, with no route to becoming part of your unified operations is a liability.
Who's responsible for securing the new tool when, by design, you're largely blind to what's under the hood?
The speed of delivery is the appeal, and the absence of a review process doesn't announce itself. The tool works, teams are happy, so it's less painful if no one interrogates our new silo. But looking correct and being technically sound are different claims, and the gap between them is your data can become vulnerable.
Your tools tend to hold real data: customer records, commercial information, staff pay, perhaps client data sitting inside your business. For any internal tool built this way, it's worth establishing who has checked how the data is stored, who can access it, and how we might detect if something has gone wrong.
What you need is the apparatus of a platform, even when your product is purely internal:
Each of those is something you get from a platform, not from a standalone tool. They're the difference between a system you can rely on and one you're hoping holds together.
If you're intrigued by what else a software platform should provide, check out our Airtable features index for the most exhaustive list we could write.
Unified operations means connected data, connected tools, and connected people. Rather than a landscape of isolated apps, it's a single platform where multiple teams work from the same source of truth.
A platform houses data and features for multiple teams in one place, so the same information isn't being re-entered and re-interpreted across disconnected applications. It provides single-login access to consistent interfaces, so people aren't learning a new bespoke UI every time they cross a team boundary. And it can evolve as the business changes shape, as processes mature, without a rebuild from scratch each time.
A low-code platform's backend is, to a large degree, self-documenting: the structure is visible and legible rather than buried in prompts and generated code that only made sense to one person on one afternoon. And if you partner with an agency to build and maintain it, continuity stops being a single point of failure. It becomes a relationship, with people whose role is to keep the system healthy as your business moves.
Vibe coding is a genuine shift in who gets to build. The risk is in reaching for it to solve problems that are fundamentally about scale, continuity, and shared access. These were never coding problems in the first place.
Prototypes prove an idea is worth pursuing. Be wary when the prototype becomes the system the business depends on.
The question to ask of any internal tool isn't whether you can build it quickly. It's what happens in a year, when three other teams need to use it and nobody is certain what's inside it.
If that question doesn't have a clear answer, you've built an island.
Learn about unified operations with low-code
Let's talk about replacing your islands with a connected platform that scales.
