New Series: How AI Is Changing My Job as a Software Engineer

0:05Let's do it. Let's take a breath. And we're live. I think we are live. Welcome, everybody, to Brain Food Live on Air, bringing it to you every Friday, no fail. It's episode 414, and we are launching a new series today, folks. Very excited for this one, because it's sort of a show I've been wanting to do for a long while. Now, Brain Food Live, as you know, it's a discussion show. It's a panel. It's usually focused on recruiting. It's some great conversations going on. But I wanted to widen the scope a little bit with this series. We know that AI is transforming the world of work, transforming the work we do, but it's also transforming the work that others do as well.

0:52And what I want to try and do on a fairly regular basis, I think if we could do one of these a month, that would be fantastic. What I want to do is essentially bring onto screen, not recruiters, but people from a different profession. And every month we'll just look at a different profession. I want to speak to teachers. I want to speak to doctors. I want to speak to lawyers even. Let's get them on the show and ask them the question, how is artificial intelligence changing your job? And then for us as recruiters, this should be good information, right? This should be from the horse's mouth sort of information, which will tell us sort of exactly how people are experiencing this change.

1:39So that's the topic of today. Today, we're going to be talking about software engineering, of course. My background has always been hiring for tech. This is very close to home to me. And I guess the lowest hanging fruit in terms of getting people to come on screen and have a chat with me. But let me know in the comments if you know of any of the profession you want to see highlighted next. Because like I say, I do want to make this a persistent series going on to the end of this year and then into next year as well. Okay. So preamble over. but let's just do the sound check. I want to make sure if we're going to hear and see me.

2:12Okay. I've just monologued that you for two minutes. So if you're watching this on crowdcast, let me know if the audio and visual is fine. Got wired mic and ear pods now. I'm getting tired of trying to Bluetooth my way through it, especially when I'm traveling. It's just simply no good. So I plugged it in old school. Hopefully audio and visual is fine. Let me know if you're watching this on crowdcast, whether you can hear and see me. Okay, folks. I am on LinkedIn Live as usual. So if you're watching this on my LinkedIn, do let me know whether the audio and visual is fine there as well. Just let me know in comments whether you can hear and see me.

2:50And that would be wonderful. Okay, it looks like a few people can hear and see. Thank you, Debbie. Thank you, Rob. Thank you, Josh. Okay, looks like audio and visual is fine. Wide ahead, folks, for the win, folks. What can I say? um friends brain food live um cannot continue um without the support of our weekly sponsors we always get some company coming in and saying yes we want to make sure these conversations keep going um and keep circulating value to the community this week is one of our favorite and most consistent sponsors they've been with brain food for the last five years or more it is of course greenhouse uh one of the leading ats is maybe still the leading ats in that top right hand quadrant whenever you see sort of Gartner published there, their two-by-two grid greenhouse is always featuring Northeast on that sort of plot.

3:45And for very good reason, been a leading player in the industry for a long while, ever since I've really got into the game. And they're constantly producing very interesting and valuable innovations as well. Not least of which is actually an AI voice interviewer. We're seeing a lot of this in the ATSs starting to provide real genuine added value at top of funnel for employers. No longer kind of just a neutral system where it's your responsibility to fill it with quality data. They're actually starting to provide quality filters and provide sort of upgraded candidates that you can go and check out.

4:23So if you're not a greenhouse user yet, or if you are a greenhouse user and you haven't checked out the AI interviewer module, go ahead and do that. And if you haven't and you're looking for an upgrade in 2027, check out Greenhouse. Make sure they are in the room when you're making those decisions. Okay, I've just shared the link into the chat stream there, greenhouse.com. You should be aware of it already. The AI voice interviewer might be interesting for you. Okay, let's get on with the show, folks. I've got a bunch of engineering friends to bring on to screen. So without further ado, I think we're going to go ahead and do that.

5:02And we'll see how everyone fares with this. So Andy, I'm going to bring you on first. And then Josh, I'll bring you on as well. Simon, I'm serious. If you're there, I'm going to drop you into the chat as well. Anybody else, by the way, who wants to come screen if you are a software engineer and you want to take part in this and just share you know your thoughts there's no sort of stresses about this it's just about okay you do this job you have done this job how has it changed that's basically what we're talking about here so let's get on with that and see how we go so Andy Josh I'll push you into gallery just got to get the camera on and the mic on as well.

5:49I'm going to put you on here as well. Just let me know where you're happy to do it. Okay, we've got Andy here. Let's say hello to him. Andrew, great to see you. Nice hair, by the way. I dig it. Well done. It is. You're the best when it comes to hair, but I think it's all right. You know what I mean? It's not bad. Anyway, Andy, great. Why don't you quickly introduce yourself? Who are you? What it is you do? uh hi everyone i am andrew andrew lawson i work at monzo bank where i'm a software engineer an engineering director um i've kind of done uh on lots of different hats at monzo and other places uh before but yeah i'm a software engineer that's me um i can go into details about the kinds of work that i do or the kinds of work that i have done um if that would help um it it we definitely will in fact sort of your sort of i mean i'll come to you once we bring josh on as well i'm gonna see if simon's up for us as well you know si of course uh bring him on but we've seen josh here as well josh great to see you man um can you quickly introduce yourself who you what it is you do yeah great to see you and uh i'm also uh like you sporting the wired headphones so hopefully that'll work well um but yeah i'm uh i've been working in tech for quite some time started as a software engineer focusing on infrastructure spent most of my career working with startups and scale-ups and helping them build up their technology and you know kind of find their their foundation and get big spent 10 years at red hat doing professional services and consulting across a wide variety of enterprise organizations and then last 12 years or so working in europe and startups across berlin and amsterdam and i am currently doing fractional cto work so great stuff um let me just share one of linkedins there have i done that on the chat um so andy yes i have so go and go and connect with sort of josh and andrew uh on linkedin if you want to get sort of the tech point of view on where we're at um and and i want to start with you andy because you and i obviously go way way back i mean we we just a kind of a disclosure um we probably end up working with it's probably early startup days wasn't it for my first startup definitely and maybe yours as well that was over what 15 years ago so long long time um and i remember you and i having a conversation when you told me um that you used to dream in php uh and i just thought wow this guy's neurologically wired himself to think in php this is actually problematic and i remember we had a really interesting conversation as to how you know human beings are bending themselves down to the machine we said actually at some point machines will come to us um and it seems that that's what's happening now isn't it so we've you've seen that journey um where human beings had to force their brains to look at non-human language really um and that was the job of software engineering back when we were doing it um so let's start there 15 years ago um you know what was programming then what was the job what was the the key tasks that you were focusing on um at that point in in time yeah well i mean php uh has come on a long a long way it's had a bit of a bad rep uh this week a little bit but um back in like 2010 when we were working together uh the kinds of things we're doing we like sat in rooms doing like you know like what's it called like planning poker and t-shirt sizing and doing all that sort of stuff where we're like yes the size three is the size eight you know try like pull apart what we thought were like really big problems into like the smallest most granular things and spending like months building these things where we weren't really sure what the value was maybe that was just the particular place that we were working at but we were like we thought we were doing good but the things we were focused on was like writing the code we're like yeah the code needs to be like this and this is the thing that i care about a lot and this is how we're going to like separate these concerns and uh by making all these like decisions in the code that surely must mean some some business value somewhere or that would mean like good outcomes for our company and we're sort of like implicitly certainly i was implicitly thinking that that was true um i don't think we're thinking exactly focused directly on those business outcomes and thinking how do we make the code get there i think in 2010 a lot of startup money was was cheap and so we could spend a lot of time focusing on the technology um rather than the outcomes yeah there was a lot of just building for business like just blasting code out wasn't it again there was a there was a culture of that back in the day there was even a measurement of uh of of performance i think it was going away by then but there was still some sort of measurement of performance by like lines of code written right It was like, how come you haven't written any code this week?

10:49This kind of conversation I remember hearing. And code coverage tests as well, where you're really deeply focused on, are these three or four or 10 or 100 lines of code covered by these unit tests? And you're like, yeah, there's still some value in that stuff. But that's the stuff we're really focused on, seeing that the background of this code had changed from red to green because we've written a test that covers those lines. That was the stuff that we deeply cared about. Yeah, so it was very much to the code, nose to the code, it almost feels like. You know, you're gazing at this. And it was essentially, was the reason for this because it was, I wouldn't say fundamentally flawed, but the surface area of error was very large back in the day, because you had basically a code base that was manually typed by lots of different human beings.

11:43over different periods of time, often doing different things. And it was just layering on like complexity. Therefore, the next generation of code are looking at that code base who think, right, first, they've got to understand it. Secondly, I've got to figure out what potential risks are about on here. Thirdly, that's when you maybe rewrite or refactor some parts of it. Refactoring was a huge term in 2010, right? It was like, okay, we've got to refactor this, means basically rewrite and replace. Josh, you might even outage both me and Andy. I hope you don't mind saying, not by much, but you probably do a little bit.

12:22Does any of what Andy described there resonate to you in terms of what coding was like in that time frame? So we're looking at 2010s and so on. Any additional things you might want to add to how a code was done there? What software engineering was in that time? Yeah, I mean, I think this is also a big boom time for a lot of people coming into the industry. And that had a huge effect on how we approach things. But absolutely, there was a lot of attention on not just what do we need to do, but how are we doing it? How are we doing it in a way that a group of people can participate in? and one of the things that I like to point out is you know you go back far enough it was often just one person writing a piece of software or some team creating a perfectly detailed spec before anyone wrote software so either way you're sort of removing the communication barrier and then we got into like let's do this as a group and find ways to share the information and to communicate and keep our code organized so we can all deal with it and the way I kind of tell people is you know if you think about in your kitchen you have a cabinet you keep your spices and things uh if you keep it very well organized and i ask you to uh i don't know grab the time we'll take you a second you know boom it's right there but if you're in my kitchen i'm not very well organized you open that cabinet stuff starts falling out there's it's all in the weird places there's small things behind tall things it's just a mess and by myself i can work this but we learned in the 2010s, you can't approach software like that.

13:58You have to put that extra work in, keep it all organized, put the tall things in the back and the small things in front and make sure, you know, we came up with all these rules, maybe Andrew remembers some, like the principle of least surprise and, you know, all these sort of things we would focus on to make sure we're producing not just something that works, but something that can work within the team that the team can extend and maintain. Yeah, really, really good point. And I do remember that was the big challenge on the recruiting side. That was one of the things we were looking for. It wasn't just this individual hero that could just blast out functions or create applications.

14:34It was, look, does this person produce code in such a way that it's easily picked up by somebody else and it's compatible with how other people do their work? And in fact, sometimes we had maverick coders that were amazingly talented, like these idiosyncratic, kind of eccentric geniuses that were brilliant, but we have to kind of like isolate them somewhat because we thought, okay, this person's style is simply incompatible with the wider group. And that was one of the challenges of software development in 2010. Simon Hammond, great to see you as well. Simon, of course, another old friend back in the day.

15:09Si, might as well quickly introduce you. Who are you? What it is you do, mate? So I'm a bit of an interloper here. So I come from a data science direction. So I've done software engineering or something, approaching software engineering. But it feels like those days are kind of drawing to an end, actually typing code. By being able to read code, knowing what good code kind of looks and smells like is great. But actually matching braces and stuff, it's just like those days feel like they're kind of, it's more of a hobbyist thing. But I think just knowing the shape of good code is still the thing.

15:42having the experience and the instinct, but just learning syntax, learning libraries and stuff, it feels like not a thing anymore. So it's more of my background. I've skipped over that. So the last year I've just been working on my own thing, which has been way too much fun. So just kind of vibe coding kind of came into its stride. So I've just been going a bit crazy with that but I'm actually going back into regular employment where I'll actually have to be accountable for the stuff that I commit as of next week so it's going to be an interesting time can you tell us who are you joining Simon or is that still confidential or what no it's Adzuna so still back in the recruitment space fantastic fantastic great to join Adzuna and I know the Adzuna crew very well as well so Doug great great Doug and James great hire with Simon Hammond here.

16:37Okay, brilliant stuff. So software engineering 2010 was this way. We were recruiting people that were very good code producers, right? So they needed to be able to produce the code, but they also needed to be able to produce a code in a disciplined way, such that other people can follow and pick up what they were doing. No good them submitting something that other people would take ages to have to figure out. It's actually better to have, let's say, a slower developer that was simply more compatible with others. That was one of the things that we were looking for in 2010. And it seemed to be a period where everyone was talking about the right frameworks to use.

17:22There was a lot of tribalism at that point, wasn't there? People were hiving, I'm using this, you're using that, are you an idiot? It was actually really fun and games um when did coding start changing i mean would it be fair to say it was more or less should we talk about microservices is is that a a point of is that a significant enough moment in the journey we're trying to the story we're trying to tell or do we need to go straight into the ai moment um like was the big change when github rolled out copilot for you guys what's your what was your your feeling on this andy you've got a grimace in your face so you've got to say you've got to explain that i'm having to think about this i think that we um i reckon when we were working on stuff in 2010 we we were writing so i mean there weren't microservices there were there were a couple of services i guess we'd maybe call them um they weren't micro they were big chunky things i don't think that like microservices is the is the thing the moment that changed the direction of things.

18:27GitHub was a huge change of direction for lots of other reasons, like the social aspect of sharing code and open source and all that sort of stuff. It was like, that was a real moment for engineering. But I think the moment that things changed for this conversation about AI, I think it was slightly towards the end of the like the co-pilot cursor sort of wave just as Claude Code hit there was like before Claude Code really hit it was sort of sort of like autocomplete but a little bit better and that's kind of all we got and so you kind of go like this is this like helpful but I'm not going to spend loads of money or loads of time like making this better or you know I'm not going to like change the way that our engineering organizations work because we've got better autocomplete.

19:20But code came along and changed the way that you're interacting with code and changed the way that you're thinking about how to write code and changing the kinds of questions that you're asking about it. I think for me, that was the moment. That was maybe like spring last year, that it really changed. It was like a huge flip. Very recent in this case. Let's not forget the timestamp everything. Basically, GitHub rolled out Copilot in 2021. I think mid-2021, something like that. So devs actually had a version of Gen.AI kind of pre-most mainstream, right? So mainstream folks, we had ChatGBT in what, November 2022.

19:56I think it's nearly coming to anniversary, four-year anniversary. Devs had it really for about nine months, if not a year before. And then it was like, okay, increased the generation of code, but the engineer was still a person prompting it, basically, and creating those code. and it wasn't coding on its own. Now, what you're saying, Andy, is that basically Claude code changed things. Now, again, I want us to explain what Claude code is because things are moving so fast, we might have actually forgotten what it is. So does anybody here want to explain what Claude code is and why it was different from what they had before?

20:35Josh, you want to give it a blast? Yeah, I mean, the short version is we started with these chatbots where you can kind of converse with it and ask it to do things for you. and CloudCode was a different class of product that came where it's more like an agent that sits in your computer you can give it a project you can give it a blueprint and it iterates and works on it until it has achieved the goal that you've given it and so it's it's like a it works for you as opposed to something that maybe is working with you yeah so prior to CloudCode essentially it was an inert AI like it was very responsive to you but it wasn't necessarily autonomous or semi-autonomous whereas cloud code you could give it an instruction and potentially it could continue until it achieves its objectives for good or bad end by the way but it does work until it tries to achieve this thing and then the job then becomes how do you i'm going to use the word parameter parameter ties it's not a word but you know how you put guardrails against this attempt to achieve an objective.

21:37Because obviously we know this is how sort of bad things go wrong. You know, ancient Greek mythology, the golem stories, it all emerges from, you know, the honest sort of setting of an objective, but the relentlessness of the pursuit of it and the lack of common sense basically creates a monstrosity that cannot be stopped. So anyway, Claude Code, that happened. what um a year and a bit ago simon how did this affect your sort of worldview you mentioned you started vibe coding and stuff did you interact with quad code tell me about your journey there yeah there was a point with um with copilot where it was literally just like you know kind of write the function header write some comments and then it just kind of fills in the blanks that was the kind of thing so it just felt like a sort of speedy up autocomplete kind of vibe um and then going, I kind of moved over to like cursor.

22:32So it's like something that's happening in your editor and it's like writing large blocks of code and you've kind of got a chat window on the side and you're saying, yeah, write this, write this speech or whatever. But you're still looking at the code and you're still eyeballing every time it makes a big change. And then after a while you realize you're just kind of approving everything very kind of automatically. And then you have this kind of mindset switch where basically you realize that you turned into a technical product manager at this point you're kind of you have this you're kind of writing the spec the spec becomes the thing that you're actually designing with and you're working out the details of the spec and then you're working out a plan to work through it and then it's just going through writing its test writing stuff you're kind of you're kind of checking it you're kind of making sure that it's not going off piste at all but really you're you know you're thinking more about the high level thing and I think this is kind of the step up is that people aren't thinking of things in terms of programming constructs anymore, they're thinking in terms of functionality they're thinking about the high level interactions between the parts of the system which it feels like a bit of relief because it's obviously way faster and the actual code quality, I mean certainly compared to the stuff that I've knocked out previously.

23:51It's just way better. If you look at the code, you probably learn some stuff, you know, because, you know, the principle of good code is it should be very generic. It should be very kind of best practice. And, of course, this is what the agents have been trained on. So they're kind of producing very literally predictable code. But it's also explicable as well. If you say, I don't understand this thing, go into it. They can reason with it. you can jump in and out as you like. And we know this is, we've got strong confidence this is the case, don't we? Because sort of code, there's multiple ways to achieve an objective with software, but there's optimal ways to do it.

24:35And of course, AI is going to more or less always try and find the optimal way, much better than a human being might, simply because it's got more access to that information. so I guess the future direction this is a segue I don't want to necessarily go down but we can predict that the idiosyncrasies of software engineering will disappear to a large degree it will get homogenized in the sense that if you're calling the same thing Josh I'm going to bring you in as to why you're shaking your head but go with this one sec basically I think AI eventually homogenizes most things and it will homogenize code such that it can be more easily understood by other agents and more easily understood by human beings up to a point, even though I think human beings will soon lose control of sort of the minutiae of what's going on because the code production volume is going to be such that we can't read it all.

25:29You know, we're going to have this human attention bottleneck whereby actually we can't eyeball it. As Simon, you said, that experience of just, you know, getting to the point where you're just approving everything because more or less it's always right. and it's like, okay, at some point, you're going to not understand the system because you haven't actually thought through it, but that's okay because the system starts to work, and then your mind goes to somewhere else, and we've left this problem set behind. Josh, you were shaking your head on my story there, so I want to open space for you to make your point there.

26:05Yeah, I think that it's tempting to fall into the trap of assuming a little more capability and agency on these things than they really have. And what I've found over the last six months is that to truly achieve great results and consistent results and maintainable results actually requires a really big shift in how a software engineer thinks and more importantly, what they think about. But the reality check is that, to challenge a little bit what we've been saying, the LLMs are trained on what corpus was available, right? So that's GitHub, that's GitLab, that's a lot of stuff. But the reality is the majority of this code is average at best.

26:51It's not the kind of code that if you just pull random projects off GitHub, you're going to find some that are written very cleanly and some that are written by someone who barely knew what they were doing. And I would, you know, maybe it's a controversial opinion. But my opinion is that most of the code on GitHub is written by people who barely know what they're doing. and this is what they're trained on, right? So it's a very peculiar technology because if you give a coding agent a task and you're just very generically prompted, create a login page and add two-factor and whatever, okay, it's going to do a mediocre job.

27:27It'll be effective, but that's fine. But you take the same agent, you say, build the same thing for me, then double check for best practices and then ensure that the code has been reviewed at the expert level, it will do a better job. And understanding why that is, is the key to really knowing how to work with these things and what you can get out of them. But a big part of this is that we want this fantasy of just give it the spec, tell it what we need, give it the design, it writes the code. The challenge here, and what I'm seeing when we really get down to how software engineers work with this, is that there are a lot of things in a piece of software that you're writing that matter.

28:09And then there are a lot of choices that are kind of coin flips and they don't really matter in the instance, right? You know, should this box be red or blue, you know, these things like this, but they're also technical design coin flips and anything you don't specify, you're asking the agent to flip the coin for you. And there's nothing wrong with that, but the practical result is that it does literally flip it every time because you didn't give it guidance. So you won't get consistency this way. And you will end up with multiple variations of things in each version of something you put out. And so learning to have an opinionated view, a vision of those pieces you might not have thought about before, but you need to give some guidance in your specification and your prompting to cover those cases and bring consistency to it.

29:02And these are some of the new areas where we're really seeing a division between what the person who works great with these agents and is highly productive and produces really high quality, maintainable stuff, and the person who produces a lot of stuff but can't really extend it and maintain it and keep it going. And so I think it's important we really understand that these are not just taking over jobs. They are really changing jobs and how we approach this job and how we work with these tools. And they're not going to, for example, write their own AI coding language that agents use because it works better because they're not trained to do that.

29:41And they're not trained on any such thing. They really are rooted in their training. And at least my opinion, taking that view helps you get the most out of them. Yeah, really good, Josh. Josh, very interesting. And one thing I can see here is, are we not just moving up a level of abstraction when it comes down to code that isn't compatible with other people, for instance? Again, the maverick coder back in the hand coding days, totally genius, produces loads of stuff, nothing compatible. You just basically, he is not suitable to be working in team setup. That character may be exactly the individual today that hasn't got the discipline to put in those additional sort of questions, those additional guardrails for the agents to say, can you check for consistency?

30:28Andrew, I want to bring you in on this because you, again, great micro expressions, man. It encourages me to say, okay, Andrew's upset for something. Let's hear about it. Any thoughts on this kind of change of how an engineer needs to be thinking? And are we heading towards a way where we can start identifying what is a good, can we call an AI engineer or AI orchestration engineer? You know, are we getting to sort of some sort of clarity as to how we differentiate a good interactor with agents compared to an average one? Yeah, I think that I think I relate quite a lot with Joshua's points. there are I don't know I think there's some questions I've got really about what it means to be to produce good quality and like for me quality I guess the start of my career was like does this function read well does this comment make sense is this comment even valuable is my function not too long or not too short is it separated nicely and stuff And I think that if that's the same shape of quality that we're still trying to achieve with AI tools, and I think we're kind of like, if that's the guidance I was going to give to engineers that I work with, it feels like as a whole, we're kind of missing the point.

31:53and the point for me I think is that quality comes from the outcomes of writing code as a mechanic rather than the code being the thing that I care deeply about the quality of and by outcomes I don't just mean the like the business outcomes or the the like the revenue we can generate from it or anything like that it's also things like the stability of it the operational resilience of it they're like the but like the the times that my engineers are paged out of hours because it went wrong those are the kinds of outcomes that i really care deeply about and so long as we're still achieving good outcomes in those dimensions that's the thing that i care the most about yeah i actually don't understand what you said dandy um but i uh but that's that's i just it's out my depth bro i mean i totally agree i think you know in the earlier times there's a lot of emphasis on what i would call penmanship right like in other words is it is had written in a way someone else could cleanly read it.

32:51And we argued about things like how long should a line be before you break to the next line? And, you know, how many blank lines should be between a function and the next function? And this is not what I'm talking about when it comes to quality. I mean, this stuff is important for human reviewers if you need to do that. But it's really the other thing that Andrew was talking about, like how well does it work and how reliably does it work? And this, unfortunately, these two things are a little bit connected in the sense that, I mean, it doesn't matter how many spaces you put or how long your lines are, but if the code is written in an uninformed way, let's say because, you know, you're trying to fill a swimming pool and you have maybe a spout in your yard, you're going to put the water in, you could write it in such a way that you're taking the smallest cup you have and you're just getting a little bit and running over to the pool and you're running back and forth with this tiny cup.

33:46And this would work, right? It would fill the pool, but it wouldn't be until you start maybe checking how long does it take or, you know, where you would find the flaw. And so, you know, that might not hurt you for a while until suddenly you realize you're going from filling one pool to filling a hundred pools. And it is just impossible with your current method. And no one thought about that because the, you know, the agent wouldn't care. It just was given a task to fill the pool. And so this is where thinking about not just writing it so it works, but how was it done? Will it scale? Is it using components that are common and well understood?

34:25Or is it doing something really esoteric? that we are tempted to think, well, it's fine, because when it needs to be updated, the AI will just understand what it did the last time and be able to move forward with it. But we're starting to see that that is not universally true. If you just keep piling more stuff into it, the total amount that they can read in and can, you know, think about, for lack of a better word, is limited. So as the code base grows, if it's not modular enough where you can consider just part of it to change it and then understand the interfaces to the next part, this gets still harder and harder for the agent to maintain.

35:07So a lot of the stuff that we did with people doesn't matter, but a lot of it still does. And having the judgment to see which parts are key for this and which we can throw away, I think this is the change we're talking about. okay um team structure for guys how does all of this change the structure of an engineering function um the again my my info is outdated so the last time i was involved in any kind of tech team was 10 years or so ago um but it seemed to be okay you had a bunch of like ices we call them ICs, they would actually be developers. There may be somebody who's a leader of that, that person would review the development work.

35:52Maybe that person would also be the deployment guy. If there wasn't, there will be a separate person, you know, doing the release management and what we now call, I guess, DevOps. Then there might be, you know, some sort of product owner guy. This is, you know, someone owns a product, non-technical person. Maybe that's a product manager. Maybe that's a a line manager a person who's in the business and there'll be some interfaces that way and then we had you know legit product managers involved in some of the functions so quite a complex system um involved there was a career progression pathway in different ways you you know how how you work forward how does ai change that structure uh as simon hammond your your your thoughts on that uh i mean i was kind of just thinking back to the previous point about uh of making the system kind of resilient and adaptive.

36:45Because I think this is the future of the code generation gets very fast now. It's very easy to write a ton of code. And AI is perhaps inclined to write more code than it needs to. Often it will kind of create busy work almost for itself. So you kind of have to rein in a bit there. But it does mean that maybe this whole kind of feedback loop of the deployment, product design, specification gets a lot tighter. you can make you can almost have a little bit of a more experimental or a bespoke mindset towards maybe products features than you might have been able to do before but generally yeah the idea of code that doesn't get bloated and actually stays adaptable is a thing so the modularity, the reusability that's where the knowledge of kind of the business

37:37knowledge comes in so that you have to kind of have that knowledge about how is this thing going to be used not now but in the future and making sure that the code is structured to actually be able to evolve into the future and so it's less of a less of this kind of what we used to call the waterfall model and very kind of very kind of lean but also having tests and stuff like this. So it's a very different dynamic. The pace is very different and maybe the roles kind of merge into each other a little bit. This is what I'm kind of getting towards because back in the days of product management, agile, et cetera, it was an attempt ultimately to discipline the code, to align it with business, but also to speed it up, like speed up the development, right?

38:22That was one of the big cells of product management. um and i don't like someone's knocking on the door either come in or not babes you know i'm saying it's like nothing i'm gonna do live streaming there's a cleaner coming in but you know come in i don't mind but don't stop knocking um but um okay um so in it's sort of we're in a world now though where we're sort of it's kind of cheaper to experiment isn't it um like you can just like go tell it to do stuff you can even do it sort of on its own um and you can come up with a prototype that people can poke around with and it's like okay doesn't that like chop out like huge parts of the previous software development uh life cycle and does it not even chop out some of the the key parts of what were jobs um in that structure so how does the the ai enabled dev team now look like are there still product managers for instance where what's who's doing release management there is that a bigger job now because they've got lots more stuff being generated maybe maybe developers become all release managers actually um do engineers in fact um if they stop producing code themselves are they now kind of like qa in a way like you know are you now actually qaing the bot stuff which probably you wouldn't accept as a great you know psychologically a great move but how has it changed in your view so andy you're actually working in a big organization a big dev team now so i'm assuming he's kind of seeing some of this stuff happen in real time um can you explain sort of what your view is on on how ai is changing the structure of software engineering teams yeah like i think that um that uh or like even if i take like just software engineering for it as as like a like that already has a title software engineering inside of that you already have specialisms you already have like security leaning software engineers and like platform or infrastructure leaning security software engineers uh you've got like product software engineers um all sorts of different flavors i think that kind of what we kind of like end up with going forwards with ai where we kind of think there's a lot of blurred lines between product management and designers and front-end engineers and back-end engineers and all these sorts of things is something that uh speaks to kind of where anthropic are kind of heading which is like everyone is just a technical member of staff but even within that blob of technical member like like those technical staff members they will have specific leanings some are more commercial leaning some are more infrastructure leaning some are more front-end leaning or whatever it is i think that's kind of where we end up where like that's not what we where we are currently as a business but we already are in a place where our product managers are writing code to kind of prototype certain things same with our designers we've got product managers learning how to like figuring out the shape of a of our new interfaces that they want to kind of talk to our designers about producing properly with our software engineers more properly before it goes into production and i think that that's sort of the train of or the the direction of travel really that everyone is mucking in but everyone still has their like leanings or specialisms yeah so But basically, perhaps the discretion between the roles is blurred a little bit.

41:41Yeah, because you want people to be able to contribute across those lines more freely because people are able to contribute more technically or to design more freely or whatever it is. But then you would still, even inside of that title, still want to lean on someone who really deeply gets it before you go like, oh, actually, this is a good idea or not. Yeah, I get it. Is it not the case that... sort of product building diffuses across the organization so it escapes from engineering it go you know we talk product managers but they typically sit within engineering as a function um but it spreads beyond right it could go into marketing goes into sales goes into recruitment goes into different functions everyone can vibe code something um but then if it works and it's really good then maybe engineers then rebuild it properly quote unquote um for a wider distribution across the organization, in which case does the engineering team kind of become like a DevOps for the business, so to say, like you create the environment for experimentation for other people to prototype.

42:46And it could be anybody in the business becomes the product manager type person, but you're there to make sure they do it in a sandbox environment. So they don't end up like doing stuff that's out of compliance or leaking stuff into the cloud or in any respect, endangering the organization. And then there's some sort of internal marketplace where everyone just creates the same thing. Market dynamics kind of determine which is the best three options. CTO eventually says, you know what, we're going to pick one option, delete the rest. You guys, devs, you're going to rebuild this properly, quote unquote, with the scalability, the robustness, the compliance, et cetera.

43:22And out you come with kind of an in-house built bit of product. So, okay. Is anyone doing that? Josh, or is that just my fantasy? I think some organizations are certainly attempting it. I've talked to and actually consulted with one that had this grand idea that everyone can commit code. Everyone, if you have an idea, just plug it in. They built a system. It'll auto-generate a merge request and send it. And it was a disaster. What they found was that they so they left it with the engineering team to be the sort of gatekeeper to production to decide what, you know, is acceptable. And the rest of the organization drowned them in submissions and ideas and contributions.

44:07And it was just untenable. And this for me, I think it is the right direction. But to get there, we really need good management. Right. Like what is, you know, Google did that famous experiment. What do managers do because they saw software engineers don't understand and don't think they add value? Well, what we need here is we need rules of engagement, right? It's great if you could say, hey, everyone can flood the engineering team with code. But if it's impossible for them to make sense of it or work with it, then you're not gaining anything. So we need procedures, right? We need policies that say, here's how you make a change.

44:43Here's how you can evaluate it. Here's an AI agent that'll help you decide whether you're making the change that, you know, is the right approach or should be done now or fits within planning, whatever it is. But we need some sort of alignment within the company in the same way. Right. So let's think of it in reverse for a second. And this is what I challenge people to do. You say, what would happen if everyone in the company took their favorite AI and wrote copy and sent it to the marketing team and said, get this out there. This is the new stuff that's going to really sell. Or, you know, they created an influence campaign or whatever.

45:18All these things I can easily do myself. Right. Or I created I could create a 400 page sales Bible with my LLM in a weekend. Right. And I can tell send it to the sales manager and say, look, this is so much better than what you've got. like you need to switch to this now but you'll notice that's not really happening right like you're not seeing the accounting department in some company make a new sales bible and sending it to the sales team or use an llm to generate text and send it to the marketing team or to create you know whatever and the reason i think it's not happening is because we don't normally think like that we think about the product and we you know okay i can make the product better But we need to kind of remember why we don't overwhelm the marketing team or the accounting team or whatever with submissions, because there is still expertise that goes into this.

46:09So for me, it's important. I challenge any team that's really heavily working with AI to decide at what level. And what I mean by that is you can come in high level and describe a product and prompt it and get it to build the whole thing like we've been talking about. but a lot of teams are working one level down where the team is deciding what their goal is, how it should be broken into components, and then creating the tickets and having the AI agents build the components. So it's some of the difference between I want to build a car, so I don't just tell it, build me a car, but I say, I want to have this size wheel, so make some wheels.

46:48And then I want a drivetrain that has these requirements, So build that drivetrain. And I want an engine like this. And I'm getting more control over the car. I'm having it build the components. And my thinking is, in the end, I will have a car that this will be easier to iterate on with the agents because it was conceived at the modular level rather than just letting them flip coins and make this whole thing and, you know, make random decisions as they go along. So I think there's still a lot of calibrating and figuring out for which kind of project and which kind of company, what level do we want to use?

47:23Where do we want to plug it in? How many people do we want submitting? What kind of gates do we want on those submissions? These are all things we're figuring out.

47:35Andrew, your take on the same question. yeah I think that um the I think it depends what we're like what we're trying to build for right so like I think that um I think I I agree with Josh on the like the like the product direction and like the things that we're building as a product and we're a product company let's go build this thing and so we need to think more deeply about how what does this look like to our customers does this like fit into our terms and conditions what's the copy look like the There's the other stuff that's like, how do we as software engineers at a large company support everyone else that works at this company?

48:14Like, how do we make sure that we're helping people to automate and augment their business functions, whether they're lawyers or salespeople or finance people or whatever, and help them do that in a safe way where like we can apply what we think is our taste to their discipline. and we would get it wrong most of the time because what we're trying to do is ask them to do the same thing if they come to us when we're building this product. How have you applied your taste to this thing? How does this apply to our product strategy or direction? How does this mean that our product is more maintainable or how does it impact maintainability over time?

48:57Where what I want to be able to do is to give our lawyers and our finance folk and people the ability to create their business functions with AI without the helicopter parents of software engineers, but help them do it in a safe way because we don't want data breach or data loss or whatever it is. That, I think, is sort of the other side of the same coin. I think that, yeah, it's an interesting space. I'd love to hear from the crowd here, folks. where is your business when it comes down to, I guess, the diffusion of prototyping in the business? Is it still pretty much within engineering? Better in mind, pre-AI, there's no way this would be anywhere else.

49:39It had to be within software engineering. But now with AI, everyone's vibe coding away. CEOs are vibe coding away. Okay, is this happening? Is it promoted? Is it a strategy your business has to get to a certain endpoint where you basically have a pretty decentralized way to prototype. And I do think, to your point, Josh, that you're not going to end up with a situation where at any serious scale, you get a non-engineer building something that's used throughout the business at an enterprise level. That's too high risk, I would say, for anybody to really release. But this is where this engineering expertise might come in to say, okay, we've seen that the user wants to do it this way.

50:26Let's just rebuild it properly because we figured out how to do it. Okay, how does this change the sort of skills that we need in the function? Are they completely transferable? Is the software engineer, is the elite software engineer in 2010 the same person in 2016? Is there a reshuffle as to who's better or worse given that the job has changed in some way? and even more extreme, are there some people that are simply that would be good then, but are actually not good now and vice versa? Are we going to see new people potentially come into this engineering space that have different sets of skills more compatible with this AI era?

51:05Thoughts on this? Anybody can give it a shot. Yeah, I think just really quick, I'm seeing quite a change. So we often had people that I call syntax engineers, and these are ones who know a language and are reliable and you can give them a small problem and they'll make the solution and commit it and it's great but they don't really have broad experience or deep understanding of what's happening right sort of like i can write a poem that rhymes but i don't know what all the word all the words mean it's okay it's still a poem still rhymes it's probably fine is it going to be a poem that moves a nation and changes a you know, everyone's thoughts about something?

51:44No, right? That's the elite writer that can write and knows the word and the meaning of everything they're doing. And this person who is beyond the syntax, right, who really understands the impact of what's happening, that person can excel with AI in a way that those who were kind of just knowing the syntax aren't. Because it's really those judgment calls and that guidance and that kind of deeper understanding that allows you to give the prompt to the ai agent to get a successful result yeah i think there's a point here as well is that a lot of code it's not you know it's not homogenous in terms of its its complexity so a lot of code is like kind of standard boilerplate code that you know it's it's going to be the same way in lots of different systems and there's certain parts of the code base that like the you know the secret ingredient the sort of really core algorithms uh the very you know specific protocols whatever that really make the system the system.

52:42And I think the promise here is that AI allows elite engineers not to be writing boring code, not to be writing the standard stuff. They can really focus their attention and their time on the place where it actually counts, either on the algorithms or the large-scale structural strategic stuff. Just like not doing the stuff that doesn't really use their full capacity, basically. Do you know what? I think engineers, a friend of mine mentioned this, and I think he was so right. There's elastic demand for engineering capability. So in the sense that if we superpowered every software engineer, we could probably end up making good use of that.

53:25There's good use where you can deploy that. That's not necessarily the case for every other white-collar job, by the way, which is why I think we do get divergent sort of outcomes when you have AI enablement. in some outcomes you actually have a job reduction because you know what there's a limited number of if you supercharge sort of a call center agent that can do times 1 ,000 the effort of that he or she was able to do before probably you're going to reduce the overall number of call center agents because there's an inelastic demand for that whereas engineering is different if we supercharge an engineer times a thousand, probably a business will find ways to apply that additional capability across different things.

54:07Maybe not perfectly, but there'll be ways to absorb that extra capacity. So maybe it goes down that route. I think basically AI is generally quite positive engineering, apart from one segment, which is early entry junior, right? Where we have seen a, I would describe it as a collapse. People are talking about 10, 15%, 20 % decline of vacancy, That in normal pre-AI language would be described as a collapse. So we are significantly reducing the numbers of junior people coming in. And the reason I think is this, by the way, is very similar to every other white collar function. It's simply because the first one or two years of anybody's white collar job was essentially a training run, learning on the job, doing office gopher stuff.

54:53and that productivity, those activities actually can be completely done by AI now, such that we're figuring, oh, is it really worthwhile bringing a young person in and literally sitting him or her at desk just observing for 12 months? None of our businesses can stomach that, so we're simply not hiring for those people. Now, obviously, we all know this is a problem. I personally don't think we're going to solve it. so let's project further forward in five ten years down the line when people start aging out and we leave or we decide we've had enough of cop life you know we're leaving so we're going to lose all of the engineering talent how do denuded engineering teams deal with that is it going to just be more ai agents then like are we now more or less on this flywheel where we're going to head to headcount zero at some point

55:49I think it's a mistake we're all making because juniors are our source of hardworking, loyal, great employees. When you get your skills at your first job, you're loyal to that company. I think there's been a bad trend in the industry for a while that we were just hiring juniors as chief engineers rather than as people we wanted to invest in and grow. I've seen a lot of companies rewind three years or so. You had big rooms full of juniors and maybe one or two seniors to kind of help them. And this was just a cheap way to build an engineering team. And this is where you'd hear that, oh, they had five years experience as a junior, but it was the same five years, so they're still a junior.

56:30We were already doing a disservice to these people by not actually trying to build them up, but instead by trying to keep them cheap. And not every company did this. The good ones do it well. This is the thing I'm concerned about, is if we cut that pipeline off, because the ones who were looking for cheap teams are the first that'll just get rid of them and put it all on the agents. Yeah, where are we in five or 10 years, right? Who has come in and learned and grown with these technologies and mastered them? Some companies are going to get this right and they're going to be the ones that are going to be winning in the future.

57:02Yeah, any thoughts on this? I totally agree with you, Josh. What do you think, folks? Let me know. It's a pipeline problem I see in almost every profession, by the way. Recruitment is the same. Like when's the last time you saw junior recruitment for a sort of role being advertised? I haven't seen it for two years, bro. So there's going to be a problem for all of us. The issue is, though, like none of us are incentivized to do anything about it because it's really about sort of there's a misaligned incentives for the people who basically commission the vacancies. It takes a longer view and none of us have a longer view.

57:39Similar to politics, right? We know what the right thing to do is to do an aggressive shift to renewable energy. we can't do that because you know what it's not a vote winner in the next four years um it's the same deal with with with what we're doing here it's not a it's not a company winner um to be more inefficient by hiring in the short term by hiring these junior people um andrew lawson so the pessimistic view let's assume that's the case we ain't going to fix it what does that what does that mean five years down the line like how does engineering continue to be without a pipeline is there a way you can see that AI agents might actually fully take over code production

58:21I'll take this in two directions because I don't think that it is I don't know that junior engineers is a lost cause at all I think that one way that we could help to change what feels like the course of the direction of travel is that I guess we to Joshua's point we sort of like treated junior engineers as sort of like cheaper labour for sort of like the lower hanging fruits in software engineering so like all the stuff that Simon was talking about all the like the slightly more boring stuff so we could focus the expert engineers on the really really important stuff we'd hire a bunch of junior engineers to fill those gaps so the expert engineer could like do much less of that kind of stuff.

59:11I think the way to encourage junior engineers into engineering over time and future is to probably change the expectations that we have of junior engineers and actually expect much more of them, not because, you know, not to turn them into like immediately senior engineers, but I think that the work that currently senior engineers are kind of focused on is sort of producing the same levels or the same amounts of outcome or output for like the tools they have if a junior engineer comes into a workplace already being like highly literate in ai tooling and ai systems and like building uh building outcomes good outcomes with ai we can have slightly different expectations of them that they can actually have like um you know uh they could actually have like really high ambition which like 10 years ago in engineering i didn't have high ambition to go change the like direction of a company but i think that's the kind of things that you could push junior engineers towards yeah but let's let's pretend that that doesn't happen let's pretend that the the like the pipeline dies you know dries up and there's and there's and there's nothing then i think that the only direction that we have is towards attempting to uh to i guess be a little more hands-off uh with code but i think that that's not going to produce good outcomes so i i i don't know how to answer that uh that fork in the in the question yeah i don't think anybody's got a a welcome answer i mean i've come down the pretty much on the doomer side of things um simply because i just don't see like the only scenario where i see this not not being the case is if you have an owner managed business where there's a like a literally an a no exit vision for from the the management um you know someone who basically loves his business never going to sell it.

1:01:03He's not beholden to shareholders, doesn't really care if he has an off year, never mind an off quarter. Yeah, that person might be able to grow an apprenticeship and have a pipeline companies through. But if you're a PLC and you've got answers to shareholders that demand their return, you're going to make aggressive decisions in the near term. And that ultimately means chopping into payroll everywhere you can. And the easiest place to chop it is at this entry level. Okay, let's move on to skills fade. So there is this idea, skills, you learn them, you get better at them. And the more you do them, you also get worse at them.

1:01:42And you actually can lose skills. I know this for a fact, because I used to be a good footballer. These days, I can't because I haven't kicked the ball in 15 years. I'm terrible now, absolutely terrible. Even though my memory of being able to play the game at one point is still there. I know if I took the field today, I'd be an embarrassment. So I've lost my skills, skills fade. The same thing happens intellectually cognitive skills, right? So all of those skills that you guys developed the last 15 years pre-AI, you're no longer using them in the same level. There will be a point where there is skills fade.

1:02:18What do we do? Do we let it go and build new skills? Or do we find a way to practice It's almost that, you know, get back to your school, almost like martial arts, where you've got to keep practicing the kata, right? Because you've got to develop and keep that muscle memory fresh. What's your take on this, Josh Hoffman? Yeah, number two, for sure. The trick is figuring out which skills are valuable to maintain and which to let go. But absolutely, you've got to go to the mental gym or whatever you want to call it. But, you know, I find myself sometimes sitting down and just a quick question about something.

1:02:57I could look in the man page or, you know, I could ask Claude, which one am I going to do? And I try to read the man page, even though I'm just tempted to ask Claude because I want to make sure I don't lose that skill. And I think it's just that. This is where you've got to be very mindful. Yeah, really important. I'm not sure whether, again, this is something we could negotiate internally. There's a friend of mine called John Blastelike. He calls it intentional inefficiency. And it's the idea of, look, yes, you can optimally do something like this, but sometimes it's good to actually go through the step-by-step.

1:03:32Firstly, it's a retraining to make sure you understand the fundamentals, and then you can accelerate again. So it's almost like you go through that mental rhythm. I don't know whether the Brits might know this or the English guys might know this. Johnny Wilkinson, back in the day, great rugby player, always had this mental rhythm. He knocked the sort of how many rugby balls did he kick through the goalposts, but he had the same routine every single time, even to the point where it became a little bit weird. Like, why is he doing this sort of a ritual, it seemed like, but he was getting into that mental zone and making sure the skills don't fade.

1:04:07Do you have time to do that, Andrew? like in a corporate environment you say hey listen sorry boss I'm switching off AI for a week I'm going to get back to just pounding this out I need to get back to some coding sorry do I get time? I don't think I get time I try to afford time to engineers at Monzo but I don't think personally I afford myself that same time but I think that like the I think I agree with Josh that it's important to hone the right skills. But I think that there's an element to which you don't want to hone those right skills so that you can repeatedly just use them at work or just use them even in a project outside of work.

1:04:52But you want to repeatedly use them so you can kind of maintain the instincts that you want to be able to lean on when you're working with AI and working with people and other things. That's the most important thing. um i think skills and like maintaining skills is the the mechanic the instinct is the important bit at the end yeah super interesting um sy hammond what's your take on this uh skills are you thinking about it in terms of like you did bullet point them out to say these are the skills that i have these are skills i want to keep these are the skills i'm prepared to let go it doesn't work like that does it i mean we just do our job and then you know we find out we can't do certain things anymore it's like oh my god i can't do this anymore yeah with the skills i think it's important to work out what what are the skills that we're thinking of losing and we're thinking of you know picking up i think that the set of skills that are required does change and i think that reaches back to the you know what do we do with junior engineers what are their skills as andrew was saying you know just saying okay all your first week's work is to like create a login page or something doesn't cut it anymore you know in first morning's work could be to pop up an entire app so the ambition can be a lot a lot greater but then building at that higher scale requires different skills it's not just you know learning syntax whatever it's thinking about you know how is this like to be used in future where what are the failure modes stuff like that so i think maybe the skills tilt more towards being like a system designer more than just a you know a coder um so you think you're kind of thinking and working at a higher level, a bit closer to the actual domain.

1:06:32And the, what was the other thing? The point about, yeah, I think that's it really. It's just the set of skills changes. Yeah, to actually keep the skills sharp. So I think it's possible to, it is possible to switch off a little bit and to say, okay, it's just going to, we can let the AI just make the decision, split the coin or whatever. I think you've got to have a little bit of curiosity about, OK, I'm making a decision, I'm going along with this, but why am I making it? So going down a level a bit more, kind of getting a bit more grounded and keeping that curiosity just so that you have the confidence about any decisions you make or any direction you take it.

1:07:14So the skill is maybe being more questioning, being more curiosity driven, being more critical, critical thinking. It never really goes out of fashion, I think. yeah really really good okay i we're really over time but i want to end with a final question which i think is is something that's important to deal with it's actually three questions really um so everyone's going to try and give this a go um number one um what do you miss about the old way of working is there anything that you're no longer doing as a result of the change of your job that you think you know what i really love just zoning out and doing that part of it for me it was looking at a database.

1:07:51It was sourcing. It was like going through that, you know, sourcing, spend hours looking at candidates. It was like, it didn't, it was low cognitive effort, but it was relaxing in a way. And I miss that because that's literally pointless now. Like, there's no excuse to do that anymore. It's a waste of time. So number one, what do you miss about the job that is no longer there? And because of AI. Number two, what is it you're doing now that you weren't able to do before that you really enjoy? And then number three, sort of what is the, what's your recommendation for an engineer right now today?

1:08:34No, actually, no, the number three is not recommendation. Number three is the identity. How are you dealing with a potential identity shift? You know, if you're no longer coding, a lot of people called themselves coders once upon a time um a programming analyst programmer was once literally the job um how are we dealing with sort of the identity shifts the labeling has changed the job has changed um how do you manage that potentially psychologically difficult so three three things really okay andrew lawson what do you miss about how it used to be the thing that i miss the most is the um uh well i don't think i'd ever call myself an expert a programmer or engineer or whatever i think that like finding the the like what feels like uh the the like the most concise specific way to solve a really complex problem and you're like you can like you can see it in the code and like only really code can really like express it in the way that you need to express it that was like there are only really a few moments where like you get something that looks like that and you're like yeah this is this is like this this took a lot of like brain gymnastics to get to this point this is it i really missed that and that was a huge like massive spike of serotonin wasn't it was like oh my god and dolphin should i say it was like amazing achievement it reminds me of what the mathematicians are saying today i don't know whether you're following the maths chat on on x uh but they're devastated half of them are like oh my goodness like i really enjoyed really thinking hard uh but now ai is just solving all these things it's like i'll never get the joy of break those breakthroughs again so yeah very very good okay josh go to you what do you miss about the job that isn't uh that you're not doing anymore yeah i suppose it's similar you know like andrew was saying when you when you for me it's something so beautiful simple and elegant but yet it took you months of thinking to get to it and and it's something you could be super proud of i think there's opportunities are still there but they're a lot smaller and they're de-emphasized right um but yeah that that kind of being able to become one with a problem until you just birth an amazingly elegant solution is probably something that's not going to be as common no i i love the the language there uh josh and it is it is a spiritual moment i mean there are moments where you're in that state where you've just like you're your soul is in there.

1:11:01And yeah, we may not get those opportunities anymore. And Simon, I think you probably say the same thing. So let's move on to the next question, which is sort of what is it that you're doing now that gives you joy that you didn't have before? So Simon, let's go with you on that. Yeah, so I think it's the process of just being able to have an idea and then see, okay, what's the general shape of this idea look like? How viable is this before I even start, you know, getting my hands dirty and really digging into it? So just to kind of go from something that's an idea to something that you can kind of poke and play and maybe start manually extending or whatever, that reducing that distance feels like just a major boost.

1:11:44You can just be much more creativity. You can, you know, manifest a lot of things that may just exist as a bulletin a text file somewhere so you can like a lot of one day someday projects can be something that actually materialize and you can actually test the viability maybe discover the flaws of them or the viability of them in the time it takes to you know drink a cup of coffee yeah how many how many great ideas were never pursued for the the theory that it would take too much time to get through it it wasn't worth the squeeze to do i've got to leave it and you never picked it up but now you can explore those ideas because the juice is easier to squeeze very good um andrew your thoughts on that you've got a sort of things that you really enjoy about the work now yeah i think that um so there's uh i guess i've had a bit of a shift over my time in software engineering from like a really deep in the weeds of code to really focusing on um i guess producing outcomes using code um and i think that now i get to uh well i get to do that with a lot of people but in a way where i can express that we can get to really good outcomes by still making some trade-offs but not having to make quite as heavy trade-offs as we had to make before to get good outcomes much sooner so it's less about exactly you know ai speeds up the writing of code but it It just means that I can have a conversation with a group of engineers about producing an outcome and making some trade-offs where we know we can just come back and revisit those trade-offs quite quickly and quite soon.

1:13:19Whereas before, we might have to go, we can make some trade-offs and cut some corners, but we might only be able to revisit that in 12 months' time or three months' time. I can revisit that next week. That's the thing that I'm really enjoying. Yeah, almost the reversibility of decisions, right? This is why architecturally before it was so difficult to do because you'd pay someone a lot of money to make the right call. But now actually maybe that decision making isn't so important because it's much more easy to retreat and redo again because the software production is cheaper. Okay, very, very good.

1:13:50Josh, your thoughts on this stuff that you're enjoying about life in 2026? Yeah, I think Simon brought it up first. Not having to write the boring parts is huge and awesome. that you can work on the parts you find interesting and have the LLM, the agent, work on the boilerplate boring stuff. But also it has really opened up as an experienced software engineer what you can do in the sense of you can try a new language instantly because you have a coding partner that is fluent in this language. You can try a framework or a library or something that you previously might have set aside a weekend just to learn that library.

1:14:23Now in that weekend, you built something out of it and have a functional whatever. You know, it's just speeds you up so much more, even if you still want your hands dirty in the code. Also, like Simon said, hey, give me a template that I can now build on. You know, whereas that might have taken me, I don't know, a whole Sunday takes five minutes and now I'm building on it. And this kind of, you know, having this at your fingertips is amazing. Yeah, fantastic stuff. OK, we're out of time, folks. I want to do with the identity question, but we don't want to bleed any more anyone's time here that we have.

1:14:56Brilliant conversation, folks. Really, really enjoyed it. And thank you guys for coming on and sharing your thoughts. Andrew Lawson, great to see you again. I'll be back in London, by the way, on Saturday. So we've got a couple of weeks left. Let's catch up for Greg's Sausage Roll down in Dalston. Simon Hammond, great to see you, mate. I might need to get you. You might need to come around and feed the turtle, by the way. I'll see you, mate. And Josh, great to see you, mate. Hopefully we'll find the time to catch up. I don't know when I'm next going to be in in Amsterdam, but hopefully it won't be too much longer.

1:15:32OK, that's it. Thanks for watching, everyone. Hope you enjoyed it. Let me know in the comments what other profession you want me to talk about next. The idea is the same. We're going to get a bunch of people on screen. But let me ask the panelists right now. One occupation that you'd love to see repeat this formula. What would that be, guys? Andrew? Legal. I would love to see legal on this. A lawyer? Yeah. Let's just get some lawyers on. Okay. How about you, Simon? Who do you reckon? I would have said legal, but second guess would have been medical. Medical people. Yeah. I love this. There's some GPs on.

1:16:04Why not? Josh? I think adjacent to legal, I'd love to see compliance. Yeah. Okay. Great. Let's do that, folks. DM me if you've got an idea of an occupation you want to do on this show. I think it's fascinating because we've got a much deeper dive than we otherwise would. And as recruiters, we need to care about it because we need to understand the shape, how the shape of these jobs are changing as if we want to recruit effectively for it. Okay, that's it, everyone. Thanks for watching. We'll let you go now. We're back next week with a double header, by the way, two shows. We're going to be talking about next generation background screening and why it's all about identity, behavior, and personalization.

1:16:46We've got Ben Moniz of Fama coming to join us for a one-to-one on that. And we also have a wonderful show on how to use Claude for talent acquisition, where we have people who are in the recruitment space that have dived deep into Claude to produce innovations that apply directly to TA. So follow the channel if you're interested in those two shows. If you're watching this on LinkedIn, follow my page there, basically a live stream, both of those things on LinkedIn. Okay, that's about it. Have a good weekend, everyone. Have a good one. Cheers, guys.