The age of native AI: the new paradigm redefining the role of the programmer

Little by little, the adoption of Artificial Intelligence is moving beyond the hype to become the driving force behind business transformation. In the software development ecosystem, this technology is redefining how organizations operate. The market is currently at a decisive turning point. Deloitte surveyed several organizations in the United States, a third of which are beginning to use AI to create new products and services or to reinvent core processes or business models. The industry's greatest challenge is not simply adopting new tools, but completely changing traditional work paradigms.

The true revolution no longer lies solely in implementing generative AI on top of legacy structures, but in achieving "native AI." This concept represents the highest level of maturity, where companies modify their processes from the ground up rather than forcing the technology to fit. Through "agentization" and orchestration, multiple artificial agents can handle complex tasks simultaneously. This methodology frees software from being an expensive resource to build, significantly accelerating time-to-market.

As a result, the role of the programmer who merely wrote code is rapidly disappearing. Now, developers take on the role of editors within a "human-in-the-middle" model, overseeing quality and validating architecture. New key competencies include designing scalable systems and specifying requirements. In fact, mastering agent-based tools is now a much more highly valued prerequisite than knowing a specific programming language.

Despite its benefits, the transition faces obstacles. Companies in highly regulated sectors, such as traditional banking, are resistant due to risk and a lack of time to experiment. To overcome this, leadership must commit to ongoing training. On En Contxto, we spoke with Pablo Gamba, VP of Technology for the Americas at intive, about how to implement native AI and the future of development. 

Stiven: Hello, and welcome to En Contxto. Today we're featuring a new episode on Artificial Intelligence, and I'm joined by Pablo Gamba from intive. Pablo, welcome to En Contxto. Could you tell us a little about your role within the company and what intive does?

Pablo: Sure, thanks, Stiven, for the invitation. It's a pleasure to be here. Well, intive is a company that offers software development and technology services. It's a global company, and we basically cover the Americas and the EMEA region. We've been in business for quite a few years now—about 20 years in the market. We offer a wide range of technology services applied to software development across various business verticals, including Automotive, Fintech, Healthcare, Media, Technology, Communications, and Retail. We have a comprehensive range of technologies covering all aspects of the platforms we're currently working on, ranging from front-end and back-end development to complex architectures, as well as release and automation processes using DevOps, QA (Quality Assurance), and software engineering. Above all, in recent years we have been continuously working with artificial intelligence, which really took off three years ago and further expanded our range of services for clients around the globe in both regions. In my case, I'm in charge of the technology division for the Americas region, leading the engineering teams and bridging the gap between operations and technology through the people we work with. Lately—let's say over the past two years—my focus has been heavily on the transformation driven by artificial intelligence, specifically how it's redefining the way we build software and run organizations. So I'm really focusing on that discipline and on all the transformation we've undertaken here to help our clients.

Stiven: That's great, Pablo. You just mentioned something really interesting—that you've been working with AI. Well, it became popular, as you mentioned, three years ago. I think that's a good starting point because AI isn't new, right? What is new—or what has become popular—is generative AI. Could you explain a little bit about why AI isn't really new?

Pablo: Well, it all started several years ago. With the rise of big data and data science—which involved handling large volumes of data—people began working on processing information to make decisions and make this data available to companies. All of that evolved, so to speak, taking a giant leap forward with the arrival of Large Language Models, which opened up new possibilities around the time transformers were developed. Up until that point, AI had been somewhat focused on generating information based on large volumes of data and processing that data. Now, generative artificial intelligence already enables much greater functionality and is beginning to permeate all disciplines and markets. Thanks to these data volumes, all those language models have made it possible to build applications on top of them, with all the automation we're seeing today—and how it's impacting us and fundamentally changing our work paradigms.

Stiven: Exactly. And within those very paradigms you mentioned—which are changing things so profoundly—a new concept is emerging: native AI, right? How does it differ, and how did this new concept come about? What does native AI consist of?

Pablo: Well, to explain native AI, maybe we should take a step back and look at how we got here, right? There are different levels of maturity; there isn't necessarily a standard framework today, but in my view, we can identify four levels. Level zero would be when you start out and conduct your first experiments, allowing a company—whether it's a software development firm or an operations company—to grant licenses, experiment, begin to explore, and achieve certain individual improvements in work, such as performing better, faster, or with higher quality. That would be an initial level. The second level is where we start to see how we can standardize a practice and establish some defined elements that we can reuse across teams or among peers. This would be the second level, but it still lacks governance or a well-defined plan for evolution and scalability, so while there is still significant improvement on an individual level, the collective improvement is not as great. Then, when we reach level 3, we establish governance and leadership with a plan and defined metrics that we'll be working toward. We begin to think and realize that applying AI to existing processes isn't necessarily what will give us that largely exponential return when we're talking about a 10x increase. Then we reach Level 4, which is when we start discussing agentization and orchestration. We start talking about these processes that allow us to think differently, and in doing so, we necessarily have to restructure the way we work, our processes, and change our mindset; even roles and responsibilities change. So, it wouldn't be about applying artificial intelligence to the status quo, but rather modifying the status quo to then implement that artificial intelligence. Through this orchestration of agents and shift in roles, we'd already be in a native AI environment, because we're using it natively and have adapted to it, rather than adapting AI to us—okay?

Stiven: Okay, perfect. That brings me to the next section, Pablo, because that's precisely what many companies may not understand: they try to implement it within what they already have when, as you say, it should be a process of adaptation. So, moving on to the next question: What goes wrong in a company like yours—at intive—based on the examples or cases you've encountered? What can go wrong, or what can work, in a company when it comes to implementing all these automation processes?

Pablo: Well, we can cite specific examples of implementation in software teams. The main issue—or I'm not sure if "issue" is the right word—but the problem we're seeing today is that the challenge is that companies are producing, almost all of them. Especially these days—over the past two years—we've been operating at a more limited capacity, not as much slack as during the pandemic, which means the company is running at nearly 100% capacity or more. So there's very little room left for experimentation. In other words, there is experimentation, but there isn't necessarily enough investment available to make that fundamental change: taking a team, putting it to work on testing and developing, and thus beginning to transform. So, that's the number one challenge—it's what we see with our clients, and it's where we step in to help. We have a general idea of the path forward and understand the technical challenges our clients face, but they don't necessarily have the time or experience to scale this up and ensure that the impact is truly significant beyond individual cases. That's one of the limitations we see today. Another limitation comes from companies that deliberately don't want to innovate and are slow to embrace that innovation because there's so much hype surrounding artificial intelligence and there's a process of acceptance. First comes denial; then you can start experimenting and say, "Wow, look at what I can do with this"; and suddenly, adoption kicks in, where you say, "I don't know how I ever worked without this technology before." But even so, the steps I'm outlining aren't necessarily fundamental changes; what's missing is leadership capable of making that change and driving it forward. It's essential that those leaders be prepared. Not all leaders are, or perhaps they're afraid to make the change for whatever reason, since the market situation today isn't so easy. That's basically one of the limitations we're seeing today. That's where we come in: we offer our clients a model for how to get started and how we can help them. We begin by transforming their operations as an additional layer integrated into their teams; we help them scale so they can continue on their own, and at the very least, we've already set them on that path so they can carry it forward. In this case, the key is the ability to innovate. The understanding that—beyond the hype and the news you see on Twitter every day about new models—if you grasp that this is a significant shift in the paradigm and in software engineering, you begin to adapt and make those role changes. For example, the fact that a software engineer is starting to stop writing code is something that should already be accepted by now. They become more of an editor and a reviewer, since the automation of quality assurance is now an absolute necessity. In the past, one of the challenges we typically faced in projects was a lack of automated testing coverage or a lack of a comprehensive quality discipline due to cost and time constraints. Today, you can accelerate this process with artificial intelligence, and those roles are beginning to blur. A software engineer is also beginning to incorporate quality practices. This is becoming evident because they're essentially starting to orchestrate and design. In that design process, they begin implementing the solution with the help of the agent, which means they gain an understanding of the entire discipline, the definition of architecture, and what software engineering entails. Thanks to that and the integration with artificial intelligence, you're already seeing a major shift, because one role is incorporating several roles. The market is giving these roles new names, isn't it? The labels for Prompt Engineering are constantly changing; the landscape is constantly shifting, but fundamentally, one has to understand that this is accelerating because it's changing. Software is no longer expensive to build. We're in the disruptive phase, but it will reach a point where the limitation won't lie in building the software itself, but rather much earlier in the process.

Stiven: Exactly. You also mentioned leaders just now, right? That there are obviously leaders who are resistant. From the pitches and information I'm receiving, I see that one of the sectors that's perhaps most apprehensive about all these innovations is banking—especially traditional banking. At least in some countries, there's a bit of a delay in implementing automation strategies due to that fear or, as you said, because of their investment capacity. You mentioned something about orchestration earlier. What does it really mean to orchestrate workflows, Pablo?

Pablo: Let's say, to draw a parallel, that in an orchestra you have different instruments and there's a conductor guiding them, telling who plays first, who plays next, and what they need to play. In this case, it's similar. Let's say we replace defined roles in the software engineering process with agents: one agent that defines or specifies requirements, one agent that writes the code and handles development, another agent that verifies quality, and another agent that validates what's been implemented… In the middle is the orchestrator, who essentially configures and acts as what we call the "human in the loop," the human in the middle, ensuring that every step in this chain is effective and performing the necessary validation so that the software is built properly, thereby avoiding the cognitive debt that comes from letting everything happen automatically. There's also automated orchestration; we're experimenting with that, and we have partners who are doing the same. It's all experimental because there are many challenges to resolve along the way, but that orchestration is precisely what gives you speed—and that's the significant change. Notice how the roles are shifting: humans are the ones doing the work and streamlining it, which requires a new skill set—and that's what's transforming the industry and will continue to do so in the coming years.

Stiven: Excellent. Yes, that brings me to my next question, because I had it written down right there, and it was about those agent-based systems: To what extent can you build a system that's autonomous, sure, but at the same time is fully verifiable by an orchestrator—one that doesn't make mistakes or simply act without being accountable to a human? How do you build a successful orchestration system?

Pablo: Well, today it's quite challenging to eliminate the human element. If you do it, you basically configure all the agents and feed them models like Claude or others that provide the entire interface for you to set them up. You configure these agents and their skills, and you establish the dynamic loops between them. You can also configure a meta-agent or orchestration agent so that, for example, using the ID of a ticket from a requirements management system like Jira, it retrieves all the information and delivers the software to the production branch. But I'll say it again: I believe humans are still in the loop; if you're not participating or keeping track of what's happening, it creates that cognitive debt. Then, when that software goes into production and eventually fails, no one knows exactly what the software is doing. Obviously, we'll turn to artificial intelligence again to try to understand what's happening, but in a way, we're delegating too much. And if I want to go back to what you mentioned about fintech or banking, it's too high-risk a vertical to engage in extensive experimentation, since we're talking about financial transactions, security, and a lot of regulations. We have extensive experience in applying regulations to software in industries such as fintech, automotive—which is also highly regulated—and healthcare. In these cases, a special review is necessary, because that's precisely where extensive validation is required. That's what scares leaders: To what extent is this technology mature enough for me to use it without causing a problem? Because ultimately, what this new agent-based GenAI technology is giving us is greater speed in releasing features, producing software, and doing more business. If I want to put new features into production, the cycle time—the time from when I decide which feature to implement until it goes live—is shrinking, but it shouldn't come at the cost of a risk or a problem down the line. So that's one of the major challenges in fintech.

Stiven: Exactly. Pablo, what is the role of developers like now? It's true—it's no longer just about writing code; they're now also becoming part of orchestration systems. What is it like today, and what will it be like in the future? What skills should a programmer have in the future?

Pablo: Excellent question. As we know, we're constantly reviewing this, and things are changing. Even before what's happening now—let's say over the last 24 months—some roles were already shifting. Generally, when we build software, we're talking about platform software at scale. We have front-end development—which can be web or mobile—handled by specialized front-end developers using JavaScript, or native or hybrid mobile technologies. Then there's the entire backend platform side, typically handled by a backend engineer. Every project is always supported by a software architect or solution architect who designs the solution. Then full-stack developers came along; suddenly people started asking, "We want full-stack developers—we don't want separate front-end and back-end roles." And then we started saying, "Well, but we also want them to have QA skills," so the roles began to blend. And when AI comes along, you basically say, "Okay, now I can mix it all together." Because the skills you need today are based on a foundation of understanding what software engineering is—the discipline that allows you to build high-quality, well-developed software that is maintainable and enables you to implement a solution for a real business. So, within that discipline, the most important thing is to understand its implications. Today and in the future, the most important thing for a software developer is to understand the fundamentals not only of programming but also of software engineering. The requirements that are already being sought—and will become even more prevalent—are an understanding of software architecture and the ability to design it based on requirements. While a client might come up with the design, you need to ensure that the architecture is scalable, maintainable, and cost-effective. So you need architecture skills first, followed by programming skills—whether front-end, back-end, or mobile. Today, knowing a specific language—be it JavaScript, Java, or Python—isn't as relevant; right now, it's not as important because the agent does the coding for you. You need to be able to read and understand a programming language, and the agent will guide you through it. And of course, quality assurance and requirements specification are also key. Being able to specify and describe in natural language what an application needs to do is essential. Architecture, code, and quality are all fundamental. Those are the skills you need to have, but above all else is the judgment necessary to make decisions throughout that process. In the past, people used to say, "I'm going to be a programmer and nothing but a programmer," but that's changing—and very quickly—so you have to gain experience and cross-functional knowledge. How do you specify a requirement? What is a requirement, and what is its purpose? Many of the problems we face today when we want to automate or implement artificial intelligence in a project stem from the fact that we suddenly find there's no requirements specification, which means we can't ensure quality. So we have to go back further in the process and correct it. All these implications for the software engineering process are skills that current—or even veteran—software engineers will need to have in order to remain relevant in this field.

Stiven: And there, Pablo, leaders also play an important role in training, because let's say there's already a team of developers. What would you say, or what tools should they have to train and empower their team of architects and developers—so they don't suddenly end up saying, "We don't need them, so now we're going to look for developers who understand requirements and all that"?

Pablo: That's also an excellent question because, as a leader, the most important thing you have is talent. The truth is that discarding your existing talent to go out and find new talent that brings what you need is complicated, because what's most valuable today is experience. As you need to bring in new talent, the wise and effective approach is to retrain and develop your current team; then, if you'd like, we can discuss junior talent. But it's essential that the leader establish learning paths, understand how the market is changing, and provide the plans and programs so that the team can be trained and acquire the necessary skills. We generally have programs where you have a mentor and annual goals that are broken down by quarter. In this process, you clearly define your current skill level and identify the skill gap you need to bridge. From there, we essentially map out the completion of courses and certifications—not just cloud certifications or those for the hyperscalers we use, but also certifications for AI-powered tools that are now becoming available, such as Claude, Cursor, GitHub Copilot, and others. This is reinforced with a certification course that validates that knowledge through the appropriate training. So it's essential for the leader to define that skills gap and oversee their team's training. And well, new talent is already being recruited differently as well. The typical technical interview has changed dramatically; today, experience with agent-based tools is a must and a strict prerequisite. Knowledge of a specific programming language is no longer as relevant, and for a developer, greater emphasis is now placed on whether they know how to write specifications or understand quality assurance practices—beyond just coding.

Stiven: Excellent. Before, interviews were purely based on practical exercises, right? Just tests and all that.

Pablo: Exactly.

Stiven: Well, Pablo, we're running out of time. I don't know if there's anything else you'd like to share with us. Any advice for companies on how to prepare for this transformation they're facing, and to encourage them to adapt and incorporate these automation systems?

Pablo: Well, my advice for all executives, directors, and leaders is to engage in ongoing training in this ever-changing and evolving world. The ground is constantly shifting, and these days you need the discernment to tell what's real and what isn't—what's just hype and what's truly here to stay. And from there, stay informed, because it's extremely important to understand what's happening so you can make informed hiring decisions later on. Honestly, you're not going to overhaul your entire department or implement technology if your department isn't technology-focused, but you do need to be able to speak that language to truly understand. Technology is becoming increasingly accessible, and a department looking to hire services to transform its operations needs to understand the lingo and grasp what's being offered. Because in this world, there are also many who offer things that aren't quite what they seem, and there's an investment involved—and, well, we want to minimize risk and ensure success, don't we? That's why ongoing training is essential, and there's no need to be afraid; we're in a period of experimentation, but we're already seeing real impacts from the application of technology, so… that's the direction we're heading.

Stiven: All right, Pablo, thank you so much for joining us on En Contxto and for your time.

Pablo: Thank you very much, Stiven, and to your whole team.