Autonomous Software Development at Enterprise Scale: Inside a 1,000-Developer Pilot (with Blitzy) | CXOTalk #918

The percentage of all the completed work done autonomously by Blitzy, it range from eighty and ninety five percent, depending on the use case. We accelerated development velocity of between five and ten X. The human is not writing the code, the human is directing a platform on how to write the code. That's a huge changing 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 twenty 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, uh, it's gonna 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, too, in terms of how do we give longevity to this asset? We started a few years ago, incorporating the typical, uh coding co-pilots. Now we, we incorporated several informally, we started to provide all of our developers with a co-pilots without formally measuring their increase in productivity. We just basically use it, find it useful, take advantage of it, and that's being expanded among the uh all of our developer base, and we have roughly about a thousand developers.

By looking at different industry solutions, we find we basically learn about Blitzy. Uh, the value proposition sounded too good to be true. Uh, it was a little bit like magic. It's like, you know, 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 Blitzy in their, uh, at their offices in Boston to learn. You know, what was their vision, what was their product?

I mean to meet with the, you know, founders and the management. And we liked the approach. Uh, it was very aligned with what we tried to achieve in the in, you know, here in a GNP. So we decided to uh, execute a pilot that will sufficiently evaluate, you know, the abilities of Blitzy 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 Blitzy as a, as a software development platform. So, uh, what we did is we selected one, an existing system, that that we have a 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 eight, and we needed to modernize that back-end to Java twenty one. 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. Ele- eleven. 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 would 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 re 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 and have the co-pilots, you know, partially develop what they're trying to develop and, and test what, what they're doing. But this is a different type of platform. I mean, there's no, there's no IDE 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 agentic, uh, architecture, basically autonomously creates all the different software changes, so 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, and, you know, given different, not only one, but, you know, even several types of co-pilots, 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, uh, you know, paradigm of usage than the rest of the by coding, uh, tools.

So you were really looking at shifting the strategic value of technology development, what does autonomous development mean in practical terms at GNP and and how does Blitzy fit along with the other tools in your AI code generation stack?

We are interested in increasing agility as much as it is feasible. That has been our, you know, our objective for for many years. So we've been adapting methodologies, incorporating tools, you know, streamlining our CICD pipeline, uh, 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. Um, we wanna 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 tool for generating software in an, in an autonomous way. That's the value proposition of Blitzy. It looked, sounded very attractive to us, and that's why we wanted to test. What's the value of that? It's, 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 a 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 a 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, uh, the type of tests we want to execute on the, on the components that we develop. But what we found is that, you know, those specification, those guardrails, uh, those are part of the input that you provide to a platform like Blitzy.

So you not only provide, you know, the functional specs and the intention of your project with all the functional, uh, 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, hour saved?

We were very pleased with the results that we got. We roughly, uh, were able to accelerated development velocity of between five and ten X in terms of engineering velocity and the percentage of all the completed work done autonomously by Blitzy, it range from between eighty and ninety five percent, depending on 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 eight to twenty one and I'm done requesting. No, you do have to provide a lot of information on how to do it. But those type of projects, we, we basically, uh, saw that, you know, the the percentage of autonomous completion was close to 100%. Uh, front end, uh, you know, modernization of front ends is different. Those. It's a little bit more tricky, but we got around 80%.

But, and 80%, you know, but basically the team told me is 80% is just wonderful. I mean, so, I mean, we still have to do 20%. Um, and for the remainder 20%, they do bike coding, bringing their IDEs, they're bringing their co-pilots, and they finish the remainder 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 developers 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 our case, we, we deploy our systems mainly in Google Cloud, so you need to know about the technical features and the, and, 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 programmer, 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. Uh, you know, it was like this sounds too good to be true. As we started to 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, you know, different prompt, uh, 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 Blitzy at GNP, they're, they're excited about it, and they're very, uh, enthusiastic about, you know, basically, uh, expanding the use of Blitzy to the rest of, of our software development.

What advice would you give to other CIO's 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. Uh, you, you have to build trust through a phased human-in-the-loop approach. You need to target the friction, uh, you know, we need to deploy agents to first to handle high effort, low risk friction points first, you know, such as, you know, this modernization projects of basically upgrading the programming languages, or, um, writing system documentation, for example, or generating test suites, this type of tasks that generally are low friction.

And 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 unlocks different strategic advantages, and one 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 ex, uh, the high expectations of the modern consumer who, who is, uh, 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, uh, the Blitzy platform. We have incorporated seven additional teams now that are gonna be trained and they're gonna be tutored. There gonna be some hand holding of working with them between Blitzy engineers and the our engineers that have already gone through the different projects in the last four months. So we're gonna 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 a 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 using between our own developers and external developers from software factories, we have around a thousand. 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 needs to be modernized, or a system that is giving you a lot of problems, you know, during regular operation because it has a lot of bugs or it has a lot of security vulnerabilities. Try these type of tools. I mean, you know, pick, pick a use case, pick, pick an existing system and, uh, 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, uh, 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.