Once everyone’s data, contracts, and relationships are fed into AI, vibe-coding your business will be easy
Which processes can an AI-native business spin up on the fly? And what data did you feed the models to do it?
The same processes that can spin up new software in a few minutes can be used to spin up new AI-native businesses. Will they start off with your same customer list to target?
Once everyone’s data, contracts, and relationships are fed into AI, vibe-coding your business will be easy.
Yet many companies are uploading their customer lists, contracts, and their other business process data into LLMs. The frontier models need more training data, and they don’t have to scrape for it anymore. It is being loaded in for them by companies contracting with firms who are commissioned on serving up frontier models in the cloud.
Why your data is the training set
Anthropic itself talks about the future it envisions: “Some institutions will become human-AI hybrids; others where agents outcompete on speed or cost will become agent-only.” https://www.anthropic.com/research/multiagent-systems
They even acknowledge the mechanism: “The trajectory is easy to imagine and hard to slow: current institutions are designed by and for people, resting on assumptions about the sufficiency of oversight at human speed.”
The four pillars of defense
There are 4 pillars of defense, and all are presently available:
locally installed models with highly governed access to the cloud for any sensitive data
a rigorous look at organizational data, how siloed it is, how clean it is, how well-organized it is. The data structures were built by managed services or small teams tasked with providing a single business deliverable at the time that project budget was approved, and are not traversable and reliably read by intelligence that can meaningfully use them across the enterprise
a ruthlessly clear-headed willingness to redesign business processes
leaders who step up and have the mechanisms to govern and enforce the new processes and deprecate the old
Now is the time for “not another short-sighted single-focus project” filled with teams who don’t understand your business, cannot navigate your data, and are afraid to tell you where progress toward the end outcome is being impeded by legacy processes or bad data. It isn’t the time to queue up your data into models whose own leadership acknowledges the use is not just better software for your organization, but re-engineered businesses. Failing to govern, to rearchitect, to fix sprawled and error-rife data, and to re-invent may leave your firm on the sidelines.
You still have the moat, it just has to be shored up in the weak places.
AINOW has the experience in data privacy, data standards, data integrity, business modernization, and building the systems that provide Decision Provenance.
You Can't Sticker Your Way to a Database
Slapping Data Governance, Stewardship, and a "Data Catalog" (really a Data Dictionary) onto data structures no strong data person ever designed, because: "files", is the same as slapping metadata on files and expecting the benefits of a database just because you write SQL on top of it.
Every few years we try to rebuild the "database". First it was MapReduce, now it is metadata on files.
I remember a few years ago, I was working at a startup. The database went down, and the CEO bellowed "Can't we just turn this into files, so it never goes down?"
In the end, the "files" guys won, which they are pretty happy about, because Data Modelers/Architects always slowed them down, in their opinion.
Witness the decline of the data people, now the “files” guys want the Data Governance people to fix it.
Because, in the end, AI does not understand what was built.
Slapping Data Governance, Stewardship, and a "Data Catalog" (really a Data Dictionary) onto data structures no strong data person ever designed, because: "files", is the same as slapping metadata on files and expecting the benefits of a database just because you write SQL on top of it.
Tell me why I'm wrong.
We had to do some of what has happened because of the profusion of data sources, especially unstructured data, and effective use of Data Producers and Consumers and parallelism.
What did we lose, and what are we continually working around?
We got away with "metadata on files" for one reason: experienced data people silently supplied the meaning the structure didn't. That was the hidden subsidy. Hand that same pile of files to an agent, and the subsidy is gone. The agent reads a valid catalog and still gets the meaning wrong, because a Data Catalog that's really a Data Dictionary tells it what a field is called, not what it's for. And a guessing agent doesn't fail loudly. It fails plausibly: confident, well-formatted, and wrong three systems downstream.
The answer isn't to un-build the lake or fire the "files" guys. They solved a real problem with unstructured data and scale. The answer is to put the modeling discipline back above the physical layer: a governed semantic model of what the entities mean, independent of whether they live in files, tables, or a catalog.
That's the layer an agent can actually trust.