Listen on
Data teams are shipping faster than they have in years. They’re also losing sleep over it. The 2026 dbt Labs State of Analytics Engineering report puts a number on the contradiction: across 363 practitioners, trust as a stated priority climbed from 66% to 83% in a single year, while 41% still can’t say who owns the data and 53% still call its quality poor. The report’s name for the pattern is “acceleration without stabilization.”
Jason Bradwell sits down with Ross Katz to read the report from the inside. CorrDyn’s clients span every cell of the matrix the survey describes: early-stage teams trying to get a foundation in, mature teams managing AI-driven sprawl, leadership teams asking why the velocity numbers don’t square with the trust numbers. Ross’s argument is that the binding constraint inside data organizations has flipped. Time and money used to set the limits. In the agentic AI era, the limit is attention. Stakeholder management used to be a soft skill the senior IC picked up on the way to a director title. Today it’s the skill that decides who sets the terms of the AI rollout and who gets handed the consequences.
Ross maps four layers of data work: generation, integration, maintenance, governance. AI does the first one well. The other three are where it quietly creates new demand. The episode also unpacks the budget asymmetry the report surfaces (compute costs up 50%, team budgets up 36%), challenges dbt’s “trust as infrastructure” framing use case by use case, and tracks the structural shift in the data team’s job: from enabling other people’s questions to being the control layer that validates what agents are about to answer. It closes on the distinction between summarization and synthesis, and why most context-layer architectures collapse one into the other.
Key Takeaways
Acceleration without stabilization is a stakeholder management problem.
Leadership sees AI as a multiplier on output for the same investment; data teams see acceleration creating more integration, maintenance, and governance work downstream. The onus is on the data team to tell the story of what it costs to keep the foundation stable as the rate of generation goes up. That story has to be told in the language the organization uses to make decisions, whether that’s relationship-driven cultures where trust is built before influence lands, or objectivity-driven cultures where the data team’s proximity to the data makes them an automatic suspect.
AI accelerates code generation. Running the data system still needs humans.
The four layers of data work respond very differently to AI. Generation (writing code, models, queries, tests) gets meaningfully faster. Integration still breaks when upstream schemas change. Maintenance still needs someone who understands the legacy logic behind the model. Governance still requires deterministic systems and human accountability for who sees what. Generating more code at the top of the stack creates more work in every layer beneath it.
Attention has replaced time and money as the binding constraint.
Compute costs are up 50% while team budgets are up 36%. The question that gap forces isn’t “how do we do more with less.” It’s whose attention covers the new vibe-coded apps now hitting the warehouse with unoptimized queries. Headcount and platform investment have to scale alongside the compute spend, or the work the data team is accountable for stops getting done well.
Trust-as-infrastructure depends on what the data is for.
Trust matters most for operational reporting and embedded analytics; for exploratory analysis, speed often matters more. Treating trust as a uniform requirement across all data products inflates investment in the wrong places. Match the level of testing, lineage, and access control to the use case. Daily dashboards that hire and fire people aren’t the same surface as a long tail of ad hoc questions.
Data teams are shifting from enablement layer to control layer.
Agentic AI now lets stakeholders run an end-around the data team. They get an answer from a vibe-coded app instead of opening a Jira ticket. The team’s new job is to make sure that whatever happens between the agent and the answer is validated, observable, and accountable, especially for operational reporting, decision support, and embedded analytics. Every data team is becoming a data platform team.
Related: Managed Data Team | AI Strategy | Data Assessment | Episode 19: What MCP Means for Enterprise Data Strategy
Full Transcript
Jason: Every year dbt Labs surveys the people who actually build and maintain data systems. Not the vendors, not the analysts writing about the industry, but the practitioners. The 2026 edition went out to 363 data professionals, and the headline finding is a tension that I think most people working in or alongside data teams will recognize immediately. AI is now embedded in daily data work. 72% of respondents are prioritizing AI-assisted coding. Teams are shipping more, faster, with smaller prompts and shorter cycles, and yet trust as a stated priority jumped from 66% to 83% in a single year. At the same time, 41% still report ambiguous data ownership, 53% still cite poor data quality, and only 24% are investing AI where it arguably matters most: in pipeline governance, tests, and observability. The report calls it acceleration without stabilization. The speed is real; the foundations haven’t kept pace. That paradox is what we wanted to dig into today on Eventual Consistency. We’re not here to recap the report but use it as a lens on a bigger question: what is AI actually doing to the relationship between data teams and the rest of the business? I’m joined by Ross Katz, who obviously is usually on the other side of the microphone over at CorrDyn. He works with organizations across a bunch of industries as their external data team, which gives him a vantage point that most internal practitioners don’t have. We get into what that acceleration without stabilization actually looks like inside organizations, why the bottleneck has shifted from infrastructure to accountability, how data teams are navigating the shift from being an enablement layer to a control layer, and what the attention economy means for how teams decide what they say yes and no to.
Jason Bradwell: So Ross, dbt Labs have just published its 2026 state of analytics engineering report. What’s your takeaways? What’s your first reaction?
Ross Katz: The first reaction is obviously that AI is changing the way all of us do our jobs. The people who do data work, which is central to the way that AI is used at organizations, is no different than the rest of the workforce dealing with AI basically just disrupting all of our lives. So really the question is: AI is changing things. How is it changing things? And then what are the expectations that these different roles within the data ecosystem have about how things are changing, how they should change, how they’re going to change. What you see is different groups have different expectations for how much trust you should have in your data infrastructure, how fast things should move inside of the data infrastructure, and then also the quality and reliability related to trust of the data that you’re getting back. And how much should all of this cost? Depending on your level of visibility — if you have a lot of visibility into cost and into speed, all you’re doing is writing the checks and asking questions of the system — you want fast answers and you want it to not cost very much. But if your job is dependent on delivering high-quality answers that you can point to and say this is a trustworthy answer that should be delivered using this methodology, then you’re obviously very concerned about the level of trust that’s in the system, the amount of hallucination that AI is creating inside of data systems. We’re seeing all of those things come to the fore with the release of this new report and the survey that they did.
Jason Bradwell: One of the terms that struck me in this report is around this idea of acceleration without stabilization. You’ve got all these teams out there who are shipping faster, but maybe the foundations aren’t necessarily keeping pace. As a business like CorrDyn that’s working with lots of different industries, lots of different contexts, does that phrase resonate with where you’re seeing things right now? Or does it feel like someone else’s problem at this stage?
Ross Katz: It makes sense in the context of the way a lot of data teams do their job. One of the challenges of being an internal data team — and the vast majority of the people who respond to this survey are internal data teams rather than where we sit as a consulting organization; we act as our clients’ external data team — is that upward management is a skill. Expectation setting is a skill. Leaders when they’re asking for more things under the assumption that more can get done because we have AI here to generate more of the code, to create more of the data pipelines, to write more of the data models, to do more of the data testing, to query more from the data warehouse — their working assumption is we should be able to do more with the same level of investment and with a higher degree of speed because we have AI agents in the mix and these coding tools that are here to support us. It’s incumbent on the internal data team themselves to tell the story of what the leaders are missing when they ask for that acceleration without understanding what it takes to stabilize the entire data ecosystem in order to deliver that with the appropriate degree of reliability, of reproducibility, of completeness in the results, and with somebody that you can point to and say that person or that group is accountable for the quality of the answer that’s being given. It’s great that these tools allow us to ship more things, but another thing you see in the survey is that data teams are actually spending the vast majority of their time on maintenance of the things that they’re shipping. AI, at least as of today, is really great at helping you prototype, at helping you ship something really quickly, at helping you iterate on something. But not all of us are in a lean startup environment where we can iterate our way to product-market fit and then fix all the errors after we ship to production. A lot of the people who are on these internal data teams are responsible for shipping something to production that is reliable, that is maintainable, that is cost-efficient, that is doing everything we say it’s going to do and not delivering information that is wrong. Because fundamentally, data teams are a support function whose job is to deliver intelligence and insights and data products that help other people find intelligence and insights and make better decisions. What I see is two groups worried about different halves of these equations. You’ve got leaders who are very worried about acceleration, and then you’ve got data teams that are very worried about stabilization. And I put the onus on the data teams to do the internal work — the non-data work, the bureaucracy management work, the upward management work — of setting expectations for what it really means if we’re doing a ton of prototyping and not a lot of stabilization for the long-term trajectory of the organization in terms of data maturity.
Jason Bradwell: We’re talking about this gap between these two different groups and you speak about how that stakeholder management is a skill. I’m curious to unpack with you how you go about plugging that gap. If the onus is on the data teams to make this make sense, what’s your advice as a consultant sitting from the outside to your clients on how they can go about achieving that?
Ross Katz: Honestly, this is one of the reasons why we’re brought in regularly. Depending on the nature of the organization that you’re in — if you’re not in an organization that values direct speaking to people above you, or you have a director or a VP or a CEO who has a fragile ego about being challenged, or every idea is a good idea as long as it came from them first, which are all different kinds of stakeholders I’ve had to deal with previously — you have to be able to analyze the landscape and say how are decisions scaffolded in this environment and what is the way that I can intervene in the environment in order to influence the way that decisions get made. There are some environments that are highly relationship-driven where your job is to cozy up to the decision-makers, make it clear that you’re on their team, make them feel that you are supporting them, and then once you’ve built the strength of the relationship, you’re able to pass your own viewpoint to people in decision-making roles so that your voice is being reflected in the room. There are other environments that are very information-driven in terms of how decisions are scaffolded — the companies that have gone all in on bringing data to every decision that’s going to be made. You would think that a data team would be in a really strong position to do that. But one of the challenges in some of these company environments that are focused on objectivity is that, just by nature of your role, they’re immediately skeptical of the data that you’re bringing. You have an understanding of the data and you have a vested interest in the way that the decision comes out. What will often happen is you’ll get challenged on both of those things: the nature of the data and the nature of where you sit and how your own viewpoint is constructing the recommendations that you’re making. Some of the issues are that, depending on where you are in your career relative to the people you’re reporting to, you’re just viewed as a cost center. Or you’re not in a position to necessarily influence budget allocation toward the data team. You might not even have visibility into budget allocation to the team. And this is something that came out of the dbt Labs survey as well — there are a good number of data teams that don’t have visibility into where their budgets are even going. These decisions are being made without their understanding or without their voice in the room. Oftentimes what we’re asked to do as consultants is come in and bring that voice of experience, that authoritative perspective that comes from across organizations, and that sense that at the end of this assessment, you can choose to fire us or continue working with us. We don’t have a vested interest in the outcome. So we’re asked to bring that neutrality to the conversation in order to guide the organization in the right direction based on what your strategic priorities are and what the facts are on the ground in terms of how decisions are made and how data flows through your system today. And what your vision is for the way that AI delivers value for your business in the future. Those are some of the things I would think about as I was looking at the landscape and trying to figure out how to push the organization in a direction that acknowledges the investment that’s needed in something like stabilization, or the investment that’s needed in foundational data capabilities — foundational tooling, foundational data modeling with a framework like dbt — in order to ensure that the speed that we want for these decisions isn’t coming at the expense of the quality and the cost that we also want to manage and meet organizational standards for.
Jason Bradwell: Speaking about budgets, one of the stats that stood out to me from the report is that they cited a 50% increase according to respondents in compute and warehouse costs, but only 36% of teams report rising team budgets. How do you rationalize that? And how does that kind of squeeze change what a team says yes or no to?
Ross Katz: Fundamentally, we used to say that the biggest constraint we have is time. Some organizations experience the biggest constraint as money. In an agentic AI age, my viewpoint is that the biggest constraint we have is attention. Because we’re trying to do multiple things at the same time and it’s hard to do three things at the same time, five things at the same time, 10 apps I’m developing with agentic AI at the same time, to the same degree of quality and scrutiny as I would have done the one that I was handcrafting previously. What I think is that it’s once again incumbent on the data teams to tell the story of how the additional attention that they get with additional headcount needs to scale alongside the additional capabilities that the organization is developing in order to feed the compute machine — which I take as: we’re spending more on our data warehouse because our data warehouse needs to be more utilized. We’ve got all these business stakeholders who, rather than asking the data team for something, are vibe coding an app with ChatGPT or Claude or Gemini that’s hitting the data warehouse — maybe with queries that are not optimized or for which the warehouse was not designed to serve. The data hasn’t been modeled in a way that supports answering these queries in reliable and reproducible ways. The story that needs to be told is: you want to be able to ask these questions and do exploratory data analysis using agentic AI. We support that. We think that is a great path for our organization to go down. We’re finally getting to a place where we can see on the horizon true democratization of insights and of the ability to ask questions at scale. But each set of questions that needs to be asked, each capability that needs to be unlocked — if you want somebody to be responsible for ensuring that thing delivers data in an economical way, delivers data in a reproducible way, in an explainable way, that you understand where the answers came from and that they’re the highest quality answers we can get for the organization as a whole, then there need to be human beings with data expertise behind the scenes who are there to create the platform upon which all of these democratized data capabilities can be unlocked. What we see in the dbt Labs survey is basically the tug-of-war going on between those two forces: between the leadership who sees only the opportunities for bigger, better, faster data apps at lower and lower costs, and the people who are potentially going to lose their jobs if the wrong decision gets made based on the data that they are the owners of — waking up in a cold sweat in the middle of the night because they’re not being set up to succeed, they’re being set up to fail. As data leaders, it’s our job to recognize tensions like this. We’re the interface between the people who are doing the data modeling and the leaders who are making decisions or investing in the data platforms that allow the company to be successful. So we need to connect the dots for leaders so that they can make smart long-term decisions, not just the decisions that are going to make them look good in the short term because new capabilities have been unlocked.
Jason Bradwell: As you’re talking, it makes me think about this iron triangle concept — you can have things fast, cheap, or good. Pick two but you can’t have all three. And I feel like, with the proliferation of these technologies impacting every element of both our professional and sometimes personal lives, stakeholders increasingly give less and less of a — I don’t know if I can swear on Eventual Consistency, but S-H-I-T — about that concept. We want it all, because we believe that it’s now achievable to get that. I’m curious to get your thoughts on this squeeze in budgets. Is it from your perspective something that is temporary or is it structural? Are you expecting the budgets to eventually catch up as the technology gets proven and what it can actually deliver, or do you think that these data teams are more likely to be asked to permanently do more with less? What’s your view on that horizon?
Ross Katz: I think it’s going to be both, unfortunately. It’s going to vary from company to company. There are going to be companies who think they can move super fast without the data foundations and they’re going to discover that all these capabilities they thought they were going to unlock are not being unlocked because they didn’t eat their Wheaties and grow up. There’s a reason why it’s called data maturity — you actually have to mature. The organizations who are already ahead of the curve, who already had data foundations in place, they’re able to move extremely fast. But those data foundations have to be developed with care and with attention to detail. Basically you’ve got four layers of data work that data teams do. You’ve got the generation layer, which is roughly writing new code, creating new models, writing queries, doing transformations. You’ve got the integration layer, which is moving data between systems, evolving schemas as things change, enforcing contracts between these systems and making sure that the data that lands is abiding by all of those contracts. And then there’s the maintenance layer, which — unfortunately with deterministic software systems, you can basically say you wake up in the morning, the website today is the same as the website yesterday unless we choose to do something different. With data systems, the data that moves through your company changes as your company changes. The marketing team wants to launch a new campaign, that’s new data moving through the system. The product team wants to launch a new product line, that’s new data moving through the system and a new surface upon which data might be captured. Your financial team wants to break out expenses in different ways — somehow all of those categories have to make it into the system so that those breakouts are being reported in the way that the finance team needs to see them. So every time something like that happens, there’s maintenance activity. You have to refactor the existing models, you have to debug problems that are happening in the integration layer, and you have to understand the legacy logic and maybe reconstruct the data systems in order to meet the emerging requirements of the business. And then there’s the governance layer, which is testing, data lineage, who owns it when it breaks, access control, observability — observability influences all of these. On its surface for people who are not in the data world, it seems like AI just does all of this. But the truth is that AI is really good at the generation layer. If you are smart about the way you architect your data systems, it can be an accelerator for the maintenance layer and to a certain degree the governance layer. But AI is not monitoring data pipelines right now. You’re not going to set up AI to do the job of a data engineer end-to-end. Even if AI can accelerate that data engineer to improve the integration layer, there’s still a lot of work that needs to be done that that person needs to pay attention to in order to make sure the trains are running on time, that the data’s arriving when it needs to. Similarly with the maintenance and the governance layer — Databricks has AI inside of their system, for example, that when you get a Spark error it will explain the Spark error to you. But it is still incumbent on you to understand the full scope of the data system that you’re working in and understand what the levers are at your disposal in order to maintain this system or update it according to new requirements. And at the governance layer, AI doesn’t get to decide who gets access to what. That has to be a human decision. And the enforcement of those access controls needs to be done in deterministic software systems, not in vibe-coded pre-production apps. So is the squeeze temporary or structural? My answer is contingent, because some of these problems are structural. AI will not be able to do all of this work for you end-to-end. But some of it is temporary because new tooling will be introduced to the data ecosystem that will be more AI-accelerated. Processes within how data teams work will eventually be reworked in order to take the highest possible advantage of the automation that is becoming available. But we’re using a tool that’s designed for text generation, to a certain degree image understanding and generation, to manage systems for the purpose of delivering insights and data. We have to use the tools of yesterday with the AI of today in order to accomplish those goals. We all have to be realistic about what AI does, which is we’re able to generate a ton more. But when you generate a ton more, it creates even more integrations that are needed, even more maintenance, even more governance. So it’s reducing work at the top of this four-layer cake that I’m talking about, but it’s not reducing the overall amount of work that a data team has to do. And that just has to be part of the conversation when you think about whether this is structural or whether it’s eventually going away — because the truth is it’s a dynamic system that’s creating as much demand as it’s able to consume.
Jason Bradwell: The dbt report talks about how the organizations that are pulling ahead in the AI race are the ones that are treating trust as infrastructure rather than as just a deliverable. What does that actually require from your perspective to be true within an organization?
Ross Katz: There’s a reason why they’re focused on this. They’re not as focused on the cost versus speed stuff. They’re focused on trust as infrastructure because that’s one of the things that dbt does really well and is especially valuable in this environment — dbt allows you to have a central place where you’re managing all of your metric definitions. It allows you to do data testing so that you can be certain that the data sources you’re using are fresh. It allows you to do things that assist with row-level security and column-level security, and all of the things you need to do from a governance perspective. It assists in understanding your data lineage so that everyone can agree on where this comes from and what is the source system that drives the definition of a given metric. I think that is very true and the right thing to think about. But I also think that companies need to decide what are the outcomes they want to drive with their data infrastructure and then what type of infrastructure is needed in order to drive those outcomes. Roughly speaking, there’s a variety of different types of data outcomes. You’ve got your operational reporting — your daily metrics and your dashboards. You’ve got exploratory analysis — your ad hoc questions or hypothesis testing. You’ve got your decision support systems — what is the data that that person in this role needs to make this decision, let’s make sure they have the information in front of them when the time comes. And then there’s data apps or embedded analytics — data that’s feeding product and customers. If you’re on the exploratory analysis side of the equation, where you have lots of people in your organization asking questions of the data and the number of questions they could possibly ask is a huge long tail, then speed matters more and trust matters only moderately. You’re really just trying to give people the tools they need in order to splunk through it. Once they get to a place where they’ve got a critical insight, then you can deep dive on that critical insight and assign it to a human being who already knows your data model. But when you’re talking about operational reporting, speed matters less and trust matters a lot. People are making daily decisions based on these dashboards. People are getting hired and fired based on the data in here. Trust is really important; speed to the answer is not so much. If it’s decision support, both matter but trust is slightly higher. If it’s embedded analytics, both are at a maximum — but even then trust is the highest. Trust as infrastructure is absolutely one of the messages I would take away from this report. dbt obviously has a vested interest in sending that message because they’re a critical component of trust as infrastructure. But depending on your use case, the level of trust that you need may vary, and on a use case-by-use case basis I would be thinking about how important is it for us to just have something that gets us an answer versus how important is it to have something that is reliable, repeatable, auditable, with completely bulletproof access controls. Those kinds of requirements are what drive the infrastructure that you build, because it’s not a one-size-fits-all thing.
Jason Bradwell: As we look at wrapping up this interview, I’m curious — for someone who hasn’t read the report and has no intention of reading the report, what’s your big takeaway from the dbt study? What’s something that people need to know? What’s something that surprised you from what you read?
Ross Katz: The way to think about where we’re at — I’m abstracting away from the specific findings of the report — is essentially that AI has increased the speed with which code can be generated that, to a reasonable degree, works, and it’s also increased the expectations of leadership for what data-driven applications should be able to do across the business. What that’s doing is creating some really tough tensions inside the data team for how their role needs to shift in response to the emergence of AI and what it does on both sides of this equation. What I see happening is essentially data teams going from: we are an enablement layer — we’re enabling all of these other use cases across the organization, somebody talks to me every time they have a new use case and it’s my job to make sure that they’re set up to succeed by building a machine learning model for you or setting up data infrastructure for you or building you the dashboard that’s going to answer the question that you have every day — to now being more of a control layer. “Context layer” is overused, especially in this moment, and we’ll talk about more of that in future episodes, but more of a control layer. It’s now possible for people across the organization to do an end run around the data team. People can get answers to questions they couldn’t get before. They used to have to ask you just because you were the only person who could write SQL. Now they can use an agent to get an answer to their question. Is that answer right or wrong? We don’t know. But it is the job of the data team to ensure that when that person asks that question — especially if that question is a sensitive one, we’re not talking about exploratory analysis here, we’re talking about operational reporting or decision support or embedded analytics — everything that’s happening in between the agent and the answer is controlled and is validated, and set up in a way that makes it usable for everyone. In some ways we’re all becoming data platform teams now. This was the way it worked at your big hedge funds where you had a data platform team whose job was to make it easy for traders to form hypotheses. We’re all in many ways becoming data platform teams now. So we need to broaden the horizons of how we think and of the architectures that we design and of the interaction patterns that we design, so that we’re enabling the organizations to take the most advantage of these AI tools without creating unreasonable expectations on you or putting you in a position where you’re going to get fired for something that is not your fault. It’s a very sensitive position for the data teams and I think you see that in a lot of the responses in the dbt Labs report.
Jason Bradwell: Now we’re moving to one of the most exciting parts of Eventual Consistency, which is what we’re watching. Ross, what is catching your eye in the world of data and AI over the last couple of weeks?
Ross Katz: Other than the NBA playoffs, what I’m watching in the world of data and AI is this emerging conversation around — it’s called varying things: the context layer, the knowledge base, the source of truth. The emerging visions people have for what is that central repository of knowledge within a company that allows AI to have all of the context it needs to answer every question anybody might need in the context of this organization or this project. I’ve seen a lot of approaches to this. I’ve seen some manifestos out there about how different startups are going to do this. One of the solutions that gets thrown out there a lot is: put a bunch of agents in the middle of this business, give them access to all of the systems, and put them to work summarizing and synthesizing everything into a single thing — a directory of markdown files with different structures, skills to know when to access which markdown files. There are a lot of ideas around this. The one thing I want to point out is that all of this is predicated on synthesis. And I want to draw a distinction between summarization and synthesis. Summarization is: take this bigger thing and make it a smaller thing. By nature of taking a bigger thing and making it smaller, you are losing some of the information content. It will not be a perfect compression ever, especially in text — by definition it can’t be. Synthesis, to my definition, is: you’re taking a lens or a point of view on that thing and constructing it in a way that captures all of the relevant information for that lens — on that source system, that document, that customer, whatever. Synthesis is more valuable in the context of this knowledge base ecosystem because it’s going to preserve more of the information that people want to get out of these systems. But the problem with synthesis is that it’s only valuable if either the human does it — so you have the serendipity of encountering information you wouldn’t have otherwise had — or you have to know what questions you want to ask in advance so that the relevant information is surfaced within that system. Synthesis without a target is just summarization, which naturally leaks information out. What I would say is we are better off in a world where the information is in the systems and the agents can just go get what they need at question time — if you don’t know what questions you’re going to ask. But if you know in advance what questions you’re going to ask, this is what data infrastructure is for. And this is why our assessments begin with: what are you trying to accomplish and what questions do you ask to get there? Because that gives you the lens you use to synthesize the information and set it up so that you or the AI agents operating on your behalf can get to the answers that you need. There are a lot of good ideas out there. There are also a lot of harebrained and needlessly optimistic ideas out there, but there are fundamental laws of the universe and of information that you can’t violate when you’re trying to design systems like this.
Jason: So that’s it for this episode of Eventual Consistency. If you want to talk about your data challenges or you think that we got something wrong and you want to tell us how, you can find us at corrdyn.com, that’s C-O-R-R-D-Y-N.com. We’re doing this every two weeks, so you’ll see us next time when maybe we’ll be a touch more consistent. Thanks for listening.
