The Evolution of Application Developers with Globant’s Agustin Huerta

This is Textron tv. Hey guys, thanks for the throw. We're here with August wta, who, senior Vice President for Digital Innovation in North America for globin.

And we're talking about, well, the future of coding in the age of ai. August, welcome the show. Welcome.

Thank you. Mike. We have seen some comments recently from folks at AWS and other places that says that maybe in the future developers won't be coding at all and they'll be doing some other kind of work, and it's not quite clear what that work is gonna be.

I guess my first question to you is, how realistic is that assessment? I, I know we'll be coding less maybe, but will we not be coding at all? Well, truth is that there is no ground truth right now about the performance improvement that tools like Gen AI could bring into the table.

It's true that it has an impact and that it can accelerate things. We just don't know how much that would be. But Mike, I always like to think a bit more holistically about the process of developing software because it's not just about people coding, but it's also about people understanding what's the customer need, what are the expectations of the future users of that digital product.

Yes. And even thinking beyond what is already out there. You understand, and Gene AI is very good at knowing what we have been creating so far because we have fed them with a lot of that and we can ask for new permutation of that stuff, but they don't really know about things that are just happening as of now or that may be happening in the next couple of years, or maybe things that are just coming out of our, uh, human creativity in terms of, uh, connecting pieces and dots here and there.

So I believe that overall what we will see is a lot more into the creative stuff. If you look for example, into the development part, as of now, gen AI is not very proficient, for example, in code related to the Apple vision prop. Yes.

Because they just don't know it, because there is not too much open source code out there that you can train these models around. Yes, those pieces will still need developers and technology will keep on evolving. So it's hard for me to vision a, a future in which we are not coding any longer.

I believe that more people will be able to develop with less knowledge around it, um, in more task. But I think that we still have a lot in terms of the software development lifecycle itself moving forward and evolving and adding more creativity and being able to, uh, develop even bigger and richer experiences. Mm-Hmm.

And it seems to me, even if I didn't code or I coded a lot less, I need to understand how the thing works. And for me to understand whatever is being generated by the ai, I have to have some understanding of how code is written. Right?

Right. And also you need to have knowledge about, hey, okay, I have the code. Now what I do with the code is, uh, if you look into some of the, uh, demos that has been around for the evolution of, uh, clo, one of the most popular LMS out there, you have seen that a lot of people have started creating a small HDML versions of Doom or Mario Rose or other simple games that we know very well, and that's fine, but they are just shapes.

I remember seeing one that was a Mario Brola, uh, game that was actually a triangle jumping over here and there. And that may be fine for executing within your browser, but it's not a multiplayer experience, for example. Yes.

What does it take to have a game like that jumping into an online, jumping into what people is looking right now for games, you know, and, and then you have a huge gap still to cover in there. One of the common attributes of most developers is they're really problem solvers. At the end of the day, they like putting puzzles and pieces together.

Yeah. Um, so we will always need that to make software work all these different components and the stitching them together. I guess my question is, is will we still call them developers if they're focused more on the creative side, or will we create some other title or job function form?

I hope that we have better titles. I mean, developers even is like on oversimplification of what we do. It's problem solver.

I like that. Yes. That's a lot of what you do.

You solve problems. You turn something as abstract as the description of someone's intention about a digital product into making the actual real product be there and be able to, uh, leave up to the expectations of the potential users. And also through the development cycle, you end up solving a lot of problems because maybe what was defined was not properly defined or actually is not compatible with what can be achieved.

And you end up solving problems in terms of the definitions, in terms of the, even the challenges that you face when coding and not being able to make everything work as you were expecting. Uh, so maybe we'll call them problem solvers in the future. I would, I would both know that.

Mm-Hmm. There's some debate about what the future of the developer experience is gonna be. And there are some people who are saying that well, entry level developers will have more skills and they'll be able to build more applications, and we won't have to rely so much on senior software engineer types.

Conversely, there are others that are saying the software engineers will be able to automate a lot of these low level tasks themselves, and they won't need as many entry level people to help them out doing, you know, from what their perspective is scut work. And they'll be, um, more efficient. And as such, the bar will be risen in terms of what it takes to be a software developer.

So, um, on those two broad spectrums of things, how do you see this all playing out? You know, it's like a chicken egg. If you don't have entry level developers, you're not gonna have seniors.

So, uh, for me it's a no real argument in there. I mean, there is no way that can happen because if you just keep on rising the bar, you will need to rise everyone's on top because otherwise you will not get senior people. It's like, I don't know, couple developers, you end up having only a bunch of them right now still active because it's something that you end up or try to avoid using for the last 30 years.

So, uh, basically, uh, you need those entry level developers to have senior developers in the future. Yes. And of course, that entry level developer will be able to perform a lot more things that they are capable of doing right now or just being freshmen out of the university.

Um, and what I also imagine is that they will be able to have tools that will support their work, that will help them understand what they did wrong. That right now they only have to rely on the most senior developer out there in their teams, you know, and, and, and so the process of growing your career will also be, um, partnering with these tools and these tools helping you grow in there. We've also seen the rise of the so-called Citizen Developer over the years, and, uh, there are professional developers of course.

How will a relationship between those classes of developers evolve over time? Because theoretically, uh, citizen developers could do more, but, um, you know, they don't always understand how code needs to interact with each other. And, uh, historically at least we've seen issues with everything from, uh, the apps they build don't scale.

They tend to be less, and sometimes they're just downright ugly. But, um, other than that, they're great. We, we have had several types of citizens.

We have had safety sense developers, citizens, uh, business intelligence citizens are regarding RPA. And, and as you mentioned, yes, many times the things we are solving are useful, but they cannot scale. So it end ups into something that they can use as a tool only for their own, which I believe, uh, that we will start seeing is if those citizens developers find out there that it's easier for them to build tools that can solve their problem, you can then go and look into that and try to scale it faster.

Yes. And, and in the end you have like a crowdsourcing ecosystem of people thinking differently and proposing solutions that someone that really knows how to make those things a scale, how you can put and get those things into production can work over them, refine them, do the necessary adjustments, uh, correct any mistakes they may have done, uh, over the course of trying to get it working. And, and in the end, the overall organization will benefit from more people bringing ideas in there.

Yes. As thought I described before, a lot of the, or a very important part in the software development process is understanding which is the need. And the need is not something that only a few people that it has been touched by magic wand in a organization understand what you need to transform the organization.

Many different people could have ideas and having these cities and developers will help bring these ideas closer to fulfillment realization. Mm-Hmm. I mean, Will developers need to know a lot about the LLMs or will that just be something transparently invoked behind an API?

Because when I look at the LLMs, they now come in lots of different sizes and the sizes reflect capability and they also, um, reflect, uh, accuracy. But not everything needs to have, you know, the biggest baddest LLM either. So how do I figure out what LLM to use?

Right. Uh, I think that you don't need people that is an expert on understanding how one LM works or how to find TV need, endorse, those kind of things. But you really need to understand Avid, how they think we're calling it in some way.

I don't like anthropomorphic saying these things, but let's talk about thinking. Yes. So when you, we have human interactions when you are gonna be asking someone, uh, a favor, you if you know how that person thinks or how they behave, you try to use those things that will get the best outcome out from there.

Same thing happens with the LLMs. You need how you need to know a bit about how do I ask this question? Yes.

How do I make it more efficiently? How do I get to that? We solve sooner instead of having to waste a lot of time going back and forth with the other M until I am able to really reach the outcome that I was looking for.

Yes. All the techniques that are revolve around prompt engineering are very important. And for example, those are the things that we taught our people Atnt when we saw the rise of the LMS after te PT almost a bit more than 18 months back.

Yes. Uh, so everyone needs to understand that LM is behind the scenes, how they behave, how they think, which prompting techniques will allow me to get the, to the final outcome that I was, uh, expecting faster so that they get the best out of them without going back and forth and back and forth. Uh, which may end up losing the part of the efficiency that you are looking when they, uh, interact with them and, uh, ask them for support sobbing out certain issues.

Um, When you think about it, they say, and I don't know if it's true, and I'm curious to see whether you believe it or not, but some folks are predicting that we will write more software in the next few years than we have written the past decade. I mean, is that the level of, uh, exponential growth in software that we should expect? And if that's the case, how are we gonna manage it all?

I think that maybe that would be true, but also software will become, I believe, a lot more volatile. Yes. I mean, uh, we are typically used to software that sticks with us forever, like office.

Yes. Office has been there forever. If you ask people Yes.

Uh, they don't remember that there was a time before office. Yes. Um, or a time before Facebook.

Uh, but things will start happening to be more volatile because since it'll be easier to create a new experience, uh, that maybe even it will not make any sense to maintain what you have in there and just make the beast keep on growing and growing and growing, you will just discard something that no longer matches your consumer expectations and so on. And you will release a new, uh, piece of software. Yes.

And what we will see is software that involves more dramatically over the time, even if maybe the name is the same, the features, the way of interacting, the experiences that you will get from there will keep on mutating faster because we will have that capability of evolving them faster, getting rid of the past without anyone saying hello. But I spent X amount of dollars building that. Why I am gonna trash it right now.

Yes. You seem to be describing a world where we have no technical debt. Is that kind of where we're headed?

Technical That will be there always. Uh, uh, there, there is a very interesting concept. Uh, Michael Feathers worked, uh, with us for a very long time as a chief architect here at the organization.

And he said that as soon as you commit any piece of code that you have written into a code repository, it has become legacy. Mm-Hmm. And if it has become legacy, most probably it also has some technical depth because we are not perfect.

And even general AI is not perfect. So you will end up having that because you will make decisions, technical decisions that maybe will not stick in time. But the problem is right now, you have to deal with that big bag of technical depth and try to sort it out way, way of building new things.

And maybe you can say, Hey, you know what? This has accumulated too much technical debt. Let's just get rid of it and start from scratch without being afraid of doing so.

Yes. Because maybe we have some intelligence that can take the things at work and get out of the things that don't work or are no longer used or things like that are hard to perform right now. So in some ways, you're describing a future where the software is more disposable.

Um, it may take a little while for developers to get used to that idea 'cause they're kind of like, you know, this is my code and this is my thing. Yes, it's true. It's true.

My little baby all the care I have put into creating it. Mm-Hmm. Um, but you know, as we stand on the cusp of all this stuff, uh, we see lots of developers already using ai, but what's your best advice to them about how to be successful with ai?

I mean, what should they be thinking about or doing today that will stand them well tomorrow? Well, my first advice would be left your ego behind. Yes.

Which is something that is hard. I mean, um, and still people, it's a bit afraid of what this could imply. Um, but at the same time, the bigger challenge is it implies working in a different way to what we have been doing for the last at least 20, 24 years.

Yes. So the biggest challenge with that is all the people when they get into the university, or the most senior people even that has been learning on their daily jobs, have acquired, uh, certain ways of doing things. Say, I relied on these and these set of tools because they work better.

Uh, my thought process comes from, I don't know, I read the user story and I start thinking about the code lines that I need to start reading instead of thinking, Hey, how do I turn this into a useful prompt so that a gen AI can write that code for me and I can review it later on and even improve it if needed. What I get from there, that, uh, mindset switch for me is equivalent to when, uh, um, I will use, uh, analogy of when my days at the university, when I learn object oriented programming coming from, uh, functional programming. You need to do that switch.

Well, this is something similar. You need to start thinking in a different way. Yes.

And again, that implies in part leaving your ego behind, opening your mind to different ways, opening your, your mind to thinking, Hey, maybe all the lines of code that I will be committing today have not been created by me. I have not been jealous of in intelligence for many years. Why I will be of something that is even smarter.

Uh, I can focus into a lot more significant stuff. Yes, I will have more time to code review something that was developer, uh, developed by a junior developer. And that's adding value too.

If I'm a senior developer. Yes. And if I'm a junior developer, I will have a lot more gratitude out of submitting code that works first than, uh, learning through a bumpy road where you submit code and you don't know if it will work, if it will go through a code review or not.

Uh, and you have all the time that fear of, Hey, I'm good enough for doing this. Well, this still can help you. It can help you grow.

All right folks. You heard it here. Hey, the one way to think about it is let the machine have the first crack at it, and then you can see how you add value from there.

Because a lot of times those things that you're doing or think you're doing and running value, well, it might be just scut work that as the song says, you should just let it go. Hey, yeah, August, thanks for being on the show. Thank you, Mike.

You look great. And back to you guys in the studio.