You Can't Apply AI to a Broken Process – An Interview with Pablo Gamba

You Can't Apply AI to a Broken Process – An Interview with Pablo Gamba

An interview with Pablo Gamba, Head of Technology Americas at intive, on why AI-native means rethinking software engineering

As Head of Technology Americas at intive, Pablo Gamba sits at the intersection of two worlds: the day-to-day reality of shipping software for clients, and the broader view of someone who shapes the next generation of engineers. We sat down with him to talk about what AI-native actually means, where most companies are getting it wrong, and why now is exactly the right time to hire junior developers.

This interview has been edited for length and clarity.

Pablo, over the past year AI coding tools have become almost universal – but many companies are finding that their delivery timelines aren't really improving. Where does the disconnect come from?

You can't apply AI to a broken process. It's like giving a faster shovel to a worker – he'll work faster, but only in the wrong direction.

The disconnect usually sits between product and technology. Even with agile methodologies, each side has its own way of working. And often they are still running on yesterday's frameworks: same estimation approach, same team sizes, same processes. But with AI, all of that needs to change.  

Think about what's happening to the software engineer role. They're no longer just writing code – they're overseeing the output of agents, defining specs, preparing tests, validating outcomes. That’s merging what used to be three separate roles into one. If you change the roles but not the process and not how you measure, you'll just get faster to the next bottleneck.

So what should companies do differently?

Start with what you measure. Not development velocity – but the full cycle from intention to production.  

If you improve development speed but QA is your bottleneck, you've just reached QA faster. Then you fix QA and the bottleneck moves to requirements. The whole end-to-end process has to transform together. That's the number that actually matters: how long does it take to go from idea to production?

That's the case for AI-native transformation – but what does it actually look like in practice?

At intive, we start with a pilot. We come in, assess where the client is – their maturity in software engineering, whether and how they're using AI – and then define a clear plan with the KPIs we want to hit. From there, we conduct on-the-job training, apply the plan incrementally, sprint by sprint, until we've transformed the full end-to-end –  requirements, development, QA, release.  

Once we hit the KPIs, we set up governance so it can scale across the entire engineering organization. Then we step out. The goal is always: jump in, do the job, and hand it over.  

The biggest mindset shift is that AI is no longer a tool people use – it's becoming part of the workforce itself. Leaders are going to be managing teams where people, agents, and automated systems all work side by side.

AI-native is not a license. It means redesigning work because AI changes what's possible. Many organizations are trying to apply AI to old processes. That's not transformation. AI-native organizations start with a different question: if AI existed from day one, how would we design this process today?

Can you give a concrete example of what that looks like?

We have a client – a very well-known company,one of the largest candy producers in the world – that needed a recommendationengine for an internal tool. They came to us expecting it would take 9 monthsand a team of 7 or 8 people. We proposed 3 people and 3 months.

More than 50% reduction in time, more than 60%reduction in team size. They believed in us, we delivered, and we're nowexpanding our work with them.

That's not magic – it's applying the AI-nativeframework seriously. And it changes everything, including how you quote toclients. You have to be competitive at that level now.

Another area where we're seeing a lot of demand for AI is legacy modernization – particularly with banks. Is that a very different challenge?

It is, and it's becoming one of our biggest areas. Banks are sitting on software that's decades old – undocumented, written in legacy languages, with no SMEs left who actually know what it does. It works, but it's extremely expensive and risky to touch. So they're blocked on releasing new features.

We've had at least three success cases where we're using AI to modernize their architecture – decoupling core banking, migrating to microservices – and removing that complexity so product can actually ship again.  

Last question – and a broader one: as an Associate Professor in Software Engineering, you must have students asking whether it's even worth learning to code right now.

Constantly – and my answer is always yes. This is actually the moment when software engineers who went deep on the discipline will have a real advantage.  

Coding is just one part of software engineering. There's analysis, spec definition, solution design, architecture, coding, quality, validation – all of that still requires deep expertise and judgment. What AI is doing is making the coding part cheaper and faster. That raises the value of everything around it.

There's also a real risk nobody is talking about: if companies only hire seniors now, who builds the next generation? In five or six years, seniors will start stepping out – and there will be nobody ready to replace them. Juniors and seniors working side by side is how judgment gets transferred – and with AI, they can move fast, fail fast, and learn faster than ever before. That only happens when they are in the room when things go wrong.

Juniors today will be AI-native from day one. That's a real advantage.

Interested in how intive approaches AI-native software engineering transformation? Learn more ->

You want to know more? Get in touch!
You need to confirm Privacy Policy before submitting.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.