Age of Agents | Data Brew | Episode 41

Summary

AI agents vs copilots: The episode explores how AI agents are moving beyond code completion to autonomously build applications and democratize coding across the industry.
Development challenges: Key obstacles include error handling, debugging silent failures, and ensuring software quality in autonomous agentic systems.
2025 outlook: The conversation highlights why 2025 is positioned as the critical year for mainstream AI agent adoption and the transformation of software development.

Age of Agents | Data Brew | Episode 41

In this episode, Michele Catasta, President of Replit, explores how AI-driven agents are transforming software development by making coding more accessible and automating application creation.
Highlights include:

The difference between AI agents and copilots in software development.
How AI is democratizing coding, enabling non-programmers to build applications.
Challenges in AI agent development, including error handling and software quality.
The growing role of AI in entrepreneurship and business automation.
Why 2025 could be the year of AI agents and what’s next for the industry.

Connect with Michele Catasta

Chapters

FAQs

What's the difference between AI agents and copilots?

AI agents autonomously build entire applications from specifications, while copilots assist with code completion. This video explores how agents like Replit's are moving beyond assistance to full automation, fundamentally changing how we think about software development.

How is AI democratizing software development?

By enabling non-programmers to build applications through natural language instructions, AI agents are expanding the pool of software creators from less than 1% to potentially hundreds of millions, transforming who can participate in coding.

What are the main challenges in building reliable AI agents?

Error handling, debugging silent failures, ensuring software quality, and managing tool integration are critical obstacles. The video discusses best practices for building agents that work consistently in production.

Why is 2025 the year of AI agents?

The episode explores convergence of advanced models, improved reliability techniques, and growing enterprise adoption, positioning 2025 as the inflection point for mainstream agentic AI deployment.

Full transcript

`0:00` Introduction to Data Brew

Welcome to Data Brew uh by Databricks with and. The series allows us to explore various topics in the data and AI community. Whether we're talking about data engineering or data science, we're going to interview subject matter experts to dive deeper into these topics. And while we're at it, we're enjoying our morning brew. , and I'm a principal developer advocate here at Databricks and one half of Data Brew. And hello, I'm, director of the machine learning practice at Databricks and the other half of Data Brew.
And today I am thrilled to introduce Michele Catasta, president of Replit, to join us today. And for those of you who haven't used Replit, it is a programmer's best friend to accelerate innovation. Tell the Replit agent to build your app or website idea, and it will take care of it automatically for you. So, welcome. Hi, everyone. I should have had a mug with me today to match the brew. Or a little espresso cup. Yeah.
A little espresso cup. That would work fine. Yeah, yeah. Exactly. Next time. No worries. Well, thank you again for joining us. No, we have to record now. We record now. Forget Don't let me start talking. So, to kick it off, uh very famous VC once said, "Software is eating the world, but now AI is going to eat software." And so, the vast majority of the world doesn't understand how to write code. I believe from one of your previous presentations, it's less than 1% of the world is capable of writing code.

`1:02` AI's impact on software

How has AI changed this? Um how do we think about coding now? How do we think about teaching how to code with the advancements in AI? Yeah, it's changing the number profoundly, at least in potential. And we are seeing the first signs of that with agents like such as Replit agent that we released just 4 months ago. But if you project the impact that Replit agent has today to 2 years ahead or 5 years ahead, I expect the number of software creators to go in the hundreds of millions very quickly.
Replit as a company mission has always had to empower the next billion software creators. When I started to work there, I thought the timeline would have taken maybe a good decade or more. And now my my my predictions are getting shorter and shorter. And the reason is advanced software, of course, will always take uh people that have been formally trained on software engineering, people that like years of experience in the field.
But there is a long tail of software needs that are relatively simple. And then we see it just being extremely successful at them. So think about internal tools that a lot of companies uh built like for like their bespoke needs. Think of relatively small web applications. And think of also what we call personal software. Like a variation of a to-do list or a workout tracker app that is tailored to exactly what you need.
A lot of people would love to have that. They don't have it just because no one wants to spend like 6 months learning how to write code. But now that I have an agent that can pull it off in 10 minutes, so you know, why not? I'm going to have my workout tracker specialized to my needs. So that's where I think that's why the number is going to grow so much. Like there are two expansion dimensions. One is the vertical one, making developers more productive.
And AI has already proven to be very powerful at that. But there is also a horizontal expansion where we have more people in the world being able to create software. That's what agents uh are going to be capable doing in the near future. And I know that this is a recording, but would you feel comfortable sharing your predictions? I know you said you thought it was going to take well over a decade to get to a billion people that can write code.
What are your forecasts now? I mean, historically bad at predictions. The only good prediction I've done in my career has been to work in AI. But when I started, I thought this is terrible because I I got my PhD almost Oh, literally 10 years ago. It was in 2015. So I'm a I'm a I'm on hold I'm on cold duty in AI at this point. And I'm back in the days when you know we started to work on the early deep learning years and maybe like more what was called applied machine learning, we we saw some level of progress, but I don't think many of us expected this exponential growth that we experienced in the last like two three years.
So, after launching rapid agent, which you know between us we thought it would have been a low-key launch. That's how we thought of it. But it is like an early access program where I'm just going to put a video online. Let's see how people are going to react to that. And it caught up, you know, like crazy. Immediately people were talking about it and we got you know tens of thousands of users like in the first few days.
It was it was really incredible. Uh so now my timeline keeps shrinking and shrinking. And I would say having 100 million plus people creating software with agents is probably something we're going to be seeing in the next one or two years and most I strong conviction about that. And the numbers are all trending in that direction. Now, it it all depends. The subtlety there is on the complexity of the software. Are they going to be able to create their own native iOS application that makes them 100 million ARR a year?
Probably not. But are they going to be able to create personal software? Yes. Um and if you ask me the same question literally 18 months ago, I would have probably told you we are 5 years away. So, I'm eating my words about the predictions. As much as I'm extremely optimistic about AI and I've been part of that movement for a while. That's really cool. And so back to uh an earlier point that you called out. Like you you kept on noting how you're having AI generate software, but you were specific to talk about agents.
And I guess the first question I wanted to compare is like well, you you hear lots of people talk about things like GitHub Copilot. And can you inherently sort of explain what the difference is between somebody who's using, you know, an agent to build said personalized software as you're talking about versus somebody who's going to be using Copilot? Just because right now for a lot of the engineering world, they're all like, "Yes, let's Copilot everything."

`6:00` Agents vs. copilots

And then we're going, yeah, so I'd love to clarify that a little bit, basically. Yeah, totally. Uh let's use self-driving as an analogy because it's it's something like everyone will understand uh more easily. Uh think of Waymo versus Tesla. Like they have slightly different, at least as up to date, implementations of self-driving. And on the Waymo, you expect to hop into the car. You don't sit in front of the steering wheel.
You just expect the car to bring you from point A to point B autonomously. On Tesla, at least in principle, you should be supervising the car. You should be having your hands on the on the wheel. Uh and the car maybe does 95% of the job for you. I think this is this represents the difference between having a Copilot versus an Autopilot. So, GitHub Copilot uh was the pioneer in making software engineers more productive.
But it just brings some level of productivity enhancement. What an agent does for you is even though you have absolutely no clue how to drive a car, it still allows you to go from point A to point B. So, a coding agent is supposed to do exactly the same. You know how to express your intent in natural language, and then you just allow the agent to build uh the application for you. In the case of Rabbit Agent, we use the human in the loop to provide feedback back to the agent.
That's very important for several reasons. First of all, there's a fundamental alignment problem that every AI system faces. Uh we as humans, we express ourselves in bit ambiguous terms. So, no matter what you write in the prompt, and I can give a lot of crazy examples that we have collected in the last few months that Rapid Vision has been online as you can imagine. But, you know, we express ourselves in different ways.
We under specify the problem. So, it's very important to put the user in front of say like an initial prototype. And then ask them, does this reflect what you wanted? What is missing? What is working? What is not working? Um and aside from helping with alignment problem, there is also an issue of the fact that agents take several actions without any level of supervision, and you you experience compounding errors in that case.
The longer is the trajectory, the more likely you have for the agent to make an error, and it basically, you know, starts to go in the wrong direction unless you really intervene. And that that's when we use humans to say, "Hey, we built this web application. Please test the login page or test this form. Let us know if it works correctly or not." This is something necessary today. Now, let's go back to the prediction that I was making before.
The reason why I think the timeline is getting shorter and shorter is mainly because models are becoming more powerful at generating code, and because we are learning how to build better and more reliable agents. But also because we are starting to see features like computer use that we know Anthropic launched a few months ago. Or like and any other ways basically to have computer models that have vision capabilities and that can also interact with web applications.
And we're having like early signs of being able to use them like to instrument the application that the agent has built for us. So, you can imagine basically putting two AIs face-to-face. One builds the application, the other one tests it for you, and then they can autonomously basically make progress in there. So, today we're still not that advanced. We are at a prototype doing that. It would be foolish of me not to expect that to work very well, say already next year.
Okay, this is interesting. You you're laying a lot of questions I'm sure of that I'm sure wants to also tackle specifically about building agents and having agents fight with each other. But one of the things that it just led to me based on what you're discussing though, because people are very expressive right, in very very different ways, right? Is there an implication also then in essence we're building a new language I would put that in quotes obviously or at least a framework on how we were we were to prompt in order for people to be able to leverage said agents correctly to build the code.

`9:47` New interaction patterns

I'm just curious if that if is there an implication of that or is it or can we do away with that concern because of the fact that we're building these agents or are we having in essence dueling AI's? Yeah, I think we are building maybe not that new language per se but we're laying we are training users to a new interaction patterns with brand new system. So over time when your chat GPT has been out for several months you were spending time on Twitter and you learned you know the jargon, you learned what which prompts were successful, which prompts were not successful.
We're seeing the same with rapid agent. There are people that are creating amazing success stories, they're building businesses on top of rapid agent and they're successful in building amazing apps with it and so are people that get stuck relatively quickly. We're not putting them in front of two different system. This is usually exactly the same one. It's more a matter of they learn by trial and mistake what works and what doesn't.
And that is why I was you know highlighting the fact that we love to keep the human in the loop because it's it's not only about the initial prompt that you pass to the agent. It's also these subsequent interactions where you have with it that allow you to be more or less successful. So as we learn how to be productive with chatbots, They would be like a new muscle to be trained for software creators on how to be productive, you know, using agents.
Yeah, I almost view it as learning a different way of writing. Of like there's academic writing, there's informal writing, there's texting, and just another way of expressing oneself. Yeah, very much. You're right. I I'm super curious. You've now mentioned like how you can do things well, and there's also plenty of ways you can do things not so well. Um could you elaborate a bit more as to some of the common mistakes that you see, as well as some of the best practices that you see?
Yeah, I think by far the most important is striking a good balance between um clarity and succinctness. So, on one end, if you write too little and the description is completely under specified, you are asking for the agent to do the impossible, which is basically reading the human's mind. If if you if you write out a short one-liner, you don't even specify if you want a web application or a mobile app or a, you know, a Python script, of course we're going to we're going to get lost.

`12:00` Best practices for prompting

And on our end, what we try is we we ask you back questions to basically fill the specification of the application you want to build. But that kind of interaction pattern is not easy at all. It is also something that users are not used to because most of the AI products are reactive rather than proactive. They mostly react to your request, to your prompts. They don't know how to to have a good conversation back with you and elicit the information that they need.
So, the best case scenario is your description is not too short and under specified, but is also not overly long. Like we see this especially from people with a PM background that tend to write a mini PRD and copy-paste them in on the agent. And then the the negative feedback that we got there is sometimes in the fact that, "Oh, Rapid Agent ignored 50% of the requirements I gave. And it is is not because we don't want the agent to build the entire PRD that has been passed over to us.
It's it's simply impossible to pull it off in just one step. And there are like fundamental technical limitations why that is hard. If you just talking about LLMs, the output uh the number of output tokens that an LLM can give back is not infinite. Uh it's it's your own save the inverse standard on Azure 8,000 tokens. You don't write a full-fledged web application with just 8,000 tokens. Like you need to have like multiple rounds and uh go through multiple requests.
So, it's an experience. It's uh if anything, launching early as we did taught us a lot just by looking at the data. Um it's it it's always exciting to see our users interface with our agent. Now, I feel I want to go ahead and actually take one of our PRDs and just dump it directly and see I'll be checking for your for your username, okay? Yeah, yeah, yeah, yeah, yeah, no problem. I know I've I'm pretty sure our PRDs are long enough to basically break the context.
I'm just calling that out. Huh. I'm quite sure as well, yeah. All right. So, let's let's go backwards a little bit because as opposed to um wants to use PRDs to make my job easier. Um I'm curious like now we we've talked about like the concepts right now. But I'm just curious, how do you build these agents? Like, you know, how how how do you like like where where's the starting point? Because I'm presuming you're not just like saying, "Hey, here's an LLM.

`14:52` Building reliable agents

We're done." Right? I'm presuming there's got to be something around it. So, I'm just curious like, you know, for obviously there's a there's a bunch of secret sauce, so fair enough. We're not going to talk about that. But by the same token, like what are the basic parameters, basic structures, concepts, architectures? Yeah, let me start by saying probably the most counterintuitive thing, the LLMs are the least important ingredient in agents.
And what what I mean by that is the play field is almost level for everyone. Like we're all using the same frontier models, give or take. Maybe there is some level of fine-tuning that can help in some like specific cases, but when it comes to coding agents, for example, everyone is using Sonic 3. 5 from Anthropic because it is the best code gen model available out there. What the special sauce that you build is predominantly software.
It's predominantly the code that you write to create the agent and partially out to out to prompt the LLM, but I think there is enough mindshare at this point that everyone knows what are the best techniques out there and it's more about cherry-picking what works well for a coding agent rather than inventing new things. I I I don't want to speak on behalf of other companies that built agents, but I'm in touch with a lot of people that do my same job and the feeling is the reality is how you make the entire agent infrastructure and how you make them reliable.
So, and also for this reason, I think the best agent builders out there are not, in a sense, people that have done a lot of AI research exclusively. You also need in the team strong software engineers, especially those that have distributed system background. And the reason why I say that as I was mentioning earlier, agents the main pain point of building an agent is dealing with a vast variety of different errors that they can encounter.
If you think about it, building a distributed system is something very similar. And you guys at Databricks are, you know, ninjas at that. I have a deal. Real as classes, they can fail in so many different reasons. Same as with agents. So, how do you write software that allows you like to recover and to be as reliable as possible regardless of, you know, all the different ways in which it can fail. So, that's maybe that's one recommendation I can give to anyone who's creating a team like to build an agent is bet a lot on the software side rather than just hoping that additional prompting will make the difference.
And and to your point, I and I'm the way in which agents have agency is by running tools. You don't build an agent just by looping over an LLM. You need tools that then allow you to interact with the external world. The external world could be anything. It could be calling an API. In the case of Rapid, we have a wide variety of tools. Because if you think about it as a software engineer, you have a lot of tools in your toolbelt.
You have debuggers, you have compilers, you have the runtime environment, etc. , etc. So, you want to be able to access all of them. So, the complexity is not only in building the tools. In a sense, at Rapid, we kind of had an advantage because all the tools were there. They were part of the product already. It's how do you build the interface between the tool and the LLM? Cuz LLMs are not trained in a sense to be uh to output just shell commands.
They can be put in front of a very complex API. So, you need to simplify the surface of a tool. You need to make the tool usage as easy as possible. And for anyone who's interested in this field, I think the this WeAgent paper, which was published in sometimes like mid last year, talks about this new field called ACI, agent computer interface. So, we went from HCI, human computer interface, so how humans interact with computers, to the agent computer interface.
So, how do I make sure that an agent can interact with anything that's available on my computer? Being it a browser, being it an API, being it a file system, and so forth. That is probably one of the most challenging aspects on how to build a powerful agent. And so, one of the things you just mentioned was all of the ways that agents can fail. And so, they don't just throw like 404 status errors. There's a lot of silent errors and silent ways in which they can fail.
And so, I'm just curious, how do you all detect uh among the errors that you have detected, what are some of the clues that there are errors happening? So, the condition I would give to anyone who's building an agent is to battle observability as soon as possible. And any senior engineer who has built distributed systems in those in their lives, they will tell you the same. Like, if you don't have observability on your system, you're like, you know, building in the darkness.

`19:19` Debugging silent agent errors

You have absolutely no clue if what you're doing is working correctly or not. So, on one end, I will build everything very much incrementally, so that you can start to see what are the what is the error distribution, what are the errors that occur more often, and try to fix them, and then add complexity incrementally, rather than like building the castle from the ground up, and then just start into stress test it right away.
And the other one is, yes, having observability observability across the entire system, so that you can see what is going wrong. Now, when it comes to coding agents, there are like at least there is a common error that everyone share, which is the fact that LLMs are not very good at editing code. And one key reason is uh the what is called laziness in the field. So, the idea that if you're passing very large files in context on LLM, and then you're asking to do a certain edit, most of the times that they get it right or they're in the vicinity of what you what you need, but they don't output a diff.
They don't output an easy format that you can take and apply back to your code base. They they left out uh on purpose large chunks of the code. They replace that as a comment. They say, "Keep this code as it was, and just change this pattern." That is perfect for a chatbot, because most of the times, you know, you you go to ChatGPT, you ask, "Edit this file for me." and then you go back and copy paste to your editor.
So, that in the Copilot era, what was mentioning before, that was already great because as an experienced software engineer, what you needed was the answer. You copy pasting doesn't take you too long. The agent has to be way more style. It has to bring you from point A to point B. So, you go from the question and that edit has to be applied directly to your code. So, a lot of work goes in making that as reliable as possible.
And having observability on those errors allows you to understand why are my edits failing and they can fit for so many different reasons. Like, we could have a entire podcast episode where I tell you all the different ways in which it can happen, but my team has been working on this for 4 months, so um but yeah, and then there is a long tail of many other things that can happen. But, and that's why I was saying, think of the agents as distributed systems.
It's it's a very similar type of technical challenge. Yeah, the more you're talking about this, the more I'm actually sort of like sort of grokking it because I'm just recognizing to your point exactly. When you talk about like the pull pilots, like, "Okay, I already, as a software engineer, know my Rust code is just doing X, Y, and Z, but I'm calling the wrong you know, I'm calling the wrong function method or tell me which one it is, boom, I'm good to go, pop in the right property method, I'm good to go, and I'm off and running.
But, you're talking about the fact that when you're editing code, it's going back and forth, back and forth, reiterating because it's like, "Dude, you went the wrong route altogether, right? You You're You're You're You're supposed to be using Golang. You're not even supposed to be using Rust." You know, just using that side example, but that's the whole point that so, basically, you're building these systems that can actually go from A to B and I'm only providing maybe not my S9 PRD, but I'm providing the context and then it's actually deciding what's the right way of doing it, in essence.

`22:27` The user experience of agents

Yeah. Yeah, it's spot-on. Okay. And that's why it's much harder than they're building a good co-pilot. Cool. All right, so I guess using just a bunch of case statements around my LLM isn't going to work in this case. Got it. All right, fair enough. No, but I I I I I say it in jest, but I'm just curious like then is a lot of your time building because you said you had already had this advantage where you already understood how to interact with tools and your LLMs with these tools.
I'm just curious as So then is a lot of your time really observability and maintaining said infrastructure because of the talking to all these different systems then? I'm just I'm just curious. I mean, right now for instance, we are putting a lot of effort on reliability. And what I mean by reliability is not the infra. We are in a like we're in a very good position right now and I don't want to jinx it, but uh if you look if you look at our dashboards in terms of infra uh uptime, it's it's it's looking great at the moment.
The reliability challenge is making the agent reliable going from point A to point B. So again, let's use the self-driving analogy. We don't want to do the agent to disengage. There are times where we try to build the entire initial prototype from scratch like without any human intervention and you know, we will have to make that as reliable as possible because the truth is especially for people that never created software in their life, the haha moment is the first time they see a preview in their browser.
They went from a natural language prompt into a uh skeleton web app working. There's nothing more exciting than that. And I'm sure that every person who has written code in their life and they're listening to this podcast, they will know exactly what I'm talking about. The first time I had my basic basic as in the programming language, not basic script. Like when I was writing basic as a kid, the first few times I started to see things running, I was like it was life-changing.
So, this is the kind of experience I want to provide to people and I want that to be as reliable as possible. What's one of the coolest applications you've seen someone build using Replit? Great question. Where do I start from? And look, anything that ranges from personal software, I personally love that because it's one of the reasons why I I wanted to build rapid agent as well. Like I want to have my own like personal websites and mobile apps that, you know, optimize my life.
I I I really love that. On the other hand, I I get really excited about people building businesses with rapid agent. Because there are so many business opportunities out there that people are not exploring, not because they don't have the right ideas, not because they're not business savvy, but because they can't build the technical tools around them to make it happen. So, that really resonates with the with the company mission.

`25:38` Tool integration challenges

I I I I don't want to be rapid agent for my own personal software needs because I could be writing the software myself. It is just exciting to see that I can do it in 2 minutes rather than 1 hour. Uh but when I hear people saying, "Hey, I'm I live I'm not even in the states, like in some, you know, other countries where it's hard to find a job. They got a rapid agent subscription and then they build like a five-figures month MRR business on top of it.
And I feel okay, wait, we're doing something really good here. Those are those are my favorite stories. That's pretty amazing. Uh okay, I want to go backwards just a little bit because uh we because you called this out, which is like the fortunately for Replit, you already had figured out basically how to have the LLMs talking or working with tools. Can you provide a little context as like, what are some of the limitations that you actually had to work around for LLMs to actually interact with tools properly the first place?
So, first of all, um we we especially the developer tools are are very advanced, if you think about it. So, even just browsing the file system and traversing it and opening the files, there are so many subtle differences. Like, you know, even listing files, you can run it with so many different flags. If you expose if you don't put any guardrails to the agent and it is allowed to basically go around the file system in whichever way the LLM decides to do at that point in time, then there is no way to build this, you know, way more experience on top of it, because it will be returning the list of files in a different ways.
I'm using like a very simplistic example. We don't do it in that way, you know, but just just to give you an idea. So, it's it's very important to put guardrails before like you actually invoke a tool. And why is hard to work on this problem? Like, in principle, it's it's very easy to say, "Okay, if I have a command line, um like if you have a command, I will just reduce the amount of flags that I get can get access to."
So, I can just list file system in a very basic way. Um in practice, over time, the more the more you want your agent to become advanced, the more you will start to miss some of those flags, because sometimes you want to recursively list one directory, sometimes you want to get only the. py files. And then all of this complexity starts to pollute the tool and the tool specification. So, there is this trade-off between how much complexity do I expose and will the LLM be really liable at invoking the tool exactly in the way that I need?
Now, if you bring this tool a tool that is much more complicated, such as I don't know, instrumenting a browser. That's very important for us, because we we run web applications, sometimes we want access to them, sometimes we want to test them. You can imagine like putting an LLM in front of a browser and allowing them to interact straight without any guardrails in between is extremely technically challenging. Um there are startups that are just working on that.
Like BrowserBase has been working on this for a while. So, the difference for us is we don't have only one tool, we have tens of them. So, we need to go through this process for each one of them. And the other big challenge with LLMs is of course context management. You will be tempted to throw all your files in context and put all these structures rewarding your system prompt and allow the user to write a PRD because, you know, why not?
If everything fits in the hundreds of thousands of tokens, why wouldn't you do it? All right, I'm doing it. That would be perfect. The truth is at least with the current generation of models, maybe except the O models from OpenAI, which you know, we we can talk about briefly after. Um the large context are not as powerful as people might be led to believe. They're good at doing, you know, the needle in a haystack problems where they can retrieve a certain tidbit of information in a like in a large input, but they're not very good at all at following pedantically all the different structures that we give them and understanding all the code that you put in there.

`29:30` Testing and debugging agents

The truth is they start to break after, say, 30, 40,000 tokens. So, you need to be very judicious in what you pass back to the LLM. And if our flow in the agent is very long and you want to keep the memories of what the agent did did before, you need to know when to truncate those memories. Otherwise, the context starts to pollute and then the agent becomes less and less smart over time. And I think these are challenges that everyone in the industry is facing today.
I excluded the O models because there is some initial evidence that they do better at that, but it's such a wildly different type of LLM today that I don't think there is anyone out there who has really built a good agent experience on top of those, you know, test time scaling models. Yeah, Databricks recently released some benchmarks comparing the impact of long context on rag applications of the different models. Uh takeaway exactly to your point is they don't reach their context window saturation before the performance starts to drop off.
Uh I I remember the takeaway was that the Gemini models had the most consistent performance, but they weren't the best models. So they were consistent across the context window at least, but they weren't the best models. Gemini would be very tempting because they have the 2 million tokens context window. So you will be tempted to put even more in there. Uh the truth is if they can't add it the code as a need, then they they don't really move the needle for the for the agent reliability.
Exactly. Just because you can do something doesn't mean you should do something. There you go. Very wise. I I feel I feel attacked right now, by the way. I just I want to call this out. I feel personally ATTACKED RIGHT NOW. I'M SORRY, BUT IT'S LIKE HUMANS like we can keep it in our heads like eight active numbers at a time or whatever that metric is, but like it doesn't mean we reliably can do that. Yeah. Yeah, yeah, very true.
So I know you're you were just mentioning like these systems get very complex. And my team likes to say it's like Whac-A-Mole. As they build out these very complex agents, you fix one thing, something else breaks. And so as you're building these agentic systems, I'm curious how do you approach testing? Um and in particular avoiding regressions as you're adding a new functionality. So first of all, I agree very much with your statement that you could be tempted to play Whac-A-Mole cuz you you just keep finding bugs anyway and you want to fix all of them.
Uh my high-level stance is I try to find a good trade-off between doing the Whac-A-Mole job that is always necessary, but at the same time every now and then move to a different axis where you try to like do some level lateral thinking and re-think the problem, you know, in a completely different way. This paid off. We did it before we even did the first launch of the agent. We almost completely revamped the architecture 3 weeks before launch.

`32:37` Data quality for agents

And you know, it it paid off very much. Maybe not for my sleep and my team's sleep, but you know, it it made the agent much more reliable. So, sometimes it's kind of necessary not to be bogged down with all the infinite list of bugs that you see the agent having. Uh that being said, how do we how do we um approach testing? Several different ways. Uh the first one was to basically instrument the agent via one an internal API and allowing it to do very simple build automatically.
And you know, we have basically have a collection of different prompts and we have like expectation of what the prompt will be building. We have so some pre-canned answers that the human would be giving at the agent a certain times. And then we see if they go to completion or not. And we run this, you know, test basically several times a day to spot regressions. And at the same time, we're starting to explore more and more visual models and also models like computer users capable to interact with the applications that we build.
Definitely, there is no good solution out there today. Uh at least not that I'm aware of. Definitely, there is nothing in the academic literature or there was I would have, you know, studied that in depth. Um Sweep bench and similar extensions to that are very good at testing agents that create PRs. Uh so, in the guy, you know, in the style of or maybe the new GitHub agent, they are definitely helping them to be more reliable at creating PRs on large repositories.
But Rapid agent works, you know, attacks a completely different problem, which is how do you create greenfield software? You go from an a repository that is empty and then you want to build an application for the round up. So, this is a different type of benchmarking that I I think the few of us that work on this problem we're attacking it internally, but I would love to see a concerted effort either coming from academia or industry where we create our own benchmark on our base we do evaluate building apps from the from zero to one.
That's really cool. One thing that automatically leads to is like, you know, one of the more common um problems whether it's the LLM itself or actually building these, you know, compound AI systems, agentic systems around it is basically the data quality, right? As in the impact of data quality and how low-quality data uh invariably makes the system worse. And I'm just curious from your perspective then because you're going doing this zero to one, right?

`35:18` Future of agents and work

Like are are you like what's the data quality scenario that you have? Like what is it a synthetic data? Is it the error logs themselves? I'm just curious from that from that context. And not to mention uh related to this because it's you're talking about code, different versions of different code results in often different error messages. And so, I'm just curious from that particular context like the data quality problem that you guys face.
Yeah, we we try to standardize as much as possible the starting point, you know, so we have some elements in the stack that we use like to bootstrap the build. Um but you're totally right. Like the further the agent trajectory goes, the more we start to end up in a completely unique scenario where we're collecting this data, uh but we're still not leveraging as much as I would like to. And you know, honestly, I wouldn't even know exactly how to leverage it right now.
Uh it helps us to understand, you know, across these thousand errors maybe 900 of them are easy to classify and maybe they're all under the same umbrella and it's easy for us to think of a high-level fix for the agent to avoid them in the future. But then there will always be be this very long tail where one way to fix that would be to wait for the next frontier models and see if that problem doesn't happen anymore, like outsource it to someone else.
And if it keeps, you know, being there for too long, then it would be like, "Okay, can I fine-tune my models? Can I have a different agent loop that just attacks that specific issue?" So, for now I'm excited to be in the position where we can collect a lot of this data. Like we have thousands and thousands of runs per day and that we're sitting on a gold mine of data that, you know, I I will I will be spending the next the next year just analyzing.
Like one thing I tell my team all the time is even if for some obscure reason the AI progress, you know, alarm stops today and we're not going to see a new frontier model for the next eight to years, I will still be working 24/7 on what we're doing cuz there's so much to be done to optimize over just the current model of capabilities and making our agent more reliable that I'm, you know, we're never going to run out of work regardless of where AI is going.
That said, I don't think you need my prediction that new frontier models are going to keep, you know, being pushed out on a at a fast pace and I'm excited to see what kind of issues they're going to fix for us in the near future. Cool. And then, okay, related to exactly that, but because you've got me all excited again. Well, I mean, this entire conversation is like I got it anyways, but just this idea that basically, yeah, like you have so much data now that even if we do nothing when it comes to improving the our these models that you actually have to analyze that.
So, I'm just curious, based on what you're doing and based on this like this this um uh uh uh and as it's new zero-to-one job market you're basically creating. I'm just curious like how do you see your overriding thing for 2025? I think you and I had had it before where I said like 2025 is like the year of the agents, right? And so I'm just curious like what do you think the prospects for the impact to the job market is based off the fact that it is the year of the agents and what you guys are doing right now already.
Yeah, I think it's the year of the agents not in a this token way. At least my optimistic self wants to wants to believe and say that. It's it's more about giving so many powerful tools to the to the workforce that task that took maybe a week before and they were very tedious and didn't make you very very efficient will now be perhaps taking care completely by an agent or they they know they will be almost 90% done by an agent so that the human can just complete the last mile and in turn we're all going to be capable of focusing ourselves on the creative process, on basically talking to the humans on how to actually run correct a company or to run the business correctly.
So this is why I think 2025 is the year of agents not because all of us have then we're going to be living in a completely different world. It's more about right now even myself like like historically I'm terrible at creativity. I don't know how to draw. I don't know how to like do do good images and so forth and something like mid-journey back in the days kind of changed all my life. Like I could do a nice talk. I could put some graphics.
I could do nice slides. The same is going to happen with agents and if I wanted to start my own business tomorrow, I know that I could do some you know, SDR by using an agent and I could have another agent that takes care of my email and calendar and that would this would empower so many people to become entrepreneurs. So that that's what keeps me very bullish about the near future. Amazing. And I love that we're ending this uh podcast on such a positive note of how we're enabling people to create uh new jobs, new markets entirely, all powered by agents.
So, thank you again so much for joining us today on Data Driven by AI, and uh best of luck with all of the new applications that people can build using Reputations. Thank you. It's been a pleasure.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.