Why Developers Who Only Code Will Struggle In 2026

Think code that ships faster, reviews itself, and arrives with tests baked in and humans who write fewer lines while making more decisions. 

That’s the shift we unpack with CTO and software architect Stephen Houston, CTO TeamFeePay, who moved from healthy sceptic to AI-native practitioner and now runs an end-to-end workflow where models generate features, independent AIs review against the ticket, and a third engine composes tests to probe real behaviour.

TLDR:

• AI as leverage across the software lifecycle
• Enduring value of architecture, design patterns, and clear requirements
• Why pure coding roles shrink and product skills grow
• Levelling of junior and senior lines through supervised AI
• Practical AI workflow with Jira, codegen, reviews, and testing
• Common pitfalls, overconfidence, and guardrails for quality
• Leadership actions for CTOs in small and medium teams
• Mindset shift from fear to measured adoption

We dig into what actually changes and what never should. The timeless pillars still stand: clear requirements, sound architecture, and deliberate design. The reframe is where engineers spend their time. Instead of inferring missing specs and grinding boilerplate, top performers write machine-readable acceptance criteria, think through edge cases, and supervise multiple AI agents in parallel. 

Juniors with strong fundamentals can now punch above their weight, while seniors extend their reach by orchestrating, validating, and aligning work with product goals. The real skill is judgement: knowing when an answer is plausible but wrong, catching shortcuts like hard-coded outputs, and encoding lessons into prompts so the whole team compounds.

We also get honest about risk and reward. Some developers will be replaced—mainly those who only type and never think in systems or business value. The rest can treat AI like a tireless junior: fast, eager, sometimes wrong, always improving with guidance. 

Stephen outlines practical steps for leaders: integrate LLMs with your issue tracker and repo, define prompting standards, remove policy bottlenecks, and measure throughput and defects before and after. Start asking “why can’t an AI do this step?” and automate ruthlessly so humans focus on design, decisions, and outcomes.

Ready to move up the stack and future-proof your craft?

Listen, subscribe, and leave a review with the one habit you’ll change this week. Then share this with a teammate who needs a nudge from fear to practice.

Chapters

• 0:00 Setting The Stage: AI In 2026
• 1:51 Stephen’s Background And Healthy Skepticism
• 3:31 What AI Really Changes For Developers
• 6:01 Enduring Engineering Principles Still Matter
• 10:38 2026 Skills: Move Up The Stack
• 13:20 Juniors, Seniors, And A Levelled Field
• 16:24 A Fully AI-Embedded Dev Lifecycle
• 20:15 Teams That Win With AI Vs Toy Use
• 23:18 Fears, Misconceptions, And Overconfidence
• 27:05 Growth Mindset And Leadership For CTOs
• 31:20 Practical Advice: Don’t Be Afraid

Transcript

Kieran Gilmurray: 0:03

Hi everyone, I'm Kieran Gilmury, and today we're going to talk about the future of software development and testing in 2026. By this I mean AI vibe coding and high velocity engineering. Today's guest, Stephen Houston, CTO software architect, MD, and enterprise API IoT expert, really truly is an expert in this space. So, Stephen, uh, would you mind introducing yourself to some of the audience who don't know who you are? And then let's jump into some of the hottest questions that we've got today to try and make a bit of sense of this whole software development vibe coding AI space.

Stephen Houston: 0:38

Sure. Um thanks very much, Kieran. Uh so I'm Stephen Houston. I'm the CTO of TeamFeePay, been with Team VP now since the very start, I'm one of the founders of our company. Uh previously, I've worked in the blockchain space, I've worked in the IoT space, and I would describe myself as probably the ultimate skeptic when it comes to all new technology. I really want to see how it can be used and is used before we really jump straight into it. So with AI, I was somebody who's dead in the background, watched it evolve, was very skeptical would really make anything of it. And now, now that I've seen what it can do, really uh excited by what the opportunities that it brings.

Kieran Gilmurray: 1:15

Yeah, I suppose it there is a healthy skepticism that we do, Nean Stephen. Otherwise, the amount of money that you and I have probably seen over the decades wasted on technology, and I use the phrase comically, you know, was I going to put a $4,000 headset on my head that weighed the same amount as a small dog that showed me cartoon body? So again, part of this could just be the tech, part of it could be the time to actually jump on board and knowing that's tough. But when you look at the software world right now, what is the biggest shifts that you're seeing that engineers are maybe not prepared for?

Stephen Houston: 1:51

Right. And I think it is the change that AI will bring. You know, they we've had a lot of people thinking about what AI can do. It's gonna replace you having to physically type stuff in the computer, which of course it can do much faster. I'm pretty good at typing, it's quicker than I am. Um, but really they're not prepared for the scope of the change that it's gonna bring once it actually becomes more powerful. So every model that we get now, you can see the increases in the performance of the models, how much better they are at coding, how much bigger the context windows are, and just generally to use the phrase, how much smarter they are at understanding realistically what somebody is asking for and what they what can be achieved. I think now a lot of developers, you know, they they've used early models, they've maybe used corporate models that are heavily restricted, maybe not used AI at all, they wouldn't be highly skeptical of it, or maybe fearful of what it can mean and fearful for their jobs. Um, but you know, you need to look at this, you need to embrace what's coming and actually see what the big changes are. So I think developers these days, they're just not really prepared for AI and everything that it can do.

Kieran Gilmurray: 2:56

I wonder if it's they're not prepared or their business is not preparing them, or is it a mixture of both? You know, it because it it it you know, the I remember working in a in a cybersecurity company in the non-too distant past, and their actual version of their back-end operating system was about four or five years old, you know, and and I really felt sorry for the developers because that's what they had to compete with, you know. So it wasn't, by the way, just uh upgrade issues in terms of it was insecure, they just weren't keeping up to date as a company, you know, so kind of odd. You but you've built scalable systems across enterprises and IoT and blockchain and fast-moving startups. Have the principles stayed true over the years when it comes to the the you know the the standards behind software, software development, everything else?

Stephen Houston: 3:44

Oh, absolutely. I mean, the principles of software development, software engineering uh have never really changed. You know, good architecture, good designs, following design patterns, thinking through what it is you're actually going to do before you actually do it, they haven't changed. I mean, my software design pattern book, I think is now over 40 years old. The patterns are still the same, they're still valid today. There, you know, there are no real new patterns coming out. It's still the same stuff. You know, the if you look at how the JPL built software for uh for rockets, they were designed mostly on paper before somebody had that job of typing the code in. This was seen as the as the little bit of programming that you did at the end, but all the work was actually in thinking through how it was going to behave, you know, having the requirements up front, thinking through the system behavior, doing the design, doing the architecture, working through how the code is going to behave, thinking through all the edge cases, and then small bit was typing it in at the end. You know, that and that's why rockets like it actually work. Uh so these principles haven't changed. You need to think about what it is you're doing, understand the business requirements clearly before you actually get started, think through all the edge cases because they always trip you up. But like that's that's the same in all domains and will always be the same in all in software development, as far as I can see, um, for the foreseeable future. So, yeah, you need those fundamental understandings of good engineering practices before you start to embrace any AI journey.

Kieran Gilmurray: 5:14

So, if we take that principle, you need to build on solid foundations. Technically, you know, 2024 was the year engineers should have learned how to prompt. You know, we've had paired programming, but now we've got autocomplete, we've now got code suggestions in the background. Like what should they be concentrating on? Uh up, you know, what's the layer above the good standards? What does 2026 actually look like?

Stephen Houston: 5:40

Yeah, I think 2026 is 2026 and beyond is the year where developers who simply code are going to struggle. You know, we when we're interviewing for developers, we always ask about the business domains that they've worked in before. We dig into how much understanding they've had around that, what impacts they've understood, what their products are actually delivering. We look for people that understand the business primarily because and have an interest for software development. Those are the two things we look for. You can teach people how to program, but I can't seem to be able to teach those other skills. People who who have no passion for this thing, they're never going to have a passion for it. You can't instill that passion. But similarly, people who don't want to think bigger than just writing code and they don't want to understand how it you know fits into the business, that's a skill you can't teach either. So those people, those people who are just pure what I would call, you know, developers, you know, people who code, code monkeys was the term we used to use, uh, you know, they're gonna struggle going forward because the computer can do that now. And they can do that really easily. So the people, if you want as a developer to really move forward in 2025, 2026, 2027, she need to go higher up the stack and actually be thinking more about the business. You actually need to take on some of that product ownership role, understand the requirements, the customer needs, you know, be able to understand and write product requirements, detailed uh use cases, detailed acceptance criteria, think through all that kind of concepts and so on beforehand, because then you're just basically now feeding that into an AI engine that's taking all of that information and generating the code for you. So I think that that to me is where I see you know developers really having to expand their skill sets uh over the coming years.

Kieran Gilmurray: 7:30

So, but is that just when you're describing they're moving up the software stack? Do you where do you see AI playing its part? Like, is it leveling the playing field that junior engineers produce more senior level output? Do senior engineers simply move higher up the stack? How does that all work?

Stephen Houston: 7:47

Yeah, to me it seems it's actually a little bit different, and we're blurring the lines uh around what is now being traditionally a junior, senior uh, and principal engineers, those different levels that we had that you you know sometimes progress through because you had experience, sometimes you progress through because you were just there long enough and you got promoted. But, you know, now I think it is those more rounded developers, the you know, people who are they have the wide variety of experience and have the solid foundation in in design principles and thinking and can spot when an AI produces bad code or spot when it has done something that's went off tangent and not actually implemented the business requirements properly or thought about various edge cases. I think for me that does level the playing field because it allows people who are at more junior level traditionally because they haven't had that experience, long enough experience of writing code, but they maybe have had good principles, good grounding. They understand they can identify what's good code, identify what's bad code, but they also have that understanding of how the business functions and behaves. Those developers they'll be able to perform at a higher level now because the computer can actually go away now and think through, understand complex API documentation, it can understand how various systems interact. And AIs are a little um, you know, the AIs can do a lot of digging, you know, you can put it on a task and it just works away and turns away at things in the background. So that allows those developers to actually do more with less real-world experience because they can actually rely more on the AI, which has that and has built that real world experience. Similarly, for senior developers as well, you know, again, it they need to be thinking more roundly. They need to actually think across the entire business. Because if they don't, effectively those juniors are going to be competing at a higher level now with them. So, you know, it does it does level the playing field, but also allows opportunities for those developers who fully embrace AI, who are actually able to leverage it extensively, make it part of their workflow to excel even further. Because now, where previously you had maybe one or two tasks you were able to work on in parallel. Now you can split that up into a number of different AI agents that you're monitoring, that you're thinking about and controlling. And you know, you could be at half a dozen tasks easily uh in parallel now. So you're actually your throughput is much, much higher. So I think potentially that's where the separation still comes. Junior developers may not be able to manage as many parallel tasks because they just need a little bit more time to think about the outputs. But certainly for the seniors, you would expect to see far more throughput than they would have done before.

Kieran Gilmurray: 10:29

So walk me through then that modern development lifecycle. What does it look like when AI is embedded in every step for your juniors, your seniors, or just your development team in general?

Stephen Houston: 10:41

Yeah. So it starts with really thinking about the requirements in depth and in detail up front. So previously, uh, a lot of um I'd say more agile or believe they're agile companies would operate on the principle of having these uh somewhat incomplete requirements, throw it over to a developer who's worked on this project for a long time and can infer all the missing detail requirements to actually build your working system. That's how companies have operated in the past. They may, you know, think they're being agile, they're just being incomplete. But you need to sit down and think about your requirements up front. Really think about what the good requirements are gonna look like. Make sure you've got it documented, make sure you've got your acceptance criteria done out, and you've got that ticket complete so that you're really now thinking about what's a machine readable format for that. And that machine is your LLM that's gonna take that on board and actually uh and produce your software from it. So, what we do is we write all that up. We've got all our requirements, got our acceptance criteria and so on, and then we feed that through. We set up our instances of Claude code to be able to interact with JIRA and the various other tools that we've got. And we have a lot of detailed system prompts underneath that explain to it, you know, exactly how we write software, what's expected, and so on, how to write tests and whatnot. So, what we actually do is we point um Claude at that JIRA ticket, Claude goes away and actually produces um working software with all the fully tested and documented code and stuff around that as well. And I indeed now automatically raises a uh a GitLab um merge request for us to review. But that's not where it stops. So we have two other tools that we use as well. We have an AI uh code review tool that um goes away and reads all of the uh the code that's been produced, compares it against the original Jira ticket independently using a different model, and then it analyzes the code that's been produced by the first AI to see what's been missed from it, what's good practices, what needs to be improved, and so on. And then we have a third tool that actually generates another independent set of tests against the code that's been generated. So again, it reads the Jira ticket and it reads the code and tries to figure out what tests should be created as a result of that. You get into then a cycle of interactions between these tools. So our code, our code tool, that our review tool will review the code that's produced by the test tool uh to make sure that actually it's validating what's actually being asked for in the Jira ticket as well. So we have all these AI models working together to actually produce a piece of software, uh, which we also independently review as well and run locally to make sure it actually works and behaves as it does. So my role has changed from a lot of typing uh of code to actually now thinking about requirements, typing those up, thinking how that's going to work and so on, and then monitoring the behavior of what these tools are producing underneath. So now I'm working on far more stuff in parallel, as you can imagine, uh, and getting through stuff at a much higher rate. Um so, yes, the modern work stack has changed quite significantly, whereas previously you would have spent a lot of your time writing code. Now you're spending a lot of time doing the more business focused uh aspects of the work.

Kieran Gilmurray: 13:58

Which I suppose what people wanted all along. They didn't necessarily wanted the code, they wanted the output. So, what what skills then make a world-class engineer in 2026 that maybe didn't matter as much uh, you know, two years ago or five years ago?

Stephen Houston: 14:14

Yeah, well, I think the skills to make a world-class engineer probably always stayed the same, just the emphasis was different. Um so curiosity is a big, big skill that's required for software engineering and the ability to try stuff, new stuff, and have an open mind about it. I did say earlier I'm a skeptic, but that's because I've been through so many of these different hype curves. Um, that I always now have a little bit more approach things with more caution than I would have done when I was younger. But these days, you still need to have that curiosity, understand what is going on around you. You want to know what is going on around you, you want to explore that, you want to see how everything fits together, how everything, you know, what you're doing is actually working in the business and transforming the business, helping it achieve its goals. That's a skill that just never goes away, but was was de-emphasized over time because we had so many other layers that, you know, I guess protected the developer from what was going on around them. You had business people, customer support people, and then you know, eventually these information would trickle down to a developer who would simply code. You know, that that's like I said, that those days are gone. So having that ability to be more curious about what's going on, the will to understand, want to learn more is really important. Um, but I think the main skills that are new are obviously you know, understand how these AI tools work uh because they don't all work the same, they don't all work well, you know, and it's having that ability to trial them out, understand what works, be able to craft them and move them around to what you want to do, you know, craft those system prompts in a way that actually allows the code to evolve and being, I guess, less precious about your code. Um, one of the first projects I ever worked on, I was a student, summer placement student, um, with uh a large telecom provider in uh the UK. And we wrote a piece of software um uh that was to be used in call centers. Uh, I spent three months writing my piece of it, was really happy with it, and so on. I bumped into a guy sometime later. I was like, whatever happened, that that um product we wrote, and he goes, Yeah, uh one of the senior execs uh in the company was walking past uh a bus in London and seeing an advert from a competitor that did exactly the same thing as what we did. He walked back into the office and killed the project. And I was like, seriously, all that man, man, years of effort just killed immediately. So I learned then not to be precious about code. It code comes, code goes. It's not meant, it's not a work of stone, it's not a work of art. But a lot of developers treat it like that, and they they're really precious about what it is they've written. It's a mindset that probably needs to go away a little bit. Yes, have pride in what you're doing, but understand that that's not forever. Once it stops serving the needs of what the business um wants, it needs to go away because it's no longer relevant, it's no longer useful. So having that ability to say, yes, I've done the best job I can, it satisfies you what you'd need today. But you know, two months down the line, if you delete it, I'm not gonna get upset about it. You know, that's that's what's needed because these AI tools will will allow that kind of change of pace much more rapidly.

Kieran Gilmurray: 17:29

We're not Leonardo da Vinci when it comes to code, uh uh, although many would assume. So, what then separates the teams who get value from AI teams versus teams who maybe treat AI like toys?

Stephen Houston: 17:42

Yeah, so the ones that treat AI as like toys, they're only playing with it. And again, this could be not just because of the mindset of the developers, it can be the corporate environment that they're in. Because a lot of corporate environments are heavily locked down and the models that you can use are very limited as a result of that. The workflow that you're you know, the places in workflow that you can integrate the AI into are limited as well. So those developers are, you know, um held back from being able to embrace the full potential of it. So to them, they may want to do more, but effectively they're using AI like a toy. They're only playing with it, they're only you know able to put snippets into say, you know, their private version of ChatGPT or whatever and get out a very limited set of results. They're maybe still using just um co-pilot autocomplete, which was okay, straight of the art a couple of years ago, you know. Uh maybe not even these days, the word moves so fast. But now that's that's left behind. The teams that are fully embracing it, they start to think now about what AI can do for them. And actually, when you've achieved really, you know, the full transition, it's really why can't an AI do this? You know, let's start from the principle of why do I have to have a human doing this? Let's get an AI involved in doing this as well. And that allows your humans to actually do more and to you can do more with less less people, and you can actually have a higher level of understanding around what's going on and achieve more things. So those teams that fully embrace it and are actually thinking first, well, why do I have to write this? Why do I have to think about this test? You know, why am I, you know, writing this bill script or thinking about monitoring my environment in this particular way? It's more like, right, why isn't the AI doing that? Which AI can I use for that? Can I use an AI to produce another tool that actually does this? You know, why do I need to do it? Let's get an AI to write a tool to do this for me. Those teams obviously will get a higher throughput, higher velocity, and will get more done. So they will achieve far more than the teams that do not.

Kieran Gilmurray: 19:48

So what about the nervousness of the of developers, though? Because it some of this comes from you know lockdown, some of it comes from fear. What's the the misconceptions you Hear about AI replacing developers? And is there also a danger, Stephen, that developers, when they do embrace AI, sort of have an overconfidence in what it's actually able to do? Or, you know, they they're they take the code suggestions and don't even challenge it because you know it's infallible. What are the misconceptions you're seeing? And are developers going to get replaced by AI? Let's have the honest conversation as a way.

Stephen Houston: 20:28

Yeah, well, let's let's let's start there. Are developers going to be replaced by AI? Um, some, yes. I truly believe that some developers will be replaced by AI because they just don't think bigger. They they're they're the code monkeys we talked about. So they don't be honest.

Kieran Gilmurray: 20:43

In the real world, everybody talks about a coder as if the most precious thing, but just like you have a crappy mechanic, you have crappy coders as well. So if they do get replaced by AI, those ones, fantastic.

Stephen Houston: 20:55

Absolutely. Uh, a lot of people, like I said, you know, we have for people who have a passion for the job, uh, they want to do it because those people they'll want to upskill. They're more like craftsmen, you know, artisans who actually will spend time. If you go back to our like analogy about code being stone, well, if you think of code maybe as stone, they're the master stonemasons or they're the people who will embark on a seven-year journey to actually become a proper stonemason, you know, they're the ones who will constantly want to improve their their craft, but will also embrace where that's going. You know, you're that stone is part of this cathedral, right? So where does it fit in? How does it look? You know, they're looking at the bigger picture all the time. The people who are just there to cut cut the code, cut stone, go home at five o'clock, forget about this, you know, they're the people who probably are most at risk for this because the AI can turn that code out. Um, and those are also the people that aren't thinking about it, going like, well, you know, what is the quality of what the AI is producing? Is there a way I can make it think better, you know, improve what this output's gonna be, and so on. Uh so I think those, those to me, they're the probably the ones that are you know going to be replaced probably relatively soon. And probably, you know, from an industry standpoint, that's probably not a bad thing. You know, those are a bunch of people who, you know, developers are expensive, right? You know, they're reasonably well paid in most companies. So if you can trim some of those off, you know, that allows a company again to do more without without spending as much. So it's sad for the people who uh are caught up in that, but at the same time, you know, maybe this wasn't the right path for them as well. You know, it's it's a tough, it's a tough thing to hear um for people, but um, sometimes it can be the truth. But you are right, people do seem to go on a bit of a journey with AI. Uh they have that immediate you know, initial kind of like skepticism, scariness uh about it. They're afraid of what it can do. It's gonna replace my job, therefore I'm not gonna look at it, I'm not gonna touch it. Then they start to explore it a little bit and they see, yes, wow, we can churn stuff out really, really quickly. Maybe you get some initial wins because probably you're trying it on a little toy hobby project, or you're trying a little bit of functionality it can do easily, maybe a bug or something that's pretty clear and it just spits out an immediate response. So you build up that kind of initial trust in it, and probably a little too much trust. And you have to remember it isn't another person, it isn't thinking as critically as a good engineer will think. And sometimes it'll lie to you. Like we have had times where the AI has literally hard-coded in responses so that it passed the test, and you're going like, yeah, okay. I mean, that's not what we wanted. We wanted it to actually go out, call this service, we wanted it to perform this calculation or whatever, don't just return the result uh and uh and pretend that everything has worked. Um, so you have to obviously watch a lot of what it's doing, and that comes with the experience of it, like any two. You know, the more you use it, the more you understand how it behaves, the more you understand where it can go wrong and how to how to spot those and what you need to change about your development workflow to make sure that you're actually looking out for these issues, able to spot them, identify them, and then more importantly, feed it back into your process and into your persistent prompts so that you can try to prevent this kind of behavior happening again. And again, that's good from a team scaling point, then, because everybody on the team then benefits from those improved prompts. So I think initially developers generally are afraid of it, generally afraid it's going to replace their jobs, try it, get overconfident in it, and then they go through that kind of real world. This is realistically what it can do. It's good at this, it's not good at that. Uh, I read a quote the other day and it was um, you know, that uh the AI was good for the, you know, the writing. The AI was good for writing like 200 lines of boilerplate around the 10 lines of code I actually needed to write.

Kieran Gilmurray: 24:57

That's quite funny. It does go back though, doesn't it, to a large degree, and it doesn't matter the profession, whether you've got a fixed mindset or a growth mindset. You know, the fixed mindset will always be in the past, find the things that don't work, feel threatened by something that could actually help them grow and put them out of the comfort zone. And the growth mindset very much, you know, bring it forward. You know, what can I do to improve? What should CTOs do then? Uh how should they change as to how they lead engineering teams in a in an AI native world, Stephen?

Stephen Houston: 25:30

Yeah, it's a tough one. And as a CTO, it's a question I really struggle with as well, Kieran, is to think about, you know, how does this work across the team? Because I even see in my small team, we have various levels of adoption of AI. Uh, and some people like it, some people hate it, and some people are very much in the middle around it, waiting to see what it can actually do. But I think the key thing is you have to lead. You have to be the guy at the front, particularly in a small company like ours. If you're operating in a big, you know, multinational company with tens of thousands of developers under you, that's probably not my bag. I've never done that, so I can't really speak to how you need to change and think behaviorally. But if you're one of the small to medium companies, you need to lead from the front. You need to be in there showing people, embracing the AI, and actually fully embracing it into your workflow yourself so that you're now able to demonstrate to the team, you know, the benefits it can bring, be able to explain to them where the pitfalls are, and and really guiding them and helping them understand that you know, don't be afraid of this thing. It's like every other tool. You know, it's we weren't afraid of compilers, we haven't been afraid of the IDE, you know. So maybe not be afraid of this thing. Let's try to see how it actually behaves and how we can leverage it because it's it is that growth mindset. As a small and medium business, you need to move fast and you need to move faster than your competitors. So the more you can do, the better you're gonna be, and the more you can address the market. So you need to show as a CTO just what the tools can bring, be able to demonstrate to your team what it can bring, being a you know committed to it, but also being aware of the shortcomings as well, and helping your team along that journey and guiding and mentoring them so that they can actually embrace these tools. And don't be afraid to try, you know, as well. Um, a lot of CTOs again can be a little bit um afraid of what's new. They know what they know, they're maybe caught up on stuff, like a CTO, a small company, will also be involved in in many meetings and stuff beyond just looking after their team. Uh, but you have to dedicate the time to be able to do this so that they can actually help your team and help your business business grow effectively.

Kieran Gilmurray: 27:42

It's funny though, as you're mentioning their ID and compilers. Like I can't imagine going back 20, 30 years. Although at the time you did doubt the compiler, you wondered what was going on, you know, all the usual modes.

unknown: 27:54

Yeah.

Kieran Gilmurray: 27:54

And I wonder if we got into that growth mindset to say, look, give it a go, and then we'll work back from why not? Why should we not use it as opposed to why would we bother using it? If you were to end, Stephen today, if you were to give one or every engineer one piece of advice for 2026, what would it be?

Stephen Houston: 28:11

Yeah, don't be afraid. Uh that would be my single piece of advice. Try these tools, think of them as a companion, something to assist with what you're doing. It's like having like last year I described it as having uh like a junior developer, a really, really eager junior developer working alongside you, doing power programming all the time. And like, you know, we've all worked with junior developers before, we've all been junior developers before. And if you're you know keen, you will turn out a lot of stuff and you'll turn out quickly, and you know, you're learning about what's actually happening and stuff like that. And a lot of times, like a child, you'll run into the wall, you'll fall over, you know, these things happen. And the AI, though, has improved over the over the last years significantly. But you know, you have to treat it as as a per programmer. Think about it that way. Like it is like a tool in your tool belt, like like we talked about the IDE, it's another tool that actually assists what you're doing. It's it's lifting, taking some of that heavy lift away from you to allow you to become more productive. So I'd say start there, think about your output levels, think about your productivity, think about your peers. If your peers are learning AI and you're not, uh you might have a problem going forward. Because, you know, you maybe not, maybe you're one of these well-rounded engineers, maybe you're one of these people who fits well into the business. But if you're there when amongst a group of people who are also like that, and they're able to become more efficient with using these kind of tools, and you're not, well, you know, it's not that you were replaced by an AI, it's you were replaced by somebody who's better at using AI than you are. Um so they're more efficient, and businesses look for efficiency. So don't be afraid, be curious, embrace the new technologies, understand what they can do for you, and try them. That would be my advice.

Kieran Gilmurray: 30:00

Yeah, it's interesting that because the great management guru, Stephen Covey, he gave an example once where he met someone coming across, you know, uh cutting a tree with a saw. And of course, the saw was blunt. And he says, What are you doing? He says, Well, I'm cutting the tree. And he says, Well, your saw is blunt. And and the individual allegedly responded, Yeah, I don't have time to sharpen it. And his advice was always sharpen the saw. And it's it's funny, over the decades that I've been in my career, you know, you you have a choice. Do you want comfort or growth? Both are painful, let's be honest. But one is going to be significantly less painful in the long run than the other. So again, same advice, folks. If you're listening to anything today, it's it's embrace, try it. We're on version, whatever it is, five of ChatGPT, version 10 isn't going to be 10 years' time. And if I'm going to hiring someone, I want someone more productive, more curious, more creative, more inventive. I want someone who will take the tool and produce more. But me as an individual, I don't want to be doing the same stuff that I'm doing in five years' time. I want to throw technology at it to allow me to create even more value. And to your point a moment ago, Stephen, to create more agility within the business. Because the world has never been quicker and it ain't going to get any slower. And therefore, if we can use the all the tools that are available to us, then why not? They're not massive, they're not expensive. Stephen, if people want to find out a little bit more about you and the company, how do they go about doing that?

Stephen Houston: 31:25

Yeah, so you can see our team VP behind us here. So we can go to our website, go to LinkedIn. Uh, we'll probably be hiring again in the new year. So if people want to apply, they should watch out for our jobs and stuff as well. But we just do sports club management software for grassroots football clubs across UK, Ireland, uh, Europe, and beyond now as well. So they're happy to come to our website and find out more about us. And if they need any more information, feel free to reach out to any of us on LinkedIn and we'll be happy to get in touch with them. Fantastic.

Kieran Gilmurray: 31:56

I'll put all of the links to every can to yourself and to the business and everything else in the comments as I post this out. But Stephen, thank you so much today, folks. And if you take anything away from this, you know, if you think you can, you will. If you think you can't, you won't. If you want to grow, you will. If you don't want to grow and stay stuck, you can stay there. But the world of software engineering is moving, AI is having a tremendous impact. You can be part of the movement, or at some stage you can look back and regret; the choice is entirely yours. I do hope you pick the right one. Stephen, until next time, thank you very much, sir. Thank you, Claire.