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

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. You. Can't even hire other people unless you can justify how AI couldn't actually help you with that extra resource, right? But what do we do about our junior engineers? It's going to be harder to break into the industry harder than it

was say three years ago. I think we're trading off that short term speed increase and what we perceive to be productivity gains, which they are, but at what cost. That speed really is very seductive and fun, but fragility and complexity is very expensive. One of the main questions that I'm asking as part of my research is how does the introduction of AI coding assistance shift the perceived focus across various development tasks such as like designing and writing, refactoring, testing,

debugging, reviewing? If we've just taken a technology that can speed up one of those phases by a lot, well, where's the next bottleneck? We'll come up with the requirements and then the other end as well, who will do the review and testing and all that. One might ask themselves, well, where is that extra time going then because we're saving all this time? Or are we just writing more code faster? I would suggest to start thinking of these AI tools as not just mere tools, but as team

members. I do wonder if we might head to a place where we each have our own AI that knows us intimate. What if it could also connect to a model that is yours? Is your personal one that knows the way that you think? Hello everyone, welcome back to the new episode of the Technician podcast. Today I have with me a repeat guest, Annie Vella. So I think the previous episode that we did is episode 30 like 4 years ago.

It's been quite a long while. The reason I reach out to Annie is because I saw her quite active 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, Dehype about AI, maybe some fears that some people have and try to maybe demystify and give us some better guidance. So any welcome to the show.

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

Yeah. So any, 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? Well, 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 that 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, encourage me to spend my free time thinking about it. So yeah, early 2024, I decided to do a masters 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 6, 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 because 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, OK, 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. 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 don't know God, what, you know, like other

AI software. So I think also interestingly, just a few days ago as well, there was a announcement by Shopify CEO, right, Toby Lucas saying that everyone now is expected to use AI, the term reflexive AI. I'm not sure what that means, but basically saying that you can't even hire other people unless and justify how AI couldn't actually help you with that extra resource, right? So I think that's a very, very new thing in my opinion, right?

So asking people to try to use AI as much as possible. So I think in your paper you mentioned about this future of

AI driven software engineering or 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 that 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?

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 life cycle, 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 life cycle. You know, I, of course we learnt how to code, but we also learnt how to analyse the requirements, you know, and 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 of the team who are going to solve all their problems, come up with the right

solutions for them. You know, right through to modelling use cases, UML, you know, back then when we used to do a lot more of that kind of stuff upfront on 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, and try 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 proudly announced 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 assistance 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, this time refactoring code as well, and this 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 2nd order or lagging indicators that we should start looking for?

Well, thankfully we don't need to look too far because Dora and the Get Clear 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're 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, they're 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 assistance. So previously you would have gone to Stack Overflow, you would have 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. 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 that 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? So I think 1 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 solver developers specializing into different roles, some even specializing in different technologies. Maybe it's a React, maybe it's a cloud thing, maybe it's 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 front end engineer, but I do understand a little bit about front end technology, right? I could now come up with some kind of maybe decent good looking UI and also complimenting myself with other skills like back end engineer or maybe cloud. I can build much better application with more coverage in terms of, you know, technology thing, right?

So do you, 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 upscaling themselves in those skills? So what do you think about this? 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 front end frameworks that, you know, went through the hype

phase. You know, I think I stopped playing around with and I say playing because I was never officially a front end developer, but as a sort of full stack developer, I did have to work in front ends and I was never very good at it. But I think the last time I did anything decent in front end was angular days. And you imagine how far, like, how long ago that feels now.

But, yeah, 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 a 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 Andre Carpathy. I hope I'm saying his name right. Apparently Twitter has articles

on it now. I, I didn't and it's not called Twitter. It takes, 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 1st 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 1st.

And although I'm sure that there are, you know, more advanced models that the 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, I've had to write a bunch of R scripts to analyse the data that I've collected as part of my research. And I'm not an art developer, but with the help of, I'm using Windsurf connecting to clawed Sonnet 3.5, it's a huge help. It just shortcuts the amount of time I would have had to spend. 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 are spent at work, that if you can take joy in your work and be proud of the work that you do, it makes a 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. Because, you know, it's 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, OK, 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. Yeah, more freedom in that sense.

And to that end, as you said, like now previously you thought of yourself as not a very good front end developer, so you probably never. Going to 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 got to 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 going to be thrown away and just proving something. These tools are amazing and I see that shine through and 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 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. Well, 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.

Yeah, myself, I'm afraid I couldn't keep up with so many different changes, new technologies, new inventions, new tools being popped up. And sometimes it's not just one aspect of software engineering, it could be other things like testing, generating UI, generating app, things like bold, 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 fallen behind like by a lot, right?

Especially from people who leverage these tools everyday. 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.

Yeah. You mentioned the time spent for engineers now has becoming less about writing code because, you know, writing code is not the bottleneck anymore that 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 of 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 base 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 Get Clear report that you mentioned as well, mentioning that there are a lot of churns in terms of code they 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 now if let's say code writing is not the bottleneck anymore? What would other aspects that we need to be concerned about? That's a really interesting

question. And honestly I think that's if I could work that out, my research would be complete. I think you're right to mention like software development life cycle 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 if 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

because I've done my bit. Now you, it's like every team's dream, I suppose. You know, like, oh wow, how 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're churning out code much faster. Who's reviewing it all because 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 wondering, 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. That's actually I saw the other day. Patrick, the plan, the godfather or grandfather, wife of dev OPS, 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 it, 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 e-mail 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're 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're going to. Yeah, vigilance decrement is a problem because, well, honestly, there's vigilance fatigue. You know that when you're writing it, you're going at the pace of like you're 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 you can generate so much more code, so much quicker, when do you go and check or that 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're stepping into.

We don't yet know what tooling, what extra phases within the software development life cycle may need to be introduced or augmented, you know, to deal with the removal of a bottleneck that has existed for, I want to 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 have 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 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. OK, 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 learnt 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, 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, but it's broader than that. And it'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. Yet even just figuring out when to trust an AI coding assistant, that in itself, that probably requires a huge amount of research. How do you know? Trust is a big topic and it's not one that we typically talk about in software engineering. I would say, I'm 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 that trusts or, 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've trusted, 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 specialising on the libraries or the syntax, because the bots can do that rather well, is a good idea. And in future we might find new specialist roles that crop up.

The world's our oyster. I think we're creating these paths, so I think that's an important aspect to consider. 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 disability, we would like to think that we

want to be faster as well. Like, you know, churning out 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 so many times, right, I would assume that everyone will start to build some kind of trust simply because it becomes like a close

friend of yours, right? And I remember back then when we Googled as well, right? Anything that is top ranked, 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 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 vigilance and

trust, right? So try not to assume everything that AI gives us is actually true.

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

Well, 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 and don't exhaust your obtaining 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, 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 at the different angles of the same skill, right? You can't just practice the same, the same song on a guitar and become a, you know, the best guitar player in on 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. Yes, simply reviewing something else is you'll get a feel for it, but you're not going to 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, additional 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, has to be the

GPS. And that's something that previously you would have figured out himself, you know, and he would have learnt the way to a place and then never forgotten it. But now he never needs to learn it because the GPS will take him there every time until his phone runs out of battery and then he just can't get there. It's OK, I'm not going there today because I can't.

You solve the right. In that case, you 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 going to become so dependent on these tools, not just for coding, but for a lot of aspects of our lives that we're going to 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's 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 Open AI 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 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 don't know if we're actually sit down and read the whole thing into it. 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 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 this very exciting and scary at the same time. Yeah. So I think, yeah, open AI 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 of 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? Bit writing code, it's something that AI can learn as well. So definitely it's something maybe exciting but also scary at the same time.

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's so many different aspects like design, you know, maybe non functional requirements, maybe be it the deployment network, things like

that. So in your blocks, actually you mentioned about this trend of software engineering or software engineer now has this kind of identity crisis this day, 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, OK, we can reduce the number of of 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? Well, 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 put it in. 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 yeah, I couldn't have imagined such a response. And also people reaching out to me about it as well. They're 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 because 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 turn into something on the computer was probably, you know, it was certainly at that age, the best feeling I'd ever had, you know,

to see this. It was a smiling bounce a :) 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? And there's a beauty behind it. And I think a lot of software engineers feel that way about

their code. There's a reason that things like lead code 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 leet code. I wish like 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 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 the sight of perhaps why we were

building that code. Because it just the act of building the coding and using different libraries and frameworks and 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 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 their 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 LLM's have already revolutionize 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 1 component. That's fine and we're 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 going to call, which tool it's going to 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, yeah, 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. But 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 going to be hard, I think, for some to break into the industry harder than it was, say, three years ago. Yeah. So I think everyone is feeling this kind of identity crisis in

their role, right? Funny enough, probably it hits a lot of nurse 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 these two is capable of, right.

And I think you mentioned about, you know, juniors, I think the other day I went into like a meet up, you know, small meet up 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 it's job. And it's cheap. You just spend a few, you know, maybe 100 of bucks a month just

to use these tools. And compared to hiring a junior, maybe a fresh grad who just graduated, the economy seems like very, very, you know, lopsided, right? So it seems like leaders probably will start to think more, OK, how can we leverage AI more? Just like what I mentioned about a Shopify experience, right?

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 it just to breakthrough 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?

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 going to 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 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. 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,

oh, 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 part way through their career, like Mid Korea, I think they're struggling with it, right? Because they're sort of, OK, 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're building are changing, how we build them are changing. So it's done settling. But they, you know, juniors probably have a unique opportunity to help create the roles that they want, but they're probably going to need to have a lot of imagination.

You know, I think that the moment, if you can imagine it, you can create it. So imagination becomes a really important skill. But again, we probably don't teach it at school all that much. I don't know, I, 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 a 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.

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, another episode as well. We have a term about it like AI native, you know, AI native developers just like, you know, social media aspect, right? The youngsters these days are much more savvy than maybe I would say 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 what we used to believe. And now adopting these new techniques, these new tools, they seem a little bit icky for some of us there 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.

So you mentioned about the aspects of management as well, right. And management maybe needs to tweak their, I don't know, performance appraisal, maybe hiring, maybe giving tasks to, you know, their team. What do you see will change a lot by for managers? And what's the danger? And 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? I think the most important aspect is not to focus on at 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 Sonar cube can help you with, you know, it's was that latest PR increasing or decreasing Cyclomatic 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 of the speed at which we can erode.

Like how these reports that we see Dora and the get clear 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 going to create the next phase will be a clean up phase where we pay the price of the speed gains that we all experimented with in

2024 or 2025, you know. But if we want to 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 the direction that engineering managers need to be meeting their teams towards. Because 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, 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 OK, 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. 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 aspects,

right? Productivity gain, you know, less the number of people, speed off delivery and things like that. So I think there will be 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 that probably, you know, your software is 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 guard rails like what you mentioned, I think this is also important, right? Because when you turn out code, you need to have the guard rails, 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 it's also one thing that we need to think about. And I think another thing that I would say for managers out there, leaders, right, try to be hands on leveraging this tool, right? Because especially for people like me, you know, we are in the 40s 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 these two is capable of that kind of gives you the first effect is like, you know what these two 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 block, 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. 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? 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 going to 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,000,000 developers around the

world. So there's a lot of software engineers who are in one way, shape or form currently wondering what's going to 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 myth.

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 tree technical leadership wisdom. So just think like an advice that you want to give to the listeners. Maybe is there anything different for this episode? Maybe can you share with us? Yeah, so I reflected a bit on this and it's funny to think back four years ago, but time has changed.

Well a lot has changed in the time in between. And so I think this time my advice would be or the take 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, 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 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. We'll start looking for opportunities to use that skill because it's the 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 #2 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 this 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 is 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 need to start thinking about. So that's sort of the futuristic thinking. Food for thought. A very interesting wisdom.

So I would say maybe it's like a tech leadership wisdom in the age of AI. So I think 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 members 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 thoughts for people to think about South, for people who would love to maybe continue this discussion, asking you more questions, follow you online, is that the best place for them to reach out? Sure, probably LinkedIn is the one that I seem to gravitate towards the most, but I'm also on Blue Sky these days and I'm probably less active on X. But yeah, those other two or just through my website, you should be able to track me down

to any of those others. Annie valor.com, that's my blog. 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 yeah, thank you and wish you good luck with all the research for this AI related stuff. 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. Yeah, looking forward for that. Thank you.