4 May 2026 · 21m · Kris Tokarzewski, Michael Krigsman · 18 quoted facts
Kris Tokarzewski, who runs technology at the insurer Vitality, argues that AI coding only pays off in a regulated industry if the code is deterministic (predictable and repeatable) and the whole software delivery process is improved, not just one step. Vitality uses Blitzy to reverse-engineer old systems and generate code, feeding it company standards and tests.
The central tension is that speeding up one stage exposes the next bottleneck. Code now arrives faster than people can review it, so Vitality expects AI reviewers to check 50,000 to 100,000-line changes before humans do. Tokarzewski admits the process is not yet fully measured, so the proof of end-to-end gains is still being built.
Tokarzewski says casual 'vibe coding' may suit a startup or coffee shop, but insurance customers call with specific problems that must be solved correctly. He credits Blitzy with generating deterministic code fit for that standard.
Vitality could generate code quickly, but then nobody could review it fast enough. Tokarzewski compares it to whack-a-mole: fix one limiting factor and another pops up upstream or downstream.
Vitality ingests millions of lines of its own code plus engineering standards and development rules into the AI's context. Tokarzewski says this context engineering produces higher-quality code aligned with its requirements.
Vitality defines test cases before code is written. Tokarzewski says AI fits this method naturally, so generated code passes tests more easily and is also higher quality.
Reverse-engineering legacy code is about five times faster than manual work. Tokarzewski concedes the full cycle isn't yet quantified or instrumented, so token spend isn't fully tied to overall results.
Deterministic code behaves the same predictable way every time, as opposed to probabilistic output that can vary. Tokarzewski says insurers need it because of regulation and because customer problems must be resolved correctly, not by chance.
Tokarzewski says Vitality reverse-engineers its legacy code about five times faster with AI than people did manually. He says this is a local gain and the full development cycle has not been measured yet.
AI can generate tens of thousands of lines at once, and people can't read them fast enough. Tokarzewski says Vitality plans to use another AI to review the code first, then have a human review that.
It means giving the AI the material it needs to write good code: Vitality's existing code base, engineering standards and business rules. Tokarzewski says this helps produce higher-quality code.
Tokarzewski says they are consuming tokens (the units AI services charge for) and want evidence of what they get back, measured across velocity, quality and end-to-end throughput. He admits the instrumentation is not complete yet.
Stated by the speakers. Each quote matches the transcript, which shows what was said, not that it is true.
Kris Tokarzewski says Vitality holds about 12% of the UK market and competes with institutions that are centuries old.
“We've got about 12% market share and we compete against large institutions that have been in business for, like, hundreds of years.”
Vitality is described as a multinational insurer with 14,000 employees.
“a multinational insurer with 14,000 employees.”
Vitality is building event-driven architecture to support its product requirements.
“we are building event-driven architecture that supports our product requirements.”
Vitality is building microservices that are event-driven services.
“we're building microservices, which are actually event-driven services, and that's quite important.”
Over the previous couple of years, Vitality modernized a chunk of a legacy system each time it built a new product.
“Every time we would build new product, we would then take a chunk of a heritage system and we would modernize it.”
Vitality began its work with Blitzy by using it to reverse-engineer legacy code.
“We started with Blitzy on reverse engineering of legacy code”
Vitality's context engineering ingests its code base of millions of lines plus engineering and development standards into the AI's context.
“the context engineering is effectively ingestion of code base, millions of lines of code of, uh, uh, of our systems, our engineering standards, our development standards”
Vitality has adopted test-driven development, defining test cases before code is written.
“We've gone to what we call a test-driven development, and what it means is they that you define test cases before you actually write the code”
Tokarzewski says AI lets Vitality reverse-engineer legacy code about five times faster than manual work.
“We are able to reverse engineer our code probably five times faster than we were able to do it manually, uh, by people.”
Vitality has not fully quantified end-to-end gains and currently sees pockets of efficiency.
“We haven't fully quantified end-to-end the entire cycle, but we've got pockets of efficiency at this point in time”
Vitality calls its approach an AI-native software development life cycle, with autonomous development as only one part.
“we call it A I native software development life cycle, and then autonomous development is just part of it”
Tokarzewski says code generated at scale, such as 100,000 lines, is too much for humans to review alone, so another AI would review it first.
“So if we generated, let's say, 100,000 lines of code, who is gonna review 100,000 lines of code?”
Tokarzewski says Vitality can generate requirements and code rapidly but cannot review the code fast enough, making code review the next limiting factor.
“we can generate requirements rapidly, we can generate code rapidly, but we cannot consume that code fast enough.”
Vitality operates a matrix organization where R&D, product and engineering work as one blended team.
“At Vitality, we operate in matrix organization and R and D product and technology or engineering are actually one team.”
Tokarzewski says some Vitality requirements engineers are now reading code with AI's help.
“we've got examples where requirements engineers dive into actually code and actually they want to have a look at what the code looks like.”
Tokarzewski says Vitality wants evidence of the value gained from the AI tokens it consumes.
“we are consuming tokens, so the question is, what do we get for those tokens, right?”
Tokarzewski says the AI effort has support from Vitality's board, executive committee and management.
“we've got a a full sponsorship and full support at all level of all the way from the board, through executive committee, through management”
Tokarzewski says Vitality believes AI is as important as the internet.
“We believe that A I is as important as the internet.”
Opens with the case that regulated industries cannot rely on probabilistic AI output.
“if you are regulated industry, you need deterministic code.”
Explains why Vitality is replacing legacy systems with event-driven services that pair well with agentic AI.
“event-driven services are natural partners of agentic A I.”
Describes treating autonomous coding as one part of a broader process, and how each speedup reveals a new bottleneck.
“A I is accelerating specific processes and it exposes other bottlenecks”
Covers starting with reverse engineering and moving to deterministic code generation for insurance.
“we started with Blitzy on reverse engineering of legacy code”
Shows how company code, standards and tests are used to raise quality.
“you define test cases before you actually write the code”
Reports the five-times reverse-engineering gain and the push to measure end-to-end value.
“We are able to reverse engineer our code probably five times faster”
Looks at blending product and engineering and at code review as the next limit.
“we can generate code rapidly, but we cannot consume that code fast enough.”
Covers board-level backing and advice to start by deciding why AI matters to your organization.
“I'm personally determined to be the fastest horse in the race.”
Probabilistic code, you just vibe coding, cute ideas and put on the website, and you can get away with this. If you are a startup, a coffee shop, but if you are regulated industry, you need deterministic code.
Kris Tokarzewski is group chief technology information officer of Vitality, a multinational insurer with 14,000 employees. He's at Blitzy's headquarters, rethinking vitality's software process using autonomous AI.
Our legacy systems were not scaling fast enough, so we embarked on modernization plan to scale them up faster and future-proof the business. We see ourselves as a challengers in the U. K. market. We've got about 12% market share and we compete against large institutions that have been in business for, like, hundreds of years. So as a challenger, we are growing and we need flexibility, so opportunities are all over the place and our systems have to be flexible to capitalize on those opportunities.
So we've realized that that flexibility has to manifest itself in the systems. Because when there's new market opportunity, we need to build products and services that actually, that actually support those those market needs. So we've been modernizing our systems for quite a while, we are building event-driven architecture that supports our product requirements. So as our R and D colleagues come up with new products and services, we want to launch in the product that we want to launch in the market, uh, we're building microservices, which are actually event-driven services, and that's quite important.
Uh, from a customer perspective, because historically, it was okay to make a phone call to an insurance company and make a request and somebody would do something. Nowadays, everything happens in real time. So, in order to be able to service our customers in real time, you need event-driven architecture and event-driven services. And also, when it comes to the agentic A I and the A I world that we're entering into, event-driven services are natural partners of agentic A I.
So when you combine event-driven services with agentic A I, now you've got a very powerful combination because they actually like amplifiers that A I is amplifying the event-driven capabilities, and the event-driven capabilities can leverage the A I capabilities, and ultimately we can service our our members better in that way.
You're using autonomous development, working with Blitzy.
With Blitzy, we're doing a number of things. Autonomous development is part of it because we are in the regulated industry, the autonomous development has to be augmented with other processes. So we call it A I native software development life cycle, and then autonomous development is just part of it, but actually development life cycle spans right across. I'm looking at what are the limiting factors, so what is slowing us down? Because what happens is A I is accelerating specific processes and it exposes other bottlenecks, so it's it's a continuous refocusing of the team.
Now we've automated this part of the business or this part of the SDLC process, what limiting factors have been exposed? So, for example, we were able to generate the code very fast. Now who's gonna review that code? So if we generated, let's say, 100,000 lines of code, who is gonna review 100,000 lines of code? And probably not a human. We're gonna need another AI to review that uh, A I A I developed code, and then have a human review that part.
So it's a continuous process of optimizing the throughput, so I'm quite keen on optimize the throughput because local efficiency does not translate into overall throughput. So you have to optimize the entire software deliver deliver life cycle to achieve optimal throughput.
So you're working with Blitzy and you have essentially reimagined that entire software development life cycle,
That's exactly right. We asking ourselves, what are the limiting factors in our software development life cycle process? How do we leverage A I in that process to our advantage so that we get? We generate better code, higher quality at a faster velocity, and that translates into throughput.
clearly, this requires an end-to-end platform rather than specific point solutions.
That's exactly right. You do need to have an integrated platform that automates and integrates the entire software develop development life cycle to achieve optimal throughput. Because if you've got fragmented process, that fragmented process is gonna manifest itself in bottlenecks, which I call limiting factors. If you've got integrated process with integrated tooling, you can achieve optimal velocity, quality, and throughput.
Where does Blitzy fit into this?
We started with Blitzy on reverse engineering of legacy code, and we've learned very quickly that Blitzy is an excellent reverse engineering tool. But then we quickly learned that Blitzy can also generate a high quality deterministic code, and it is massively important. The insurance business because many of AI companies can generate probabilistic code, and probabilistic code you just vibe coding, cute ideas and put on the website, and you can get away with this if you are a startup, a coffee shop, or some other company, but if you are regulated industry, you need deterministic code.
And that's where Blitzy comes into it, that one, we were able to reverse engineer our legacy systems, and we are able to create and generate deterministic code, and that translates into efficiency and throughput of the entire process.
And of course, here again, you're operating within a regulatory framework and you're a very large organization, multinational organization, so that consistency is fundamental.
Absolutely, so the quality of the code and the consistency is massively important to us because of the regulation. And also because we've got to do the right thing for our customers. You know, when some when, when, when customers call in the insurance industry, they call with a specific problem. That problem has to be resolved correctly, not by a probabilistic scenario. You know, it's a very deterministic scenario. I've got a problem, this is a solution, and that's where Blitzy comes into it.
There's lots of AI companies out there, but very few companies can actually generate deterministic code, which is fit and proper for the insurance business.
Why didn't you use traditional approaches to modernization, such as hiring more engineers or adopting standard A I coding systems? Why did you take this platform approach?
We have been modernizing our systems progressively over the last couple of years. Every time we would build new product, we would then take a chunk of a heritage system and we would modernize it. So it was kind of a just-in-time modernization for specific new product. However, we believe that the whole world is accelerating and we have to accelerate our modernization process. So we believed that, uh, uh, we can achieve acceleration of modernization with Blitzy.
Chris, how does the platform support Vitality's internal validation rules, coding standards, governance, and compliance requirements?
We achieve it through context engineering, and the context engineering is effectively ingestion of code base, millions of lines of code of, uh, uh, of our systems, our engineering standards, our development standards, these number of documents and set of rules that get ingested into the context that help us to build higher quality code.
So this context is massive and includes both technical and business requirements.
That's right, so you've got the code, the code base, you've got rules, standards, and all of that put together, uh, generates higher quality code base.
When you say higher quality, can you elaborate on that?
We've gone to what we call a test-driven development, and what it means is they that you define test cases before you actually write the code, and we found that when we generate code with Blitzy with test driven development, uh, A I is, uh, naturally naturally aligned with that methodology and generates much higher quality of code, so that when we generate the code, not only we pass the test cases much easier, but also the code quality is higher as well.
Can you describe the results you've seen so far across autonomous work completed, engineering velocity, development cost, timelines, and also adherence to your compliance requirements?
We're looking at different areas of software development life cycle, and, uh, what we found is that, for example, reverse engineering of legacy code. We are able to reverse engineer our code probably five times faster than we were able to do it manually, uh, by people. So A I helps us to accelerate our reverse engineering of legacy systems by five times. We haven't fully quantified end-to-end the entire cycle, but we've got pockets of efficiency at this point in time, and now we are in the process of actually optimize the full deliver life cycle.
So we're going from local efficiencies of steps in the process to the overall effectiveness of the end-to-end process, and that's where right now we see major improvements in different steps of the CYC of the cycle. But now I want to optimize the whole throughput, because local efficiency of each step in the process doesn't necessarily translate to the overall effectiveness. For example, if somebody can generate code quickly, maybe they can have an extra coffee break because now they've got a bit of extra time until the next process kicks in.
Now I want to optimize the whole thing so the throughput gets accelerated, not only specific steps, but the entire process gets accelerated. Because we are shared value insurance business, we providing value to our customers. And the question is, does the new product deliver value as expected by the customers? And then the question is, how fast can I deliver that better proposition to the customers? So then accelerating the software delivery life cycle gives me the faster response time to the market.
So there's always this linkage then between what you're doing with your software development and the architecture of your approach and the outcomes that your customers will then experience.
Absolutely, so the architecture has got direct impact on the product that we're delivering, and the software development life cycle accelerates that process of from the inception through the engineering to the product delivery.
Now, how does all of this change the relationship between product and engineering teams?
At Vitality, we operate in matrix organization and R and D product and technology or engineering are actually one team. So we actually've got a blended team with R and D people, with product people and software engineering people working together to accelerate that process. So we are able to generate quick prototypes for R and D so that we can conceptualize our ideas faster. Then through the, uh, with, uh, with use of, of Blitzy and A I, we can then accelerate the delivery of the product and then, of course, launch it in the market.
It's almost like you've transposed DevOps into product and engineering,
That's right, so the DevOps is an integral part of the software deliver deliver life cycle, and we connecting DevOps with product, so product and DevOps are then integrated.
now, when requirements can move more directly into working software, what happens to the steps in between, such as specifications, handoffs, and iter-iterations?
We're using A I to help us crystallize and document our requirements. Those are then ingested into the context that we spoke about a few minutes ago, and of course, that ultimately translates into test cases and code generated and into testing. So product requirements engineering, software engineering, testing and release is an integrated process.
What changed for your engineering teams in terms of their roles, their skills, the workflows, and how they spend their time?
We are still at the early stage of that transformation, but I can, I can already see early signs of what kind of a, what, what we call a leveling up, so the skills get uplifted. So we've got examples where requirements engineers dive into actually code and actually they want to have a look at what the code looks like. And, uh, you know, so requirements engineers build requirements, they build test cases, and they actually have a look at the code.
And even though they are not software engineers, with A I, they've got that ability to do that, so it is an integrated process and you can see the uplift, the, the, the skills being uplifted, and then software engineers look upstream at the requirements closer, so, so, the teams, the teams are actually getting well integrated. I see a better handover and more integrated process, or better integrated process, which translates into greater velocity and effectiveness of the whole throughput.
What was it like to shift from reviewing small incremental code changes to reviewing pull requests of fifty to 100,000 lines?
This is exactly where we are right now, and this is, uh, this is why I'm right now at Blitzy head office here. Because we actually analyzing the situation, how do we optimize it? Because we find ourselves that now we can generate requirements rapidly, we can generate code rapidly, but we cannot consume that code fast enough. So the code review is now a next limiting factor. So now that's a next challenge for the, for the agentic. A I.
How do I accelerate code review to get to testing and, of course, release and and launch of the product? So as we go through the process and we accelerate one part of the, uh, part of the SDLC process, we find other limiting factors and those shift. They shift downstream, now they shift upstream, and, uh, you know, it's like an old whack, uh, uh, whack-a-mole game. And you whack this one, this one pops up, you whack this one, you pop and you kind of you've got to optimize to achieve greater throughput through the whole process.
This kind of development is very new, so you are analyzing each of the components as you go and optimizing along the way. That's how it sounds.
That's exactly right. And as we optimize the process, we are measuring the velocity, the efficiency and effectiveness of the whole process. That's right.
It sounds like the measurements are also integral to what you're doing.
Yes, because we want to evidence, you know, we are consuming tokens, so the question is, what do we get for those tokens, right? So we might accelerated specific activities, but if that activity doesn't translate to the overall effectiveness, it's a limited utility. So it's all about, uh, measuring the process throughout, and I have to admit, we, we haven't, we haven't completely instrumented the whole process. We're in the process of actually analyzing and instrumenting the whole process, but that's exactly the objective to optimize the entire process.
I have to imagine in a regulated industry such as insurance, your risk audit and compliance folks are gonna be looking at this very, very carefully.
Absolutely right, and you know, this is exact science, and, uh, you know, us as technology professionals, we are equally motivated to get it right because it is a cutting-edge brand new technology and we want to make sure that the code generated is as good or better to what we were, what we were able to do historically.
This is a significant set of changes that goes right to the core of your business. Given that, what role did executive sponsorship and leadership play in driving adoption of this new approach to technology?
It's massively important. I have to say that we've got a a full sponsorship and full support at all level of all the way from the board, through executive committee, through management, everybody is equally motivated to, uh, get it right. We believe that A I is as important as the internet. You know, this is a game changer, and I'm personally determined to be the fastest horse in the race.
This is a strategic move for vitality.
It is for us, and we want to be the leaders in the industry. And that's, uh, I believe that whoever wins this race is gonna outrun the competition and I intend vitality to be the host, the fastest horse in the race.
Chris, any advice for CIOs, CTOs who are listening to this and wondering how can I get started with this kind of AI-driven autonomous development?
I think first one has to decide why we're doing this and why is it important to our organization. And vitality because we are fast-moving and agile organization. A I is massively important to us. You know, for some companies might not be, so I think maybe it is not for everyone, but if anybody's got an ambition of being a agile, fast-moving organization, A I is the is the obvious answer.
Okay, Kris Tokarzewski, thank you so much for spending time with us.
Thank you, Michael. Absolute pleasure.