AI Can Write Code. Only a Data Platform Can Make It Reliable.
Vibe coding is real, it is genuinely useful, and it is not going away. But the honest conversation about what it can and cannot do is only just beginning.
Andrej Karpathy — formerly of Tesla AI and OpenAI, and the person who coined the term "vibe coding" — wrote on X that no matter what he does, he gets junior code out of the model.
The mistakes, he noted, have changed — they are no longer simple syntax errors. They are subtler: wrong assumptions made confidently and silently, a reluctance to push back, a tendency to overcomplicate, and a habit of quietly removing code the model does not fully understand. His overall verdict: no matter what he does, he gets junior code out of the model.
"Vibe coding works. It is just not sufficient on its own — and in an enterprise context, 'not sufficient' is the same as 'broken.'"
This is Andrej Karpathy. If the godfather of vibe coding cannot extract senior engineering output from these tools, the problem is not a skill issue. The ceiling is structural.
And yet — and this is the part that gets lost in the discourse — Karpathy's conclusion was not to abandon AI-assisted coding. He said it is still a net huge improvement and that it is very difficult to imagine going back to manual coding. Both things are true at once. The tool is transformative and the tool has a hard ceiling.
The question for enterprise teams is not whether to use AI coding tools. The question is: what determines where that ceiling sits, and can you raise it?
The skill did not disappear. It moved.
The popular framing — "vibe coding requires no skill" — is technically wrong, but it points at something real. The skill required has shifted, not disappeared. What used to require syntax knowledge and framework familiarity now requires something different: the ability to provide context, detect silent failures, and govern the outputs.
The problems Karpathy describes are almost universally context problems. The model makes wrong assumptions because it lacks the right context. It runs along without checking because it has no way to validate its output against a ground truth. It removes code it does not understand because the relationship between components is not explicit anywhere the model can see.
This is not a model problem. Better prompting will not fix it. It is a structural problem about what the model has access to when it generates code — and what exists to catch the output before it reaches production.
What vibe coding actually needs
If you trace Karpathy's complaints back to their root, three things are missing every time. First, the model needs structured, consistent, versioned data to work against — not stale CSVs or inconsistent schemas across environments. Second, it needs semantic context: not just what the data contains, but what it means and how entities relate to each other. Third, the output needs a governance layer — something that can validate, trace, and catch failures before they become production incidents.
These are not AI problems. They are data platform problems. And solving them is precisely what D.Hub 2.0 is built to do.
Where D.Hub 2.0 enters the picture
D.Hub 2.0 is not an AI coding assistant. It is the infrastructure layer that determines whether AI-generated work is actually trustworthy at scale. The three connections between vibe coding's limitations and D.Hub's capabilities are direct.
AI outputs are only as reliable as the data they reason about. D.Hub's Collections and Pipelines module provides versioned, schema-governed, consistently processed data — turning vague prompts into context-aware execution.
Speed without traceability is a prototype, not a system. D.Hub's pipeline monitoring captures execution time, error messages, failure reasons, and audit history — everything that vibe-coded output alone cannot provide.
D.Hub's Ontology layer defines relationships between entities across your data estate — giving AI agents genuine semantic context, not just flat table access. That is the difference between an AI that guesses and one that understands.
Take the Ontology module specifically. One of Karpathy's sharpest observations is that models quietly remove code they do not understand as a side effect of unrelated tasks. This happens because the relationship between components is invisible to the model. An ontology layer makes those relationships explicit — orders connect to customers connect to fulfilment pipelines — in a structure the AI can actually navigate rather than guess at.
When a pipeline fails in D.Hub, you see the exact error message, the timestamp, and the reason execution stopped. When an AI agent generates a workflow, approval gates can be configured before any ontology relationship is created automatically. When a data schema changes, version history is tracked at both the dataset and table level.
These are not features. They are the difference between a prototype environment and a production system.
The Knowledge module takes this further. Rather than pointing an AI agent at raw data and hoping it reasons correctly, D.Hub lets you build a structured, queryable knowledge base from your existing collections and pipelines. Semantic search, keyword search, hybrid retrieval — the model gets the right context, not a haystack.
The honest framing
There is a version of the vibe coding conversation that is mostly hype: anyone can build anything, skills are irrelevant, just describe what you want. That version deserves the pushback it gets from engineers.
There is a more useful version: AI coding tools have genuinely shifted the skill floor, they have not eliminated the need for architecture, and the bottleneck has moved from writing code to providing the context and governance that makes code trustworthy.
In that second framing, the question for any serious engineering organization is not whether to adopt AI tools. It is whether the underlying infrastructure can support them. Vibe coding on top of inconsistent data, missing lineage, and no governance layer will produce exactly what Karpathy described: junior code, shipped fast, that eventually breaks in ways that are difficult to trace and expensive to fix.
The ceiling on AI-assisted engineering is set by the data platform underneath it, not by the model on top.
Vibe coding is the interface.
D.Hub is the infrastructure.
The models will keep improving. The assumptions they make silently will get subtler. The code they produce will get harder to audit by eye. The need for a governed, semantically-structured, traceable data layer underneath will increase, not decrease, as AI coding tools become more capable and more embedded in how teams ship software.
D.Hub 2.0 is built for exactly that moment — not to replace AI tools, but to be the layer that makes their output mean something in production.