#223 - The Software Engineer Identity Crisis in the AI-Driven Future - Annie Vella

[00:01:26] Introduction

Henry Suryawirawan: Hello, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I have with me a repeat guest, Annie Vella. So I think the previous episode that we did is episode 30, like four years ago. It’s been quite a long while. The reason I reach out to Annie is because I saw her quite active, uh, on social media, on LinkedIn. And also on her research, right, talking about AI assisted development or AI in general, right? Generative AI in software engineering. So today I hope we have a good discussion to talk about, you know, the hype about AI, maybe some fears that some people have. And try to maybe demystify and give us some better guidance. So, Annie, welcome to the show!

Annie Vella: Thank you, Henry. It’s so good to be back after, yeah, just over four years, I think. And boy has a bit changed in the world in that time, hasn’t it?

[00:02:32] AI Impact on Career and Software Engineering

Henry Suryawirawan: Yeah. So Annie, I think we know about AI usage these days, right? Everyone is talking about it over social media. There are new technologies even being invented recently, right? And the term vibe coding is kind of like very, very popular these days. So maybe tell us a little bit more, four years apart, right, what do you see have changed maybe in your day-to-day work with software engineering? Or what do you see other people doing in software engineering?

Annie Vella: Wow, four years in a time when things have changed as much. So personally, I’ve changed roles since the last time we spoke. So I think when we spoke last time, I was about to start a senior engineering manager role. And since then, I’ve actually moved into a…, on the Staff plus engineering career track. I’m a distinguished engineer. And so my own role has changed in that time. And so the things that I spend time doing have also changed. But more importantly, I would say, end of 2022 or November 2022, I think it was when ChatGPT was released, I think that caught the world by surprise. And what’s been so interesting is to see how quickly it’s been adopted. I was watching a video just yesterday, Sam Altman said that there’s 500 million active users using ChatGPT. That’s just a huge number, it’s hard to wrap your head around, right?

But then starting to see where it’s being applied. Not just ChatGPT, but the underlying technology LLMs, obviously, very, very useful in software engineering. And hence, as you said, you know, vibe coding, all of these sorts of terms are starting to come out. And I was lucky enough to be in a position where I could entertain the idea of going back to university to do the masters that I always told myself I would do. When I graduated over 20 years ago, I thought, oh, I’ll go back to university one day and do that further study. But I had to find the thing that was going to pull me in and, you know, encouraged me to spend my free time, uh, thinking about it.

So, yeah, early 2024, I decided to do a Master’s of Engineering focusing on the impact of AI on software engineering. Because, I mean, it just feels like the most natural topic for me to focus on. I love software engineering so much. I’ve done it since I was such a young, I think we covered this probably when we spoke last time, but you know, since the age of six, I have been fascinated at what you can accomplish by instructing a computer to do something. But there’s always been limitations, right? It can’t think for itself. You have to be so specific in your instructions. But this technology starts to allow us to be a little more fuzzy with our instructions, that non-determinism that we didn’t really have before or was very hard to achieve. And so, yeah, how does that impact the way that we write software, the type of software that we build, but also how we build software? And that’s what I focused my part-time masters on.

So I’m about halfway through and that’s why you will have seen that I’m, one of the reasons I’m so active on social media now about this is ‘cause I find it fascinating. I think a lot of people do. But particularly, the impact on software engineering and the software engineer themselves. You know, what does it mean to be a software engineer today? I think it’s a very different landscape to what it was even two years ago or four years ago when we spoke. The sorts of skills that you need to build up, you know, that’s all changing, so, okay. I wish I had a crystal ball, but as I do not, the best I can do is try and research what’s happening today so that we might project and predict what happens tomorrow and so we can prepare ourselves for a brave new world.

Henry Suryawirawan: Yeah, so I think it’s really interesting the, you know, you just saw a video, you know, the active users using ChatGPT, right? I guess these days, it’s not just ChatGPT. There are even more, right? You have like Perplexity, Gemini, you know, Claude and I dunno God what, you know, like other, uh, AI software. So I think also interestingly, just a few days ago as well, there was an announcement by Shopify CEO, right? Tobi Lütke saying that everyone now is expected to use AI, the term reflexive AI. I’m not sure what that means. But, uh, basically saying that, uh, you can’t even hire other people unless you can justify how AI couldn’t actually help you with that extra resource, right? So I think that’s a very, very new thing, uh, in my opinion, right? So asking people to try to use AI as much as possible.

[00:07:00] The Future of AI-Driven Software Engineering

Henry Suryawirawan: So I think in your paper, you mentioned about this future of AI-driven software engineering, right? I think let’s just focus on this topic for today. What do you see changing? You know, software development is still kind of like, you know, a large kind of a work body, right? So like there’s so many activities, people try to use it so much, you know, building applications, building programs and things like that. But what do you see actually changing in terms of software engineering in general?

Annie Vella: Yeah, so that paper was an attempt to look into the future and see what of all of the different types of activities that are involved in the software development lifecycle, which of those would be impacted and in what ways. My own research for my masters is focusing more on, like the things that software engineers do themselves today. And this is something that I’ve been reflecting on so much as a part of all of this.

You know, when I went to university over 20 years ago, I was taught the full software development lifecycle. You know, of course, we learned how to code, but we also learned how to analyze the requirements, you know, and, um, discuss with the customer what the problem they were trying to solve and encourage them to not give us the solution, but instead just really focus on the problem and let us, as the team who were going to solve all the problems, come up with the right solutions for them, you know, right through to modeling use cases, UML. You know, back then when we used to do a lot more of that kind of stuff up front. And the design of the software and then the build and thinking through all the test scenarios. And then obviously, the deployment and the maintenance of it.

And what I’ve noticed throughout the years is that probably due to the fact that there’s such a massive demand for software engineers, but not enough supply, we have created specializations, you know, and tried to kind of reduce or narrow down what a software engineer should focus on to the things that we perceive only they can do with the skills that they have, and that is the writing of the code. What I find really fascinating about this shift is if you, you read what people like the CEO of GitHub have to say, you know, they, they proudly announce that now with these tools, software engineers will be able to do a lot more of that higher level thinking, critical thinking, you know, all the other tasks that were always meant to be a part of software engineering. But the truth of the matter is that many software engineers have specialized on the coding aspect of it.

I used to work, many years ago when I was in the Netherlands, I worked with a team who were based in the UK and I remember one of their engineers there was just really, really smart, but focused all of his energy and his skill building and becoming like the best React developer. He knew React inside out. That was his area of interest and his domain, you know? And we had frequent discussions, because I was trying to encourage him to think more about the product that he was building as well. Like what is the problem you’re trying to solve with this technology that you’ve become very good at? And he just didn’t have much interest in understanding the domain we were working in, you know. He felt his area of expertise should be the technology and others could think about the product.

Well, I fear for people who have gone down that path because I think that the tools that we have today and, and, of course, it’s only going to get better, they’re very good at writing the code. They can generate code way faster than any of us can hope to ever type. So that shifts things, right? But where does it shift it to? So one of the main questions that I’m asking as part of my research is, how does the introduction of AI coding assistants shift the perceived focus across various development tasks, such as like designing and writing, refactoring, testing, debugging, reviewing, you know. Like I have a hypothesis that developers may spend less time writing code and perhaps more time reviewing.

Well, so far the data is showing that yes, developers feel that they will spend or that they already are spending less time writing code, less time refactoring code as well, and less time testing because they can generate tests. That all makes sense. But what we’re not seeing is really like an equal and opposite increase in the reviewing, the time spent reviewing. There is a slight increase there, but not equivalent, right? So one might ask themselves, well, where is that extra time going then? Because, you know, we’re saving all this time. Or are we just writing more code faster? And what does that mean into the future, right? What are the second order or lagging indicators that we should start looking for?

Well, thankfully, we don’t need to look too far because DORA and the, um, GitClear Report. I came across that one a couple of weeks ago and, you know, they’re analyzing the impacts of this technological shift. And we are already seeing some of those second order or lagging indicators. And it’s not really a great picture, to be honest, Henry. It’s like, I think we are trading off that short term speed increase and what we perceive to be productivity gains, which they are, but at what cost, you know? And I think that’s going to become quite interesting. So software developers right now are generating code faster. They’re also feeling like some of the code that gets generated isn’t great. You know, sometimes it hallucinates for all the tools that are available. Some are better than others, but you still need to be vigilant and manually adjust and carefully verify that the code that it’s generated is doing what you hope it is, which is where vibe coding comes in, and tells you actually, maybe you don’t need to worry too much about that. So that’s another topic.

And another thing that’s quite interesting that I’m seeing in my research is software engineers are trading the more traditional sort of search tools for AI coding assistants. So previously, you would’ve gone to Stack Overflow, you would’ve gone to Google, maybe even opened up the documentation for a particular library or framework that you’re working with. That actually seems to be shifting as well. So we can already see a decline in the use of Stack Overflow. You know, it had its day and it seems like now it’s just easier to stay in the IDE. Why would you pop out of it into a browser if you can just ask the AI coding assistant to help you with that?

So are we moving towards being more like orchestrators of AI coding assistants? Like just being able to describe what it is that you want or getting really good at prompting? Is prompt engineering becoming a new core competency and does it potentially replace the ability to recall all of the syntax that we used to have to learn? So these are the big questions I’m asking and I’m, yeah, still super fascinated about. It’s an evolving picture, absolutely.

Henry Suryawirawan: Yeah, so as you were mentioning all those, I kind of like reflect back to what my recent experience as well. So I could definitely relate with some of these things, these are changing, especially for me, right? So uniquely enough, right? I was also into management now back kind of like semi management, semi hands-on. So I think I could see the so called the dichotomy, you know, being a hands-on developer and also as a manager, right? So trying to think of how we can use AI more effectively and being more productive, and also not forgetting about the second level or maybe third level order of thinking, right?

[00:14:29] The Shift in the Role of Software Engineer

Henry Suryawirawan: So I think one aspect that you mentioned very interesting is about the role of software engineering. You know, traditionally we were trained with so many different things, like requirements and things like that. But over the time, as maybe like what you mentioned, like so many software developers specializing into different roles, some even specializing in different technologies. Maybe it’s React, maybe it’s a cloud thing, maybe it’s a DevOps, SRE, whatever that is, right? And now it seems like these kind of specialization is blurring a little bit, I would say. So for example, if I’m not a, if I’m not a good frontend engineer, but I do understand a little bit about frontend technology, right? I could now come up with some kind of maybe decent, good looking UI, and also complimenting myself with other skills like backend engineer or maybe cloud. I can build much better application with more coverage in terms of, you know, technology thing, right?

So do you think these days, software engineers have to think of becoming a generalist more and more? Especially now that AI can help actually to maybe provide shortcuts, you know, finding the answers quickly, but also upskilling themselves in those skills. So what do you think about this?

Annie Vella: Yes, I very much agree with that. And you know, I think as time goes on, different phases will come and go. You know, maybe we had to go through a phase where there were so many new technologies coming up. I lost count of the number of frontend frameworks that, you know, went through their hype phase. You know, I think I stopped playing around with, and I say playing because I was never officially a frontend developer, but as a sort of full stack developer. I did have to work in frontend. I was never very good at it. But I think the last time I did anything decent in frontend was Angular days. And you imagine how far, like, how long ago that feels now. But yeah, we, we’ve gone through a phase where we’ve introduced so many new frameworks and technologies, cloud and mobile itself, you know, and people chose to specialize because there was demand for it. But now, as you say, like these tools do in many ways democratize the access to becoming a developer, somebody who can contribute to development.

In fact, I read something by Andrej Karpathy, I hope I’m saying his name right. Apparently, twitter has articles on it. Now, I didn’t, and it’s not called Twitter text. But he wrote an X article on the diffusion of this technology, which previously like big technological changes like this might have started in government or big companies first and then trickled down to the average individual at home, you know. But this technology seems to have been released out to the general public first. And although I’m sure that there are, you know, more advanced models that bigger companies are using internally and maybe even the government, the perception is that it’s out in the public much earlier than it would normally have been with other technologies. And that means that, you know, the general public, you and I and everybody else, can use these technologies to sort of supercharge themselves.

So, as you say, like I too have found myself like I’ve had to write a bunch of R scripts to analyze the data that I’ve collected as part of my research. And I’m not an R developer. But with the help of, I’m using Windsurf connecting to Claude Sonnet 3.5, it’s a huge help and it just shortcuts the amount of time I would’ve had to have spent. And now I feel like I could probably write something in any language with just a little bit of help.

What I love about that, Henry, is, you know, last time we spoke, I was right in the middle of trying to be the best engineering manager and technical leader that I could be. I really focused so much of my energy on how do I give other engineers enough confidence to try things and fail sometimes but safely, you know. Because you learn through your failures and your mistakes. Probably, better lessons than you’ll ever learn any other way. How do you create an environment in which people lean into that and then are able to discover for themselves some new path, some new way of, some creative way of solving a problem, and be able to feel really proud about that. And I think like we spend so much time working, so much of our lives is spent at work that if you can take joy in your work and be proud of the work that you do, it makes the time fly by. And that’s, I think, part of my passion for software engineering is I’ve never really seen it as work. It’s always been an enjoyable thing for me.

So I wonder if these tools can help give perhaps the more introverted, quieter members of our teams like a quiet assistant just sitting there privately on their computer. You know, now, those who might previously have not had the courage to put their hand up and admit to the rest of their team that they don’t know how to do something, that they need a bit of help. Cause, you know, it can be hard to admit that. You know, not everybody has the courage to do that. And some, you know, over time might find that courage, but some might never. But this tool, if you can just chat with it about some idea that you have before you get to the point of, okay, I think I really need to ask for help. You might be able to solve a lot more of your own insecurities about trying some technical solution for something. And I love the idea of that. I think that can really help allow developers, uh, yeah, more freedom in that sense.

And to that end, as you said, like now, if previously you thought of yourself as not a very good frontend developer, so you’re probably never gonna put your hand up to do that piece of work or for that job, well now you might actually really consider actually going for that. And that’s gotta be a good thing, you know? But beneath it, it still needs to be backed by a deeper understanding of what it is that you’re doing, because you do need to think about how long is this going to last. If it’s just a prototype, then go for it. You know, if it’s just gonna be thrown away and just proving something, these tools are amazing, and I see that shine through in some of the open-ended answers that I got in my research. But if it’s a production code that needs to be maintained over time, you do still need to probably be a little careful about the complexity of the code, the duplication that you’re, that you might be stumbling into. But that’s maybe where we see introduction of new tools will, you know, layering of agents that can help you identify those mistakes as well.

Gosh! Pandora’s Box has been opened and, you know, who knows where this evolution will take us. But it’s very interesting.

Henry Suryawirawan: Yeah, I, myself, I’m afraid I couldn’t keep up with so many different changes, new technologies, new inventions, new tools, you know, being popped up. Sometimes it’s not just one aspect of software engineering. It could be other things like testing, you know, generating UI, generating app, you know, things like Bolt, Lovable and all that, right? So I think definitely, this is something that everyone at least needs to follow a little bit, I guess. Otherwise, you will be falling behind like by a lot, right, especially from people who leverage these tools every day.

I think you make a great points about, you know, people who are maybe a little bit more introverted or shy or maybe some imposter syndrome as well, right? They are scared, you know, asking questions with others. So now I think everyone has some kind of assistant, although you still need to fact check, you still need to try to understand why it suggests certain things that way, right? So I think at least now we have some partners that we can just ask, you know, the partners that never get tired. And always seem to be resourceful, always trying to help us the best they can.

[00:22:13] When Writing Code is Not the Bottleneck Anymore

Henry Suryawirawan: Yet, you mentioned the time spent for engineers now has becoming less about writing code, because, you know, writing code is not the bottleneck anymore. Everyone seems to be able to churn out, maybe features fast, right? But all other aspects of software development maybe gets impacted, right, so to speak, right? So now if let’s say you can write a lot more features, that means who will come up with the requirements? And then the other end as well, who will do the review and testing and all that?

So do you see some kind of problems that could happen? Because like what you mentioned, the DORA research saying like there’s an increased productivity. There is, right? Definitely. But the impact of software delivery performance is actually going down and maybe the GitClear report that you mentioned as well, mentioning that there are a lot of churns in terms of code that are being produced from. Meaning that you write this code today and you keep changing them over time, right? And the churn is pretty high. So what do you see the impact in that? Now if let’s say code writing is not the bottleneck anymore, what would other aspects that we need to be concerned about?

Annie Vella: That’s a really interesting question. And honestly, I think that’s, um, if I could work that out, my research would be complete. I think you are right to mention like software development lifecycle is a system, right? Over the years we have identified different phases. Things work from sort of left to right and then we decided maybe we should have iterations in there because of waterfall didn’t work out super well for everyone. And if we’ve just taken a technology that can speed up one of those phases by a lot, well, where’s the next bottleneck? Like now you don’t have enough requirements coming in or there’s not enough UX work happening up front? And so the developers are sort of waiting around for where’s my next piece of work coming from ‘cause I’ve done my bit now, yeah. It’s like every team’s dream, I suppose. You know, like, oh, wow, our developers have nothing to do. It’s been a long time since I’ve heard anyone say that.

And on the other end of the scale, so, you know, we are churning out code much faster. Who’s reviewing it all? ‘Cause if you’ve played around with these tools from a code generation perspective, you will be aware of how much faster it can generate large pull requests. And I think the DORA report talks about that, right? As they are wandering, they hypothesize whether some of that delivery stability decrease that they’ve started to see might be, in part at least, related to much larger PRs that are being generated. And I’ve felt that myself, to be honest. It’s um…,

Actually, I saw the other day, Patrick Debois, the godfather or grandfather of DevOps, you know, fabulous man. He commented on LinkedIn that, I think he said it was Windsurf or Cursor have introduced this new feature where it makes a sound when it’s completed doing the task that you’ve given to it. And I thought, oh, here we go. It’s an important feature because we are already getting used to asking it to do so much more for us that it can actually take a bit of time. And I’ve found myself also sort of waiting there patiently watching and thinking, hurry up already. Why are you taking so long? Maybe I need to spin up another instance of Windsurf to get it to do more in parallel, it’s taking too long. So then you get distracted and you go and do something else. You start reading email or answering a message. And so you don’t know when to come back unless it makes a little sound.

But that just goes to show that we are moving into this phase now where it’s just generating so much code. Are you really going to go and have a look at all of the code it’s generated? Like we say we should, we say it’s important, but it will just over time vigilance, we are gonna, you know, vigilance decrement is a problem. Because, well, honestly, there’s vigilance fatigue. You know that when you are writing it, you’re going at the pace of like, you are thinking about it, you’re writing the code, you’re looking at what you’ve written. You’re maybe writing a unit test and testing that what you’ve written works the way it should. And there’s a sort of a natural pace to it. But now if it can generate so much more code so much quicker, when do you go and check or you know what it’s done? And how does the person who now needs to review your code deal with a much, much larger PR?

So I think there will probably be some new tooling that comes out that helps us with that. You know, that helps identify what, maybe, what the areas to focus our review on might be. And I think this is possibly part of the brave new world that we are stepping into. We don’t yet know what tooling, what extra phases within the software development lifecycle may need to be introduced or augmented, you know, to deal with the removal of a bottleneck that has existed for, I wanna say about 50 years, you know. 50 odd years that the software industry has been trying to find ways to reduce the time it takes to build software by, you know, little things like the libraries and frameworks that we use today that abstract away as much of the heavy lifting or the thinking that we previously would’ve had to have done. Like we can’t even think about what it must have been like to do all of this on punch cards, you know, or, or even writing assembly code directly, how much slower that must have been, right?

So we take for granted what we have today. And even today, we feel like, oh, it could be faster, it could be faster. So we have a need for speed, right? Like this speed is exciting, it’s fun. But then we need to, you know, move on to the next. Okay. So if that’s true now, then what’s the next thing to think about? So I reckon developers will end up spending more time thinking about how you verify that the work that you’ve, the code that’s been written does what it’s supposed to do. And I’m not talking about unit tests or even test automation. They’re a part of it.

But we’re starting to see, I only learned last week this concept of product managers building what they call evals. So apparently, in 2025, evals are the new thing that product managers are starting to think about, to evaluate whether the product that they’re building that has AI embedded in it does what it’s supposed to do, safely and all of that. And it’s not quite the same as the test automation that we’ve, as coders, we’ve traditionally built and relied on it. It’s broader than that. And that’s super interesting. Like already, like that didn’t exist two years ago, you know. So I think new things like that will come up and we’ll have to find innovative ways to automate that and stitch it into our pipelines, and anything and everything around that.

Even just figuring out when to trust an AI coding assistant. That, in itself, probably requires a huge amount of research. How do you know? Trust is a big topic, you know, and it’s not one that we typically talk about in software engineering, I would say. But sure it might come up, but almost like as a side effect of something else. But trust is kind of a very heavy psychological thing, you know. You have the person, the trustor and the trustee, I guess. So you have to try and work out, you know, when I say I trust a tool, what’s my belief in its ability, you know. And versus the other side of the equation.

So, so maybe we can find ways to systematize that trust so that it results in a better calibrated trust so that we don’t end up almost washing ethics, you know. Like ethic washing where we think we trust it, it’s trustworthy, but are we just overlooking something deeper? There will be a whole bunch of new jobs that arise out of all of this, like specialties, I suppose. But for now, I think generalizing your knowledge is to, to get through this near term phase. I would say that becoming, moving back towards being a bit more of a generalist. Certainly, less specializing on the libraries or the syntax. ‘Cause the bots can do that rather well is a good idea. And in future we might find, yeah, new specialist roles that crop up. The world’s our oyster. I think we are creating these paths. So I think that’s an important aspect to consider.

Henry Suryawirawan: Yeah, so I think the need for speed is in everyone’s mind these days, right? So they think, with AI, we can be more productive, we can work on more, we can deliver faster. And I think the temptation is there. So when I say like, I’m becoming much more hands-on, right? I become a developer, right? So supercharged with this ability, we would like to think that we want to be faster as well. Like, you know, churning out a code. Sometimes even if the requirements is a little bit vague, we can speed up just by taking our assumptions and deliver things, at least, get something done, right? So I think the temptation is there.

And you mentioned about vigilance, right? So every time when you write a code and you ask AI, you know, so many times, right? I would assume that everyone has, will start to build some kind of trust, simply because, you know, it becomes like a close friend of yours, right? And I remember back then when we google as well, right, anything that is top rank we’ll just assume that it’s true, right? It’s more accurate. So I think these days, especially people will just easily trust AI. Uh, and especially with coding, it becomes much more… the feedback loop is very short, right? When you ask question, it gives back, and then you continue and build features on top of that. So I think you remind us a very good point about, you know, vigilance and trust, right? So try not to assume everything that AI gives us is actually true.

[00:32:04] The Danger of Over-Reliance on AI

Henry Suryawirawan: Which comes to the next discussion that I wanna bring up is about over reliance on AI. I can actually feel it myself as well. So every time I need to do something, be it big or small, I would need to ask AI, you know, as like a giving me a fresh pair of perspectives or maybe even criticize, summarize, and all those things. So what do you think is the danger of this over reliance on AI?

Annie Vella: Oh, that’s a great question. It’s one of the things I think about a lot because, like you, I also feel it in myself. Like it, it’s too appealing, you know, you’ve got this tool that is never tired. It’s always available as long as you, you know, pay for it or the free one or, um, and don’t exhaust your daily limits. But it’s just so helpful to have this sort of second pair of eyes there that’s there as your helper. But I’m a firm believer that we learn through experience, hands-on experience. You know, you can read and watch all the YouTube videos about something that you can find, but at the end of the day, if you don’t have a variety of experiences.

And I think we spoke about this four years ago, I think I talked about the Dreyfus model and how you go through from novice to expert over 10 years apparently of skills acquisition. And that skills acquisition is built through experience, through 10 years of experiencing a variety of different angles of the same skill, right? You can’t just practice the same, the same song on a guitar and become, you know, the best guitar player in the world. So from that perspective, if you are outsourcing or delegating a lot of what you do to this bot, then you, yourself, are not experiencing it. You’re not experiencing the friction, the frustration, the pain, the resolution that you come up with through your own critical thinking. You’re kind of offloading that to something else.

And what does that mean for our ability to gain those skills now? I’m really not sure, because research will tell you that deliberate practice is indeed the best way to learn something. Yeah, simply reviewing something else is you’ll get a feel for it, but you’re not gonna have that confidence to go and do it yourself. So I am quite sure that if we keep going down the path that we’re going, which I can’t see us not, and we all become super reliant on this, these new tools, that over time we’ll all become quite rusty at the thing that we used to do by hand and we’ll become very dependent on these tools. And to some degree, it’s a bit like the calculator. You know, like how many of us, even to sum up a pretty simple, you know, addition or subtraction, we pull out the calculator, just in case, you know? Or GPS, right?

It’s quite funny. But my husband is not good with directions and fully relies on GPS. Without GPS, he’s just not confident about getting where he needs to go. There’s plenty of other skills, but directions and following them, you know, it has to be the GPS. And that’s something that previously he would’ve figured out himself, you know, and he would’ve learned the way to a place and then never forgotten it. But now he never needs to learn it. Because a GPS will take him there every time until his phone runs outta battery and then he just can’t get there. It’s okay. I’m not going there today because I can’t. You solve the right, in that case, he would solve the problem of putting, giving your battery a bit more juice so that you can then use GPS to then get to the place that you’re going to, right?

So I wonder if at some point we’re all gonna become so dependent on these tools, not just for coding, but for a lot of aspects of our lives that we’re gonna have this like virtual assistant in our back pocket that is just always on and ready to help us. And I do wonder if we might head to a place where we each have our own AI that knows us intimately, you know, and that we can kind of bring to work, almost, you know. So we’re already seeing it to some degree with the GitHub Copilot. Like it allows you to connect to a number of different models. But what if it could also connect to a model that is yours, is your personal one that knows the way that you think, your interests, you know, the way that you tend to think about things and is more tuned to you. I suspect OpenAI and Sam Altman, they’re going in that direction from what I heard in the video that I watched yesterday. Like he really sees a world in which everyone has their own personalized ChatGPT.

In terms of raw skills, maybe the skill that we’ll learn really, and actually, that’s a good point because there’s uh… The World Economic Forum produced a report on the future of jobs. And in that, it’s like a 290 page PDF. So without getting an AI to summarize it for me, I dunno that I’ll ever actually sit down and read the whole thing end to end. I don’t have enough time. But there’s some really nice visualizations. And one, in particular, they show the skills that are becoming more important, that are already important, and they project will become more important, are things like resilience, agility, flexibility, you know. Basically, embracing change.

These are not skills that we really learn as a subject at school or at university. You know, they’re kind of just life skills that you build up as you mature. So how, how do we teach people these things earlier on in their lives? How do we kind of leapfrog experience and all of that that life gives you naturally and sort of try and instill that type of thinking in the next generation? There’s some really big problems to solve, you know, to fully understand how we can leverage these tools without giving away everything that, you know, as humans, we’ve been used to doing ourselves, which is what makes us all very exciting and scary at the same time.

Henry Suryawirawan: Yeah. So I think, yeah, OpenAI is releasing this thing called Memories probably, right, in, maybe, in your ChatGPT. And also the trend seems to be like the larger and the larger context that AI model is able to use, right? Yeah. I think maybe one day, like what you said, we can have a personal clone of us maybe that can think or feel just like us. Feel is probably a bit too far. But I guess the thinking, you know, the kind of rationale, the kind of styles that we use in terms of our output, right? Be it writing code is something that AI can learn as well. So definitely is something maybe exciting, but also scary at the same time.

[00:38:51] The Software Engineering Identity Crisis

Henry Suryawirawan: And you mentioned that we human would love to learn by doing, you know, like the experiential aspect, right? And I think also software engineering is like a craftsmanship thing, right? You cannot just, you know, learn software by reading book, type “hello world,” and you know, you become a software engineer. So there are so many different aspects like design, you know, maybe non-functional requirements, maybe be it the deployment, network, things like that. So in your blogs actually, you mentioned about this trend of software engineering or software engineer now has this kind of identity crisis these days, right? Like what you mentioned, right? So many things now is available to us. Maybe our roles have become much more, I would say changing a lot, like demanding at the same time. Everyone is scared of their job because the news always say, okay, we can reduce the number of software engineers, junior engineers will not be needed anymore. So tell us about this identity crisis. I’m sure everyone is feeling it, I’m feeling it myself as well. What is your take about this identity crisis?

Annie Vella: Oh, it’s funny you should mention that particular blog post. It’s the the last one that I published and it’s by far the most popular blog post I have ever, ever written, or even could have conceivably imagined writing. Just so, you know, to be completely transparent, I’ve had a blog in the past which went nowhere. I was just yelling into the wind, nobody cared. And I started off a blog again a couple of years ago, maybe a year and a half ago, figured, oh, well, at least, it’ll get me writing. You know, I have a lot of thoughts about things, and I’ve, aside from filling my poor husband’s ears with all of my thoughts, I thought maybe I can just pour it into my writing and I put it out. But for the most part, my blog doesn’t get all that much traffic. But this particular blog post I’ve had, I think at the last count, 43,000 views of it in less than a month. And I, yeah, I couldn’t have imagined such a response. And also of people reaching out to me about it as well, they wanting to either thank me for writing it because it resonated for them or, you know, sharing it with their own, their own networks, because it meant something to them and other people are commenting on it. So it’s clearly hit a nerve, which is quite interesting.

But what does that mean? See, I wrote that from, it was a very heartfelt blog post from my perspective. ’ Cause like I said, I started coding when, well started coding. I started playing with code when I was six years old. And it was basic at the time, right? But the feeling that I got when I saw my work turned into something on the computer was probably, you know, it was certainly, at that age, the best feeling I’d ever had. You know, the, to see this, it was a smiling bounce, a smiley face that bounced around the screen, a sprite. And it was just one of the examples in the basic manual that came with the Commodore 64. And ever since then, you know, I’ve really held onto that, the craft itself, the knowledge that you’ve written some words that have turned into this cool thing. It’s like, it’s more than just solving a puzzle, right? There’s a beauty behind it.

And I think a lot of software engineers feel that way about their code. And there’s a reason that things like LeetCode websites exist because we like to solve existing problems in new and imaginative ways using a slightly different technique that is that much faster, more efficient or more memory efficient or, you know. And we like to, you know, some of us might even, we certainly feel some a level of pride. We might boast about our, you know, being top of the leaderboard on LeetCode. I wish. Like I, I’ve never been good enough to make it anywhere near that. But, you know, a lot of software engineers tie their, at least their professional identity, into their work and into the quality of the code that they’re producing. And so if that is now kind of not the point, you know, like, because these tools can generate the code for you. So really the point becomes more about solving the customer’s problem.

But as we spoke about earlier, over the last 10, 15 years, you know, we’ve even had to introduce new titles like product engineer to refer to a software engineer who actually cares about the whole problem that’s being solved, the product that’s being built, and the customer at the end of the value chain that, you know, actually makes use of the solution that you’re building. Because somehow we’ve lost that sight of perhaps why we were building that code. ‘Cause it, just the act of building, the coding, and using different libraries and frameworks in new and interesting ways became, you know, so interesting for so many people.

So, in that regard, how do we take that passion and apply it a little bit more broadly? Some people might still be able to spend their energy and their passion building things at the code level. But maybe even the type of things they build might change, you know? So maybe in, if that’s the area that really brings you the most joy, then maybe start looking at things like agent development kit. And these new frameworks that are coming up that allow you to build solutions that have AI embedded in them. You know, so there’s, we’re still forging new paths around that. Like MCP, great! But, you know, already we’re finding some new vulnerabilities that might creep in. So, you know, get good at building the tools that protect us from things like that. There’s going to have to be some sort of AI version of SRE, you know, so when you have AI embedded in your systems, then how do you do observability and monitoring and resilience and all of that. So, you know, there will be things that are maybe closer to the what we would consider coding today in future for these new solutions we might build.

But for anybody who was already at a point in their career where they were thinking, maybe it’s time to consider a management role, because, you know, I don’t find coding the hard part anymore. You know, maybe there, start thinking about how best to leverage these tools, how to manage that calibrated trust and automate some of that eval verification. How do you layer the kind of a distributed cognitive support where you end up with layers of AI agents that check each other’s homework, you know? And I think we see that already in some tools. And that’s likely.

And Sam Altman said this in his talk that I listened to yesterday as well. Like he’s… We can see that the current version of LLMs have already revolutionized software engineering in particular and starting to revolutionize many other things. But software engineering for sure. The next thing he’s very interested in is Agentic AI. And I completely agree. You know, so LLMs are kind of like one component. That’s fine. And we are all using them in our own different ways. But the power will come when you create a system that is made up of many components, some of which might be LLMs, and then potentially controlled by an orchestrator that is an LLM itself. And that’s where you get that kind of extreme non-determinism, because you just give the system a task and it figures out for itself which agent it’s gonna call, which tool it’s gonna use. It may just not go down the path you expected at all. So those will be very interesting systems to create, to test, to maintain, to reason about, you know. So there will be work in that area.

But, so that’s, you know, becoming slightly more generalist, becomes really good at using these tools, building these tools, and also managing these tools, wrangling these tools. Like how do you fix the system when it stops working? How do you improve it? These will become some new interesting jobs in the future. What do we do about our junior engineers, like the me of, you know, 20, 30 years ago, who wanted to be a software engineer? That’s a tough one. It’s gonna be hard, I think, for some, to break into the industry, harder than it was, say three years ago.

Henry Suryawirawan: Yeah, so I think, uh, everyone is feeling this kind of identity crisis in their role, right? Funny enough, probably it hits a lot of nerves, simply because we are feeling it. Especially for people who are using it. But for those people who are not using it, maybe they don’t know yet. But I think it’s very, very concerning if they don’t start picking up, you know, at least understanding what this tool is capable of, right? And I think you mentioned about, you know, juniors. I think, the other day I went into like a meetup, you know, small meetup within, you know, my area. Some managers, some leaders even saying that, oh, I’ve tried vibe coding on certain aspect and it seemed to be doing its job and it’s cheap. You just spend a few, you know, maybe a hundred of bucks a month just to use these tools. And compared to hiring a junior, maybe a fresh grad who just graduated, the economics seems like very, very, you know, lopsided, right? So it seems like leaders probably will start to think more, okay, how can we leverage AI more just like what I mentioned about Shopify experience, right?

[00:48:09] Advice for Junior Engineers in This Challenging Time

Henry Suryawirawan: So I think for juniors out there, maybe looking back at you, you know, maybe 30 years back, what would you say to them? Is software engineering still a good career for them? Because just to break through and get a first job probably is a little bit tough. And especially now in the very difficult situations globally, you know, with all this happening in the US and some parts of the world. So is there anything that you would want to say maybe to the younger, junior engineers of us?

Annie Vella: I reckon if it’s a path that you, you know, I would encourage anyone to follow their dreams. Life is there to be lived. Don’t choose a career that you don’t think you’re going to enjoy because you’re gonna spend a lot of your life doing it. So make sure that whatever it is that you pick, you know that it’s something that you enjoy doing. And if software engineering is the path that you had your mind set on, and by all means, follow your heart. But understand that, say, talking to somebody who, um, is five years into their career, like you won’t be able to follow in their same footsteps. I think it’s just going to be different.

So I would encourage them to simultaneously try and educate themselves on all of the fundamentals. You know, I’m pretty sure that universities are still teaching all of that. The basics around SOLID principles and, yeah, like naming conventions and algorithms and sorting algorithms and all of that. Um, familiarize yourself with that. But then get really good at using these tools to generate code that reflects that foundational learning. Because I think if you showed up to a job interview and you said, sure, I’m a junior. I, you know, I haven’t had much experience or really any at writing code, but I am a master at using all of these other tools, Cursor and Lovable, and this tool’s good for that. And then I port it over here and then I open it here. And then I, you know, I look at it through this and I know it’s important to verify because these are the sorts of mistakes it tends to make and, you know, with all of that knowledge, probably find yourself being quite in demand, actually. And, you know, maybe they’re in a perfect position to really adopt these new technologies at a time that they’re coming in.

You know, those further on in their career, I have a feeling that in my research what I’m seeing is people who are well into their career, they might not have been writing that much code anymore anyway. So to them, it’s kind of like, ah, yeah, it’s nice, but, you know, I might just use it to play around with a bit. So they almost feel like it’s not that big a deal. But the people kind of partway through their career, like mid-career, I think they’re struggling with it, right? Because they’re sort of, okay, so do I now need to become really good at using this thing, like what I’ve known to be true over the last 10 years is now changing? That’s probably harder than somebody who’s entering the market at this point where, you know, where the tools are already, they’ve landed, they’re here to stay. They’re only going to get better. And the types of systems we are building are changing. How we build them are changing. So it’s unsettling.

But they, you know, juniors probably have a unique opportunity to help create the roles that they want. But they’re probably gonna need to have a lot of imagination. You know, I think, at the moment, if you can imagine it, you can create it. So imagination becomes a really important skill that, again, they probably don’t teach it at school all that much. I don’t know, I never felt like I had much imagination. But these tools help you be a little bit more, you know, imaginative if you’re struggling in that domain. But yeah, imagination, creativity, you know, the confidence to try it, use the tool to help you have the confidence to, you know, it’s very circular in a way like that.

So I wouldn’t say all hope is lost for junior engineers. Just that the type of work they’re going to be doing will be different. So they probably won’t have as much guidance as perhaps the last 10, 15 years worth of new engineers have had. But yeah, as leaders, we need to be able to systematize what that looks like as well. Like potentially change our career ladders and the sorts of skills we expect people to build up and how we measure their performance. You know, maybe it becomes a measurement of how well are you using these tools, which is quite different to how well do you understand the SOLID principles, you know? Yeah, we all have to adjust.

Henry Suryawirawan: Yeah. Very interesting that you mentioned about, you know, the juniors now have the time to actually learn these tools, you know, from the get go, right? So I was having another conversation in another episode as well. We have a term about it like AI native developers. Just like, you know, social media aspect, right? The youngsters these days are much more savvy than maybe I would say, uh, me, you know, using social media. They have even different interaction patterns and maybe the way to leverage social media. So some of us, maybe it’s generational thing, right? Like we were not trained using that. And now we have to adapt in the middle of, you know, what we used to believe. And now adopting this new techniques, these new tools, seem a little bit icky for some of us. Because like what do you mean? I used to do this, now I have to change, you know, all my habits, all my techniques and all that. Yeah. So I think juniors have this opportunity, I would say that they can learn this tool natively. You know, like the first thing that they can leverage on in their job.

[00:53:34] The Shift in the Role of Engineering Management

Henry Suryawirawan: So you mentioned about the aspects of management as well, right? And management maybe needs to tweak their, I dunno, performance appraisal, maybe hiring, maybe giving tasks to, you know, their team. What do you see will change a lot but for managers? And what’s the danger now that everyone is using AI, right? As a manager, at the end of the day, you’re kind of like responsible for the delivery of your team, you know, the organization. What aspects do you think management will need to consider these days?

Annie Vella: I think the most important aspect is not to focus on that speed, right? Like as if that’s all we care about is, are we moving faster, then you’ll probably find that you have a big price to pay later on. You know, like it will hit you in the face at a later stage when you’re not prepared for it. So really I would say leaders today should be thinking about how to leverage these tools for optimizing quality as much as possible, as counterintuitive as that feels because the speed is so seductive, right? Use it to leverage the quality of the systems that you’re building. Because that will in turn create sustainable productivity gains into the future, right? That’s probably somewhere where engineering managers need to really reflect on how they perceive good performance, right? How do you even measure building high quality systems? Well, we have some tools available like SonarQube can help you with, you know, was that latest PR increasing or decreasing cyclometic complexity or, you know, code smells or things like that?

But I would urge people to look at that angle of it more than ever, because at the speed at which we can erode these reports that we see DORA and the GitClear one are pretty clear indicators that things are not moving in the right direction in that sense. And I don’t know. If we keep going down the path that we’re going, we’re probably just gonna create, the next phase will be a cleanup phase where we pay the price of the speed gains that we all experimented with in 2024, 2025, you know? But if we wanna avoid doing that, then I, think we can already maybe start to give a little bit more attention to the quality aspect of things. And then through that, I suppose, is where you shift the needle on what it is that you’re expecting your teams to really focus on. And it has to be adaptive as well, right? Because these tools are evolving so much that maybe today the sort of code that it generates is hallucinates and qualities a bit random. But maybe in a year’s time a lot of that will be resolved.

And actually what, what we then need to focus on is how do these LLMs reason about distributed systems, you know. Because right now, they’re pretty good at staying within the one repository, you know, and they can reason about the logic and the workspace there. Some more than others. But, you know, most of our systems are far bigger than just one repo these days, you know. So how do you reason about bigger systems? That’s where your human software engineer has an edge today. So being able to reason about systems like that and frame problems correctly, those are the sorts of skills that software engineers, you know, those who can do that well will be at an advantage. And therefore maybe that’s the type of direction that engineering managers need to be leading their teams towards.

‘Cause as you say, like every individual is still very much responsible for the code they commit, irrespective of whether the bot wrote it or you wrote it or you kind of collaborated on it, you know. At the end of the day, you’re committing it. Your name is behind that. At least for now, till we have fully automated agents that are spinning off and writing code for us while we sleep. But for now, it’s still your code, right, which means it’s your responsibility and then it’s your manager’s responsibility. And so, yeah, work back from okay, if that’s still my responsibility, what needs to be true for me to be proud of that work and for it to be good quality. And focus on the skills that would help people move in that direction.

Henry Suryawirawan: So I think a very good reminder you just said, right, as tempting as it is, right, don’t focus solely on speed and productivity, right? Because everyone seems to be still focusing a lot of these aspect, right? Productivity gain, you know, and lesser number of people, speed of delivery, and things like that. So I think there’ll be a time probably where this becomes unsustainable, right? Maybe your software becomes unmaintainable, nobody can reason about, simply because nobody has that cognitive load to actually understand what AI is suggesting to your code, especially if nobody’s reviewing it properly, right? So I think there will come a time where probably, you know, your software, is, uh, unmaintainable, right? And maybe you can try to leverage AI more, but I don’t know where it will go to, right? And putting in guardrails like what you mentioned, I think this is also important, right? Because when you churn out code, uh, you need to have the guardrails, right? Be it, you know, the design, you know, cyclomatic complexity, security issues as well, right? Especially if you are not knowledgeable about it and you adopt, you know, insecure code, probably is also one thing that we need to think about.

And I think another thing that I would say for managers out there or leaders, right? Try to be hands-on leveraging this tool, right? Because especially for people like me, you know, we are in the forties. Sometimes, you know, we are into management a lot, right? And we forget our hands-on experience. So at least, adapting, trying to learn what this tool is capable of, that kind of gives you the first effect is like, you know, what this tool is capable of. But the other aspect is like, how can you think about the impact of using these tools? You know, what are the effect to your, maybe your team, maybe to your process, right? And I think the most important thing as well now becomes like first principle thinking and systems thinking. I think you also mentioned it in your blog, right? So I think manager will have a tougher job, I would say. Especially trying to keep up with the AI changes and putting guardrails and make sure that the team is as productive as they can be.

[00:59:46] You Are Not Alone

Henry Suryawirawan: So we have talked a lot about all these aspects. Is there any, maybe one thing that you think you would still want to convey for people who listen to this conversation?

Annie Vella: I think I would, yes, I would say that, you know, you’re not alone. If you are, if you’re listening to this and you’ve been wondering what’s gonna happen to your own job or whether you, you have a path forward from wherever you are today, you’re certainly not alone. There’s many, many of us. There’s something like 27 million developers around the world. So there’s a lot of software engineers who are in one way, shape or form, currently wondering what’s gonna happen. Be curious to learn to use these tools, right? Like get good at them. And imagine. Use your imagination to work out how you’d like to see it go and see if you can make it happen that way, right? But play. It doesn’t all need to be doom and gloom. There’s a lot of excitement around. But yeah, just know that you’re not alone, I think is probably a good message.

[01:00:50] 3 Tech Lead Wisdom

Henry Suryawirawan: Yeah, that’s a good thing. So Annie, it’s been a pleasant conversation. So I have one last question for you. I asked this last time as well, so what I call the three technical leadership wisdom. So just think like an advice that you wanna give to the listeners. Maybe is there anything different for this episode? Maybe can you share with us?

Annie Vella: Yeah, so I reflected a bit on this and it’s funny to think back four years ago, but time has changed. Uh, well, a lot has changed in the time in between. And so I think this time my advice would be or the tech lead wisdom would be more around AI is what we’ve just spoken about.

So the first point would be, for our software engineering community, to really embrace the full role again, you know. If there was a time when you specialized on the code as we spoke about before, on the syntax, on all of that minor, minor detail, keep that in your back pocket. But start looking for opportunities to expand your horizons and, you know, have opportunities to experience and practice requirements gathering, you know, software design. Think about that that systems thinking, that higher level thinking that we keep being told is, you know, where we will now go and spend more of our time. Well, start looking for opportunities to use that skill. ‘Cause it’s a muscle that you have to build up. So I think it’s important for everyone to start looking for those opportunities. So basically, move back towards more generalist than specialist for the time being.

And number two is repeating what we have spoken about a fair bit, but that speed really is very seductive and fun, but fragility and complexity is very expensive. And it may not be obvious immediately, but we are starting to see signs of that. So temper your enthusiasm for that huge productivity gain that you’re reading about in social media and in academic papers. It’s there to be gained, but it’s a trade off between that and the potential cost of trying to maintain the software later on. So find your balance. It’ll be different for everyone. At a startup, you might be able to take more risks, but in more institutionalized large code bases, you have to take that into account a lot, I would say.

And the third one, it’s an interesting one and there might be opinions around this, but I would suggest to start thinking of these AI tools as not just mere tools, but as team members. I feel like that’s the way that it’s going. You know, we are already seeing people talking about human-AI teams and what that means. You know, there’s research out there about, some papers say that a human plus an AI can be more productive or perform better than two humans together. And others find the opposite. So it’s an evolving landscape at the moment. But if you think about it, the way that you interact with these tools is more similar to how you would interact with a team member, perhaps. You know, some people describe them as, it’s like working with a very eager junior engineer who might make a lot of mistakes but is eager to please, you know. Others actually describe it as having like a principal engineer on demand. And it all depends on the perspective of the person in the equation, right?

But for both software engineers and software engineering leaders alike, there may well come a time when your team will be made up of some humans and some AI. Start thinking about how that changes things for you. If you’re not treating it just like a tool, but instead you’re actually treating it a bit more like a team member, then how does that collaboration work? What roles would they fill and how do you manage their performance, you know? And maybe, maybe there’s some rubrics around that that we’ll need to start thinking about. So that’s sort of the futuristic thinking. Food for thought.

Henry Suryawirawan: A very interesting, uh, wisdom. So I would say maybe it’s like a tech leadership wisdom in the age of AI. So I think, uh, I like the last one that you mentioned. We have to now think that AI is part of the team, right? So it’s a member of the team. Because if everyone is using it, right, and they kind of like take a lot of part in the delivery aspect of the team, so they should be treated as a member as well. So I think that’s a very intriguing thought for people to think about.

So for people who would love to maybe continue this discussion, asking you more questions, follow you online, is there the best place for them to reach out?

Annie Vella: Sure, probably LinkedIn is the one that I seem to gravitate towards the most, but I’m also on Bluesky these days. And I’m probably less active on X. But yeah, those other two or um, just through my website, you should be able to track me down to any of those others. annievella.com. That’s my blog.

Henry Suryawirawan: Right. So I would say for people who are intrigued by the software identity thing, read Annie’s blog post as well. I think it’s a very good food for thought, especially in this era where everyone seems to be concerned about their role. So thank you so much again, Annie, for your time. So, um, yeah, thank you and wish you good luck with all the research for this AI related stuff.

Annie Vella: Thank you so much, Henry. And maybe let’s not leave it four years until we speak again. But thank you very much for the opportunity to be a repeat guest on your podcast. And yeah, I guess we’ll catch you around.

Henry Suryawirawan: Yeah. Looking forward for that.

Annie Vella: Thank you.

– End –