Patrick Van Deven

The through-line

Across his posts, talks and interviews, Patrick Van Deven keeps returning to one claim: the hard, valuable work in data has never been writing code, it's the messy human judgment layered underneath it, and that judgment is now the thing standing between companies and real AI adoption. In the spring posts this shows up as a product argument about VaultSpeed's template library and agentic framework . By early summer it hardens into an economic argument: the integration work that used to be invisible, buried in headcount, now shows up directly in AI agents' token bills . And in the podcast and webinar appearances, it becomes a governance argument: most regulated industries are running AI on top of decades-old data infrastructure that was never built for it, and bolting AI onto that infrastructure creates regulatory exposure rather than a genuine "frontier firm" ¹³. The throughline holds steady, but the framing moves from "we generate better code" to "we make the knowledge underneath the code explicit, reusable, and safe for agents to reason over" .

On code generation versus the real work

Van Deven is explicit that code generation was never the differentiator: "we generated code long before the LLMs did" . What actually consumes months is "profiling a source you've never seen," figuring out "which column is the business key and which is noise," and "designing the semantic layer so analysts get answers, not just tables" . That work, he says, "has always been manual, person-dependent, and slow" , which is why data projects take months rather than days.

On knowledge that compounds

He frames every migration, acquisition, or platform move as the same set of unanswered questions repeating: "How do we match customers across systems? What do we do when sources disagree? Which fields can we actually trust?" . His complaint is that teams "solve those questions, bury the answers in code, and start over next time" , and his stated fix is building "a way to capture those answers as knowledge that compounds," so you "solve it once, carry it forward to every project after" . He ties this directly to agents: "when that knowledge is trapped in scripts and spreadsheets, agents guess. When it's structured and explicit, agents reason" .

On treating AI agents like employees

In the deterministic-versus-agentic split, Van Deven draws a hard line: "the agents propose. Humans review. The production code stays fully deterministic" . On the podcast he extends this into an operating principle: organizations should treat AI agents like employees with clear briefs and operating parameters, rather than expecting legacy pipelines to magically produce AI-native capability ¹³. He also frames the stakes in regulatory terms, arguing that automating the deterministic data layer underneath agents is essential, and that companies which simply layer AI onto existing systems are vulnerable to regulatory problems rather than becoming true frontier firms ¹³.

On the cost of bad data hitting token budgets

Van Deven's clearest cost argument: "the cost of bad data integration used to be invisible. Now it shows up in tokens" . He walks through what a data warehouse actually does, "name and address matching, code table harmonization, pre-calculation, aggregation," and warns that removing that layer means "every user's AI agent" has to rediscover it "from raw sources... for every single query," multiplied across users . The same instinct shows up as a design principle for VaultSpeed's own tooling: "good for the data teams, good for the planet, good for everyone's token budgets," with "no need to pull a bazooka to reinvent joins and data pipeline at every turn" .

From the stage

In the Sabine VdL podcast, Van Deven goes further than any written post in naming regulatory risk directly: most regulated industries still run on data infrastructure built decades ago, and layering AI on top of it, rather than fixing the deterministic layer underneath, is what makes companies "vulnerable to regulatory problems" instead of genuine frontier firms ¹³. In the VaultSpeed webinar with Hans, he pushes into modeling philosophy not covered in the LinkedIn posts, insisting that core business concepts, natural business relationships, and logical data modeling terminology should be based on how businesses actually operate rather than on technical abstractions ¹⁴. And in the Valipac interview, he describes his own approach to a real deployment: treating physical waste streams as data, tracking packaging from market entry through recycling, and organizing both the physical and financial flows of waste recovery as an integration problem ¹⁵.

Takeaways

• When scoping a data integration project, expect the bottleneck to be profiling unfamiliar sources and defining business keys, not writing the transformation code itself .
• Capture matching, conflict-resolution, and trust decisions as explicit, structured knowledge rather than burying them in one-off scripts, so they carry forward to the next migration or acquisition .
• Budget for the fact that ungoverned, unmodeled data now costs AI agents directly in tokens on every query, not just people in headcount .
• Keep AI agents proposing changes while humans review and production code stays fully deterministic, rather than letting agents write directly to production .
• Before adopting AI agents in a regulated industry, audit whether the underlying data infrastructure was actually built to support them, since layering AI on legacy pipelines creates regulatory exposure ¹³.
• Build logical data models and business terminology around how the business actually operates, not around technical abstractions ¹⁴.