The percentage of all the completed work done autonomously
by Blitzie, it ranged from 80 and 95%.
Depending in the use case. We accelerated development
velocity of between 5:00 and 10:00 X.
The human is not writing the code.
The human is directing a platform on how to write the
code. That's a huge change in
paradigm. That's Enrique Ibarra, CIO and
Head of Business Transformation at GNP, Mexico's largest
insurance company. Our conversation covers AI
adoption, change management, and autonomous software development.
Our main operational system is a mainframe based map with IBM
components. System has been running for a
little bit over 20 years. The initial rationale for
modernizing this application was basically cost.
That was one of the concerns, but it was not the only one.
In a few years from now, it's going to be much harder to get
COBOL resources. I mean, if you go to the
universities, students don't learn COBOL in the universities.
There's no real interest. That's going to be an issue I
guess in the future to in terms of how do we give longevity to
this asset. We started a few years ago
incorporating the typical coding Co pilots.
We, we incorporated several informally.
We started to provide all of our developers with Co pilots
without formally measuring their increasing productivity.
We just basically use it, find it useful, take advantage of it,
and that's being expanded among the all of our developer base
and we have roughly about 1000 developers by looking at
different industry solutions, we find we basically learn about
blitzing the value proposition sounded too good to be true.
It was a little bit like magic is like you give me the
specifications, give me the code and we will autonomously
generate everything. It was very, it was very
attractive. So we went and visited blitzing
their their offices in Boston to learn, you know, what was their
vision, what was their product? I mean, just meet with, you
know, founders on the management and we like the approach.
It was very aligned with what we're trying to achieve in the
in, you know, here in GMP. So we decided to execute a pilot
that will sufficiently evaluate, you know, the abilities of Blitz
C in our own environment and with our own code.
Tell us about that pilot and what were your goals for the
pilot? The goals of the pilot were to
evaluate, you know, the capabilities of Blitz C as a as
a software development platform. So what we did is we selected
one an existing system that that we have real system that
actually had a, you know, a number of requirements that had
to be executed anyway. And what we decided is to test
different types of use cases using this existing system.
So one of them was a back end migration.
I mean the back end was written in an old version of Java, Java
8, and we needed to modernize. Got back into Java 21, that was
very clear. Same thing with the front end.
Front end was developed in a very old version of Angular.
I think it was Angular 11, I might be wrong and we needed to
upgrade it to one of the latest versions.
We also wanted to test a specifically use case to build a
new feature autonomously that is providing the right prompt to
the platform of you know, describing the new functional
feature in business terms that we wanted to build and having
the system built the new feature for us.
And then a fourth use case where we wanted to do the remediation
of a number of security vulnerabilities that the system
had. So we thought that, you know,
with that breadth of use cases, it will be a nice spectrum to to
basically test the capabilities of the system in a real life
environment, which was our environment connected to our Git
lab repository where all of our code resides and connecting it
to our CICD pipeline. Basically, that's what we wanted
to test. Why didn't you just give these
small teams the opportunity to vibe code their way into this
modernization? That was perfectly possible.
Most of our teams, they're using, you know, Co pilots to
basically work faster and have the Co pilots, you know,
partially developer, they're trying to develop and test what
they're doing. But this is a different type of
platform. I mean, there's no, there's no
ID initially here. It's just a platform.
You provide a very detailed prompt of what you want to
achieve and then the system using its own internal logentic
architecture basically autonomously creates all the
different software changes or creates the new software that
needs to be incorporated into your project.
That's what we wanted to test, yes.
I mean, we could have given this to a team, you know, given
different not only one, but you know, even several types of
copilots. And we're working that way
already. But we have never worked with an
autonomous platform. And the idea was to explicitly
test a platform that has a different, you know, paradigm of
usage than the rest of the byte coding tools.
So you were really looking at shifting the strategic value of
technology development? Right, exactly.
What does autonomous development mean in practical terms at GNP
and and how does Blitzie fit along with the other tools in
your AI code generation stack? We are interested in increasing
agility as much as if it is feasible.
That has been our, you know, our objective for for many years.
So if we're in adapting methodologies, incorporating
tools, you know, streamlining our CICD pipeline in order to
try to achieve agility, we keep improving, trying to make
changes to improve agility. We want to change the role of
humans in the software development process.
We want to do it to achieve agility by coding.
And you know, all the tools that assist work groups are great.
I mean, they do provide value, but we wanted to test a new
generation of or or a new type of tools for generating software
in an in an autonomous way. That's a value proposition of
bleed. See, it looked, sounded very
attractive to us and that's what we wanted to test.
What's the value of that is, you know, you have to learn a new
skill, which is being very good at prompt engineering.
You have to be, you have to create very precise and complete
prompts for for the platform. But if you do, and that's the
skill that you know, I've seen that our engineers have learned
fast. Once you get the right prompt,
then you get the right results in the speed.
That was very impressive. What about enterprise
requirements such as security, governance, architectural
standards? How does this approach support
the corporate technology requirements that are needed?
You definitely need to be very specific regarding your own
corporate guidelines. We do have our own guidelines,
you know, technical guidelines. We have our own security
guidelines too, regarding characteristics that code has to
meet and the type of test we want to execute on the on the
components that we develop. But what we found is that, you
know, those specification, those guard rails, those are part of
the input that you provide to a platform like Blitzing.
So you not only provide you know the functional specs and the
intention of your project with all the functional you know
specifications, you also provide all the technical and security
guidelines too. What results have you seen
across development? Velocity, Quality of code?
Cost Hours saved. We were very pleased with the
results that we got. We roughly were able to
accelerated development velocity of between 5:00 and 10X in terms
of engineering velocity and the percentage of all the completed
work done autonomously by Blitzie, it ranged from between
80 and 95%, depending in the use case.
For example, use cases that you basically want to upgrade from
an old version of Java to a new version of Java.
And you do have to provide the guidelines of how to do the
upgrade. It's not, it's not as simple as
just mentioning just upgrade it. Just upgrade from May to 21 and
I'm done requesting. Now you do have to provide a lot
of information on how to do it. But those type of projects, we,
we basically saw that, you know, the, the percentage of
autonomous completion was close to 100% front end.
You know, modernization of front ends is different.
Those, it's a little bit more tricky, but we got around 80%
but and an 80%, you know, the, what basically the team told me
is 80% is just wonderful. I mean, and so I mean we still
have to do 20% and for the reminder 20%, they do by coding,
bringing their IDs, they're bringing their copilots and they
finish the reminder 20%. And you know, overall that
accelerates the process a lot. So they're using Blitzy to do
the heavy lifting and then using lighter weight tools to do the
fine tune polishing. Exactly to basically complete
the project. Enrique, how did the developer's
jobs, roles and daily work change as a result of this shift
to autonomous development? The role of humans changes.
You still need developers. If you're going to develop a
system, you need to provide technical guidelines, you need
to provide guidelines related to the platforms where the software
is going to run. And an end user cannot do that.
I mean, in in our case, we, we deploy our systems mainly in
Google Cloud. So you need to know about the
technical features and then and, and the technical settings that
you need to enable in the in the cloud platforms in order for the
system to run. An end user is not going to do
that. So you still need a program, but
the role changes completely. I mean, it's the human is not
writing the code. I mean, the human is directing a
platform on how to write the code.
So that's, I mean, that's a huge, you know, changing
paradigm. How did the developers react?
You have to be careful with the change management and the human
resistance to change is something that you cannot
overlook in general. Some of them were skeptic at the
beginning, You know, it was like this sounds too good to be true.
As we started work with the platform and getting results,
their attitude changed very rapidly and they started to get
interested and they started to see value.
They were intellectually challenged by, you know, this
new type of work. So they not only accepted it,
but they were very motivated in, in testing the platform in, in
testing the different prompt, you know, techniques to try to
achieve better results from, from the platform.
And I think that overall the group that so far has worked
with Blitzi at GMP, they're they're excited about it and
they're very enthusiastic about, you know, basically expanding
the use of Blitzi to the rest of of our software development.
What advice would you give to other CIOs on transforming their
engineering organization to be AI native in this same way?
You don't just flip a switch to full autonomy.
That doesn't doesn't work that way.
You have to build trust through a faced human in the loop
approach. You need to target the friction.
You know, we need to deploy agents to 1st to handle high F4,
low risk friction points first. Such as you know, this
modernization projects of basically upgrading the
programming languages or writing system documentation for
example, or generating test suites.
This type of tasks that generally are low friction.
Then you need to shift the engineering mindset.
We have to train our engineers to transition from being
creators to editors and orchestrators.
It's a different role, and the human leader's job now becomes
defining the prompt, reviewing the architecture, and validating
the AI's execution. You are a technologist, You're
also a business person. Can you describe the strategic
benefits that this approach and the faster development speed
unlocks for GNP? Development speed is isn't just
about writing code faster. I think it on lots different
strategic advantages and 1 is like first to market innovation.
I mean, you know, we can design, deploy and iterate on like new
insurance products in weeks rather than in months or
allowing us to capture market demand before our competitors
even react. That's one of the goals that we
have. The other benefit and the other
objective that we have as a company is improving customer
experience. So this speed and this agility
empowers us to continuously ship digital improvements, so like
instant claim processing or, or seamless onboarding and
basically try to meet the, the high expectations of the modern
consumer who, who is, you know, basically they're more demanding
all the time. It shifts our technology
organization from simply maintaining the business to
actively dictating the pace of the Mexican insurance market.
That's that's our goal. As you plan to roll this type of
agentic product development out across the company, what are
your thoughts? What are your concerns?
What's the approach that you're taking?
We are now a process of expanding the use of the Blitzy
platform. We have incorporated seven
additional teams now that they're going to be trained and
they're going to be Twitter, they're going to be some hand
holding of working with them between Blitzy engineers and the
our engineers that have already gone through the different
projects the last four months. So we're going to gradually
start expanding the use and what we are going to measure and make
sure that it gradually happens and becomes a reality is that
our speed of execution basically improves at a very noticeable
and exponential rate. And gradually we will continue
to expand. I mean initially we have seven
groups. Once this groups are
sufficiently mature, they will continue working in this fashion
and they will continue incorporating groups.
We think that in the two year time frame we will be able to
change the paradigm in in the company.
And how many developers do you have?
Currently we use in between our own developers and external
developers from software factories.
We have around 1000. Ideally we should not rely on
external developers in the short to medium term and we will only
keep internal employees basically working with
platforms. So speed was the driver, but
ultimately you will also be reducing cost.
Yes, definitely. Any final advice on how
engineering leaders can get started or should get started
with autonomous development? You can easily pick within your
organization a use case. I mean, either a very old system
that need to be modernized or a system that is giving you a lot
of problems, you know, during regular operation because this
has a lot of bugs or has a lot of security vulnerabilities.
And try these type of tools. I mean, you know, big bigger use
case. Pick an existing system and just
try it and you know, sandbox it, do it carefully, you know,
select the right initial set of engineers to work in this
project to make sure that they will be able to to do the
transition and to understand this new paradigm.
Test it, see how it goes. And you basically elaborate from
there. You just presented a very
practical and wise textbook on AI adoption.
I think it's just common sense, but thank you.
Enrique Ibarra, thank you so much for taking time to speak
with us today. No thanks to you, Michael.
It was an honor. Thank you.