Bringing AI Into The Inner Loop of Data Engineering With Ascend

WEBVTT
NOTE
Transcription provided by Podhome.fm
Created: 03/24/2025 00:32:55
Duration: 3166.888
Channels: 1
1
00:00:11.280 --> 00:00:15.460
Hello, and welcome to the Data Engineering Podcast, the show about modern data management.
2
00:00:16.155 --> 00:00:22.654
Data migrations are brutal. They drag on for months, sometimes years, burning through resources and crushing team morale.
3
00:00:23.355 --> 00:00:26.654
DataFold's AI powered migration agent changes all that.
4
00:00:26.955 --> 00:00:35.360
Their unique combination of AI code translation and automated data validation has helped companies complete migrations up to 10 times faster than manual approaches.
5
00:00:35.900 --> 00:00:40.239
And they're so confident in their solution, they'll actually guarantee your timeline in writing.
6
00:00:40.700 --> 00:00:46.415
Ready to turn your year long migration into weeks? Visit dataengineeringpodcast.com/datafolds
7
00:00:46.415 --> 00:00:47.555
today for the details.
8
00:00:48.095 --> 00:01:02.260
Your host is Tobias Macy, and today I'm welcoming back Sean Knapp to talk about how Ascend is how Ascend is incorporating AI into their platform to help you keep up with the rapid rate of change. So, Sean, for folks who haven't heard your past appearances, can you just give a quick introduction?
9
00:01:03.120 --> 00:01:12.340
Yeah. Happy to. Well, first and foremost, thanks for having me back. It's always fun to to get a chat about data together. Quick way of introduction, I'm the founder CEO at Ascend.io.
10
00:01:12.515 --> 00:01:14.115
Started my career twenty years ago,
11
00:01:14.435 --> 00:01:14.935
accidentally
12
00:01:15.235 --> 00:01:29.000
doing data engineering back at Google. I led the web search front end team. And when you play around with the web search user experience, you move around a bunch of pixels, and you pose a lot of theories, and then you process a lot of data to see what actually happened. And so that was really how I got into data.
13
00:01:29.300 --> 00:01:31.460
Started a company back in 02/2007,
14
00:01:31.460 --> 00:01:32.520
built that up to
15
00:01:32.979 --> 00:01:34.680
about four to 500 people.
16
00:01:35.060 --> 00:01:36.280
We had over,
17
00:01:36.820 --> 00:01:39.000
60 people in our data product,
18
00:01:39.300 --> 00:01:44.174
team and got really excited about data, and that eventually took me here to Ascend.
19
00:01:44.795 --> 00:01:46.415
And for folks who haven't,
20
00:01:46.875 --> 00:01:55.530
come in contact with your work yet, can you give a bit of an overview about what Ascend is and maybe some of the story behind how you got to where you are today?
21
00:01:56.490 --> 00:02:04.909
Yeah. Happy to. So Ascend provides an automation platform for data engineering teams. We focus really hard on taking the
22
00:02:05.450 --> 00:02:06.270
both repeatable
23
00:02:06.570 --> 00:02:14.055
parts of data engineering, a lot of the the toil and the the rote work, as well as a lot of the sort of harder parts around going from
24
00:02:14.355 --> 00:02:19.335
simple basic data pipeline to far more complex, large scale, large complexity data pipelines.
25
00:02:19.635 --> 00:02:27.079
And we look to help productize a lot of that experience and help automate a lot more of it, both through advanced layers of automation, but now, obviously,
26
00:02:27.459 --> 00:02:31.159
given these days, a lot of, help around AI as well,
27
00:02:31.700 --> 00:02:34.920
that makes the life of the data engineer actually delightful.
28
00:02:35.220 --> 00:03:05.820
The last time we spoke, I don't think we talked too deeply about Ascend specifically, but it was in August of twenty twenty two, and I'll link to the episode for folks who want to listen back to that. But that happens to have been kind of right at the precipice of the current era that we're in right now where generative AI has sucked all the oxygen out of the room for everybody. And I'm wondering if you can talk to some of the notable ways that your platform and the ways that you think about the problems that you're solving have changed in that space
29
00:03:06.125 --> 00:03:14.625
and the role that AI plays in the data ecosystem for people who are just trying to keep their business running and empower them with data?
30
00:03:15.724 --> 00:03:18.224
Yeah. So a lot has changed
31
00:03:18.605 --> 00:03:19.105
clearly
32
00:03:19.610 --> 00:03:33.150
in the last two and a half years, and it's actually you know, when we last spoke, I think it was just right before so much really had had dropped into the space. And, you know, I think when we look at data teams, first, it it you know, that old saying where,
33
00:03:33.605 --> 00:03:39.545
the cobbler's children have no shoes. It it feels oftentimes like this where data teams themselves,
34
00:03:40.005 --> 00:03:42.505
while powering such incredible experiences
35
00:03:42.885 --> 00:03:44.905
for their consumers, their their companies,
36
00:03:45.460 --> 00:04:02.465
oftentimes get some of the weakest tooling and the weakest capabilities to actually make their lives easier as well. And so I think what, you know, what we've seen over the last couple of years is a tremendous excitement around AI, especially as it pertains to the software engineering realm, a tremendous amount of interest in more data
37
00:04:02.765 --> 00:04:03.584
to drive
38
00:04:03.965 --> 00:04:05.504
really powerful experiences,
39
00:04:05.885 --> 00:04:20.920
but we haven't seen yet a lot of, I think, really interesting investments that just make the life of the data engineer easier, more delightful themselves. And I think we're we're on the cusp of some really cool new innovations there that will change that much for the better. ChatGPT
40
00:04:21.300 --> 00:04:27.880
was the, I guess, shot heard around the world, if you will, in the AI space where for the first time,
41
00:04:28.420 --> 00:04:29.720
generally, AI
42
00:04:30.194 --> 00:04:30.694
broke
43
00:04:31.155 --> 00:04:39.094
from something that nerds talked about and speculated about and worked on to something that everybody was exposed to and incorporating into their daily lives
44
00:04:39.474 --> 00:05:05.825
because of the fact that it was available as an API in a web interface in a manner that didn't suck, frankly. Yeah. Since that time, there has been a lot of evolution in the capabilities of those AI as a service, as well as the open ecosystem of models, as well as the ways the AI is incorporated into different tools and technologies that we all use every day. For developers, it has taken the form of things like Copilot and some of these other language model assistants that live in your editor.
45
00:05:06.525 --> 00:05:16.210
For people who are content creators, it's in the form of things like Grammarly or Gemini in your Google Docs where it can correct your grammar, generate content for you, etcetera.
46
00:05:16.670 --> 00:05:17.970
In the data space,
47
00:05:18.510 --> 00:05:27.970
there are different tools that you can use to bring to bear where maybe you feed your schema of all of your database tables to an AI model so that you can use that to propose
48
00:05:28.395 --> 00:05:32.014
a dimensional structure that will incorporate all of that information.
49
00:05:32.475 --> 00:05:59.765
But it still feels like there's a lot of friction to actually getting the data that you need to the thing that you need to make the decisions for you. Different platforms are trying to make that more native. The Snowflake folks, Databricks, you know, they're obviously very invested in making AI a native part of their experience, but I'm wondering what you see as some of the most impactful areas for the application of AI to the work that data teams are doing and the ways that they can
50
00:06:00.145 --> 00:06:05.525
accelerate the pace at which they're able to iterate, their own problems and the problems of their organization?
51
00:06:05.825 --> 00:06:14.485
Yeah. I think that's a great question. First thing I would say is data engineering has yet to have its own chat GPT moment. I think the industry as a whole
52
00:06:14.819 --> 00:06:16.039
is applying
53
00:06:16.419 --> 00:06:18.599
what are the earlier stages
54
00:06:18.900 --> 00:06:21.000
of innovation, but we haven't had that incredible
55
00:06:21.620 --> 00:06:29.639
moment yet for data engineering. And by that, I mean, you know, when you saw ChatGPT, it was sort of this moment. When, you know, you first use
56
00:06:30.155 --> 00:06:36.175
Copilot or Cursor as a software engineer. That's a, wow. This is is really changing
57
00:06:36.635 --> 00:06:38.575
how I work. I think
58
00:06:38.955 --> 00:06:42.255
the prevailing sentiment to date that we've seen
59
00:06:42.730 --> 00:06:44.190
when it comes to data engineering,
60
00:06:44.650 --> 00:06:48.990
around and the assistance of AI in data engineering has kind of been this,
61
00:06:50.010 --> 00:06:55.070
that helps a little bit. It's kinda nice. I'll take it. But it's not this mind blowing
62
00:06:55.610 --> 00:06:56.430
game changing
63
00:06:56.730 --> 00:07:10.884
experience yet. And I'll dive into, I think, a little bit of why we're at that. I think what we're going to see is the early stages, and we're starting to see that. I think, you know, we're seeing that from an integrated chat perspective in
64
00:07:11.240 --> 00:07:12.620
both Databricks and Snowflake's,
65
00:07:13.080 --> 00:07:15.420
experiences. I think we're going to see,
66
00:07:16.200 --> 00:07:48.270
others also start to innovate a lot on, well, if I can get my entire catalog, can you then help me define a model that will, you know, generate a bunch of new data or will actually take into account everything out of my schema and help me generate new datasets. But when I think about where that tends to sit, that's going to be further downstream closer to the analytics engineer workload. What we haven't seen yet is what I would describe as, you know, either the cursor for data engineering or even the Devon for data engineering experience.
67
00:07:48.650 --> 00:07:52.590
And I think of that as something that plays a far more proactive
68
00:07:53.130 --> 00:08:25.655
role in the actual data engineering life cycle itself. The way that I like to think about this is in a few layers. You know, the baseline parts from a cursor, for example, is look. It it's doesn't even have to write entirely new applications for you. Cursor is quite delightful as a software and engineering experience because it just completes your thoughts really, really, really darn well. And its composer capabilities are incredible and amazing, but we we we don't even have that yet, I think, from a data engineering perspective. Once we get that, I think we'll then start to get into more of pipeline development
69
00:08:26.115 --> 00:08:37.830
and architecture and design and even optimization. The other thing I think we'll start to see in data engineering is because data engineering is not just a write code, test it, ship it, but it's a far deeper in observability,
70
00:08:38.210 --> 00:08:41.990
you want to scale it far greater across engineering orgs. We see a lot of interest
71
00:08:42.770 --> 00:08:47.270
in allowing data engineers to even write their own bots and their own agents
72
00:08:47.730 --> 00:08:50.630
to do specific actions and take specific activities
73
00:08:51.144 --> 00:09:31.035
on their behalf as part of that data engineering life cycle. Now if I kind of hit one last point, I think, that's really important to this as well is, you know, why haven't we seen this yet? I think it's harder in the data world. In the software world, we're writing software, but in data, we're writing software, and it's being applied to to the data in in a really interesting way where most of the tooling, most of the architectures that we see from folks, even though they actually touch and process data, they tend to actually not keep track of a lot of that data. They tend not to keep track of the metadata long term. They tend not to keep really close tabs of what code was run on what piece of data, what was the historical performance over time, who made that change to code, when was it deployed,
74
00:09:31.335 --> 00:09:33.910
what was the semantic change that happened
75
00:09:34.210 --> 00:09:39.270
to that that new data operation? And so because of there isn't that unified metadata and understanding,
76
00:09:39.810 --> 00:09:54.785
it's hard to create a data engineering agent or set of agents or utilities, if you will. Right now, we're seeing software engineering agents or tools just being exposed into the data engineering role. I think that's will be the next big step functions if we can actually create that combination
77
00:09:55.085 --> 00:10:03.800
of data and software combined. And I think too that one of the reasons that data engineering has not caught up to where software engineering
78
00:10:04.180 --> 00:11:00.855
is in the adoption of AI or the capabilities that it offers is that we never got to a point where the development environment caught up with where software engineering was because of the fact that it needs to be so close to the data and so aware of that data to be able to do that development and testing work. So there have been lots of efforts, especially over the past five years, to try and close that gap, but we never quite got there. And now AI is causing that gap to widen again because development is pulling ahead of where data engineering left off, and so we're we're still playing catch up in that regard of we don't have all of the wires connected to be able to say, on my local laptop, I can do all of these things and have confidence that whatever I'm changing is the right thing because I have to actually test it in production and see what breaks and then go back and try again where which is where we never quite figured out what is the pre prod for data engineering
79
00:11:01.389 --> 00:11:01.889
for
80
00:11:02.190 --> 00:11:34.130
the entirety of the actual workflow where we have bits and pieces of it of the copy and write tables in Snowflake or the versioning and branching capabilities. And things like Iceberg brings in CI for your orchestration system, but then there's still all the missing wiring to make sure that that ties into all of the copy on rate tables, etcetera. So you can get to a point where you sort of have that, but it requires a lot of effort that, at the end of the day, has no actual impact on the problem that you're trying to solve for the business. You're just trying to solve your own problems so that you can get to that point, and you don't necessarily
81
00:11:34.510 --> 00:11:44.115
have enough time and leeway to do all of that engineering effort to solve your own problems to help you move faster. Yeah. I I agree. I think, you know, this might have been one of the
82
00:11:44.435 --> 00:11:56.935
unfortunate and accidental side effects of the modern data stack in many ways, which was we had so many different tools and we're and that were propelling us forward. We didn't get enough time for that to really bake and settle for everybody.
83
00:11:57.315 --> 00:12:14.830
And, you know, I was chatting with a bunch of folks yesterday about this, which was so much of the team's time was spent integrating and trying to actually integrate at a metadata layer as well, but nobody completed that job. And as a result, there was this rapid change in what you could do where you didn't have to use these verticalized,
84
00:12:15.735 --> 00:12:16.475
tightly integrated,
85
00:12:17.015 --> 00:12:23.515
tools, and you could use more modern day, capabilities. But as part of that, you had to do your own integrations.
86
00:12:24.135 --> 00:12:25.915
And when we think about
87
00:12:26.295 --> 00:12:31.920
where a lot of the advancements come from AI is are in these more tightly coupled systems because
88
00:12:32.300 --> 00:12:44.140
AI, you get this exponential effect from just the the power and capabilities of those those models, the more data they can have access to and and the the more purvey that the system itself has access to. And so I think that's why the
89
00:12:44.885 --> 00:12:48.665
it's changing so fast. It's becoming very hard for for teams to to keep
90
00:12:48.965 --> 00:12:50.985
up. The other piece of this too is
91
00:12:51.525 --> 00:13:05.540
that the introduction of AI, not even just in terms of the data engineering workflow, but at the organizational level is that all of these businesses are now hurrying to build their own AI based products or incorporate AI into their existing offerings,
92
00:13:06.080 --> 00:13:09.300
which forces these data teams to try and leapfrog
93
00:13:09.920 --> 00:13:20.365
the data maturity cycle of, I just barely got my business intelligence system set up, and now I have to be an AI expert. I never even got through the machine learning, build your own model cycle.
94
00:13:20.824 --> 00:13:31.540
And so we're trying to, you know, race so far ahead of our skis that we don't even really know where we're going or, you know, overdriving our headlights as it were. And so I'm curious
95
00:13:31.920 --> 00:13:32.420
how
96
00:13:32.800 --> 00:13:52.775
the capabilities of AI as an accelerator to the work that we are doing can maybe allow us to catch up to the point where we're actually driving at a reasonable pace so that we can actually see where we're going rather than just racing through the dark and hoping that we don't see somebody coming around the next corner or whatever, however you wanna stretch that metaphor.
97
00:13:53.350 --> 00:14:20.615
Yeah. Totally. Well, I so I think it you know, we are gonna see AI help in a number of ways. The, you know, what I would call code and data aware development environments, we are going to see a a pretty significant surge in. At least, I hope so. I mean, clearly, these are these are things that, obviously, we're working really hard on and and building very quickly at Ascend for that reason. And and so I think that will be the the very baseline level is, does your system understand what you're working on from both dimensions
98
00:14:20.980 --> 00:14:23.640
to accelerate? I think we're going to get
99
00:14:24.020 --> 00:14:33.160
additionally a lot of assistance in this classic shift left or move upstream model where we can help more people self serve. We can help more people democratize
100
00:14:33.540 --> 00:14:34.280
their access
101
00:14:34.595 --> 00:14:35.175
to increasingly
102
00:14:35.475 --> 00:14:40.135
complex use cases where, you know, oftentimes we would try and solve these problems
103
00:14:40.595 --> 00:14:48.135
with basically no code interfaces. And I think GenAI is a really powerful alternative to no code interfaces
104
00:14:48.675 --> 00:15:16.084
as it helps bridge the gap where you can use Gen AI to generate code. Business analyst could actually use that, and an engineer could still actually understand and be comfortable working in the same platform if it boils down to to actual code itself. And so I think that will start to change a lot. I think then we're going to also see a lot more AI is we still see teams massively saddled with a huge amount of maintenance burden, on legacy systems.
105
00:15:16.385 --> 00:15:17.480
It's one of the
106
00:15:18.019 --> 00:15:32.199
primary draws on Teams time based on on our annual surveys that we do. And one of the challenges we see from most teams is I would love to either have AI manage this for me and make smarter decisions around how we just maintain
107
00:15:32.805 --> 00:15:38.905
existing systems? Or even better yet, can I get AI to help migrate that off of this old
108
00:15:39.445 --> 00:15:45.385
clunky legacy stack and actually get it into a modern architecture so I can run a a unified,
109
00:15:45.830 --> 00:15:53.610
approach again? I think that's where we'll start to see some pretty powerful lift that will get data engineers out of this just crappy toil,
110
00:15:53.990 --> 00:15:55.850
of of maintaining old systems.
111
00:15:56.390 --> 00:15:57.610
I think another
112
00:15:58.310 --> 00:16:04.945
barrier for data teams to the wholesale adoption of AI is the consideration
113
00:16:05.325 --> 00:16:06.225
around governance
114
00:16:06.685 --> 00:16:16.570
and data access control where you don't want to give unfettered access to some proprietary model or some third party company to be able
115
00:16:17.029 --> 00:16:19.050
to operate across your data with impunity
116
00:16:19.670 --> 00:16:35.455
because it has so many risks associated with it. And so then you're left trying to say, okay. Well, how do I either run my own model? Or I just can't do it, so I just have to continue with the status quo where with the software example, the software itself is typically
117
00:16:36.155 --> 00:16:39.720
much less regulated, and there are fewer risks involved with it.
118
00:16:40.120 --> 00:16:43.420
And a lot of the companies that do have their
119
00:16:43.800 --> 00:16:48.939
AI focused code assistance already have some capabilities in place to say,
120
00:16:49.240 --> 00:17:04.885
this is never going to be used in our training data, or this is being run in some sort of gated fashion so that your private repository is not ever going to be leaked or trained upon, etcetera. And so I'm curious how you're seeing the adoption of AI
121
00:17:05.530 --> 00:17:07.950
in terms of the deployment and incorporation
122
00:17:09.130 --> 00:17:15.630
of our people just saying, whatever. I'll just go ahead and use OpenAI or Anthropic. Are they running their own models in
123
00:17:16.010 --> 00:17:18.990
Bedrock or self hosting it on VLLM or whatever,
124
00:17:19.290 --> 00:17:21.424
and some of the ways that they're thinking about
125
00:17:21.885 --> 00:17:28.205
what model capabilities they even need to be able to get their work done where maybe they don't need the 400,000,000,000
126
00:17:28.205 --> 00:17:30.845
parameter model. They just need the 14,000,000,000
127
00:17:30.845 --> 00:17:34.559
or whatever it is. Really great question. You know, we see a
128
00:17:34.860 --> 00:17:36.160
pretty wide range
129
00:17:36.780 --> 00:17:38.400
of, let's call it, readiness
130
00:17:38.780 --> 00:17:39.280
and
131
00:17:39.660 --> 00:17:40.640
hardened thinking,
132
00:17:41.340 --> 00:17:41.840
across
133
00:17:42.140 --> 00:17:55.105
our our customer base and across those we just interact with in the industry as well when it comes to AI. There's a number of companies that we'll talk to where we've been asked, are you allowed to use generative AI solutions in your development experience?
134
00:17:55.804 --> 00:18:11.590
And we still get answers from from some folks where they they don't know. And there's no mandate that they should or that they shouldn't, but the company hasn't decided yet, which I'd say is more rare, but that's on the the sort of extreme trail end. Where we see with a lot of enterprises
135
00:18:12.370 --> 00:18:14.655
nowadays and a lot of more mature teams
136
00:18:15.615 --> 00:18:17.875
is, I'd say, pretty stringent
137
00:18:18.255 --> 00:18:20.915
policies, but not overly restrictive.
138
00:18:21.295 --> 00:18:24.915
And where they tend to focus pretty intensely is
139
00:18:25.215 --> 00:18:37.570
you've picked your cloud or you've picked your data cloud, and you generally stick to that. So if you run if you're an Azure shop, you're fine with OpenAI as long as it's hosted on Azure. If you are a Snowflake customer,
140
00:18:38.030 --> 00:18:46.795
and this is a huge value prop for, Snowflake customers is you have access to a ton of models. And as they they just recently announced,
141
00:18:47.415 --> 00:18:55.110
even OpenAI models soon as part of your Snowflake environment. And I think that's what we're seeing is the sheer demand
142
00:18:55.570 --> 00:18:59.510
for access to to these generative models ends up being
143
00:19:00.049 --> 00:19:00.870
so compelling
144
00:19:01.250 --> 00:19:12.215
that both the platform providers as well as are racing to at least get it within some sort of governed walls. And at the same time, companies are willing to, even with some of that ambiguity,
145
00:19:12.755 --> 00:19:21.095
press forward because they know there's so much value. And so that's what we're seeing is the if I can at least stay within my data governed walls,
146
00:19:21.600 --> 00:19:27.460
so to speak, where most companies tend to sit. And in terms of your own
147
00:19:27.840 --> 00:19:31.299
work of integrating AI into the
148
00:19:31.760 --> 00:19:32.980
platform capabilities,
149
00:19:33.440 --> 00:19:49.905
what are some of the ways that having it natively offered in the substrate versus as a bolt on changes the ways that you think about what it can do, how it can do, and what it should do, and then also some of the ways that that enables your customers to
150
00:19:50.290 --> 00:20:08.174
reduce some of the busy work that they would otherwise be engaging in? Yeah. Great question. You know, the a couple of fold. You know, one is, hey. Look. When when something goes bump in the middle of the night, something broke and you wanna figure out what went wrong. What classically can be a multi hour triage
151
00:20:08.875 --> 00:20:22.280
of when did the last deployment go out? What was the, set of of changes that went out as, code changes as part of that? What was the state of data before? What's the state of the of data now? Do I have to actually replay or recover or
152
00:20:22.580 --> 00:20:31.080
somehow fix and repair the the underlying data? Is it safe to revert? Is it not? All those kinds of questions, generally, as a data engineer, would require
153
00:20:31.620 --> 00:20:37.160
your your Git history on one screen, a bunch of your observability tools on another, looking into your Snowflake or Databricks
154
00:20:37.515 --> 00:20:38.015
ecosystem
155
00:20:38.315 --> 00:20:41.775
on yet another screen and trying to deep dive. But the reality is
156
00:20:42.315 --> 00:21:12.294
if you can actually have agents that actually have full access to your Git understand the entire run history for all time, for all of your data pipelines, They know what changed, who changed it, and when did that go live. All of those kinds of and and they can also look at the data if you've allowed it to to do so. That entire recommendation remediation step can largely be alleviated by an agent to at least make your life a heck of a lot easier. They're not gonna take over, I think, in the control seat anytime soon.
157
00:21:12.755 --> 00:21:20.280
But the you know, imagine it is sort of the equivalent of, you know, for those who play with the deep deep research capabilities coming out of a a bunch of the
158
00:21:20.840 --> 00:21:38.755
the AI providers. Imagine you had your own triage report ready to go by the time, you know, you've gotten, you know, the pager duty alert and you got up in front of your monitor and you could just digest all that information. Life would be a lot easier. So I think there's things like that that are really, compelling and helpful. I think in more of the day to day experience
159
00:21:39.135 --> 00:21:42.995
where this becomes really exciting is, why do I even have to search a catalog?
160
00:21:43.295 --> 00:21:48.835
Like, why do I have to remember the table names? Can't I just describe more of what I want to actually
161
00:21:49.190 --> 00:21:52.730
do? Can I get a the intelligence of a cursor like experience,
162
00:21:53.110 --> 00:22:12.075
but that is actually aware of all the data that I have access to and can start to suggest things that I should do? Or even better yet, if I'm writing a data pipeline, wouldn't it be amazing if I could also have it suggest, hey. Are there smart partitioning strategies to keep my compute cost down? Are there, data quality checks I should be running continuously on my datasets
163
00:22:12.615 --> 00:22:30.850
based on the nature of the data that's already available to me that I can see? Those are the kinds of things that, as an engineer, I I shouldn't have to spend time on in this day and age, and we should be able to actually have AI offload huge amounts of that workload before. And in terms of the engineering effort of actually operationalizing
164
00:22:31.710 --> 00:22:45.375
AI and incorporating it and and embedding it in your platform, what are some of the challenges that you had to address, some of the ways that you had to restructure the core of the system to be able to feed the necessary information
165
00:22:45.835 --> 00:23:02.150
as well as the overall architecture of the AI system itself, whether it's just a straight chat based or tool calling or agentic and just some of the ways that you iterated on that problem space as well as you started to incorporate it into the the core of your functionality?
166
00:23:02.825 --> 00:23:05.485
Yeah. Great question. You know, for us, this has been
167
00:23:05.945 --> 00:23:08.125
a now a year long investment
168
00:23:08.425 --> 00:23:09.245
in rearchitecting
169
00:23:09.785 --> 00:23:22.250
from the core out. And one of the things we've done at Ascend is we've actually rebuilt the platform for the AI era. I think it's very hard to take an entire architecture that's been baked for
170
00:23:22.630 --> 00:23:33.525
five, ten years, even a few years, and say, you know what? We're gonna try and, like, weave AI back into the core. I I think that's very challenging. I think that's where we're going to see a lot of, companies in the space
171
00:23:33.825 --> 00:23:43.650
really struggle because they weren't architect and design with that to begin with. And what I mean by that is, you know, as part of our new architecture and design at Ascend,
172
00:23:44.030 --> 00:23:53.490
we store everything. And we actually store it away from our cloud hosted environment. We actually store, for example, all get history we have, access to for our agents,
173
00:23:54.025 --> 00:23:56.205
all metadata access, which is literally
174
00:23:56.505 --> 00:23:59.245
everything that's ever been run, the performance characteristics,
175
00:23:59.705 --> 00:24:07.005
the git SHA that was run, the SHA of the code that was run so we can detect changes over time. And that across every developer
176
00:24:07.305 --> 00:24:07.805
workspace,
177
00:24:08.260 --> 00:24:31.625
across every deployment of the environment, across dev to stage to prod. And by tracking all that and making that data available to a model, it becomes incredibly powerful. And then what we've ended up doing is as part of this entire unified metadata core, we keep full history of that in the underlying, big data, systems, whether it's Snowflake, Databricks, BigQuery, you name it. And then at the same time, we put it all on a real time event bus
178
00:24:32.005 --> 00:24:44.350
so that, the system can take real time actions on it as well. And so by combining both the the streaming nature to to do instantaneous activity, but the full historical nature and feeding that into the the agents
179
00:24:44.730 --> 00:24:51.630
creates a huge amount of power and capability for us. Digging now into the technical architecture that you've settled on,
180
00:24:52.015 --> 00:24:52.515
obviously,
181
00:24:53.294 --> 00:24:53.794
AI
182
00:24:54.174 --> 00:25:03.315
inference can be a very expensive proposition. I can't imagine that you're just saying, we'll just throw up an AI at it. And so I'm wondering how you worked through some of that experimentation
183
00:25:03.855 --> 00:25:04.515
and validation
184
00:25:04.895 --> 00:25:12.320
of what are the actual runtime operating costs. How do we build up the operational maturity around actually having to own this capability,
185
00:25:12.780 --> 00:25:27.855
and some of the ways that you thought about the size of the model that you needed, the inference costs, and the the compute necessary, and what you settled on as far as whether you run it yourself, rely on the cloud provider, rely on, one of these third party GPU clouds, etcetera?
186
00:25:28.395 --> 00:25:58.644
So we've definitely decided to to rely on the cloud providers. And the primary driver behind this is is actually related to what we were talking about before, which is most companies we interact with have generally decided on a camp. I'm a Google camp, which means I'm going to use BigQuery and Cloud Pak for my data processing and storage, and I want to use Gemini for my models. Or I'm running on AWS, and I wanna use, maybe at some point in the future, s three tables and a bunch of glue capabilities,
187
00:25:59.105 --> 00:26:02.460
and I wanna use Claude on Bedrock, for example.
188
00:26:02.840 --> 00:26:09.500
Or I'm on Snowflake, and, similarly, I wanna use the anthropic models and use all of the the amazing sort of cataloging and capabilities
189
00:26:09.880 --> 00:26:15.180
with, Snowpark and and native, Snowflake SQL. And so what we see is
190
00:26:16.015 --> 00:26:17.795
across those different camps
191
00:26:18.335 --> 00:26:24.515
that there's a a strong draw towards keep me in these walls, and and then it's very smooth sailing from a capabilities
192
00:26:24.895 --> 00:26:32.650
perspective. What that means from the Ascend perspective is we've taken much more of a how would we from an architectural perspective, how would we design
193
00:26:33.030 --> 00:26:34.090
sort of a Kubernetes
194
00:26:34.390 --> 00:26:39.770
for data engineering from a platform perspective. And so when we think about that from an architectural
195
00:26:40.150 --> 00:26:40.650
perspective,
196
00:26:41.335 --> 00:26:42.075
we separate
197
00:26:42.535 --> 00:26:51.835
out where you store your code, which becomes highly configurable. Then we separate out, where do you actually store your data, and we separate that from where do you store your metadata,
198
00:26:52.455 --> 00:26:56.419
all historical operations, which usually ends up being the similar underlying,
199
00:26:56.799 --> 00:27:04.019
data platform, but in a fully isolated, far more secure location. Then as we start to build up on top of that, a lot of our design is
200
00:27:04.320 --> 00:27:07.380
to be model agnostic. So you may be running,
201
00:27:08.080 --> 00:27:12.245
Snowflake on Azure, and you wanna use OpenAI for your models,
202
00:27:12.625 --> 00:27:14.085
and for your agents. Whereas,
203
00:27:15.024 --> 00:27:22.565
conversely, you may be running in Databricks and wanna use some native, Databricks hosted models. And so we we try and keep very agnostic
204
00:27:22.865 --> 00:27:31.950
around what underlying models we support because we wanna be able to tap into the ones that are closest to the data. Then what we build on top are is our
205
00:27:32.330 --> 00:27:33.790
tooling and agentic,
206
00:27:34.170 --> 00:27:34.990
layer itself.
207
00:27:35.370 --> 00:27:41.825
One of the really important things we've learned over the course of the last year is there's no one architecture and no one
208
00:27:42.205 --> 00:27:47.185
structure to to rule them all. So, for example, our chat interface is a a multi agent
209
00:27:47.485 --> 00:27:53.190
model that has multiple experts that are really good at writing SQL verse,
210
00:27:53.590 --> 00:27:58.570
generating, YAML definitions versus writing Python. And each one has access to
211
00:27:58.950 --> 00:28:00.889
different parts of our documentation repository
212
00:28:01.350 --> 00:28:32.010
and rich sets of examples, so they they can really help you. And, of course, access to all of your own code. And that becomes really different than if I wanna create my own agents as a user of Ascend. The structure that we create behind that is very different than a structure for our chat and what we a a chat agent. And that's what we found is we've been trying to break it into each one of these sort of constituent elements and then expose through different agentic architectures and different sets of tools all of the underlying components that you would need to deliver different activities.
213
00:28:32.630 --> 00:28:33.130
And
214
00:28:33.445 --> 00:28:34.825
in terms of the actual
215
00:28:35.205 --> 00:28:37.545
models themselves, feeding them the appropriate
216
00:28:37.845 --> 00:28:58.790
data, have you found it most useful to go with the RAG based approach? Are you able to just inject directly into the prompt the context that you need? Are you investing in more fine tuning capabilities to be able to optimize the the model capabilities and the functionality? Just some of the ways that you think about the optimization and evolution of your capabilities.
217
00:28:59.410 --> 00:29:02.685
Yeah. Great question. We've, to date, primarily focused
218
00:29:03.305 --> 00:29:04.925
on RAG and prompt injection.
219
00:29:05.305 --> 00:29:07.085
The reason we've done that is
220
00:29:07.545 --> 00:29:10.125
the when we generally look at the
221
00:29:10.665 --> 00:29:19.210
volume of data, distinct of the volume of context that you would put in. While there's some benefits to fine tuning, that gets much harder when,
222
00:29:19.669 --> 00:29:32.125
customers are wanting to bring their own moments. If we start to fine tune, then we have to to focus on fine tuning across the various providers. And we've given the nature of the problems we see in data engineering,
223
00:29:32.665 --> 00:29:38.605
the data itself isn't that large by comparison. The amount of code you have in your in your repository
224
00:29:39.065 --> 00:29:48.150
in a a sort of tighter declarative architecture, it's not so large that you can't be highly effective with large amounts of RAG and prompt injection.
225
00:29:48.530 --> 00:30:05.695
And what we focused really hard on is making our models, our agents, very, very good at doing reg and calling tools to get access to more of that data, and that's been really quite successful. Now I will say too the one of the really cool parts about building these tools for data engineering
226
00:30:06.075 --> 00:30:06.575
teams
227
00:30:07.034 --> 00:30:10.280
is data engineering is such a valuable role
228
00:30:10.660 --> 00:30:11.240
and profession
229
00:30:11.780 --> 00:30:17.480
that we don't have to tackle problems that a consumer tech company would have to solve, which is
230
00:30:17.780 --> 00:30:20.760
we don't really worry about the cost per invocation
231
00:30:21.540 --> 00:30:52.320
or the cost per token in the same way. We care about some of the response time speed, but when you're trying to help a data engineer that's such a re a a resource constrained or such a tapped resource in the tea in a team and is so so valuable, it's really easy to justify throwing the largest, most expensive model so there's so long as they can respond quickly to provide the best experience to the the user. And so we find that we just don't have to spend as much time in the data engineering side of the house trying to tune and refine smaller models that you wouldn't necessarily have to do if you're running,
232
00:30:52.985 --> 00:30:56.765
either things locally or that you if you were trying to run things, at a consumer
233
00:30:57.305 --> 00:30:59.165
scale. Now in terms of the
234
00:30:59.705 --> 00:31:00.205
capabilities
235
00:31:00.665 --> 00:31:02.285
that it offers to your customers
236
00:31:02.745 --> 00:31:07.170
now that they actually have AI as part of their inner loop of development,
237
00:31:08.130 --> 00:31:10.310
what are some of the ways that it changes the
238
00:31:10.690 --> 00:31:28.495
types of work that they do, the way that they approach the work, maybe the volume of work that they're able to complete, and just some of the ways that it shifts their overall thinking about the work that needs to be done and how to approach it? Net effect is obviously you know, hopefully, people can produce a lot more. And I think, you know, more importantly, though, is
239
00:31:29.115 --> 00:31:32.815
where teams can spend their time. The you know, what
240
00:31:33.195 --> 00:31:47.770
we really are starting to see and and really hope that the whole industry will help deliver on too. But where we see is far less time should be spent on documenting and testing, though debatable how much teams truly do because that's usually the first thing that gets cut in a pinch.
241
00:31:48.150 --> 00:31:57.784
But everything from development times should be much lower. One of the other really big things we see that we see wild variability across teams is even code review processes.
242
00:31:58.164 --> 00:32:05.020
Platform code hygiene itself across teams varies quite wildly. All of these things should largely disappear.
243
00:32:05.320 --> 00:32:07.260
We should see incredible consistency
244
00:32:07.640 --> 00:32:24.925
across teams and and far more efficiently. So, yeah, I think the you know, if if you use SonarCloud or other kinds of of similar software that analyze the quality of your code, we expect to see dramatic increases in code quality across customer bases, where we'll see greater levels of consistency,
245
00:32:25.305 --> 00:32:28.685
greater levels of reusability, higher testability, higher documentation.
246
00:32:29.385 --> 00:32:37.669
And these are the kinds of things that I I think AI will will be knocking out faster than anything else, which I think is incredibly valuable, especially in
247
00:32:38.210 --> 00:32:39.830
large, large teams where there's,
248
00:32:40.530 --> 00:32:41.990
hundreds of developers
249
00:32:42.370 --> 00:32:43.429
on these platforms.
250
00:32:43.970 --> 00:32:47.190
That guaranteed level of consistency and durability then
251
00:32:47.745 --> 00:32:56.885
helps new members of those teams ramp up faster, be effective quickly, pays into a very virtuous cycle. So those are a couple of areas I think in in a very immediate
252
00:32:57.265 --> 00:33:00.390
term are are really powerful benefits that we're that we're seeing.
253
00:33:00.790 --> 00:33:02.010
On the documentation
254
00:33:02.870 --> 00:33:04.010
side too,
255
00:33:04.630 --> 00:33:07.690
one of the aspects of that typically feeds into
256
00:33:08.310 --> 00:33:10.090
governance and understanding
257
00:33:10.390 --> 00:33:18.095
what is this field. And once I know what this field is, then I can have a better and more informed decision about how it can and should be used.
258
00:33:18.475 --> 00:33:22.095
There's long been automation available for doing,
259
00:33:23.115 --> 00:33:26.655
profiling and sampling of your data, doing automatic PII tagging.
260
00:33:27.115 --> 00:33:29.360
What are some of the ways that
261
00:33:29.660 --> 00:33:30.320
the AI capabilities
262
00:33:30.940 --> 00:33:34.240
and the fact that you can auto generate some of this documentation
263
00:33:34.700 --> 00:33:37.200
that is typically left to the wayside
264
00:33:37.900 --> 00:33:40.800
improves the visibility and effectiveness
265
00:33:41.260 --> 00:33:41.760
and
266
00:33:42.225 --> 00:33:45.365
strategies around governance as that data becomes
267
00:33:45.825 --> 00:33:47.445
more of a conversational
268
00:33:47.745 --> 00:33:55.045
interface and less of a, well, let me just go through this spreadsheet. And after about the 15 flying, my eyes glaze over, and I'm not paying attention anymore.
269
00:33:56.980 --> 00:33:59.960
Yeah. I mean, honestly, every time I cut a PR for
270
00:34:00.260 --> 00:34:03.720
some sort of emerge off of a data pipeline, we should have AI
271
00:34:04.100 --> 00:34:08.745
re updating all of my documentation for me. There there's no reason we shouldn't. In many ways,
272
00:34:09.065 --> 00:34:14.125
and this is even a a development practice we we have internally at Ascend, we have what we call pre PRs.
273
00:34:14.585 --> 00:34:24.125
And part of the goal of the pre PR is document the things that you're actually planning on doing. You know, what is it? Why does it matter? What's the customer impact? And we try and get a
274
00:34:24.609 --> 00:34:26.390
a detailed enough pre PR
275
00:34:26.770 --> 00:34:27.510
such that
276
00:34:27.810 --> 00:34:37.305
anybody who's dropping in could even check and be like, hey. By the way, have you thought about x, or, you know, could I help you with y? What I would love to see is not just the post
277
00:34:37.605 --> 00:34:38.985
PR, update all my documentation,
278
00:34:39.445 --> 00:35:09.655
do all these other things, but I would love to see a model where whether it's through a chat interface or an actual, you know, draft pre PR, if we could get teams able to describe here's what I want to do, here's what I'm thinking about doing, And oftentimes, it's hard to get an engineer to do that into a chat prompt, actually. But if it was just a simple markdown file describing your thought process before you got started, not only is it an amazing ability for other members of the team to help and contribute some of the thinking, But that's where we should be able to see AI
279
00:35:09.955 --> 00:35:14.375
be able to actually go and tap into, hey. Here's all the data that's in the catalog.
280
00:35:15.075 --> 00:35:26.869
Here's the things that you probably would wanna look into that could really help you. And here's even some drafted updated models or brand new models that you could, leverage. And I think the if we can get into that sort of a practice
281
00:35:27.410 --> 00:35:28.470
as data teams,
282
00:35:29.089 --> 00:35:29.589
the
283
00:35:30.210 --> 00:35:32.950
ease with which we should be able to build becomes
284
00:35:33.345 --> 00:35:33.845
pretty
285
00:35:34.385 --> 00:35:34.885
significant.
286
00:35:35.185 --> 00:35:38.244
On the junior versus senior, another
287
00:35:39.025 --> 00:35:40.645
aspect of AI
288
00:35:41.025 --> 00:35:41.845
is that
289
00:35:42.145 --> 00:35:50.100
for for both sides of that coin, the AI can serve as a stand in for the other. So as a junior, having an AI right there
290
00:35:50.640 --> 00:35:56.900
can be your infinitely patient senior developer who has all of the context and history available to them.
291
00:35:57.200 --> 00:36:05.315
And for the senior engineer, the AI can act as the stand in to the junior developer that you have to explain things to that helps you understand the problem more effectively.
292
00:36:05.855 --> 00:36:06.355
And
293
00:36:06.655 --> 00:36:15.020
often, the challenge is getting both of those participants to actually engage with an AI as part of their standard flow. I'm wondering how you're seeing that
294
00:36:15.400 --> 00:36:15.900
reticence
295
00:36:16.280 --> 00:36:34.735
manifest in the teams that you're working with of no. Just talk to it. Yes. It might be stupid or you might not understand it, but it's worth just engaging with it because this is a skill that you're going to need to develop and be able to feel comfortable with as it becomes more prevalent and part of absolutely everything in our lives going forward.
296
00:36:35.115 --> 00:36:43.695
Mhmm. Mhmm. So I think you you highlight something that's that's really interesting too, which is look. Like, was it probably a year and a half ago I gave this presentation,
297
00:36:44.250 --> 00:36:48.030
to the the company, which was none of our jobs will exist
298
00:36:48.330 --> 00:37:00.865
in twelve to eighteen months as they do today. Like, we we all have to rethink this. And it's very akin to you know, we always have talked about digital native and digital non native companies, and the non natives had to go through their transformation.
299
00:37:01.165 --> 00:37:10.145
Yet pretty much every company in existence today, minus a handful of very early startups, is an AI non native company, and we all have to go through this transformation
300
00:37:10.685 --> 00:37:12.089
together. But the difference is,
301
00:37:12.950 --> 00:37:15.849
well, Moore's law has actually driven a pretty
302
00:37:16.550 --> 00:37:26.310
slow growth rate by in by comparison. We always thought Moore's law was was, you know, fast compounded growth rate. But when we look at the computational power of AI, it's growing 13.3
303
00:37:26.310 --> 00:37:36.355
x year over year and has been for the last, decade. Looks like it's probably going to grow 13.3 x year over year for the next decade as well. It's basically like taking
304
00:37:36.815 --> 00:37:41.635
all of the change we've seen since the launch of the iPhone back in, I think, 02/2007
305
00:37:41.950 --> 00:37:51.010
to today from a a software perspective, computationally, at least, and saying, hey. All of that change is going to be possible and probably gonna happen in the next two to three years
306
00:37:51.310 --> 00:37:56.305
instead of, you know, the last eighteen years. I hope everybody's ready for this. And
307
00:37:56.765 --> 00:38:35.995
the the reason why we went through that conversation is I put up this this very funny GIF, which we have a very strong, like, GIF culture in in the company, and it was of this movie Shazam where there's, like, you know, teenage high school kid. He has spinesy superpowers. And he's like, ah, this is great. I have superpowers, but I don't even know how to go pee in my my super suit. And it's like, yeah. It's kinda like the awkward stage where all of us have these superpowers in AI and some things it does amazingly well and some things it is just absolutely terrible at, and we're left so disappointed. And I think the reason why that becomes so important is the just because you're disappointed in it today, which will happen often with AI, it is
308
00:38:36.375 --> 00:38:36.875
improving
309
00:38:37.255 --> 00:38:37.755
and
310
00:38:38.200 --> 00:38:40.780
accelerating at such just this unprecedented
311
00:38:41.160 --> 00:39:00.234
rate that you gotta stay on top of it because saying, ah, that being yeah. I tried that last quarter and it sucked. This quarter is probably gonna be pretty darn awesome. And then you'll hit a new threshold where it's gonna really disappoint you. But, like, figuring out where those boundaries and those parameters are, I think it's really, really important to stay on top of. Because if you don't,
312
00:39:00.615 --> 00:39:14.840
how much you're going to miss out and how far behind from a skill set perspective you are of just intuitively knowing, ah, if I craft a prompt this way or I craft a prompt that way, which I would also contend is probably pretty in line with how you should talk to another
313
00:39:15.140 --> 00:39:16.280
engineer around
314
00:39:16.660 --> 00:39:18.040
consistent and clear communication.
315
00:39:18.515 --> 00:39:20.215
If we don't learn that that model,
316
00:39:20.515 --> 00:39:32.295
you're just you run the risk of falling behind. And I think the the world needs more really great data engineers solving really hard problems. And so we don't want anybody to get left behind on this on this journey.
317
00:39:32.720 --> 00:39:39.220
Absolutely. And I have been reading the book Co Intelligence recently, which is a very accessible
318
00:39:39.839 --> 00:39:40.720
book by,
319
00:39:41.119 --> 00:39:48.585
a non computer scientist academic talking about the impact of AI on everyone's work and lives. And one of the quotes
320
00:39:48.885 --> 00:39:54.505
that I think was noteworthy was assume that whatever AI you're using today is the worst one you will ever use.
321
00:39:54.965 --> 00:40:07.680
Yeah. Totally. It's getting better so much faster. I mean, and and remember when it was chat GPT first came out, we also got GPT three five, and it seemed like magic. And now we look back, and it seems so basic by comparison.
322
00:40:08.060 --> 00:40:10.880
It's the how quickly we've sort of been readjusted
323
00:40:11.180 --> 00:40:11.680
to
324
00:40:11.980 --> 00:40:13.040
the new capabilities.
325
00:40:13.580 --> 00:40:14.400
In many ways,
326
00:40:14.700 --> 00:40:26.664
I feel bad because we're all just given this, like, magic. Like, it's almost freaking magic. And somebody just showed us this amazing thing. It's like, look at how cool this is. And we're all like, yeah. But what have you done for me lately? And we're getting
327
00:40:26.964 --> 00:40:28.904
drops of amazing new innovation
328
00:40:29.285 --> 00:40:30.505
on a monthly basis
329
00:40:30.869 --> 00:40:37.289
right now. And so I think that's the really cool part is they are just getting better and better and better. You know?
330
00:40:37.750 --> 00:40:41.130
The the moment o three came out, we were playing with it extensively,
331
00:40:41.509 --> 00:40:44.170
especially from an engineering perspective. And
332
00:40:44.565 --> 00:40:53.305
already, like, the, you know, the we've been testing out a ton on on the o three mini models and their ability to generate incredible output for incredibly complex
333
00:40:53.765 --> 00:40:57.785
data problems far greater than what we were seeing with four o and and even,
334
00:40:58.580 --> 00:41:03.800
to cloud three five. Three seven's looking great as well. But it's just, like, every month better and better and better.
335
00:41:04.100 --> 00:41:06.760
And as you have been incorporating
336
00:41:07.060 --> 00:41:10.040
these AI capabilities, you went through this whole replatforming
337
00:41:10.580 --> 00:41:19.215
to bring AI to the center of your offerings. What are some of the most interesting or innovative or unexpected ways that you've seen that combination applied by your customers?
338
00:41:19.835 --> 00:41:21.115
Good question. The
339
00:41:21.515 --> 00:41:22.895
I'd say for our customers,
340
00:41:23.195 --> 00:41:24.495
it's more around
341
00:41:24.875 --> 00:41:25.615
their productivity.
342
00:41:26.075 --> 00:41:28.015
The customers of creating
343
00:41:28.635 --> 00:41:29.370
AI products,
344
00:41:29.850 --> 00:41:31.070
I think it's still
345
00:41:31.450 --> 00:41:38.110
trailing a bit for a lot of especially big enterprise teams. They're so battling with how do I get out of a ton of legacy
346
00:41:38.410 --> 00:41:42.830
challenges, and they're trying to figure out how do they get their teams off of Informatica,
347
00:41:43.290 --> 00:41:44.825
off of traditional
348
00:41:45.125 --> 00:41:45.625
SSIS
349
00:41:46.244 --> 00:42:06.470
and other more traditional systems, or even how do they simplify down there and make more production grade their modern data stack investments. And so I think that's where the sort of true reality for a lot of, at least, enterprise data teams is still battling to get their head above water, you know, as we were talking about before. And in your own efforts of going through this replatforming,
350
00:42:07.010 --> 00:42:07.510
reengineering,
351
00:42:08.050 --> 00:42:08.550
understanding
352
00:42:09.090 --> 00:42:15.994
the utility of AI in the context of Ascend, what are some of the most interesting or unexpected or challenging lessons that you learned?
353
00:42:16.535 --> 00:42:19.515
I I think the the most important one
354
00:42:19.895 --> 00:42:25.355
was, you know, for us, this really big bet of you do have to rethink all of the assumptions.
355
00:42:25.655 --> 00:42:39.690
Without rethinking the those assumptions, I I don't I don't think we we would have got to the sort of incredible platform we have today. And that was a big bet because you have to to take a step back and say, hey. Look. Like, we're not gonna process data the way we did before. We're not gonna store metadata
356
00:42:40.150 --> 00:42:41.210
the way we did before.
357
00:42:41.510 --> 00:42:47.665
And when you'll even put in hard remits around some of the crazy things we did early on where we're not allowed to have a database
358
00:42:48.045 --> 00:42:51.345
of our own. We have to store data in the customer's environments
359
00:42:51.725 --> 00:43:11.760
so that the agents have access to it, which people throw all sorts of concerns when you do something like that, which sounds like that's crazy from a classic SaaS distributed systems architecture. You're talking crazy talk. But when you put it against the backdrop of the automated engines and the AI agents have to have access to everything, and we have to be able to run all of these inside of a customer's
360
00:43:12.165 --> 00:43:19.465
environment, all of a sudden, it starts to make a a lot more sense given those parameters. And I think when we think about trying to do that
361
00:43:19.765 --> 00:43:30.060
from any of the classic architectures, you're just you're fundamentally hamstrung. For people who are interested in the experience that you're offering of AI at the center,
362
00:43:30.360 --> 00:43:35.100
automate away all of my toil, what are the cases where Ascend is the wrong choice?
363
00:43:35.880 --> 00:43:45.925
Good question. If you like writing a lot of code, we're probably not your jam. And I say that jokingly, but there's definitely places where, you know, we encounter teams oftentimes who
364
00:43:46.225 --> 00:43:48.405
really want more of a a software experience
365
00:43:48.785 --> 00:44:11.325
that they want to do more imperative style work versus declarative systems. And there's always some of that push and pull or give and take between, an automated system that you can do things in a tenth as much code, but you have to relinquish some of the automation into the the underlying system so it can take care of those things for you. And what we oftentimes find are if you do like writing a bunch of code or you do want
366
00:44:11.625 --> 00:44:14.125
really specific ways, that are nonstandard
367
00:44:14.585 --> 00:44:23.020
with where a lot of the industry and sort of best practices have evolved, if you really wanna do those things, Ascent gives you escape hatches to do those kinds of things. But at that point,
368
00:44:23.320 --> 00:44:45.295
you might be better off with just a generic code orchestrated by an airflow, for example. And that and that may be okay for for other use cases. And so we do try and and, you know, be really transparent to folks about, hey. We are a really advanced automation and and AI backed system. If you want less code, you want the system to take more of the toil for it for you, that's great. But it it comes with those trade offs. As you were mentioning, Airflow,
369
00:44:45.675 --> 00:44:46.175
etcetera,
370
00:44:46.555 --> 00:44:47.935
it made me also think
371
00:44:48.250 --> 00:44:50.270
in the act of replatforming,
372
00:44:50.730 --> 00:44:57.550
I know that at least in your initial formulation of Ascend, you were very invested in the Spark and Airflow
373
00:44:57.930 --> 00:44:59.470
combination of that ecosystem.
374
00:45:00.090 --> 00:45:01.470
How has this replatforming
375
00:45:01.930 --> 00:45:03.385
and the centering
376
00:45:04.005 --> 00:45:09.944
around AI changed the ways that you think about what tools you can bring off the shelf versus what you have to build custom?
377
00:45:10.405 --> 00:45:22.700
Yeah. The, we have this joke internally where, you know, we try and embrace this mantra of, look, if for whatever the task or the job is today, if we could just swipe a credit card or PIP install something, we would be so delighted.
378
00:45:23.080 --> 00:45:32.575
And the default approach is not just, hey. What exists today? And let's avoid that that that classic engineering, what what I like to call accidental ransomware,
379
00:45:33.115 --> 00:45:41.855
trap, which is, oh, but I could build it better. This thing's missing that that feature. Like, I could just build it better. And and the question we always try and ask is, well, what's the trajectory
380
00:45:42.400 --> 00:45:58.485
of that thing? Is the industry going to standardize on it? And how much time and energy is it gonna take? And is it really gonna differentiate us that much? And let's be really pragmatic about it. And what we've, you know, really come to to learn is, look, we like this Kubernetes for data architecture
381
00:45:58.785 --> 00:46:21.010
where we think about, look, you have a a data plane. You know, these are sort of atomic units. Like, it stores data. It processes data. It generally carries a catalog with it. It maybe it's gonna toss in iceberg tables or delta lake tables, but it's going to take care of that for you just like you have code storage somewhere, just like you have metadata storage somewhere. And so what we did with this architecture was try and go very agnostic
382
00:46:21.310 --> 00:46:25.090
from a you're gonna have your data processing in one of the hyperscalers
383
00:46:25.390 --> 00:46:26.930
or one of the data clouds,
384
00:46:27.285 --> 00:46:43.400
and you're going to similarly have your code in one of the really popular repositories. You're similarly going to use one of the the mega models. And for us, what we decided was let's be not opinionated about that from a platform perspective and instead be opinionated at the data engineering
385
00:46:43.780 --> 00:46:48.040
side of, hey. What do good pipelines look like? They're combinations
386
00:46:48.740 --> 00:46:51.640
of Python and SQL and generic tasks, and
387
00:46:52.045 --> 00:46:56.225
they sometimes materialize data, and they sometimes don't materialize data. They sometimes
388
00:46:56.605 --> 00:46:59.025
are incremental, and they're sometimes hyper partitioned.
389
00:46:59.565 --> 00:47:07.105
Sometimes it's transactional data. Sometimes it's mutable data. And when we took that step back and just looked at that data engineering life cycle,
390
00:47:07.430 --> 00:47:50.675
the the end factor of how many things there really are isn't that high. And if you can really intelligently support those, that's where you can streamline a lot of the the data engineering experience. And then let people plug in the parts that they want. And if you let's say the last piece is for those platform teams that support a lot of the data engineers and the analytics engineers, the key sort of final part of that is give them this tremendous ability to extend and customize those behaviors, just like what we've seen in in the Kubernetes world. If you do that, it it it really can can meet a lot of those really compelling needs from the platform team to the data engine team to the analytics engine team, even off to the data ops or, you know, support team depending on on on how you cluster that.
391
00:47:51.055 --> 00:47:52.595
As you continue to
392
00:47:53.055 --> 00:47:55.715
build and iterate on the Ascend platform,
393
00:47:56.015 --> 00:48:03.155
the AI capabilities that you are centering around, what are some of the things you have planned for the near to medium term or any particular
394
00:48:03.750 --> 00:48:10.230
trends or capabilities that you're keeping an eye on? A few fold. One of the things that we're really excited about is,
395
00:48:10.710 --> 00:48:15.050
we want the platform team and the architect team well, any user, but we anticipate
396
00:48:15.350 --> 00:48:36.140
more platform and architects. We want them to be able to write their own agents that operate inside of the Ascend environment. So, I mean, how many times for, you know, for you as, you know, a senior member of the team are like, I keep having to review all of these pull requests. I have the same feedback every single time. Couldn't I just delegate this to at least a first pass or a second pass? Or,
397
00:48:36.680 --> 00:48:40.860
every time I get paged for memory pressure on a device,
398
00:48:41.320 --> 00:48:56.535
or on a node, couldn't I try these two remediations first beforehand? And until we we really want to not just provide what Ascend envisions as really powerful AI capabilities, but for these teams that are working, collaborate together on data, wouldn't it be amazing if they could actually write their own? That we think it's super super,
399
00:48:56.935 --> 00:49:01.275
coiling exciting. The other thing that we're paying a lot of attention to right now is
400
00:49:01.660 --> 00:49:10.800
the surge on the reasoning models. That starts to get really interesting for a few reasons. While they're slower, so they're not as good in a chat based experience oftentimes,
401
00:49:11.180 --> 00:49:14.880
that that will solve too. The things that we used to have to have a multi agent
402
00:49:22.225 --> 00:49:22.725
complex
403
00:49:23.585 --> 00:49:25.765
set of steps, things you would do asynchronously
404
00:49:26.465 --> 00:49:47.605
or in more of a devon style workflow, which is, hey. Try these things. Get a feedback loop. Did the did this data pipeline compile? Like, does the flow actually run? Does it actually produce the data that I expect it to? That starts to get really, really interesting. And where I think this really becomes compelling is we have so many customers that are deeply, deeply interested in migrating
405
00:49:47.985 --> 00:49:58.005
legacy workflows to Ascend. But at the same time, that is expensive to grab a bunch of bodies to say, look at this old Informatica data pipeline, or look at this old SSIS
406
00:49:58.440 --> 00:50:00.619
pipeline and put it onto a modern architecture.
407
00:50:00.920 --> 00:50:32.309
It still takes human time to go do so. And the just sheer volume of demand we see to be able to take that and say, you know what? If you can get agents to do eighty, ninety, even 95% of that work for me, that becomes economically compelling in a way that it wasn't when I had to think about throwing dozens, if not hundreds of developers for a year at at this migration problem. And so I think that's where we're gonna see a huge amount of of shift in the market. Are there any other aspects of the work that you're doing at Ascend, the ways that you're incorporating
408
00:50:32.609 --> 00:50:43.155
AI into the experience or the overall impact of these AI models on the data engineering workflow that we didn't discuss yet that you would like to cover before we close out the show? Good question.
409
00:50:43.535 --> 00:50:44.355
Nothing public,
410
00:50:44.815 --> 00:50:48.755
I would say. But I will say, for sure, I think it's gonna be a very,
411
00:50:49.215 --> 00:50:50.115
very exciting,
412
00:50:50.655 --> 00:51:09.140
next couple of years in the data engineering world, especially for those who can bring AI to this unification of data and software. I I think we're gonna see our mantra internally as make data engineering delightful. I think as an industry, we may finally get to the point where data engineering is is a consistently
413
00:51:09.440 --> 00:51:10.580
delightful experience.
414
00:51:11.165 --> 00:51:59.740
Alright. Well, for anybody who wants to get in touch with you and follow along with the work that you and your team are doing, I'll have you add your preferred contact information to the show notes. And as the final question, I'd like to get your perspective on what you see as the current biggest gap in the tooling or technology that's available for data management today. The biggest gap is the tooling's not intelligent. Not just on the AI side, but I need too many tools to do too many straightforward things. There's too much repeatable process. I want my tooling to be smarter. Absolutely. Well, thank you very much for taking the time today to join me and share the work that you're doing at Ascend, the lessons that you've learned, and how you've approached this challenge of bringing AI into the fold as it were. So appreciate all the time and energy that that you're putting into making data engineers' lives easier, and I hope enjoy the rest of your day. Thank you so much, Tobias. Really enjoyed it.
415
00:52:06.895 --> 00:52:09.954
Thank you for listening, and don't forget to check out our other shows.
416
00:52:10.255 --> 00:52:11.214
Podcast.net
417
00:52:11.214 --> 00:52:20.115
covers the Python language, its community, and the innovative ways it is being used, and the AI Engineering Podcast is your guide to the fast moving world of building AI systems.
418
00:52:20.850 --> 00:52:31.010
Visit the site to subscribe to the show, sign up for the mailing list, and read the show notes. And if you've learned something or tried out a project from the show, then tell us about it. Email hosts@dataengineeringpodcast.com
419
00:52:31.010 --> 00:52:36.825
with your story. Just to help other people find the show, please leave a review on Apple Podcasts and tell your friends
420
00:52:37.205 --> 00:52:37.705
and
421
00:52:40.645 --> 00:52:41.145
coworkers.