WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=XqF-IFHBCkM

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/XqF-IFHBCkM.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:01.309 --> 00:00:03.309
[music]

s2
00:00:12.560 --> 00:00:13.880
Um we'll get started.

s3
00:00:13.880 --> 00:00:19.160
I'll introduce my fellow panelists in a second, but just to set the context of what we are going to talk about.

s4
00:00:19.160 --> 00:00:26.920
Um you know, in the last 6 months or a year or so, almost every company has been trying to deploy AI or agents in their workflow.

s5
00:00:26.920 --> 00:00:33.400
Um we did some research on this, and I'm sure it's the same for a lot of organizations around the world that they have seen this.

s6
00:00:33.400 --> 00:00:40.640
Basically, 80-90% of the companies that you ask, they say we have deployed AI or agents in some shape or format.

s7
00:00:40.640 --> 00:00:46.480
But when you ask them how many of them have actually scaled, or how many of them are seeing business impact from it, it's less than a third.

s8
00:00:46.480 --> 00:00:49.200
Um right, and there are a lot of reasons behind that.

s9
00:00:49.200 --> 00:00:56.400
We have seen a lot of companies doing it in POCs and small environments, but not actually across end-to-end um organizations.

s10
00:00:56.400 --> 00:00:57.120
So, what gives, right?

s11
00:00:57.120 --> 00:01:00.080
Like, what was the reason why that doesn't happen?

s12
00:01:00.080 --> 00:01:11.160
Um we worked with Sonar um Tariq to figure out what are the key factors that actually helps organizations scale if you're deploying AI in your software development life cycle.

s13
00:01:11.160 --> 00:01:13.120
Um and we saw some really good results.

s14
00:01:13.120 --> 00:01:13.960
Not surprising, right?

s15
00:01:13.960 --> 00:01:24.400
Like, anybody who's doing this at scale is actually seeing pretty good results in terms of PR throughput, PR cycle time, um self-reported productivity gains in tasks in the SDLC.

s16
00:01:24.400 --> 00:01:28.800
Um and we put these organizations on a scale of maturity, essentially.

s17
00:01:28.800 --> 00:01:40.360
So, if you think about where companies are today, most of them are in what we call Horizon 2, where you have human-guided and validated agents that are executing tasks across SDLC.

s18
00:01:40.360 --> 00:01:46.280
But very few companies are on the Horizon 3 on the right-hand side, where it's fully end-to-end automated workflow, right?

s19
00:01:46.280 --> 00:01:48.200
With human oversight.

s20
00:01:48.200 --> 00:01:55.120
Um and the things that we found when we were doing this work with them was there are three factors that actually help this, not surprisingly.

s21
00:01:55.120 --> 00:02:04.200
One is redesigning your process workflow, which is you are not thinking about a traditional SDLC, you are thinking about redesigning the entire workflow end-to-end.

s22
00:02:04.200 --> 00:02:07.040
You are thinking about how agents are changing that stuff.

s23
00:02:07.040 --> 00:02:08.360
Second is tooling, obviously.

s24
00:02:08.360 --> 00:02:17.680
Whether you have good agents, whether you have good harnesses, whether you have good context layers, etc. But the more critical thing that people have often overlooked is the people part.

s25
00:02:17.680 --> 00:02:17.840
Right?

s26
00:02:17.840 --> 00:02:33.520
So, when we were doing this work, we have recognized this across many, many, many pilots or scaling that we've done is that boundaries of how you traditionally define your roles, what a software engineer was, what a product manager was, what a designer was, they have started to blur.

s27
00:02:33.520 --> 00:02:44.920
And organizations that have recognized that those boundaries are changing and have actually remodeled their entire operating model around that are the ones that are seeing the promised land of 10x productivity

s28
00:02:44.920 --> 00:02:46.640
from AI and agents.

s29
00:02:46.640 --> 00:02:50.240
And And as we were doing this work with him, we'll talk about it a little bit more.

s30
00:02:50.240 --> 00:02:56.520
We saw that, you know, people who were skeptical about this, like, "Hey, agents will do the task, but we don't need to touch anything else."

s31
00:02:56.520 --> 00:02:59.959
They gradually then were converts into, "Okay, this makes sense.

s32
00:02:59.959 --> 00:03:04.480
We need to rethink and reshape how our orgs are going to be organized."

s33
00:03:04.480 --> 00:03:11.080
So, with that, I will invite our panelist, Tariq, CEO of Sonar, and Ali, CEO of Gitai, to the stage.

s34
00:03:11.080 --> 00:03:12.040
We'll have a Q&A.

s35
00:03:12.040 --> 00:03:19.080
We'll leave some time at the end for questions if we can, so you guys should also ask, but please Awesome.

s36
00:03:19.080 --> 00:03:28.400
Um I think to start with Tariq, I'll probably ask this question to you first, you know, for companies that are going through this transition, going to Horizon 2 and beyond,

s37
00:03:28.400 --> 00:03:36.880
um what are some guidelines or learnings that you have that you can share with them on what things they should watch out for as they're transitioning toward a full-scale,

s38
00:03:36.880 --> 00:03:40.160
end-to-end, orchestrated, agentic pipeline?

s39
00:03:40.160 --> 00:03:40.800
Hi, everyone.

s40
00:03:40.800 --> 00:03:43.880
Um thank you, Prakhar, for having us here today as well.

s41
00:03:43.880 --> 00:03:45.160
You can all hear me, I assume.

s42
00:03:45.160 --> 00:03:45.840
You can hear okay?

s43
00:03:45.840 --> 00:03:46.920
Yeah, okay.

s44
00:03:46.920 --> 00:03:47.920
You need it higher?

s45
00:03:47.920 --> 00:03:48.600
Okay.

s46
00:03:48.600 --> 00:03:49.239
Little bit higher?

s47
00:03:49.239 --> 00:03:50.680
All right, perfect.

s48
00:03:50.680 --> 00:03:59.480
Um So, you know, we we as Prakhar said been going through this journey of how do you use AI responsibly in the organization?

s49
00:03:59.480 --> 00:04:02.160
How do you actually uh transform an organization?

s50
00:04:02.160 --> 00:04:06.920
If you don't know us, we started off as an open-source project 18 years ago.

s51
00:04:06.920 --> 00:04:17.440
Uh so, while we're very proud of everything we're doing in the AI world, it has been a bit of a transformation for our engineering team to get used to the new tools, to really figure out how to adopt it in a native

s52
00:04:17.440 --> 00:04:18.239
way.

s53
00:04:18.239 --> 00:04:24.680
And um a part of this has really been about being super clear about what the objective is.

s54
00:04:24.680 --> 00:04:28.240
And the objective was never for us token maxing or anything like this.

s55
00:04:28.240 --> 00:04:30.800
We don't really like that uh type of idea.

s56
00:04:30.800 --> 00:04:33.960
The idea is how do you really generate real value.

s57
00:04:33.960 --> 00:04:38.160
Um and so, see being super clear about what you're measuring was really important for us.

s58
00:04:38.160 --> 00:04:44.040
I think the second piece is um being very deliberate about what the process is that we're putting in place, right?

s59
00:04:44.040 --> 00:04:55.160
And if you heard my talk I just gave a little bit ago, we've orchestrated everything around how do you actually do this guide verify solve model inside of our company as

s60
00:04:55.160 --> 00:04:58.120
just like we recommend doing it inside of everyone else's company.

s61
00:04:58.120 --> 00:05:02.560
And so, this notion of how do you construct the tooling is really important.

s62
00:05:02.560 --> 00:05:08.840
How do you construct the systems that we're talking about is really quite critical uh as well.

s63
00:05:08.840 --> 00:05:14.960
Um getting the team to trust the agents, right?

s64
00:05:14.960 --> 00:05:20.800
As working with the McKinsey team, we actually looked at what we're doing and our team had built a bunch of agents themselves.

s65
00:05:20.800 --> 00:05:30.800
But, there are things like PRD agents and how do we really capture what's in the PRD and use that to generate the e-vals that we're using to generate the the the um

s66
00:05:30.800 --> 00:05:36.520
uh I output verification, these things um were not natural to the team.

s67
00:05:36.520 --> 00:05:45.320
And part of what we needed to do was set up these lighthouse teams to really try and highlight the best practice ways of doing this.

s68
00:05:45.320 --> 00:05:56.160
Frankly, the part that has been most surprising to me is that I thought that once you have these lighthouse teams who were operating in this way, the other teams would be able to follow

s69
00:05:56.160 --> 00:05:57.160
super quickly.

s70
00:05:57.160 --> 00:05:57.560
Yeah.

s71
00:05:57.560 --> 00:05:58.880
Almost through the role modeling.

s72
00:05:58.880 --> 00:06:01.200
And what we found is that's not actually the case.

s73
00:06:01.200 --> 00:06:08.960
That that role modeling gives you part of the way there, and you can set up the tooling, and you can do all of this stuff, but the next piece

s74
00:06:08.960 --> 00:06:17.880
of of actually getting them to think differently, to understand why they're using these agents, etc., is one of the critical missing links here.

s75
00:06:17.880 --> 00:06:19.080
Since the last time.

s76
00:06:19.080 --> 00:06:20.400
Ali, maybe a question for you.

s77
00:06:20.400 --> 00:06:29.480
We have seen that smaller teams actually have a much better chance of scaling agents because there are less dependencies, less um challenges to overcome.

s78
00:06:29.480 --> 00:06:34.960
What can organizations that are at much larger scale learn from those um teams, right?

s79
00:06:34.960 --> 00:06:37.320
Yes, so first of all, uh it's great to be here.

s80
00:06:37.320 --> 00:06:38.440
Uh I'm Ali.

s81
00:06:38.440 --> 00:06:43.240
I was previously the CEO of Gitarr, and now we're actually part of Sonar.

s82
00:06:43.240 --> 00:06:47.919
Um and uh before joining Sonar, I was the CEO of Gitarr.

s83
00:06:47.919 --> 00:06:50.960
In Gitarr, we were a small startup.

s84
00:06:50.960 --> 00:06:51.160
Yeah.

s85
00:06:51.160 --> 00:06:54.120
Um only about five, six people.

s86
00:06:54.120 --> 00:06:59.760
And uh we were building an agentic solution for validating PRs.

s87
00:06:59.760 --> 00:07:02.520
Uh so, the entire workflow for PR validation.

s88
00:07:02.520 --> 00:07:09.120
And then before that, I was at Uber, where I was responsible for the entire developer platform organization.

s89
00:07:09.120 --> 00:07:18.600
So, it's an organization I built responsible for you know, making sure that all developers are productive and happy, and that the company is moving at a very fast pace in terms of velocity

s90
00:07:18.600 --> 00:07:20.000
with high quality.

s91
00:07:20.000 --> 00:07:28.560
So, I've kind of seen both um large company and running developer organizations in a large company, and then operating in a startup world.

s92
00:07:28.560 --> 00:07:36.320
And uh when we started Gitarr, uh we actually weren't AI-first, and then we quickly transitioned to become AI-first.

s93
00:07:36.320 --> 00:07:50.400
And once we made that transition in terms of adopting AI internally, as well as building AI products, we saw both an acceleration in demand, but also we were able to get a tremendous amount done with a much fewer,

s94
00:07:50.400 --> 00:07:52.600
smaller sized team.

s95
00:07:52.600 --> 00:07:55.760
So, I've kind of seen both sides of things.

s96
00:07:55.760 --> 00:08:05.120
And I think as you think about how do you take the learnings from a small company and scale it up into a large company, actually large companies have a structural advantage

s97
00:08:05.120 --> 00:08:20.360
because typically as you scale your engineering org and you get to a large enough size, you have a platform team, which was exactly my responsibility when I was at at Uber and you know, the roles I had in the past like at Google and Facebook were all about platform organizations.

s98
00:08:20.360 --> 00:08:29.120
So, there's already an organization there that's responsible for driving standards and making sure that developers are productive and and happy.

s99
00:08:29.120 --> 00:08:38.400
And I think there's a couple of principles that are important to follow as a platform team when you're looking at how do we adopt these tools?

s100
00:08:38.400 --> 00:08:41.960
One is to have really good metrics in place.

s101
00:08:41.960 --> 00:08:54.280
I think you you mentioned it, but this is not always an obvious thing for large organizations because it's actually very hard to drive enough standards across the organization so that then you have

s102
00:08:54.280 --> 00:09:01.360
telemetry that you can actually get to understand how fast am I able to ship code into production?

s103
00:09:01.360 --> 00:09:05.320
What is the productivity of engineers in terms of throughput?

s104
00:09:05.320 --> 00:09:06.720
What does the quality look like?

s105
00:09:06.720 --> 00:09:11.120
How often am I erring and going back to the beginning of my workflow?

s106
00:09:11.120 --> 00:09:13.560
And what's the sentiment of engineers?

s107
00:09:13.560 --> 00:09:18.320
As we are speeding things up, making things more productive, are engineers actually feeling it?

s108
00:09:18.320 --> 00:09:30.400
So, I think it's very, very important to have that kind of developer productivity and metrics in place as a baseline so that as you add AI and agents into your tool chain and into your PDLC,

s109
00:09:30.400 --> 00:09:34.839
you can actually measure and and iterate and quickly improve and adjust.

s110
00:09:34.839 --> 00:09:36.880
So, I I that's number one.

s111
00:09:36.880 --> 00:09:46.960
Number two, I think again you mentioned is very important also to look at it in terms of the entire life cycle and not in terms of introducing tools into one specific

s112
00:09:46.960 --> 00:09:48.320
part of the life cycle.

s113
00:09:48.320 --> 00:09:52.960
So, think in terms of the entire life cycle and in terms of entire workflows.

s114
00:09:52.960 --> 00:10:06.480
So, how can you automate entire workflows and take make developers more efficient by offloading entire workloads to agents that can autonomously act and deliver outcomes that are the outcomes of those workflows.

s115
00:10:06.480 --> 00:10:18.120
And I think the third thing um I you know, in my experience as part of a platform having run platform teams in the past is to make sure you're actually paying attention to developers' time.

s116
00:10:18.120 --> 00:10:22.160
And optimizing for keeping developers in the flow

s117
00:10:22.160 --> 00:10:22.680
Yeah.

s118
00:10:22.680 --> 00:10:26.680
and automating away as much grunt work as possible.

s119
00:10:26.680 --> 00:10:28.040
Um and

s120
00:10:28.040 --> 00:10:28.880
to do grunt work.

s121
00:10:28.880 --> 00:10:31.400
No, but agents are perfect for that, right?

s122
00:10:31.400 --> 00:10:42.000
So, if you can really deploy agents to taking entire workflows that are grunt work off the plate of uh folks, then that's where you get I think big not only productivity gains

s123
00:10:42.000 --> 00:10:52.440
and velocity increases, but also developers feel it and you get the high sentiment, which is equally important if not the most important thing I would say.

s124
00:10:52.440 --> 00:10:55.040
So, that's how I would kind of approach the problem.

s125
00:10:55.040 --> 00:10:56.680
Yeah, makes sense.

s126
00:10:56.680 --> 00:10:58.680
Um I think maybe a question for you.

s127
00:10:58.680 --> 00:11:04.080
So, as agents get more embedded into the workflows, the LLMs get better at their job.

s128
00:11:04.080 --> 00:11:10.960
We assume that there will be a point when you have a fully automated end-to-end orchestrated SDLC or PDLC.

s129
00:11:10.960 --> 00:11:19.200
What implications does that have on people, on org, on operating model of the future for any software organization?

s130
00:11:19.320 --> 00:11:25.200
Yeah, I think um there's there's a you know, the models are clearly getting better.

s131
00:11:25.200 --> 00:11:32.800
Uh I recommend Tropic talked about the fable models and you know, I'm looking forward to getting my hands on it to start start using it, right?

s132
00:11:32.800 --> 00:11:41.000
Um I I think you can you can see a world in which this this software factory idea really starts to come to life.

s133
00:11:41.000 --> 00:11:45.240
Um I think you used the keyword, in my opinion, which is orchestrated, right?

s134
00:11:45.240 --> 00:11:51.120
Um because I don't think that there's going to be a world in which you can be completely hands-off.

s135
00:11:51.120 --> 00:11:59.760
I think the question is how much do you leave to the machine, how much you leave to the agent, and how much do you um how much do you control on the outset.

s136
00:11:59.760 --> 00:12:05.800
So, what is the specification, what is important to you, what does success look like are all really important elements.

s137
00:12:05.800 --> 00:12:09.680
You have to, I think, continue to have people who are involved with this.

s138
00:12:09.680 --> 00:12:17.960
So, from a skill set standpoint, there's a lot of talk about how software developers need to become architects and and orchestrators and managers of agents, things like that.

s139
00:12:17.960 --> 00:12:20.200
And I think there's a lot of truth to this.

s140
00:12:20.200 --> 00:12:26.800
One thing that I think is an incredibly important skill set is there's a lot that we keep in our head.

s141
00:12:26.800 --> 00:12:34.880
If you think about how you design software, how you build software today, there's certain things that are in your PRD, and there's a bunch of things that you just know, right?

s142
00:12:34.880 --> 00:12:41.560
My company likes to do things this way, my company likes this sort of code, we like this dependency, we like the whatever it is.

s143
00:12:41.560 --> 00:12:46.440
And there's going to be a lot more that needs to be made explicit as opposed to implicit, right?

s144
00:12:46.440 --> 00:12:49.280
And that's actually there's a skill set associated with this.

s145
00:12:49.280 --> 00:12:55.760
So, I think in addition to being an architect and all of that, you have to start thinking in a much more explicit way.

s146
00:12:55.760 --> 00:12:57.280
This is thing number one.

s147
00:12:57.280 --> 00:13:04.600
I think thing number two, you know, my kid my my oldest son is about to go to college and he's like trying to figure out what to study and all of this.

s148
00:13:04.600 --> 00:13:12.200
And the piece of advice that I keep giving him is the most important piece is to be critical amazing at critical thinking, right?

s149
00:13:12.200 --> 00:13:21.839
Because the the point that I read on Twitter and I'm I'm shamelessly stealing it is that AI always gives you very high conviction plausible output, right?

s150
00:13:21.839 --> 00:13:27.720
Um it always sounds correct, it never admits to any doubt whatsoever, it never says I think the answer is this."

s151
00:13:27.720 --> 00:13:29.880
It always just says, "The answer is this."

s152
00:13:29.880 --> 00:13:35.640
And I think the job of the people in the system is going to be to say, "Where do I need to question it?

s153
00:13:35.640 --> 00:13:38.920
Where do I need to um well, where do I need to poke?

s154
00:13:38.920 --> 00:13:42.480
What are the things" kind of the same way that you do this with your team, right?

s155
00:13:42.480 --> 00:13:48.800
If you have somebody joining your team, you have an intern joining your team, you're going to kind of know where to poke.

s156
00:13:48.800 --> 00:13:50.040
You're going to know where to look.

s157
00:13:50.040 --> 00:13:52.280
What questions to ask, what to look for.

s158
00:13:52.280 --> 00:13:54.720
I think that skill set is also super important.

s159
00:13:54.720 --> 00:14:06.680
Last point to the question you and Ali were talking about, you know, um there's a lot of resistance that I see in the organizations we work with to this idea of smaller teams, right?

s160
00:14:06.680 --> 00:14:12.320
Um and this idea of of working in a smaller atomic unit.

s161
00:14:12.320 --> 00:14:25.400
I think the the the the pushback when you get underneath it, in my experience, is almost always, "But I'm a front-end person and I'm not a back-end person or I'm a this you know what I I'm and we have historically

s162
00:14:25.400 --> 00:14:27.920
gotten to a world where we segregate roles quite a bit.

s163
00:14:27.920 --> 00:14:29.280
We silo people.

s164
00:14:29.280 --> 00:14:32.240
And I think this is the era of the generalist, right?

s165
00:14:32.240 --> 00:14:42.000
And I'm not saying that somebody who knows nothing about software generalist, but like your software engineering generalist is, I think, going to be a much more important uh thing

s166
00:14:42.000 --> 00:14:48.120
than do you know, you know, are you super deep in front-end or server-side or whatever it happens to be.

s167
00:14:48.120 --> 00:14:48.960
Yeah.

s168
00:14:48.960 --> 00:14:53.760
Um I think following up on that, Ali, I know you've talked about this at other forums as well.

s169
00:14:53.760 --> 00:14:58.080
A lot of the coding part of the SDLC is, quote unquote, solved.

s170
00:14:58.080 --> 00:15:11.920
And so, focus, rightfully, is shifting now towards other parts, um the requirement generation, the validation, the testing, etc. Do you think we are at a point or we will get to a point in the next 3 months, 6 months where the trust in the agents to automate all of this will go high?

s171
00:15:11.920 --> 00:15:20.360
Because right now, I think everyone is skeptical of whether you can automate your validation, your testing, your integration testing, etc. How do you see that?

s172
00:15:20.360 --> 00:15:24.160
Has it shifted already or is it on a curve to shift?

s173
00:15:24.160 --> 00:15:28.680
I think uh trust is the the keyword here.

s174
00:15:28.680 --> 00:15:31.720
And uh trust I think is going to come time.

s175
00:15:31.720 --> 00:15:46.680
And so uh you know, what we're seeing is our users uh over time as they work with the tools uh and they see the precision of the AI, it's that precision that gives them the trust that then uh

s176
00:15:46.680 --> 00:15:49.360
allows them to unlock more and more levels of automation.

s177
00:15:49.360 --> 00:15:49.960
Yeah.

s178
00:15:49.960 --> 00:15:56.640
Uh to the point where, you know, changes can completely autonomously kind of flow through into your code base into production.

s179
00:15:56.640 --> 00:15:57.240
Yeah.

s180
00:15:57.240 --> 00:16:09.720
Um for example, um in with our users in Guitar and the automation that we have in Guitar, the typical pattern we see is at first they just use reviews.

s181
00:16:09.720 --> 00:16:12.240
And look at the CI failure analysis that we produce.

s182
00:16:12.240 --> 00:16:12.720
Yeah.

s183
00:16:12.720 --> 00:16:20.000
Uh and over time when they see, "Okay, actually these are very precise actual bugs in the code that are being uncovered."

s184
00:16:20.000 --> 00:16:23.160
They say, "Okay, uh I'm actually not going to give the agent some teeth.

s185
00:16:23.160 --> 00:16:30.720
I'm going to now set up some rules to block if there are any issues that are uncovered by the agent."

s186
00:16:30.720 --> 00:16:39.440
So, now you've kind of moved one step in the automation to Not only do you have reviews that you trust, now you're actually trust them enough that they're high

s187
00:16:39.440 --> 00:16:41.480
the signal enough that you're blocking.

s188
00:16:41.480 --> 00:16:47.640
Then typically what happens is they start playing around with automated fix uh features.

s189
00:16:47.640 --> 00:16:51.280
Okay, let me let me ask the agent to go ahead and fix some of these issues.

s190
00:16:51.280 --> 00:16:52.320
Create a PR to see how

s191
00:16:52.320 --> 00:16:57.680
Yeah, fix the CI failures, fix all the issues that you're uh uncovering.

s192
00:16:57.680 --> 00:17:02.240
And then when you see the precision of that, that okay, actually the fixes are working as well.

s193
00:17:02.240 --> 00:17:11.959
Uh it's producing fixes that don't introduce new problems, they pass build, um and they can iterate to actually pass the build until it's green, then they unlock auto fix.

s194
00:17:11.959 --> 00:17:18.760
So, now they've taken one more step towards, "Hey, I'm going to When a PR is created, a review happens.

s195
00:17:18.760 --> 00:17:20.839
If there are critical issues, it gets blocked.

s196
00:17:20.839 --> 00:17:28.240
Then the system start iterating and makes everything green, fixes all the CI failures, all the um you know, good review issues.

s197
00:17:28.240 --> 00:17:32.280
And now you've delivered green PRs that are ready for somebody to approve.

s198
00:17:32.280 --> 00:17:41.840
And then here's where the big shift is beginning to happen now, which is you know, uh there are some parts of the code base and some kind of PRs that I'm comfortable

s199
00:17:41.840 --> 00:17:44.400
having the system approve.

s200
00:17:44.400 --> 00:17:44.520
Right?

s201
00:17:44.520 --> 00:17:49.080
And so now we're beginning to see users put in rules to say, "You know what?

s202
00:17:49.080 --> 00:17:51.560
If you're touching this part of the code base, it's not critical.

s203
00:17:51.560 --> 00:17:56.640
Or if the PR is making this type of change, go ahead and automatically approve it."

s204
00:17:56.640 --> 00:17:59.920
So now you've gone from PR creation all the way through approval.

s205
00:17:59.920 --> 00:18:03.200
And now only thing that's left is somebody to come in and and merge.

s206
00:18:03.200 --> 00:18:09.600
And that's the next step as well that we're seeing happen, too, which is go ahead and merge, fix any kind of merge conflicts.

s207
00:18:09.600 --> 00:18:15.880
And now what you've got is fully autonomous end-to-end PR creation through merge is fully auto- automated.

s208
00:18:15.880 --> 00:18:17.800
But it doesn't come immediately.

s209
00:18:17.800 --> 00:18:17.960
Right?

s210
00:18:17.960 --> 00:18:25.800
It comes with using the system, building trust that the agent that you're working with is actually uh precise.

s211
00:18:25.800 --> 00:18:28.080
Um there's enough context that's flowing in.

s212
00:18:28.080 --> 00:18:32.600
You know, I've set up enough rules and guardrails that I'm now comfortable with the system being fully autonomous.

s213
00:18:32.600 --> 00:18:32.960
Right?

s214
00:18:32.960 --> 00:18:36.640
So I think to answer your question, we're rapidly approaching that.

s215
00:18:36.640 --> 00:18:41.760
It's I think within the next year uh we'll see more and more teams, you know, along this journey.

s216
00:18:41.760 --> 00:18:45.400
And some of these uh teams that I'm seeing are actually in large companies.

s217
00:18:45.400 --> 00:18:47.960
Which is uh pretty interesting.

s218
00:18:47.960 --> 00:18:49.520
Um I think that's our time.

s219
00:18:49.520 --> 00:18:52.320
Thank you so much for being here and answering questions.

s220
00:18:52.320 --> 00:18:52.880
Thank you.

s221
00:18:52.880 --> 00:18:54.473
Thank you all.

s222
00:18:54.473 --> 00:18:56.473
[applause]