Transcript#
This transcript was generated automatically and may contain errors.
Welcome to The Test Set. Here we talk with some of the brightest thinkers and tinkerers in statistical analysis, scientific computing, and machine learning. Digging into what makes them tick, plus the insights, experiments, and OMG moments that shape the field.
Michael's traveling at the moment, so you're stuck with a producer's voiceover this week. On this episode, The Test Set crew jams with Caitlin Colgrove, CTO and co-founder of HEX, the data platform that somehow counts a sweet green head chef among its power users. Caitlin joins Michael, Hadley, and Isabel to make the case that data teams aren't going anywhere. But right now, their job is changing from writing SQL to vouching for the answers.
Caitlin, welcome to The Test Set. Thank you. Thanks for coming on. Just by way of introduction, you're Caitlin Colgrove, the CTO of HEX. And I'm Michael Chow. I'm the host of The Test Set. And I'm joined by Hadley Wickham, chief scientist at Posit, and Isabel, software engineer extraordinaire at Posit. And we're so excited to have you on.
What is Hex?
I feel like HEX is everywhere today, and I'm constantly trying to explain to people what HEX is and why they should use it. I know HEX is included in cloud.ai now. Maybe do you mind just explaining a little bit about what HEX is and what it does?
Yeah, totally. HEX started when we started as founders. We were basically, we'd all left Palantir and we're kind of out in the world looking at how people were working with data. And what we discovered was that there were a lot of new patterns for working with data that were emerging. People were a lot more technical. There was a lot less clicking of buttons and a lot more writing of code, SQL, Python, all of that. And the tools out there were Jupyter notebooks. Those are very popular. This is 2019 or so. But in order to actually sort of string together a full enterprise data workflow, like to actually do something useful with your data, people would be doing these ad hoc analyses in Python, SQL, do a SQL in a notebook. You still had to do the backticks. It was like really not native.
And then that was in a notebook and it was a locally running notebook with your own Python environment. And okay, so maybe you do this whole analysis and what are you going to do? Are you going to email that notebook to the CFO? That, you can't do that. So they would take these notebooks and they would, okay, they're like, okay, we're going to turn it into a Python script and then we're going to run the Python script on a schedule on AWS. And then we're going to dump the output into Looker so that the CFO can look at it in Looker so that they can take a screenshot of the chart and put it in the board deck. And that was the workflow. And so Hex was really born of this idea that there just has to be a better way, that there needs to be first-class tooling for this new era of data work. And that was the original product that we built. And then obviously like, you know, in the past couple of years, AI has become a huge part of that. And I think even though some of the technology has changed, the underlying story is still true. It's people who are working with day in and day out. What are their workflows? What are the best tools for them? And Hex should be that.
The Anthropic integration and agentic workflows
Yeah, so I think this is one of the big ways that work is changing. Pre-AI, you basically had these big heavyweight vertical SaaS tools. And depending on what you wanted to do, you would navigate to HubSpot or you would navigate to Salesforce or you would navigate to Hex because you're like, I want to do something with my marketing data. I want to do data science, data analysis. And that would be where you would start.
Today, everybody just starts by like asking Claude or ChatGPT a question. And we've actually had some really, really interesting conversations with the Anthropic team and the OpenAI teams about how they're seeing the changing and sort of the emergence of these new workflows. And they really view a lot of these chat applications as a front door. They're not going to go and build a first class data science agent or a first class customer service agent or all of these things. They want to be the platforms on which those things run. But still today, it's very sticky, these habits of just ask your question to Claude.
And so what Anthropic released, and ChatGPT has sort of its own version as well, is this plugin architecture. And it's based on MCP, as you might imagine, but they've enhanced that with more UX around it. So now if you hook up your MCP to Claude, you actually get a interactive Hex experience in Claude. And Claude, you know, the models are actually smart enough to know how to route. So if you go and you have Hex wired up as your sort of data science backend, and you ask a question, Claude knows that the Hex plugin is the plugin to use to answer that. And so it'll actually go and it'll go kick off sort of a sub-agent architecture where it kicks off an agent in Hex, which will go look at all your data. It'll go look at all your semantic models. It'll do all this stuff and it'll come back. And it's actually really nice. You get to sort of see the thinking tokens. You can get an interactive set of charts back. And then if you really want to go deep, or you want to go build a dashboard, or you want to do something further, you can kind of click through into the underlying Hex project that it's been building up behind the scenes.
Confidently incorrect — AI's biggest problem in data work
We know that like models can be like pretty sycophantic. Like how much do you worry about like when you come in with a question and there's like a sort of an answer that like you want to hear? And then like, you know, do you worry about you kind of accidentally steering the model in that direction that just reinforces like what you want to hear?
Yeah, I think, I think that's actually one of the bigger problems, like model behavior is one of the bigger problems in sort of agentic AI for data science today. And it's a combination of that. It's, I think it's a less of the sycophancy side of things that we see, but we see a lot of confidently incorrect. So the models will, instead of doing what even a relatively junior data scientist would do, which is you start looking at the data, you start exploring, you get an answer, and then you check that answer. Maybe you look at some other, you know, sort of other sources to see if you can corroborate what you're seeing. Models don't do that at all. They find a table, they're like, ah, this table has a column that looks like it should be useful, and then they just go.
We see a lot of confidently incorrect. So the models will, instead of doing what even a relatively junior data scientist would do, which is you start looking at the data, you start exploring, you get an answer, and then you check that answer. Models don't do that at all. They find a table, they're like, ah, this table has a column that looks like it should be useful, and then they just go.
And so that's one thing that we're thinking a lot about is like how do we give the models, how do we push them to explore the space more? And how do we push them to sort of self-validate in, in a way that more likely will, because often, and you see this even with humans, right? If, if you start at different points in the data and there's different ways and different assumptions that you might make about how to answer a question, you can end up with just wildly different answers. And you kind of want to look at all of those and understand, okay, well, what's, what's the actual sort of truth here?
The models these days are very, they're, the reasoning steps are actually quite good and quite solid. And it, you know, if you rewind a couple of years and hallucinations and just like them not paying attention to the things that you want them to pay attention to are huge, huge problems. And even just keeping them on task. These days, I actually find that they're quite creative in taking the pieces of information that they have and putting them together into an answer. Like that's actually, it's actually like really impressive when you read their thinking traces, how much they're able to like hit a roadblock and overcome it and like cycle through that in order to get to an answer. Where I usually see the problems happening is, as I was saying before, in them having not sufficiently explored the space. And so they're very, very good at coming up with an answer based on what they have, but if they don't have all of the pieces that you need them to have, then that's where they'll, you know, that's where they'll kind of fall on their face.
So where we, what we're thinking about is that exploration phase. And you, and you see this in, in other modes too, like in coding, you have like a, kind of have like a plan and design phase and then an implementation phase. That's something that we're thinking about how we bake into our models where you don't necessarily just like start from the question and have them go at it. You actually kind of push them to look harder for things before they come back and start to actually then go and do the analysis.
The notebook, app mode, and how Hex works
Just to be sure, I'm, I'm going to try to paint in exquisite detail what it looks like to use Hex just because it's, it's such an interesting, cool experience. But I also think some people, when I talk to people, some people listening, I think might have trouble if you've never used Hex, like just conveying it that, and correct me for anything I get wrong. But if I understand, it's kind of like you have often like data in the warehouse and say like an analytics engineer, or some people have tried to transform and kind of curate what you need. And you might even be a person who doesn't do a ton of data analysis.
You know, you might be working in like finance or not, no shade on finance or like another area and essentially you go into this notebook that's wired up to your warehouse. And right now you're able to ask an agent essentially a question. And then what happens is it starts populating cells that run and produce outputs. And some of these outputs even are like filters. So it might be like a dropdown to select like something you're interested in, or to filter a company that you might want data on. And then essentially like you can adjust the filter and everything else in the notebook will kind of update. So you can sort of like build this notebook and explore your data at the same time. But then what I think is also interesting that I just want to make sure to mention is, if I understand you also have an app mode, is that right? Where you kind of shift from seeing the code in the notebook view to the app mode where the code sort of like goes away or is more hidden?
Yeah. Yeah. That's all totally correct. I think you can think about it in Hex as the backbone of the product is this notebook. That notebook actually under the hood is essentially a graph of transformation nodes that we can run behind the scenes. And then you can take that notebook, which we call project in Hex, and you can do a bunch of different things with it. So you can manipulate it with the agent. So the agent will actually like edit that graph. It will build up that graph. And you can do that, you know, just to do sort of some exploratory analysis. But often what you want and often, and this is actually one of the huge pain points that Hex was solving in the early days is, you know, data workflows don't end with getting a number. They end with making a business decision.
And so the way you get from, I have an answer from the data to we've actually decided to do something. There has to be sort of a collaboration and presentation and sharing step. And so what we've done with Hex, it used to be excruciatingly difficult to go from those analyses to that, you know, screenshotting charts into PowerPoint and things like that. And so what we've done is we've actually layered a presentation layer directly on top of the notebook. So it's exactly the same. And, you know, it's a typical more dashboard like experience, I would say. We call them apps because they can be more powerful under the hood than what you would expect from a traditional dashboard.
So Hex has the notebook and the notebook agent, which is really geared towards technical people. It's people who want to be in the code, even if the agent's writing it, they want to be looking at it and working with it. But there's a lot of people in the organization who don't want to look at the code, but also still want to be able to take advantage of the power of the Hex agent. And so what we have is we have our conversational agent, which we call threads. But under the hood, it's actually the same as the notebook agent. Yeah, it's a skin. But it's actually building up a notebook behind the scenes. And this is really, really powerful because it means that if you get to the end of this conversation and then you want to do something with it, maybe that thing is share it. Well, great. You're in a notebook. You can make the same types of dashboards, things like that, that you could before. Or maybe you're like, hey, I don't know if this is right. I actually want to send it to the data team to check my work. Well, the work's all there in the notebook behind the project.
Yeah, Hadley, I know you… In R, it's super different, right? Like the analysis, the kind of workflow versus a notebook where you're sort of like, this workflow is so great. Yeah, I think it's really interesting because the sort of heritage of R is this like REPL, this run, eval, print loop where you're in the console trying stuff out. And that's kind of your primary means of exploration and experimentation. And then as you discover things, you kind of believe to be true. Like that's when you record them into a script. And that's kind of what led to R Markdown and Quarto, which is like, you've written this mingling of prose and code, like much like a notebook, but you then you run the whole thing and that produces your output. And that has some like big advantages, like kind of pre-reactive notebooks, very easy in a Jupyter notebook to kind of get into this state where you've like run some cells in like different orders and there's no way to reproduce what you've done. Like no way to have that problem with R Markdown because you always run it from scratch.
And I mean, we kind of often joke in engineering, I guess, like, oh, that's a DAG. That's a directed acyclic graph. Like everything's, oh, that's an immutable DAG. That's a reactive DAG. Like, oh, wow. What a surprise. Like we've created a DAG and it turns out to be the right model. And sometimes so at, obviously the Hex notebook, as we've been talking about behind the scenes is DAG. And as the, as the cells within the notebook got more and more complicated, we started to realize that the cells themselves needed to be DAG. And so then you have DAGs and DAGs and DAGs, it's DAGs all the way down. And actually, you know, what is a DAG of DAGs? It's just a DAG.
Enabling non-technical users and organizational knowledge
Like one of the things I've sort of been, you know, thinking about like how, like as these, you know, people who never would have, you know, worked with data in this way before, cause they couldn't program like, and now they can because they can write in English. But, you know, there's a lot of like vocab and like ways of thinking about data that you don't, you, you don't have and you can't express in everyday English. Like how do we start to like train those people up to give them like the basic kind of like that kind of gut feel for like, I should be a little bit skeptical here or like, oh, what I, what I need right now is like a smoother or like I need to tidy data or how do you all think about that?
Yeah. So I think this is an unsolved problem broadly. And I actually think that this is one of the big breakthroughs broadly in terms of, um, uh, you know, AI for data and really enabling a much broader spectrum of people to work with data because yes, there's, you know, the actual, can you write code aspect of it? But if you look at sort of the prior generation of data tools, even ones where you don't have to write any code, people still don't use them. Like we talked to a Looker, uh, an ex Looker customer, another Hex customer. And they said, you know, they bought Looker for everybody. And in practice it was like, they looked at the last 90 days and only two people in the company had made like new dashboards in Looker. And when you like unpack that a little bit, it's just buttons, right? You don't have to write code. How hard can it be? It's actually that doing data work is just inherently very complex.
And so none of these tools code or otherwise, uh, more walkup usable. There was just too much foundational knowledge that you needed in order to be able to be effective in the tool. And so one of the big breakthroughs besides the, you know, LLM writing code bit is actually imbuing the agents with that knowledge. And today that's already a lot of what we're doing with the Hex agent is like teaching it, not just like, you know, how to write code, but you know, how to work with the data, you know, the, your tribal knowledge around the organization of what data is where all of those things you bake into the agents.
The other thing that we do in Hex that I think is very powerful, um, is the agents have access to not just the underlying data warehouse, but the other things that people are doing with the data. And so some of this is going to be garbage, just like, you know, people not knowing what they're doing, but, um, you know, you may have that company dashboard that gets looked at, you know, thousands of times a day or whatever. And that is actually a very rich source of context for the agent for how you should do something. And so when a user comes in, it's like, I want to know something about revenue. They may not know anything about how we actually calculate revenue, but that's actually encoded in various places in your data workspace that the agent, which is, yeah, which is because I mean, that's also how humans work, right? Often that's not documented. You have to go to another successful project and like copy and paste that code.
Context studio and managing agent quality
And, and this I think is one of the key sort of new jobs to be done for the data teams, if that makes sense. Um, and a big part of, of Hex that we haven't really talked about yet, but is relatively new, um, post agent is what we call the context studio, which is basically about observability and management of all of the context for all of the agents. And so you can see what people, you know, what the agents are actually doing for each thread. You can actually see what context the agent is using. And then we have a second, uh, sort of like a separate set of agentic workflows around managing the context around extracting the pieces out of these things. Um, and then putting that, feeding that back into the like highly trusted, highly governed context to kind of avoid this like spiraling problem of, you know, the agent just kind of deciding that that's the way to do something.
I'm really curious. I read recently that now more agents are deploying code on Hex than humans. Um, how do you manage as someone who obviously cares so much about their users and like is giving people such a beautiful suite of tools, like what are you making for agents versus what are you making for people nowadays?
Yeah, it's a really good question. I think in the early days of building the Hex agent, it was very clear that, um, the tools that we'd built for humans were actually also very good for agents. And so there was a lot of overlap. Um, you know, we had this modular notebook structure, looks a lot like tools that you can give to the agent. Um, and the agents just took to that very naturally. And that was like the first generation I would say, where it was pretty, pretty one-to-one. But now that we've had this sort of crossover moment, um, of more code is being written in Hex by agents than by people, you start to think about what that implies for the rest of the system. And you still have, you still want the human interfaces because there are still times where people are going to come in and tweak things. And, you know, it's, it's not, it's not fully, fully, um, be a natural language. Like sometimes typing a whole sentence is just a very inefficient way to do something that's, you know, as opposed to clicking a button.
But at the same time, knowing that over time, more and more of this is going to get produced by agents, it actually gives you a lot of opportunities to build things that are useful for agents, but less useful for humans, but are very powerful for the agents. And so, you know, one thing that we've thought about in HEX is, could we give the agents slightly different — all of our cells are built to be, you know, they're very sort of easy to inspect, you get a little preview, you get all of these nice UI features. Agents don't need that. And actually, they're quite expensive. So if an agent is building up a project, could you give it a slightly different set of tools that would have different characteristics? Maybe less data warehouse load, maybe it runs faster. Maybe it's just, honestly, sometimes agents like to work in a different way than humans. They've been trained on a certain distribution of data, and it's not exactly what our human brains have been trained on. And so I do think that there will be some divergence there.
Data teams aren't going anywhere
One of the things I really like about the context studio is it feels like HEX is sort of thinking, well, your job of what a data team or data science do is changing. This is going to be one of the things where you give value to your organization, as opposed to like there's also a lot of startups out there today, which their pitch is basically like buy us and fire your data team, which, you know, as a data scientist doesn't feel very nice.
Well, we were talking to a head of data, and he said something that was really interesting. And I think when you frame it in this way, it made it really clear to me why data teams are not going away. He said, my job is to vouch for the correctness of the data and the answer that you get. He's the head of the data team, and obviously that's a slightly different role than ICs on the data team. But when you frame it like that, you're like, oh, yeah, actually, in the abstract, when you don't have people clicking buttons, that is the job of the data team. The job of the data team is to make a system that produces correct answers. And today, a lot of that has to do with, instead of being the person who writes the SQL that is correct, it doesn't have bugs in it, how do you set up the context layer such that the agents can arrive there themselves?
He said, my job is to vouch for the correctness of the data and the answer that you get. The job of the data team is to make a system that produces correct answers.
I mean, the depressing thing is, definitely in corporate America, having the person to fire when something goes wrong is important. I mean, even more positively, someone has to own the stuff and be like, yeah, it's my reputation on the line that this is correct. You can't just distribute that to a bunch of nebulous agents that no one really understands.
But it does feel like data teams are going to get more unhinged analysis from execs. That's also going to have to be part of their job. Someone has done something that they think is really cool, and it is really cool that more people in the org are interacting directly with the data. But the consequence of that is more people are going to be making mistakes and the data team is going to have to walk them back. You see this in software engineering, like, you know, a CEO will come in and like, you know, use cursor or whatever to like vibe code some insane thing and then like make a pull request because like all the like traditional barriers to that happening. And then, you know, the engineers are kept to code and like review this thing. I do think you'll start to see a similar pattern like that in data where all of a sudden people have all of these really powerful tools at their fingertips and they don't know how to use them.
And I think there's a couple of things there. One is, you know, in HEX, we're thinking a lot about building review tools, both, you know, manual and also agent assisted review tools so that that process is as painless as possible. But I also think it's just another indication of, you know, where there will still be value. Like there are there are times where you actually want an expert to do the analysis. There's many, many ways to do the wrong things with statistics. And if you if you have a very important decision, there will still be a time and a place for people to kind of do those things and not just have someone, you know, fire off an agent query and and, you know, not not be able to really think critically about the result they're getting.
The blurring of roles and building engineering culture
I would say absolutely. But I think it's a little bit less dramatic at Hex than maybe at other places because our org has always kind of been designed like this, if that makes sense. Most of our PMs used to be technical, like actually hands-on technical in some capacity. All of our designers, we like give them an interview that's designed to be like, can you do light, you know, CSS and React work? Like we don't want people to just be completely boxed out of a core part of the technology. You know, our front end engineers and our backend engineers kind of flow back and forth. Everybody has their spikes, you know, it's not like we're expecting, you know, a backend engineer to be, you know, deep in React. But we don't want people to have these really hard boundaries because that can often create just like a lot of really annoying inefficiencies in the organization.
And I think there's a lot of hype around AI engineering and things like that. One thing that I've observed is sort of the lines between our AI engineering team and our data team really blurring and starting to overlap. And so, for example, a lot of things that we'll do internally for ourselves to build our own product and build our own agent, we'll build, you know, we have evals, we have various other things that we've built. You know, we will look at those and be like, oh, we should actually take those and put those into the product for our customers. Because these workflows of, you know, building a highly trusted agent actually, you know, converge over time.
Hex's style and brand
Hex has incredible style. Hex is just cool. I don't know how to explain, like, you go to the Hex website, and it's been like this for years and years and years, I feel like. The booths at conferences, unhinged. In a good way. Like a retro dining booth. Hex is throwing like magic shows. How did Hex acquire such immaculate style?
Well, I'm going to have to give some credit to some other people in the organization for that one. My co-founder, Barry, the second person we ever hired was Adam, our head of design. And I think, you know, those two have been kind of the masterminds. So Annie, our head of brand design, have been the masterminds of a lot of these things. So in some ways, it's down to specific individuals and having particular individuals who have these kind of off-the-wall takes. But I think also it's about the culture that you build as an organization and who you find and us trying to bring in people who are creative, who don't take themselves too seriously. And when you have some of those things, it creates an environment where you can be generative and think differently like this.
What success means as a co-founder
Yeah, I think starting a company has really forced me to like disentangle myself from classic indicators of success, if that makes sense. And there's a couple of reasons for that. One is you'll just drive yourself absolutely insane. You're like that company has how much revenue and they raised how much like you just like you just can't compare yourself. Like a lot of us, you know, come up through school. You're basically like ruthlessly, you know, trained to optimize this like one metric and like compare yourself against all the other people to get into. And like you just have to just let all of that go. Like you just have to let the numbers go and focus on, you know, what you can control.
And I think the other thing about being a co-founder that I found, I found that the hardest part about being a co-founder is that you are, you know, the job changes every six months. And so what that means is just as you're getting your feet under you, you have to do something different. And so you're always in this mode of like, I'm not good at the thing I'm supposed to be doing right now. I'm learning how to do this. And for someone who, you know, generally, you know, had a relatively successful career prior to that, you're like, you're used to operating in areas where you're good and you're strong.
And I think for me, I just kind of keep coming back to a couple of different things. One is, are we building something that, you know, is doing good for the world? That is a useful contribution. And then am I enjoying what I'm doing? Is this a good use of my time? And as long as I feel like those two things are happening, then I think that's like a pretty it's actually like it's quite rare to really be nailing both of those things. And so that's kind of how I've been thinking about my own personal career success.
Giving engineers permission to experiment
This is a pretty common piece of coaching that I give to engineers, which is, it's basically telling them, like giving them permission not to be miserable. They often, sometimes in engineering, sometimes again, sometimes you got to do what you got to do. You know, sometimes someone like we had an engineer who moved into an engineering manager role and was miserable. They hated it. And I was like, you can go back. Like we actually intentionally have set up our work structure such that like senior engineer and engineering manager are the same, no pay difference. They're just the same level, just a different title, different role.
And coaching people through their first moment of, I tried it and I didn't like it. And I didn't like make it all the way to something that feels like a success moment, but that's okay. I don't have to get there. If I'm really unhappy with what I'm doing, I can just stop. And that, especially like we've been talking about for people, high achievers that can feel like a failure because sometimes you're in a, you're in a spot where you're actually not doing a great job at the thing that you're supposed to be doing. And you feel like you have to push through to get to a point where like you've made it, but I don't know. We only, you only live once, right? Like, you know what you do with your time matters.
This is a pretty common piece of coaching that I give to engineers, which is, it's basically telling them, like giving them permission not to be miserable.
I think that like mindset shift between like this experiment failed versus I'm a failure. Like that's a really, really big difference. And to coach an engineer on that, that like jumping from to being an engineering manager is a similar like experiment as starting a company. Does it make sense for that person? And now that we've had, we've had this happen in various parts of the organization a couple of times now. And again, it creates this permission structure for people to just try things. And that obviously has like huge positive externalities when people are like less afraid to go out on a limb and try something new.
Unwinding with Soulsborne games
I mean, we do a lot of the normal stuff. I also have a toddler, so not everything is unwinding. Yeah, yeah, yeah. Winding in different ways. Once he's in bed, though, actually my husband and I have been, we've been playing through together all of the Soulsborne games, which might be a little bit weird for an unwind session, but it's like, it's a really good way to like, you know, release some tension, you know? We like, I hadn't played them before, but like, I got started with Elden Ring, and then we like, played all the way through Elden Ring. And then the rule is, when you die, you pass the controller. So you get a little bit of a break. Like, you die, you pass it, and then you get another turn.
Yeah, I will say he is much better at sort of like, learning the timing of the boss mechanics. So he's typically like, he's gonna be a little better than that. I tend to be a little bit better at the like, mobs, because I'm less reckless than he is. He just like, charges in and just get like, totally annihilated. And I'm a little more strategic in how I like, do the placement of the, yeah.
We actually stopped playing real co-op games together because they got too intense. And we were like, or it's just like, we've just different play styles. Again, like his is very like, you know, just like rush straight at it. And mine's a little bit like, more sort of like, careful exploratory. And so we were getting really mad at each other. Like we tried to play Baldur's Gate co-op together and just like, that did not go well. And so I actually think that this model works a lot better. Like one person is in control at any given time.
Caitlin, really appreciate you coming on the test set. Thank you so much for having me. Yeah, no, it's been great. I feel like so much to think about. I honestly, I hate to admit it, but I feel like I have to. I hadn't learned about Context Studio, but it is going to live rent-free in my head for the next probably all my life. We'll hook you up.
It's honestly like this moment in some ways is like a match made in heaven for data people for this workflow, because this is the workflow that data teams have been doing forever, but it's just been so painful and laborious for relatively little impact. Like if you think, or I mean, obviously there's impact, but like the amount of impact you get out of like all of this labor just sometimes doesn't feel worth it. Like, I don't know if you all remember, or I'm sure you remember like when semantic models first kind of became a thing, we just didn't see a ton of adoption of semantic models. And it wasn't because people didn't want them, it was just because it was so painful and took so much time to build them out. And at the end it's like, okay, yeah, only two people are going to be building your dashboards, right? And now today that's like totally been inverted. Not only can you take constructs like semantic models and make them available to everybody in the organization in a way they can use, but actually also you can do the curation and you can do the governance much, much more easily with sort of agents yourself. It is a pretty incredible that like it's both the cost has decreased dramatically and the impact has increased dramatically. Like it's pretty unusual to get both of those at the same time. It's pretty cool.
The Test Set is a production of Posit PBC, an open source and enterprise tooling data science software company. This episode was produced in collaboration with creative studio Adji. For more episodes, visit thetestset.co or find us on your favorite podcast platform.