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

Autonomous development at Mexico's largest insurer

Enrique Ibarra: The percentage of all the completed work done autonomously by Blitzy, it range from 80 and 95%, depending on the use case. We accelerated development velocity of between 5 and 10X. 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. 

Michael Krigsman: 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.

Why GNP decided to modernize COBOL

Enrique Ibarra: 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 too, in terms of how do we give longevity to this asset.

From co-pilots to an autonomous platform

Enrique Ibarra: We started a few years ago incorporating the typical coding co-pilots. Now, we incorporated several. Informally, we started to provide all of our developers with co-pilots without formally measuring their increase in productivity. We just basically use it, find it useful, take advantage of it, and that's been expanded among all of our developer base, and we have roughly about 1,000 developers.

Enrique Ibarra: By looking at different industry solutions, we found. We basically learned about Blitzy. The value proposition sounded too good to be true. 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 attractive, so we went and visited Blitzy at their offices in Boston to learn what was their vision, what was their product. I mean, to meet with the founders and the management. And we liked the approach. It was very aligned with what we're trying to achieve here at GNP. So we decided to execute a pilot that will sufficiently evaluate the abilities of Blitzy in our own environment and with our own code.

Designing the pilot and its use cases

Michael Krigsman: Tell us about that pilot, and what were your goals for the pilot?

Enrique Ibarra: The goals of the pilot were to evaluate the capabilities of Blitzy as a software development platform. What we did is we selected an existing system that we have, a real system, that actually had 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.

Enrique Ibarra: So one of them was a backend migration. I mean, the backend was written in an old version of Java, Java 8, and we needed to modernize that backend to Java 21. That was very clear. Same thing with the frontend. Frontend 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.

Enrique Ibarra: 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 describing the new functional feature in business terms that we wanted to build and having the system build 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.

Enrique Ibarra: So we thought that with that breadth of use cases, it would be a nice spectrum to basically test the capabilities of the system in a real-life environment, which was our environment connected to our GitLab repository where all of our code resides, and connecting it to our CI/CD pipeline, basically. That's what we wanted to test.

How autonomous software development differs from vibe coding

Michael Krigsman: Why didn't you just give these small teams the opportunity to vibe code their way into this modernization?

Enrique Ibarra: That was perfectly possible. Most of our teams, they're using co-pilots to basically work faster, and have the co-pilots partially develop what they're trying to develop and test what they're doing. But this is a different type of platform. I mean, 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 agentic 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.

Enrique Ibarra: Yes, I mean, we could have given this to a team, give them different, not only one, but 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 paradigm of usage than the rest of the vibe coding tools.

Michael Krigsman: So you were really looking at shifting the strategic value of technology development.

Enrique Ibarra: Right. Exactly.

Agility as the organizing objective

Michael Krigsman: What does autonomous development mean in practical terms at GNP, and how does Blitzy fit along with the other tools in your AI code generation stack?

Enrique Ibarra: We are interested in increasing agility as much as it is feasible. That has been our objective for many years. So we've been adapting methodologies, incorporating tools, streamlining our CICD pipeline, in order to try to achieve agility. We keep improving, trying to make changes to improve agility.

Enrique Ibarra: We want to change the role of humans in the software development process. We want to do it to achieve agility. By coding, 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 a new type of tools for generating software in an autonomous way. That's the value proposition of Blitzy. It sounded very attractive to us, and that's what we wanted to test.

Enrique Ibarra: What's the value of that is, you have to learn a new skill, which is being very good at prompt engineering. You have to create very precise and complete prompts for the platform. But if you do, and that's a skill that, 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.

Embedding security and governance in prompts

Michael Krigsman: What about enterprise requirements such as security, governance, architectural standards? How does this approach support the corporate technology requirements that are needed?

Enrique Ibarra: You definitely need to be very specific regarding your own corporate guidelines. We do have our own guidelines, technical guidelines. We have our own security guidelines too regarding characteristics that code has to meet, the type of tests we want to execute on the components that we develop. But what we found is that those specification, those guardrails, those are part of the input that you provide to a platform like Blitzy. So you not only provide the functional specs and the intention of your project with all the functional specifications, you also provide all the technical and security guidelines too.

Measured results and velocity gains

Michael Krigsman: What results have you seen across development, velocity, quality of code, cost, hours saved?

Enrique Ibarra: We were very pleased with the results that we got. We roughly were able to accelerate a development velocity of between 5 and 10 X in terms of engineering velocity. And the percentage of all the completed work done autonomously by Blitzy, it range from between 80 and 95%, 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.

Enrique Ibarra: It's not as simple as just mentioning, just upgrade it. Just upgrade from 8 to 21 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 basically saw that the percentage of autonomous completion was close to 100%.

Enrique Ibarra: Front end modernization of front ends is different. It's a little bit more tricky, but we got around 80%. And 80%, what basically the team told me is 80% is just wonderful. I mean, we still have to do 20%. And for the remainder 20%, they do by coding, bringing their IDs, they're bringing their copilots, and they finish the reminder 20%. And overall, that accelerates the process a lot.

Michael Krigsman: So they're using Blitzy to do the heavy lifting, and then using lighter weight tools to do the fine-tune polishing.

Enrique Ibarra: Exactly, to basically complete the project.

The developer's new role

Michael Krigsman: Enrique, how did the developers' jobs, roles, and daily work change as a result of this shift to autonomous development?

Enrique Ibarra: 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 deploy our systems mainly in Google Cloud, so you need to know about the technical features and the technical settings, and you need to enable 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. The human is not writing the code. I mean, the human is directing a platform on how to write the code. So that's a huge change in paradigm.

Managing developer skepticism and change management

Michael Krigsman: How do the developers react?

Enrique Ibarra: 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. 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.

Enrique Ibarra: They were intellectually challenged by this new type of work. So they not only accepted it, but they were very motivated in testing the platform, in testing different prompt techniques to try to achieve better results from the platform. And I think that overall, the group that so far has worked with Blitzie at GNP, they're excited about it, and they're very enthusiastic about basically expanding the use of Blitzie to the rest of our software development.

Advice for CIOs going AI-native

Michael Krigsman: What advice would you give to other CIOs on transforming their engineering organization to be AI native in this same way?

Enrique Ibarra: You don't just flip a switch to full autonomy. That doesn't work that way. You have to build trust through a phased human-in-the-loop approach. You need to target the friction. We need to deploy agents to, first to handle high effort, low risk friction points first, such as 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.

Enrique Ibarra: 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.

Strategic advantages for the business

Michael Krigsman: 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?

Enrique Ibarra: Development speed isn't just about writing code faster. I think it unlocks different strategic advantages, and one is first to market innovation. We can design, deploy, and iterate on 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.

Enrique Ibarra: 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, such as instant claim processing, or seamless onboarding, and basically try to meet the high expectations of the modern consumer who is basically 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 our goal.

Scaling agentic product development across teams

Michael Krigsman: 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?

Enrique Ibarra: We're now a process of expanding the use of the Blitzie platform. We have incorporated 7 additional teams now that they're going to be trained, and they're going to be tutored. There's going to be some handholding of working with them between Blitzie engineers and 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.

Enrique Ibarra: And gradually we will continue to expand. Initially we have 7 groups. Once these groups are sufficiently mature, they will continue working in this fashion, and they will continue incorporating groups. We think that in a 2-year timeframe we will be able to change the paradigm in the company.

Internal talent and cost implications

Michael Krigsman: And how many developers do you have?

Enrique Ibarra: Currently we use, and between our own developers and external developers from software factories, we have around 1,000. 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.

Michael Krigsman: So speed was the driver, but ultimately you will also be reducing cost.

Enrique Ibarra: Yes, definitely.

How to get started with autonomous development

Michael Krigsman: Any final advice on how engineering leaders can get started or should get started with autonomous development?

Enrique Ibarra: You can easily pick within your organization a use case. Either a very old system that need to be modernized or a system that is giving you a lot of problems during regular operation because this has a lot of bugs or it has a lot of security vulnerabilities. And try these type of tools. Pick a use case, pick an existing system, and just try it. And sandbox it, do it carefully. Select the right initial set of engineers to work in this project to make sure that they will be able to do the transition and to understand this new paradigm. Test it, see how it goes, and you basically elaborate from there.

Michael Krigsman: You just presented a very practical and wise textbook on AI adoption.

Enrique Ibarra: I think it's just common sense but thank you.

Michael Krigsman: Enrique Ibarra, thank you so much for taking time to speak with us today.

Enrique Ibarra: No, thanks to you, Michael. It was an honor. Thank you.