What a data estate needs before an agent can work on it
ADER — Autonomous Data Engineering Readiness — measures your estate: the tables and views, the jobs that write them, the code behind those jobs, and the conventions and business meaning needed to change them. Thirteen dimensions in two groups. Twelve hold for any coding agent against any lakehouse; the one that depends on which agent you assess is labelled.
Two questions
Safety (M1–M8) asks whether an agent can act without breaking things. Correctness (S1–S5) asks whether it can be right. The two fail differently, which is why they are separate groups. Safety fails mechanically and visibly: a build fails, a source is missing, another writer overwrites the change, and the run stops. Correctness fails semantically and silently: the agent selects the wrong customer table, doubles revenue through a join, or adds amounts in two currencies, and every step reports success. A successful execution does not prove a correct result.
Nobody escapes the twelve
Twelve of the thirteen dimensions describe what any coding agent needs before it can change any lakehouse: a known source for each relation and each job, a project that builds from a clean checkout, a convention that is written down, a test that fails when the thing breaks, a declared grain, an authoritative relation for each business concept. Only M4, stack fit, has a basis relative to the agent being assessed — how much of your existing stack that agent's tools can understand, change and verify — and its row says so. A fit gap marks a limit of the assessed agent; it says nothing about whether you chose the right stack.
Whether an agent can work on an estate safely is a fact about its relations, its jobs, its code and its conventions. A platform purchase cannot establish that fact for you.
The thirteen dimensions
The figure carries the question each dimension asks. Below is what an agent cannot do when an estate has no answer to it.
Safety — can an agent act without breaking things?
- M1 Relation coverage — change a table or view from a known source.
- M2 Item coverage — change what runs, or know what will run next.
- M3 Producer attribution & dual-control — know what it must leave alone.
- M4 Stack fit — work reliably on parts of the stack its tools do not support. Relative to the assessed agent.
- M5 Buildability — verify its own change.
- M6 Convention consistency — produce code that follows the team's conventions.
- M7 Context assets — use the team's knowledge without relying on stale claims.
- M8 Test presence — check its work against a meaningful failure condition.
Correctness — can it be right?
- S1 Authoritative relation — choose the right source or join target.
- S2 Declared grain — join or aggregate without fanout.
- S3 Units and time semantics — aggregate or compare correctly.
- S4 Freshness expectation — distinguish expected delay from a data problem.
- S5 Business definitions — implement a request stated in business language.
Every dimension is determinable from code or the lakehouse; a questionnaire alone is not a measurement.
Why the bill comes due now
Provenance, tests, stated conventions and written decisions were sound engineering before any agent arrived. What an agent changes is the price of their absence. An engineer who cannot find the code that built a table asks a colleague and waits. An agent executes literally, at machine speed, on the information in front of it, and a missing definition becomes an incorrect production change. Agentic adoption is when the bill comes due.
The bill is already large, and the team that would pay it is already stretched. Poor data quality costs the average enterprise about $12.9M a year (Gartner), and 40% of enterprise apps will run task-specific AI agents by 2026 (Gartner). Data engineers already lose 53% of their time to maintaining pipelines rather than building new ones (Fivetran, 2026), and spend about 40% of their time troubleshooting data quality — roughly 793 engineering hours a month on the average team (Monte Carlo, 2022).
Where Vibedata fits
Everything above holds whether or not you use Vibedata. Vibedata is what reads an estate against the thirteen and tells you where it stands: the evidence examined for each dimension, the finding it supports, and no result where a dimension could not be read — missing access is a fact about the assessment, and a gap in the estate is a fact about the estate. It then turns the findings into work in your own repository: conventions, a domain glossary, decisions, grain and freshness declared as tests.
The dimensions are also what Vibedata itself depends on. Isolation draws on M1 to M3, because a clone of a relation with an unknown second writer diverges from production before the work is done. Gates draw on M5, M6 and M8, because a gate with nothing to run passes everything. Context draws on M7 and the five Correctness dimensions. Stack fit is where the model stops being neutral: within Vibedata it maps your estate to dbt, dlt and pipelines-as-code, and a fit gap is stated as a limit of ours.