1
00:00:00,040 --> 00:00:04,640
Probabilistic code is you just 
vibe coding cute ideas and put 

2
00:00:04,640 --> 00:00:08,200
on the website and you can get 
away with this if you are start 

3
00:00:08,200 --> 00:00:12,680
up at coffee shop but if you are
regulated industry you need 

4
00:00:12,720 --> 00:00:17,400
deterministic code. 
Chris Tokashevsky is Group Chief

5
00:00:17,400 --> 00:00:22,280
Technology Information Officer 
of Vitality, A multinational 

6
00:00:22,280 --> 00:00:28,000
insurer with 14,000 employees. 
He's at Blitzie's headquarters 

7
00:00:28,000 --> 00:00:32,640
rethinking Vitality software 
process using autonomous AI. 

8
00:00:32,920 --> 00:00:37,120
Our legacy systems were not 
scaling fast enough, so we 

9
00:00:37,120 --> 00:00:42,240
embarked on modernization plan 
to scale them up faster and 

10
00:00:42,240 --> 00:00:45,120
future proof the business. 
We see ourselves as a 

11
00:00:45,120 --> 00:00:49,600
challengers in the UK market. 
We've got about 12% market share

12
00:00:49,880 --> 00:00:54,400
and we compete against large 
institutions that have been in 

13
00:00:54,400 --> 00:00:56,000
business for like hundreds of 
years. 

14
00:00:56,200 --> 00:01:01,640
So as a challenger, we are 
growing and we need flexibility.

15
00:01:02,200 --> 00:01:07,360
So opportunities are all over 
the place and our systems have 

16
00:01:07,360 --> 00:01:10,240
to be flexible to capitalize on 
those opportunities. 

17
00:01:10,880 --> 00:01:17,040
So we've realized that that 
flexibility has to manifest 

18
00:01:17,040 --> 00:01:20,880
itself in the systems because 
when there's new market 

19
00:01:20,880 --> 00:01:24,480
opportunity, we need to build 
products and services that 

20
00:01:24,480 --> 00:01:27,120
actually that actually support 
those those market needs. 

21
00:01:27,320 --> 00:01:30,520
So we've been modernizing our 
systems for quite a while. 

22
00:01:30,960 --> 00:01:37,320
We are building event driven 
architecture that supports our 

23
00:01:37,320 --> 00:01:43,120
product requirements. 
So as our R&D colleagues come up

24
00:01:43,120 --> 00:01:45,920
with new products and services, 
we want to launch in the product

25
00:01:46,040 --> 00:01:50,720
that we want to launch in the 
market, rebuilding micro 

26
00:01:50,720 --> 00:01:54,120
services, which actually event 
driven services. 

27
00:01:54,520 --> 00:02:00,360
And that's quite important from 
a customer perspective because 

28
00:02:00,880 --> 00:02:04,880
historically it was OK to make a
phone call to an insurance 

29
00:02:04,880 --> 00:02:09,280
company and make a request and 
somebody would do something. 

30
00:02:09,600 --> 00:02:12,080
Nowadays everything happens in 
real time. 

31
00:02:12,680 --> 00:02:15,760
So in order to be able to 
service our customers in real 

32
00:02:15,760 --> 00:02:20,120
time, you need event driven 
architecture and event driven 

33
00:02:20,120 --> 00:02:22,960
services. 
And also when it comes to the 

34
00:02:23,200 --> 00:02:30,040
agentic AI and AI war that we 
entering into event driven 

35
00:02:30,040 --> 00:02:34,520
services and natural partners of
agentic AI. 

36
00:02:35,200 --> 00:02:40,080
So when you combine event driven
services with agentic AI, now 

37
00:02:40,120 --> 00:02:44,120
you've got a very powerful 
combination because they 

38
00:02:44,120 --> 00:02:49,680
actually like amplifiers that AI
is amplifying the event driven 

39
00:02:49,680 --> 00:02:54,280
capabilities and the event 
driven capabilities can leverage

40
00:02:54,280 --> 00:02:57,400
the AI capabilities and 
ultimately we can service our 

41
00:02:57,600 --> 00:03:03,080
our members better in that way. 
You're using autonomous 

42
00:03:03,080 --> 00:03:05,840
development working with 
Blitzie. 

43
00:03:06,000 --> 00:03:08,040
With Blitzie, we're doing number
of things. 

44
00:03:08,120 --> 00:03:10,960
Autonomous development is part 
of it. 

45
00:03:11,240 --> 00:03:15,200
Because we are in the regulated 
industry, the autonomous 

46
00:03:15,200 --> 00:03:19,440
development has to be augmented 
with other processes. 

47
00:03:20,040 --> 00:03:24,160
So we call it AI, native 
software development life cycle 

48
00:03:24,920 --> 00:03:27,440
and then autonomous development 
is just part of it. 

49
00:03:27,600 --> 00:03:31,880
But actually development life 
cycle spends right across. 

50
00:03:32,240 --> 00:03:35,040
I'm looking at what are the 
limiting factors. 

51
00:03:35,520 --> 00:03:39,920
So what is slowing us down 
because what happens is AI is 

52
00:03:39,960 --> 00:03:44,880
accelerating specific processes 
and it exposes are the 

53
00:03:44,880 --> 00:03:48,040
bottlenecks. 
So it's it's a continuous 

54
00:03:48,720 --> 00:03:52,400
refocusing of the team. 
Now we've automated this part of

55
00:03:52,400 --> 00:03:56,240
the business or this part of the
Sdoc process. 

56
00:03:57,400 --> 00:03:59,720
What limiting factors have been 
exposed? 

57
00:04:00,600 --> 00:04:04,200
So for example, we were able to 
generate the code very fast. 

58
00:04:04,880 --> 00:04:06,600
Now who's going to review that 
code? 

59
00:04:07,160 --> 00:04:11,680
So if we generated to, let's say
100,000 lines of code, who is 

60
00:04:11,680 --> 00:04:15,800
going to review 100,000 lines of
code and probably not a human, 

61
00:04:15,800 --> 00:04:20,560
We're going to need another AI 
to review that AIAI developed 

62
00:04:20,560 --> 00:04:23,920
code and then have a human 
review that part. 

63
00:04:24,240 --> 00:04:28,280
So it's a continuous process of 
optimizing the throughput. 

64
00:04:28,800 --> 00:04:33,800
So I'm quite keen on optimizing 
the throughput because local 

65
00:04:33,800 --> 00:04:38,280
efficiency does not translate 
into overall throughput. 

66
00:04:38,840 --> 00:04:41,880
So you have to optimize the 
entire software developer 

67
00:04:42,000 --> 00:04:45,080
delivery life cycle to achieve 
optimal throughput. 

68
00:04:45,480 --> 00:04:50,560
So you're working with Blitzy 
and you have essentially 

69
00:04:50,560 --> 00:04:56,360
reimagined that entire software 
development life cycle. 

70
00:04:56,560 --> 00:05:00,600
That's exactly right. 
We asking ourselves what are the

71
00:05:00,600 --> 00:05:04,760
limiting factors in our software
development life cycle process? 

72
00:05:05,120 --> 00:05:11,280
How do we leverage AI in that 
process to our advantage so that

73
00:05:11,320 --> 00:05:16,920
we get we generate better code, 
higher quality at the faster 

74
00:05:17,000 --> 00:05:20,640
velocity and that translates 
into throughput? 

75
00:05:21,120 --> 00:05:25,440
Clearly this requires an end to 
end platform rather than 

76
00:05:25,440 --> 00:05:29,240
specific point solutions. 
That's exactly right. 

77
00:05:29,320 --> 00:05:33,120
You do need to have an 
integrated platform that 

78
00:05:33,240 --> 00:05:37,120
automates and integrates the 
entire software development life

79
00:05:37,120 --> 00:05:40,840
cycle to achieve optimal 
throughput. 

80
00:05:41,760 --> 00:05:46,560
Because if you've got fragmented
process, that fragmented process

81
00:05:46,560 --> 00:05:50,000
is going to manifest itself in 
bottlenecks, which I call 

82
00:05:50,000 --> 00:05:53,840
limiting factors. 
If you've got integrated process

83
00:05:53,840 --> 00:05:57,960
with integrated tooling, you can
achieve optimal velocity, 

84
00:05:57,960 --> 00:06:01,560
quality and throughput. 
Where does Blitzie fit into 

85
00:06:01,600 --> 00:06:04,360
this? 
We started with Blitzie on 

86
00:06:04,440 --> 00:06:09,040
reverse engineering of legacy 
code and we've learned very 

87
00:06:09,040 --> 00:06:12,920
quickly that Blitzy is an 
excellent reverse engineering 

88
00:06:12,920 --> 00:06:16,040
tool. 
But then we quickly learned that

89
00:06:16,040 --> 00:06:22,920
Blitzy can also generate a high 
quality deterministic code. 

90
00:06:23,560 --> 00:06:27,720
And it is massively important 
the insurance business because 

91
00:06:27,720 --> 00:06:32,960
many of AI companies can 
generate probabilistic code and 

92
00:06:32,960 --> 00:06:37,840
probabilistic code you just vibe
coding cute ideas and put on the

93
00:06:37,840 --> 00:06:40,160
website. 
And you can get away with this 

94
00:06:40,160 --> 00:06:44,120
if you are start up at coffee 
shop or some other company. 

95
00:06:44,360 --> 00:06:48,680
But if you are regulated 
industry, you need deterministic

96
00:06:48,680 --> 00:06:51,760
code and that's where Blitzy 
comes into it. 

97
00:06:51,800 --> 00:06:57,320
That one we were able to reverse
engineer our legacy systems and 

98
00:06:57,320 --> 00:07:02,200
we are able to create and 
generate deterministic code and 

99
00:07:02,200 --> 00:07:08,120
that translates into efficiency 
and throughput of the entire 

100
00:07:08,120 --> 00:07:10,520
process. 
And of course, here again, 

101
00:07:10,520 --> 00:07:15,840
you're operating within a 
regulatory framework and you're 

102
00:07:15,840 --> 00:07:19,400
a very large organization, 
multinational organization. 

103
00:07:19,680 --> 00:07:22,720
So that consistency is 
fundamental. 

104
00:07:23,160 --> 00:07:25,800
Absolutely. 
So the quality of the code and 

105
00:07:25,800 --> 00:07:29,680
the consistency is massively 
important to us because of the 

106
00:07:29,680 --> 00:07:32,440
regulation and also because 
we've got to do the right thing 

107
00:07:32,440 --> 00:07:35,760
for our customers. 
You know, when, when, when, when

108
00:07:35,760 --> 00:07:39,280
customers call in the insurance 
industry, they call with a 

109
00:07:39,280 --> 00:07:42,360
specific problem. 
That problem has to be resolved 

110
00:07:42,360 --> 00:07:47,160
correctly, not by a 
probabilistic scenario. 

111
00:07:47,560 --> 00:07:49,720
You know, it's a very 
deterministic scenario. 

112
00:07:49,720 --> 00:07:52,200
I've got a problem. 
This is a solution, and that's 

113
00:07:52,200 --> 00:07:56,200
what Bitsy comes into it. 
There's lots of AI companies out

114
00:07:56,200 --> 00:08:00,040
there, but very few companies 
can actually generate 

115
00:08:00,040 --> 00:08:04,440
deterministic code which is fit 
and proper for the insurance 

116
00:08:04,440 --> 00:08:07,240
business. 
Why didn't you use traditional 

117
00:08:07,240 --> 00:08:13,360
approaches to modernization such
as hiring more engineers or 

118
00:08:13,360 --> 00:08:16,680
adopting standard AI coding the 
systems? 

119
00:08:16,880 --> 00:08:20,200
Why did you take this platform 
approach? 

120
00:08:20,600 --> 00:08:24,400
We have been modernizing our 
systems progressively over the 

121
00:08:24,400 --> 00:08:27,640
last couple of years. 
Every time we would build new 

122
00:08:27,640 --> 00:08:32,760
product, we would then take a 
chunk of a heritage system and 

123
00:08:32,880 --> 00:08:36,400
we would modernize it. 
So it was kind of a just in time

124
00:08:36,400 --> 00:08:38,600
modernization for specific new 
product. 

125
00:08:39,240 --> 00:08:43,960
However, we believe that the 
whole world is accelerating and 

126
00:08:43,960 --> 00:08:46,600
we have to accelerate our 
modernization process. 

127
00:08:47,160 --> 00:08:52,200
So we believe that we can 
achieve acceleration of 

128
00:08:52,200 --> 00:08:56,040
modernization with Blitzy. 
Chris, how does the platform 

129
00:08:56,040 --> 00:09:00,600
support Vitality's internal 
validation rules, coding 

130
00:09:00,600 --> 00:09:05,120
standards, governance and 
compliance requirements? 

131
00:09:05,520 --> 00:09:09,800
We achieve it through context 
engineering and the context 

132
00:09:09,800 --> 00:09:15,720
engineering is effectively 
ingestion of code base, millions

133
00:09:15,720 --> 00:09:19,440
of lines of code of of our 
systems, our engineering 

134
00:09:19,440 --> 00:09:24,440
standards, our development 
standards, this number of 

135
00:09:24,680 --> 00:09:30,480
documents and set of rules that 
get ingested into the context 

136
00:09:30,880 --> 00:09:34,400
that help us to build higher 
quality code. 

137
00:09:34,800 --> 00:09:40,880
So this context is massive and 
includes both technical and 

138
00:09:40,880 --> 00:09:43,280
business requirements. 
That's right. 

139
00:09:43,360 --> 00:09:49,040
So you've got the code, the code
base, you've got rules, 

140
00:09:49,840 --> 00:09:55,200
standards, and all of that put 
together generates higher 

141
00:09:55,200 --> 00:09:58,800
quality code base. 
When you say higher quality, can

142
00:09:58,800 --> 00:10:02,080
you elaborate on that? 
We've gone to what we call a 

143
00:10:02,160 --> 00:10:06,840
test driven development, and 
what it means is that that you 

144
00:10:06,840 --> 00:10:10,880
define test cases before you 
actually write the code. 

145
00:10:11,200 --> 00:10:14,720
And we found that when we 
generate code with Blitzie, with

146
00:10:14,720 --> 00:10:21,840
Test Driven Development, AI is 
naturally naturally aligned with

147
00:10:21,840 --> 00:10:26,000
that methodology and generates 
much higher quality of code. 

148
00:10:26,600 --> 00:10:30,880
So that when we generate the 
code, not only we pass the test 

149
00:10:30,880 --> 00:10:35,920
cases much easier but also the 
code quality is higher as well. 

150
00:10:36,360 --> 00:10:39,880
Can you describe the results 
you've seen so far across 

151
00:10:39,880 --> 00:10:43,600
autonomous work, completed 
engineering velocity, 

152
00:10:43,600 --> 00:10:48,320
development cost timelines, and 
also adherence to your 

153
00:10:48,320 --> 00:10:52,240
compliance requirements? 
We're looking at different areas

154
00:10:52,240 --> 00:10:56,240
of software development life 
cycle and what we found is that,

155
00:10:56,600 --> 00:11:01,160
for example, reverse engineering
of legacy code, we are able to 

156
00:11:01,160 --> 00:11:06,400
reverse engineer our code from 
the five times faster than we 

157
00:11:06,400 --> 00:11:11,120
were able to do it manually by 
people. 

158
00:11:11,600 --> 00:11:15,800
So AI helps us to accelerate our
reverse engineering of legacy 

159
00:11:15,800 --> 00:11:19,960
systems by five times. 
We haven't fully quantified end 

160
00:11:19,960 --> 00:11:25,680
to end the entire cycle, but 
we've got pockets of efficiency 

161
00:11:25,680 --> 00:11:29,120
at this point in time and now we
are in the process of actually 

162
00:11:29,160 --> 00:11:31,800
optimize the full delivery life 
cycle. 

163
00:11:32,160 --> 00:11:36,360
So we're going from local 
efficiencies of steps in the 

164
00:11:36,360 --> 00:11:40,320
process to the overall 
effectiveness of the end to end 

165
00:11:40,320 --> 00:11:42,840
process. 
And that's where right now we 

166
00:11:42,840 --> 00:11:46,680
see major improvements in 
different steps of the of the 

167
00:11:46,680 --> 00:11:50,640
cycle. 
But now I want to optimize the 

168
00:11:50,640 --> 00:11:54,800
whole throughput because local 
efficiency of each step in the 

169
00:11:54,800 --> 00:11:58,760
process doesn't necessarily 
translate to the overall 

170
00:11:58,760 --> 00:12:01,200
effectiveness. 
For example, if somebody can 

171
00:12:01,200 --> 00:12:04,840
generate code quickly, maybe 
they can have extra coffee break

172
00:12:04,840 --> 00:12:08,400
because nowadays they've got a 
bit of extra time until the next

173
00:12:08,400 --> 00:12:11,600
process kicks in. 
Now I want to optimize the whole

174
00:12:11,600 --> 00:12:13,160
thing. 
So the throughput get 

175
00:12:13,160 --> 00:12:17,200
accelerated not only specific 
steps but the entire process 

176
00:12:17,200 --> 00:12:21,840
gets accelerated because we are 
shared value insurance business,

177
00:12:22,160 --> 00:12:24,400
we providing value to our 
customers. 

178
00:12:24,800 --> 00:12:29,480
And the question is does the new
product deliver value as 

179
00:12:29,480 --> 00:12:33,360
expected by the customers And 
then the question is how fast 

180
00:12:33,560 --> 00:12:37,520
can I deliver that better 
proposition to the customers. 

181
00:12:37,840 --> 00:12:42,040
So then accelerating the 
software delivery life cycle 

182
00:12:42,360 --> 00:12:46,560
gives me the faster response 
time to the market. 

183
00:12:47,080 --> 00:12:51,760
So there's always this linkage 
then between what you're doing 

184
00:12:51,920 --> 00:12:55,480
with your software development 
and the architecture of your 

185
00:12:55,480 --> 00:13:00,440
approach and the outcomes that 
your customers will then 

186
00:13:00,440 --> 00:13:02,280
experience. 
Absolutely. 

187
00:13:02,520 --> 00:13:06,600
So the architecture has got 
direct impact on the product 

188
00:13:06,600 --> 00:13:10,560
that we're delivering and the 
software development life cycle 

189
00:13:10,840 --> 00:13:15,280
accelerates the process of from 
the inception through the 

190
00:13:15,280 --> 00:13:17,400
engineering to the product 
delivery. 

191
00:13:17,920 --> 00:13:23,160
Now, how does all of this change
the relationship between product

192
00:13:23,160 --> 00:13:28,160
and engineering teams? 
At Vitality we operate in matrix

193
00:13:28,160 --> 00:13:35,480
organization and R&D, product 
and technology or engineering 

194
00:13:35,480 --> 00:13:39,000
are actually one team. 
So we actually got a blended 

195
00:13:39,000 --> 00:13:42,760
team with R&D people, with 
product people and software 

196
00:13:42,760 --> 00:13:46,320
engineering people working 
together to accelerate the 

197
00:13:46,320 --> 00:13:49,560
process. 
So we are able to generate quick

198
00:13:49,560 --> 00:13:53,960
prototypes for R&D so that we 
can conceptualize our ideas 

199
00:13:53,960 --> 00:13:58,880
faster. 
Then through the with with use 

200
00:13:58,880 --> 00:14:02,160
of of Blitzy and AI, we can then
accelerate the delivery of the 

201
00:14:02,160 --> 00:14:05,520
product and then of course 
launch in the market. 

202
00:14:06,040 --> 00:14:10,600
It's almost like you've 
transposed DevOps into product 

203
00:14:10,600 --> 00:14:12,320
and engineering. 
That's right. 

204
00:14:12,520 --> 00:14:16,600
So the DevOps is an integral 
part of the software delivery 

205
00:14:16,600 --> 00:14:20,680
life cycle and we connecting 
DevOps with product. 

206
00:14:21,000 --> 00:14:24,000
So Product and DevOps are then 
integrated. 

207
00:14:24,480 --> 00:14:29,200
Now, when requirements can move 
more directly into working 

208
00:14:29,200 --> 00:14:32,840
software, what happens to the 
steps in between, such as 

209
00:14:32,840 --> 00:14:37,480
specifications, handoffs and 
iterate iterations? 

210
00:14:37,840 --> 00:14:41,800
We're using AI to help us 
crystallize and document our 

211
00:14:41,800 --> 00:14:45,440
requirements. 
Those are then ingested into the

212
00:14:45,440 --> 00:14:48,360
context that we spoke about few 
minutes ago. 

213
00:14:48,960 --> 00:14:52,840
And of course that ultimately 
translates into test cases and 

214
00:14:52,840 --> 00:14:57,560
code generated and into testing.
So product requirements, 

215
00:14:57,560 --> 00:15:03,080
engineering, software 
engineering, testing and release

216
00:15:03,160 --> 00:15:06,640
is an integrated process. 
What changed for your 

217
00:15:06,640 --> 00:15:09,840
engineering teams in terms of 
their roles, their skills, the 

218
00:15:09,840 --> 00:15:12,160
workflows and how they spend 
their time? 

219
00:15:12,520 --> 00:15:17,040
We are still at the early stage 
of the transformation, but I 

220
00:15:17,040 --> 00:15:21,440
can, I can already see early 
signs of what kind of a what 

221
00:15:21,440 --> 00:15:25,760
what we call a levelling up. 
So the skills get uplifted. 

222
00:15:26,200 --> 00:15:31,080
So we've got examples where 
requirements engineers dive into

223
00:15:31,480 --> 00:15:34,240
actually code and actually they 
want to have a look at what the 

224
00:15:34,240 --> 00:15:37,160
code looks like. 
And you know, so requirements 

225
00:15:37,160 --> 00:15:41,640
engineers build requirements, 
they boot test cases and they 

226
00:15:41,640 --> 00:15:43,200
actually have a look at the 
code. 

227
00:15:43,440 --> 00:15:46,360
And even though they are not 
software engineers with AI, 

228
00:15:46,360 --> 00:15:48,000
they've got the ability to do 
that. 

229
00:15:48,320 --> 00:15:52,880
So it is an integrated process 
and you can see the uplift, the 

230
00:15:52,880 --> 00:15:57,440
skills being uplifted and then 
software engineers look upstream

231
00:15:57,680 --> 00:16:02,240
at the requirements closer. 
So, so the teams, the teams are 

232
00:16:02,240 --> 00:16:04,600
actually getting well 
integrated. 

233
00:16:04,840 --> 00:16:11,000
I see a better handover and more
integrated process or better 

234
00:16:11,000 --> 00:16:15,640
integrated process which 
translates into greater velocity

235
00:16:15,960 --> 00:16:17,800
and effectiveness of the whole 
throughput. 

236
00:16:18,320 --> 00:16:23,040
What was it like to shift from 
reviewing small incremental code

237
00:16:23,040 --> 00:16:28,600
changes to reviewing pull 
requests of 50 to 100,000 lines?

238
00:16:28,960 --> 00:16:32,520
This is exactly where we are 
right now and this is This is 

239
00:16:32,520 --> 00:16:36,000
why I'm at right now at Blitzy 
head office here, because we 

240
00:16:36,000 --> 00:16:40,240
actually analyse the situation, 
how do we optimize it? 

241
00:16:40,720 --> 00:16:44,880
Because we find ourselves that 
now we can generate requirements

242
00:16:45,000 --> 00:16:50,440
rapidly, we can generate code 
rapidly, but we cannot consume 

243
00:16:50,440 --> 00:16:55,280
that code fast enough. 
So the code review is now a next

244
00:16:55,440 --> 00:16:59,680
limiting factor. 
So now that's an exchange for 

245
00:16:59,680 --> 00:17:03,880
the for the agentic AI. 
How do I accelerate code review 

246
00:17:04,400 --> 00:17:08,720
to get to testing and of course 
release and, and launch of the 

247
00:17:08,720 --> 00:17:11,599
product? 
So as we go through the process 

248
00:17:11,599 --> 00:17:16,000
and we accelerate one part of 
the part of the SDOC process, we

249
00:17:16,000 --> 00:17:19,160
find other limiting factors and 
those shift, they shift 

250
00:17:19,160 --> 00:17:20,880
downstream. 
Now they shift upstream. 

251
00:17:21,240 --> 00:17:25,599
And you know, it's like all the 
whack, whack and mole game, but 

252
00:17:25,599 --> 00:17:28,119
you whack this one, this one 
pops up, you whack this one, you

253
00:17:28,760 --> 00:17:30,960
and you Canada. 
You've got to optimise to 

254
00:17:30,960 --> 00:17:33,200
achieve greater throughput 
through the whole process. 

255
00:17:33,720 --> 00:17:41,280
This kind of development is very
new, so you are analyzing each 

256
00:17:41,280 --> 00:17:44,880
of the components as you go and 
optimizing along the way. 

257
00:17:44,880 --> 00:17:46,760
That's how it sounds. 
That's exactly right. 

258
00:17:46,920 --> 00:17:52,640
And as we optimize the process, 
we are measuring the velocity 

259
00:17:52,640 --> 00:17:54,760
and the efficiency and the 
effectiveness of the whole 

260
00:17:54,760 --> 00:17:55,920
process. 
That's right. 

261
00:17:56,400 --> 00:17:59,680
It sounds like the measurements 
are also integral to what you're

262
00:17:59,680 --> 00:18:01,520
doing. 
Yes, because we want to 

263
00:18:01,560 --> 00:18:04,960
evidence, you know we are 
consuming tokens. 

264
00:18:05,360 --> 00:18:07,920
So the question is what do we 
get for those tokens, right. 

265
00:18:08,240 --> 00:18:13,920
So we might accelerated specific
activities, but if that activity

266
00:18:13,920 --> 00:18:17,240
doesn't translate to the overall
effectiveness, it's a limited 

267
00:18:17,240 --> 00:18:20,640
utility. 
So it's all about measuring the 

268
00:18:20,640 --> 00:18:23,880
process throughout. 
And I have to admit we we 

269
00:18:23,880 --> 00:18:27,440
haven't, we haven't completely 
instrumented the whole process. 

270
00:18:27,600 --> 00:18:30,400
We the process of actually 
analysing and instrumenting the 

271
00:18:30,400 --> 00:18:32,840
whole process. 
But that's exactly the objective

272
00:18:32,840 --> 00:18:37,600
to optimise the entire process. 
I have to imagine in a regulated

273
00:18:37,600 --> 00:18:42,240
industry such as insurance, your
risk audit and compliance folks 

274
00:18:42,240 --> 00:18:44,800
are going to be looking at this 
very, very carefully. 

275
00:18:45,040 --> 00:18:47,960
Absolutely right. 
And you know, it's this is exact

276
00:18:47,960 --> 00:18:53,000
science and you know, us as 
technology professionals, we are

277
00:18:53,000 --> 00:18:57,320
equally motivated to get dried 
because it is a cutting edge 

278
00:18:57,320 --> 00:19:01,920
brand new technology and we want
to make sure that the code 

279
00:19:01,920 --> 00:19:07,080
generated is as good or better 
to what we are, what we are able

280
00:19:07,080 --> 00:19:11,080
to do historically. 
This is a significant set of 

281
00:19:11,080 --> 00:19:16,240
changes that goes right to the 
core of your business. 

282
00:19:16,720 --> 00:19:20,320
Given that, what role did 
executive sponsorship and 

283
00:19:20,320 --> 00:19:26,600
leadership play in driving 
adoption of this new approach to

284
00:19:26,600 --> 00:19:29,560
technology? 
It's massively important, I have

285
00:19:29,560 --> 00:19:34,800
to say that we've got a a full 
sponsorship and full support at 

286
00:19:34,840 --> 00:19:38,880
all level of all the way from 
the board, through executive 

287
00:19:38,880 --> 00:19:43,120
committee, through management. 
Everybody's equally motivated to

288
00:19:43,840 --> 00:19:48,320
get it right. 
We believe that AI is as 

289
00:19:48,320 --> 00:19:52,160
important as the Internet. 
You know this is a game changer 

290
00:19:52,280 --> 00:19:55,560
and I'm personally determined to
be the fastest horse in the 

291
00:19:55,560 --> 00:19:59,920
race. 
This is a strategic move for 

292
00:20:00,120 --> 00:20:03,760
vitality. 
It is for us and we want to be 

293
00:20:03,760 --> 00:20:07,880
the the leaders in the industry 
and that's I believe that 

294
00:20:07,960 --> 00:20:12,800
whoever wins this race is going 
to outrun the competition and I 

295
00:20:12,800 --> 00:20:15,720
intend Vitality to be the host, 
the the fastest horse in the 

296
00:20:15,720 --> 00:20:20,600
race. 
Chris, any advice for CIOSCTOS 

297
00:20:20,600 --> 00:20:24,080
who are listening to this and 
wondering how can I get started 

298
00:20:24,080 --> 00:20:28,840
with this kind of AI driven 
autonomous development? 

299
00:20:29,320 --> 00:20:34,160
I think first one has to decide 
why we doing this and why is it 

300
00:20:34,160 --> 00:20:40,040
important to our organization 
and vitality because we are fast

301
00:20:40,040 --> 00:20:45,560
moving and agile organization. 
AI is massively important to us.

302
00:20:45,960 --> 00:20:48,200
You know it's for some companies
might not be. 

303
00:20:48,280 --> 00:20:52,680
So I think maybe it's not for 
everyone, but if anybody's got 

304
00:20:52,680 --> 00:20:59,200
an ambition of being a agile, 
fast moving organization, AI is 

305
00:20:59,200 --> 00:21:01,920
the is the obvious answer. 
OK. 

306
00:21:01,920 --> 00:21:05,440
Chris Tokozewski, thank you so 
much for spending time with us. 

307
00:21:06,000 --> 00:21:07,720
Thank you, Michael. 
Absolute pleasure.