Why Teams Will Break This Year (and How to Fix Them) | Battery Venture’s Dharmesh Thakker

27:24And so they've seen all of these waves of AI. They've been very against it. but where they have relented is on the more mundane boilerplate code like all these frameworks require and so the code generation auto completion that was really easy for them under to see the value like we rely heavily on rust so when the automation makes mistakes the compiler will tell us those are combination like rust kind of makes it a little more safe to adopt this and I think other languages will start to adopt some of that intelligence and their compilers over time. On the automated bug fixing and code reviews, we have thousands and thousands of dependencies.

28:09And so keeping those dependencies updated would be a whole job function for us maybe two or three years ago. And we don't even review, like we have a bot that reviews another bot opening those update PRs or dependency maintenance PRs, which is really nice. And then for the agentic, we try to keep a pulse on what's happening outside of our world. Like we have our customers, we have our Slack, and then we have like our internal communications. But there's, we felt probably about eight months ago that the world was moving much faster and we had to be really concerned about local maxima. So we constantly are pulling in data that matches, like new posts that match certain keywords.

29:02They come from a variety of feeds, ranging from Google News to Hacker News. And they are experimenting, like an agent that we have nothing to do with will propose new prototypes, new bounties even, to bring in other humans. and we're constantly trying to keep our finger on the pulse. And so are our customers, too. That's great. It's a great story. And actually very amazing. I mean, it seems like you're ahead of the curve in this audience, at least. Absolutely. Yeah, and it's great to see so much adoption. Weaving, for instance. Like, so Darmes and I are both involved in this company called Weaveate.

29:43They do all three of these, too, for sure. So that's like a vector database. Bob says hi, but like it's a vector database, it's open source. And so their agent lives in Slack. And if you ask a question, like you need some help with a feature or a new API, a new syntax, it'll just respond and drop in the docs. That's one example, but there's a ton of other examples of agentic workflows within their business, within our business, within most businesses, I would say, at least that I know about you know awesome i really appreciate the insight and for anyone else out there that is you to share their thoughts there will be more opportunities so don't worry so before we move on to the next insight i want to ask both of you what do you think is going to be the biggest impact to developers over the next year or so in terms of the impact of these new ai tools i think the near-term impact in 12 months it's i think engineers are doubling down as data scientists There used to be where you'd create a model and then you'd provide that to engineers to go write an application on top.

30:49I think the role of the AI engineer is like doubling down saying, hey, you have this extremely powerful foundational models accessible through an AI or through an API. You can now iterate through your application logic, make sure the model's not hallucinating and you're doubling down as a data scientist and a software engineer. And you're implementing much higher order logic that customers benefit from. So I think your AI engineer role is getting super elevated, has much higher efficacy more so than throughput. It's not about the lines of code. It's how we can impact the business by combining application logic with foundational models wrapped into a killer application at record speed.

31:30So I think the role is becoming really important and they're doubling down as data scientists. If I can add, I think it's almost like every developer role, you will need to complement with some AI capabilities. We're hiring right now and we need a full stacker, you know, engineer with AI capabilities. We need a backend engineer with AI capabilities. By the way, they don't need to write the models or be the best data scientist, but they need to know how to leverage them. where do the models stay what's the do's and the don'ts what can they consume etc so i think you're going to transform a lot of like their roles yeah we'll definitely get into that and it's a great segue actually into our next key prediction so and that is the senior developer is going to become more valuable in your organization so i think there's this common belief that generative ai is having a bigger impact on the lower skill developers like your junior developers or fresh graduates.

32:32But more and more research is coming out that seems to indicate that it's actually your senior developers, in fact, that not only going to reap the most benefits, but are going to be the ones that you're going to depend on the most heavily. So I think the key things that are driving this, again, AI is going to show up at a lot of these, but, you know, natural language interfaces are dramatically shifting, you know, how people learn new technologies and skills. In fact, this technology really is here today. I think if you're looking for one use case to adopt when it comes to AI, it's creating, it's giving your developers something like ChatGPT or Copilot or a tool where they can have a natural language interface into their code base.

33:18And with really the key benefit being knowledge and skills acquisition so they can more rapidly achieve proficiency in new tools or technologies or processes. Gen AI is also likely to introduce a lot of new bottlenecks to your organization. So, you know, if all you're doing with AI is producing more code, it doesn't actually mean you're going to be shipping more code into your production. So there's still going to be code reviews that are required. You're going to have to run everything through your CI and CD pipelines. And it's senior developers who feel the biggest negative impact from these problems.

33:54And in fact, I really believe, you know, for this, that structured rollouts are the name of the game. There was a recent research article from Google that found that using a structured rollout, there was a 21 % velocity improvement for what they call enterprise-grade tasks. So they gave, you know, a range of developers from, you know, the most junior all the way up to the most senior, a structured way to use generative AI. And on average, the senior developer, on average, they saw 21 % improvement. The improvement was actually bigger than that for the senior developers. And then lastly, you know, security always comes up.

34:32It's a very recurring topic, but it's going to continue to shift to the left and be more integrated into your developers environment. So, you know, you're going to be detecting vulnerabilities much earlier. Developers will be empowered to catch issues much earlier before they even hit like your CI-CD pipeline, for example. And your senior developers really need, you know, support and enablement so that the burden of maintaining a security posture doesn't fall into them. So I want to get your guys' insight. Like, how do you think that senior developers are going to be impacted over the next year?

35:07Yeah, that's it. really interesting topic. I think there's two things that are going to happen with senior developers. First of all, whoever is a senior developer today, they kind of grew without AI supporting them. And I think what it will cause or what causes is you have now in key positions in some companies, companies people who actually learn the call base on their own you know AI is assisting you to like accelerate fast and these people are going to be assets it's going to be really really hard to lose them there's something also with senior developers that are again didn't grow up on on AI supporting them that they spark they have a life I think and it's debatable I'm willing to hear like other opinions this creativity thing going on because they don't just say you know they get a task hey you should do this they're the people that can say hey you know let's refactor this entire area maybe let's change the product and do these type of things and i think the senior developers of 10 years from now won't have the same life knowledge because they're going to use a lot of AI to gain the knowledge and rely on it a lot more.

36:36So I predict the senior developers of now are going to be a major asset. I would say the second thing, the senior developers that are going to be here in 10 years from now are going to be a five people team. They want to activate agents that take like, you know, pick up, you know, simple tasks from a Jira queue and work for them. They're going to have agents that do AI-based review. They're going to have agents that fix SRE problems that they see in security. So it's almost like a strong senior developer would be like a 10x or a 50x multiplier. So it's really, really going to be interesting how senior developers evolve over the next years.

37:22Are there any skills that you think senior developers should be focusing on right now? Definitely go and see an experiment with AI. Lead the way. Don't just settle for assisted stuff. I'm asking my senior developers right now, my engineering manager is asking senior developers right now to go and experiment with agentic use cases. So those type of things. But I think, again, I said before, it's also very, very important not to lose this spark of creativity and offer ideas and all these type of things that makes a single developer great. Yeah, you know, something that I'm actually hearing a lot is the notion of like a product-oriented engineer.

38:10Like engineers who can actually take an idea or a technical challenge all the way down to the end user of that challenge. So even if you're a backend engineer that's optimizing a database query or something like that, you should still be thinking about the real-world usage of that query to make sure that it's optimized for that situation. Just on that point, you asked the question, what should senior developers be thinking about? I think of senior developers as what the industry calls 10x developers, right? It's not necessarily that they produce 10x the amount of code, it is that they have 10x the amount of impact by architectural choices, by best practices, what have you.

38:47and all this talk we hear about AI is so focused on developer productivity as measured by throughput saying, hey, AI is going to generate more lines of code. Cares, doesn't matter. The question is, what code is going to drive the most impact on your end customers? And so I think senior developers can lead the charge in focusing on developer efficacy as opposed to throughput. And by that, what I mean is, when you contribute a set of code, how do you then A-B test that? How does that impact the end customer? Does that drive the intended business impact? And then how do you bring it back, close the loop, and figure out how do you prioritize the source code that can ultimately impact the end user, right?

39:29So I think that's where a 10x developer can have 100x impact by closing the loop end-to-end, pushing code faster, but higher quality code, measure with the end customer impact, and use that to import, learn better best practices. And then that can become a training ground or coaching ground for some of the junior developers to focus on higher impact work. So I think this whole concept of developer efficacy, you know, productivity is measured by customer impact, not lines of code in terms of throughput, is an evolution this industry needs to go towards. Yeah, so I want to throw it back to the audience for just a moment.

40:03I'm curious, show of hands again, are you implementing a practice today to help your senior engineers specifically adopt generative AI versus just a general practice? Again, one hand. I don't know who that is, but do you want to share what you're doing? Kind of more kind of encouraging my senior to explore, but basically just so we can save time. So go explore and do more of that just so we can cut off time. And often what I see and kind of maybe it is a follow-up question here. because you need to you know developers they're coding in coding language so that's how they express themselves and now what all of a sudden they need to express themselves actually in english which kind of makes the product management in a way redundant i would say so kind of pushing my engineers to think more of a product managers and you know set the the prompt to solve about the problem in the context of a user or like the value that you're trying to produce and kind of as an outcome like, okay, now let's help me to code it.

41:23So that's really where kind of pushing my seniors to work. Yeah, and I think, you know, something that really resonates with me on that is that these AI tools can actually be pretty good devices to role play your user, right? Like I think developers aren't always as accustomed to meeting customers and talking directly to users. It can be difficult for them sometimes, but ChatGPT or tools like that can actually be really great at just telling you to be this user and answer my questions or how would a user interact with a system like this? So I think there definitely is a lot of potential there to help your developers think more like a product manager and to think more about product design.

42:09And I want to keep us moving forward into our next prediction. And it's a topic that I think you really can't discuss without talking about developer experience because they really do seem to come hand in hand. And, you know, I hear a lot from engineering leaders that they have a hard time understanding how to invest in developer experience. And, you know, I think it's not going to go away, but if you can do it in a strategic way, there's some pretty big benefits that you can achieve. So some of the technologies that we're looking at in this space is particularly around like unifying development environments.

42:45So, you know, things will become more integrated over time. We'll see more seamless coding to testing deployment tool chains. You know, imagine a world where code reviews start to become more automated inside of the IDE as the developer writes their code. You can have AI agents or other services running within the IDE and telling them that there's a problem before they even send it to their team. I also think the documentation and knowledge sharing are potentially dramatically going to shift. The point we have on the slide, I believe, says it's the end of documentation. But really, I think what we're seeing is developers are relying more on automated documentation and AI assistance to generate and maintain their documentation.

43:30And I really think that there's going to be some significant improvements to knowledge sharing that comes out of this, you know, as like knowledge bases start to get replaced by like hyper-focused LLMs. I think about moving from like an internal forum to like a knowledge base that is updated automatically through a natural language interface. And then there's also, you know, just the constant force of asynchronous development. So, you know, the pandemic normalized remote work culture, these recent return to office mandates that have come out. But virtually every modern enterprise is distributed to some degree today.

44:08And so, you know, if your tools don't support asynchronous development today, they really are. Even if you are an office based culture, you really are sort of handicapping yourself. So I wanted to see what you guys had to say about that. really good topic because the way you ask the questions is like the problems that cause developer experience not to be great now when i take a step back and there's a debate out there how should we measure developer experience and you know there's been companies who are saying quantitative metrics is the best way to do it you gotta measure build times you gotta measure flaky tests or how much time I wait for an environment, etc.

44:54And then others say, hey, let's do an academic survey or something like that. I say nobody wins. The most important thing to do is to have a framework to fix the problems. Whatever metrics you collect, whether you do it quant or qual or both of them, it's just the beginning. And the topics you spoke about, like how do I improve the day-to-day of the developers to have a better developer experience? By the way, not because, yeah, some of it is I want my developers to have a world-life balance, etc. But at the end of the day, I want them to be more productive. So what we're missing in this space, I think, and it's hard for me not to say that in Linear B we're attacking this problem is some sort of framework and an infrastructure that will help you solve these problems, that will help you see, hey, you know what?

45:56Reviewing code is like we talked about PRs and small PRs and all that in the previous session. Reviewing code is my bottleneck. Let me deploy an automation or an AI-based solution that helps me overcome this problem. So instead of like staying in the argument, let's take it to the next step let's build like an infrastructure and a product that lets you solve these problems so i think it's really really important to go to the next phase and here's the future that i see maybe it's a bold prediction we started seeing it with customers but i think it's going to get more and more extreme people that have awareness to developer experience and they want to improve it, they're going to go from an hour from commit to production to minutes because they're going to have AI agents working for them, solving pipeline issues.

46:51And people who are stuck behind, they're going to still stay with 20 days of a cycle time. So the gap is going to get so big between these companies. That's one of the problems that I'm really passionate about and I'm eager to help organizations solve this problem. Perhaps in my mind, I think about developer experience. It comes up as a new term and I'm like, what does that even mean? Because we talk to like 6 ,000 companies a year and now there's this trend of developer experience, developer productivity and it's coming up. So when we think about it internally, it's kind of a simple framework where developers are doing so much more.

47:30I told you they're doubling down as data scientists, they're scanning code in some cases, they're taking security responsibility. These are things they want to do. And these are things that have an impact on customers and the business, right? And then there's things that can be automated. Developer experience is like achieving both of those goals. Take the highest impact things and help them do it more effectively. Take the lower impact things that have to be done and automate it, right? And then you iterate on that so that, you know, your most valuable resources, developers, can drive the biggest impact to your business without losing sight of all the other things that need to be done, right?

48:04So finding that balance, I think, is super important. And without kind of focus on developer experience, you can't achieve that. What's encouraging is more and more companies now seem to have like a dedicated title for developer experience. There's a dedicated budget for developer experience. So companies are recognizing that, hey, by focusing on developer experience, you can get a very clear ROI. But driving much more kind of quality code in business output while keeping developers happy so they don't lose, you know, you don't lose them to your competition. Yeah, and this is actually something I would like to take to our audience now.

48:39So how many through a raise of hands have ever heard, usually this comes from a non-engineering person, but have ever heard the statement, I don't understand why we invest in DevX? Have you ever heard that statement? Wow, no one has never heard that. Oh, I've got Tara in the back. Thank you, Tara. Tara, did you successfully navigate that situation and make the argument for DevX? And if so, would you like to come share how you did that? God, I have so many hot takes right now, so I'm trying to focus on this particular question. So, you know, whether you call it developer experience, developer productivity, back in the day we called it, you know, the build release team or the infrastructure team or the platform team, right?

49:17It's the act of supporting the ecosystem and the environment within which a developer works has had many names over the years. And as someone who has done almost entirely this work, most of the time I've had to justify existence because, you know, I'm listening to Dharmesh. You know, it's like, oh, look at the developers focusing on the right thing. How do you define the right thing, I think, is the interesting thing. And so if a platform team, infrastructure team, DevX team is able to be a multiplier and you can show the data that supports that, then that becomes a really easy argument, which is why, you know, things like these reports come out.

49:53I think it's increasingly less of an issue. but for the first 20 years of my career was absolutely an issue and what you had to show every year when budget season came around is what value add are you contributing so I will pause there otherwise I will totally derail your whole conversation yeah I appreciate it that's wonderful so I'd actually like to ask both of you if someone were investing into DevEx today where would you recommend they start? I would say always start with measuring but don't stop there find your best way to measure where it's like I'm a strong believer in quantitative metrics.

50:29I would say like when you're only based on qual, I would give this analogy of like a sales leader coming into a staff meeting, imagine sales leader coming into a staff meeting and saying, I don't need the empiric metrics around my funnel in sales. I don't need to know how much like SQLs, opportunities, customers I have. I'm just basing myself on what the reps are telling me. So I think the same thing needs to happen in engineering. You gotta have improved data, and qualitative can definitely support it. So I would start with measuring, definitely, but it wouldn't stop there. Wouldn't stop there, because the most frustrating thing is to see the problems and not giving tools to fix that.

51:17Yeah, that's actually a great insight. I think I'll just move on to our next prediction, man, And that's, you know, it starts to get into how the roles of developers are likely to change over the coming years. We've talked a little bit tonight about how AI, Gen AI, machine learning stuff like that, that is becoming a thing that really all developers need to be focused on. So developers are going to be asked to have a broader skill set. There's going to be more emphasis on integrating AI and machine learning into applications, using various models. And many developers are going to need to become much more familiar with things like building, deploying, leveraging, monitoring AI models, and integrating them into applications, even if they don't specialize with these tools.

52:06And in fact, there's a lot of products that are coming out that are specifically for developers who aren't specialists in this. there's also we think maybe a good chance the productivity as a whole like is going to start to become a job function for people to the point where we may even see the rise of like devops engineers that like focus more on productivity like a productivity engineer for example and then the last two i actually added at your request or is i'm interested to see what you have to say about them. But, you know, two technologies that really seem to be becoming more commonplace at a pretty rapid rate are cloud-based IDEs and serverless technologies.

52:47So I know some of these get a little groan because we get some groans from people because they've tried these tools in the past and haven't been completely convinced. But, you know, more things are moving into the cloud. They're offering better integrations and debugging and collaboration. And then serverless is just making it easier to decouple development from the actual deployment services. So how do you think that, you know, developers' roles are going to change over the coming years? Yeah, so cloud-based ideas definitely are very interesting in the way they evolve. I actually want to focus on the roles that I see that I think are going to be new.

53:26So we talked about the fact that almost every engineer, Every developer would need to know how do I adopt AI, whether full stack, backend, whatever I do. Then I think that some two interesting roles over this one is the entire, like the thing about InfoSec. I think there's going to be people that specialize in InfoSec. I can see it right now in contracts that we have. Which one does it use? Where do you deploy them? How do we attack IP? How do we make sure that the models don't learn on the data we sent them? There's going to be a role of InfoSec specializing on AI. So that's one thing. And I think there's two interesting roles that I think are going to evolve.

54:14I think there's going to be an end of AI development. And if we build the right infrastructure for these people, they're going to be the people that are going to say, okay, here's where we're allowing agents to take a simple task out of a Jira queue and start working on them. And here's the policy where we're not allowing you to do it. Here is where we're allowing to find a bug and fix it automatically. And here's what we're not allowing you to do. So you're going to have a head of AI development that defines the policies, is implements them. And then you're going to have the practitioners that hopefully they have a product to do it with.

54:59They've kind of like write the rules, write the policies that says like maybe in this microservice, I'm allowing more, maybe in this microservice, um, I'm less permissive. So, I foresee like these two very, very interesting roles, the head of AI development and kind of the practitioner that does it day to day that are going And I don't know if they're going to seek inside a developer experience team or in other teams, but these are two very interesting roles that I can see. Maybe a slight different take is like full stack engineering. It was kind of a merger between front end, back end. I think in the next couple of years, full stack implies front end, back end, security scanning and engineering.

55:42It's like, you know, full stack engineer will expect to touch all those aspects. Right. And the second thing I see changing is even though engineers are not responsible for some of the downstream things when it comes to CICD selection, when it comes to observability tools, it comes to feature flagging tools, if you will, they still become heavy influencers. A lot of developers are trying these tools and influencing what the standard should be for other teams to standardize on. So a lot of purchase decisions within IT are going through the route of developers, trying them and influencing them. And the things developers do kind of encompasses a much larger exposure area, if you will.

56:23But you may ask, how do you do all that? It's because a lot of the work that they had to do, you know, can be automated now, which frees up time for them to do the more strategic work. that's great so i'm wondering from our audience by a show of hands again how many of you have put somebody whose job it is to lead your effort to work ai into your product either on the engineering or the product side yeah i see a couple hands back there do either of you want to share your opinion absolutely so we well it's for us people that already do with ci cd so we have kind of two facets of that one we look at how we can improve the workflow for our customers right so how do we integrate capabilities into our product based on you know i was sparing the details of all that the other is actually that we have a large number of customers who are doing the same thing right so they're trying to figure out how to deliver software with you know ai capabilities everyone described backed by llms how do we help them build and validate those capabilities so they can confidently put them out into production.

57:30So like our whole ecosystem is changing. And I think now I'm going to just go on a tangent and talk about what you were talking about before. But like, as we look at this, I think a lot of what you're, what you're talking about here is like the next year, the next two years, right? It's like, how do we subtly change what we do from a software perspective, right? How do I get some code generated so I don't just write the code kind of thing. But one of the things that we spend a lot of time thinking about, given that we're in the flow of software delivery, is how does software fundamentally change five years from now, 10 years from now?

58:05There was a quote up there about 2040, right? Like, are we just generating the same programming languages that we were writing ourselves in 2024? I don't think so. I think we'll construct software in entirely different ways that we haven't reasoned about yet. And so if you're in the software delivery industry, you need to be thinking about that. Not just like, can I write code faster because I have a coding assistant? But do we write code? Like, is that how we give machine instructions? When the machines are generating the instructions and the machines are receiving the instructions, why are we writing it in a programming language designed for humans, right?

58:41And what happens when, can you just link? Like right now we ask a model, can you please generate a webpage so that if someone hits this URL, this webpage will be returned? Why don't we tell them the model when someone hits that URL, return a web page that looks like this, right? Like, why are we writing code at that point? I don't know what the answer is to that question, but I think there's much more interesting problems five years out and 10 years out than there are in the next 12 months. So we're thinking about all of them. That's my answer. Yeah, and it's great that you can have that long-term insight, too.

59:14You know, it's, I think, very valuable to have. So, yeah, so that brings us to our last prediction that we have. And this is actually one that I added to this list because it's come up in a couple of conversations I've had on Dev Interrupted, specifically one with Burns Rucker here that should be coming out next month in January. And that's the rise of this concept of citizen developers. And specifically, I think you're going to see non-technical and less technical people start to play more technical roles within your organization. Low code, no code. These platforms have been around for a while.

59:49Usually when I bring them up, audiences like this roll their eyes and think, oh, that'll never happen. It's not going to work for us. But these platforms are continuing to evolve and non-developers are being given more and more capabilities to deploy applications, integrate with various systems, with APIs and databases. And non-engineering teams are going to become less dependent on developers to produce things that sometimes actually go into production. It may not be your central app or service, but they are often building things that touch customers in some ways. And as a part of this, I think we're also likely to see quite a few more integrated tool collaboration tools.

1:00:33So, you know, expect more sophisticated tooling that blends developer tools and IDEs with more feature-rich capabilities. So kind of imagine like Google Docs for code. And this would allow teams of all technical levels to collaborate on code, to discuss changes, and resolve issues in environments that are more familiar with them. So I'd like to hear what you all think about this rise. We've already talked about senior developers and how they're likely to be impacted, but there's also going to be a lot of impacts to people who aren't nearly as advanced in their capabilities. So what do you think about that?

1:01:08Yeah, I think it didn't start yesterday. low code, no code is like, especially in internal IT applications, it's getting a lot of momentum. I think AI will accelerate it because if I have a challenge and I don't know what to write in the Apex, you know, trigger inside Salesforce and the custom objects, I will ask GPT and it will tell me the answer. So it will only accelerate like this type of problems. I think just for us, I've seen like three cases lately where we know the go-to-market sales stack where people coming, hey, how can we create a better architecture, et cetera, and all the challenges that we know that are going to come with people that are working with low-code, no-code.

1:01:58I even had Lior, the VP of finances here, saying, hey, can we get somebody to integrate Zapier to another system, et cetera. It's happening all over the place. I think the two challenges that it will bring, number one, it will create a lot of shadow IT, not just a vetted apps that you can't use. Even if it's apps that you can use, you might use them extensively and give them more access that you want to give them. So that's one problem. And the second problem, it will create, unless you put a lot of energy into it and treat it almost like as you know regular development and major technical debt i can see companies that have broken salesforce architecture and the price they pay on the speed of rotomarket operations or others is big so it is interesting it is going to accelerate and the problem is going to get bigger in many ways we kind of seen this before if you remember like 10 years ago it used to be that that any company that was getting started had to first spend$10 million on getting a data center by servers.

1:03:11And then cloud came along and you're like, oh, I can build an application on AWS in a matter of, you know, months and, you know, for one-tenth the cost, right? And then the focus shifted to software engineering. Now the same thing seems to be happening here. Now it feels like, hey, software developers can get the first application going. You need a citizen developer who can build it. A product manager can use a natural language interface and get some prototype of a product they can test with the customer. And we're seeing this happen. I've never seen companies that are 5, 10 people who get the first product out in six months and get to like$2 million in revenue across 100 customers.

1:03:49You're like, wow, this is crazy. And I think the trend it's pointing to is that it's becoming much easier to generate logical blocks of code using AI and automate the pull request merges and downstream delivery of that code and ultimately test with customers much faster. So this trend is going to continue. And as a result of that, I think the emphasis of software is going to focus a lot more on customer delight, you know, the user experience, time to value. But I think it definitely accelerates the pace of innovation. The same way we saw cloud accelerate the pace of, you know, company launches 10 years ago.

1:04:30Yeah, and I think one thing that sometimes gets overlooked that's really critical in this is that when you have people getting involved in the development process who don't have a lot of experience doing it, they aren't familiar at all with the processes that a typical development team works. So they may not even know things as simple as like, PR should be smaller because they're easier to review, right? Like, so there's actually a level of just normalizing that has to happen often with when you have large, and we've seen this with larger companies we've spoken to where they hire, you know, large numbers of developers straight out of college who maybe come from less technical backgrounds and just some of the most basic practices that developers normalize pretty quickly from maybe just a year or two experience these people have almost no awareness of so you know being able to like establish norms around how what we expect in our code making sure that you also use the same tools that you use for your development stats even if it's low code it should still be run through your ci cne system and have a qa process and all the various typical things that would come along with software development but you're often often dealing with the group of people that really don't have a lot of experience with those things and i think that has to be accounted for yeah it's even like most of the code you develop in salesforce and in these it applications it's not even like i'm maintained in you know in source control or it's local and to the environments.

1:05:57I know there's companies who are trying to solve this problem, but yeah, the practices and the methodologies are behind. Yeah, so those are our predictions for today. And unfortunately, we don't have time for a Q &A because we're a little behind our schedule. But Ori, Dharmesh, I want to thank you for coming in today. So if you all can give him a round of applause. Thank you very much.