Edited by Christopher Douce, Friday 2 October 2026 at 11:18
I’m an AI cynic. I’m fatigued by all the hype that implies that that AI will profoundly change everyone’s jobs. There is, of course, the truth that any new technologies always change what people do. With this view in mind, I have little doubt that the latest generation of AI tools will change some of the work that software engineers do. Being a cynical pragmatist, my own view is that there will be evolutionary change within software engineering, rather than a radical revolutionary one.
When it comes to software, it is people who have requirements. It is people that need software to be created or maintained. Whilst machines might be able to help, you need to express what needs to be done in the first place.
One of the key ideas in computing is, of course, abstraction. When your software starts to get too complicated and your problem becomes too hard to solve, you simplify what you’re doing by ‘going up an abstraction level’; you provide a higher level description the problem that you’re trying to solve, which becomes easier to manage. In doing so, you also provide your own vocabulary through which you can talk about software. In some respects, AI tools reflects an attempt to provide an engineer with tools that ‘go up a level’. Does it help us to solve our problems? It is a bit more complicated than that (which, of course, is an understatement). It with all these thoughts in mind that I’m sharing two interesting conference lectures on AI and software engineering.
The topic of AI and software engineering has found its way into TM113 Computing Fundamentals 2, where the slippery notion of ‘vibe coding’ is mentioned, and a recent update to TM354 Software Engineering.
Let’s have a listen to what Kent Beck has to say. Beck wrote a classic text eXtreme Programming explained, and a text all about Test Driven Development.
Kent Beck: Software Engineering in the Age of AI
Here is a link to Kent Beck’s lecture: Software Engineering in the Age of AI. It is possible to watch, and listen to it at double speed, and still follow it relatively easily. Beck compares AI tools that can work with code to Aladdin’s genie. I think it’s an analogy that works. You can ask ‘the genie’ for things, but what you get might not be exactly what you either want or need.
There is an especially interesting point that is made 19 minutes into the talk. Beck presents a helpful representation which depicts the relationship between ‘futures’ (what could be done in the future) and the ‘features’ that a software product is able to support or provide. Your software development might reach a point where there are so many ‘features’ it is no longer possible to make any further changes since everything will start to break. In other words, your software can become brittle. There is a link here to the concept and role of refectoring, which is the restructuring and reforming of software – but what refactoring decisions you make can only be directed by adopting a strategic approach.
Paraphrasing again, Beck also suggests that ‘with AI I can make a complete mess in a week’. Another phrase I noted down was that ‘there is a temptation to let it [AI tools] go straight ahead’. The engineers remain important. Understanding of software should remain the aim.
Beck’s talk is certainly worth a listen (on double speed). I really liked his reflection that examining software should be ‘a learning process, which throws off software as a side effect’.
Matt Pocock: Software Fundamentals Matter More Than Ever
In his talk Software Fundamentals Matter More Than Ever. Matt Pocock mentions the book The Pragmatic Programmer, which describes the concept of software entropy, which is the idea that software tends tend to move towards chaos as it maintained. This is the exact same point that Beck was making with his futures/features graph, but in slightly different terms. This leads to Pocock’s reflection that ‘bad code is the most expensive it’s ever been’. I also noted down the point that ‘AI in a good codebase does well’. The point here is that ‘good code matters’ to software engineers, and also the tools that software engineers may use.
Also reflecting Beck’s comment about the ability to get in a mess in a week, Pocock highlights that the ‘AI gene’ (Beck’s analogy, applied to Pocock’s talk) can produce too much code too quickly. Pocock returns to the ‘Pragmatic Programmer’ where this phenomenon can be thought of ‘outrunning your headlights’; the situation where everything gets too complicated to keep track of.
An important point about testing was made: testing is difficult, i.e what do you test and why? Unit testing enable the creation of feedback loops. The more testable your code, the better your feedback loop is. Reflections were made about the scale and size of modules, and the difference between ‘deep modules’ and ‘shallow modules’. This conception of the character of modules can also be connected with the notion of refactoring, and the making of architectural decisions.
Interestingly, Pocock explicitly references Beck, quoting from eXtreme Programming Explained, sharing the quotation ‘Invest in the design of the system every day’. The software engineer must make decisions on the strategic level, whatever magical AI tool they are using. They must be able to understand the big picture. They are the link between the real world of people and requirements, and the changing tool chains that build the software that solves real-world problems.
Reflections
There are interesting similarities between these talks. Pocock suggests that ‘AI coding tools are overhyped and powerful at the same time. Used well, they're extraordinary. Used badly, they'll bury you in spaghetti code faster than any human team could.’ This was the exactly same point that Beck was making.
Pocock talks about creating a shared language with an AI tool, and the AI ‘thinking’. I always cringe when I hear AI tools being referred to as ‘thinking’. The notion of the ‘shared language’ comes back to the importance of requirements, and abstractions; ideas that enable us to talk about whatever it is that software does for us. All this leads onto the slipperiness of language. Words such as ‘client’ might well be customers, but they also might be other people within a system, or even bits of software that does something for us.
References
Beck, K. (2003) Test-driven development: by example. 1st edition. Addison-Wesley.
Beck, K. and Andres, C. (2005) Extreme programming explained: embrace change. 2nd edition. Addison-Wesley.
Thomas, D. and Hunt, A. (2020) The Pragmatic Programmer: Your Journey to Mastery. Second edition. Pearson Education.
Acknowledgements
Thanks to fellow TM354 module team member (and VLE blogger) Richard Walker who kindly sent me a link to the Matt Pocock talk. Really appreciated!
Software engineering and AI lectures
I’m an AI cynic. I’m fatigued by all the hype that implies that that AI will profoundly change everyone’s jobs. There is, of course, the truth that any new technologies always change what people do. With this view in mind, I have little doubt that the latest generation of AI tools will change some of the work that software engineers do. Being a cynical pragmatist, my own view is that there will be evolutionary change within software engineering, rather than a radical revolutionary one.
When it comes to software, it is people who have requirements. It is people that need software to be created or maintained. Whilst machines might be able to help, you need to express what needs to be done in the first place.
One of the key ideas in computing is, of course, abstraction. When your software starts to get too complicated and your problem becomes too hard to solve, you simplify what you’re doing by ‘going up an abstraction level’; you provide a higher level description the problem that you’re trying to solve, which becomes easier to manage. In doing so, you also provide your own vocabulary through which you can talk about software. In some respects, AI tools reflects an attempt to provide an engineer with tools that ‘go up a level’. Does it help us to solve our problems? It is a bit more complicated than that (which, of course, is an understatement). It with all these thoughts in mind that I’m sharing two interesting conference lectures on AI and software engineering.
The topic of AI and software engineering has found its way into TM113 Computing Fundamentals 2, where the slippery notion of ‘vibe coding’ is mentioned, and a recent update to TM354 Software Engineering.
Let’s have a listen to what Kent Beck has to say. Beck wrote a classic text eXtreme Programming explained, and a text all about Test Driven Development.
Kent Beck: Software Engineering in the Age of AI
Here is a link to Kent Beck’s lecture: Software Engineering in the Age of AI. It is possible to watch, and listen to it at double speed, and still follow it relatively easily. Beck compares AI tools that can work with code to Aladdin’s genie. I think it’s an analogy that works. You can ask ‘the genie’ for things, but what you get might not be exactly what you either want or need.
There is an especially interesting point that is made 19 minutes into the talk. Beck presents a helpful representation which depicts the relationship between ‘futures’ (what could be done in the future) and the ‘features’ that a software product is able to support or provide. Your software development might reach a point where there are so many ‘features’ it is no longer possible to make any further changes since everything will start to break. In other words, your software can become brittle. There is a link here to the concept and role of refectoring, which is the restructuring and reforming of software – but what refactoring decisions you make can only be directed by adopting a strategic approach.
Paraphrasing again, Beck also suggests that ‘with AI I can make a complete mess in a week’. Another phrase I noted down was that ‘there is a temptation to let it [AI tools] go straight ahead’. The engineers remain important. Understanding of software should remain the aim.
Beck’s talk is certainly worth a listen (on double speed). I really liked his reflection that examining software should be ‘a learning process, which throws off software as a side effect’.
Matt Pocock: Software Fundamentals Matter More Than Ever
In his talk Software Fundamentals Matter More Than Ever. Matt Pocock mentions the book The Pragmatic Programmer, which describes the concept of software entropy, which is the idea that software tends tend to move towards chaos as it maintained. This is the exact same point that Beck was making with his futures/features graph, but in slightly different terms. This leads to Pocock’s reflection that ‘bad code is the most expensive it’s ever been’. I also noted down the point that ‘AI in a good codebase does well’. The point here is that ‘good code matters’ to software engineers, and also the tools that software engineers may use.
Also reflecting Beck’s comment about the ability to get in a mess in a week, Pocock highlights that the ‘AI gene’ (Beck’s analogy, applied to Pocock’s talk) can produce too much code too quickly. Pocock returns to the ‘Pragmatic Programmer’ where this phenomenon can be thought of ‘outrunning your headlights’; the situation where everything gets too complicated to keep track of.
An important point about testing was made: testing is difficult, i.e what do you test and why? Unit testing enable the creation of feedback loops. The more testable your code, the better your feedback loop is. Reflections were made about the scale and size of modules, and the difference between ‘deep modules’ and ‘shallow modules’. This conception of the character of modules can also be connected with the notion of refactoring, and the making of architectural decisions.
Interestingly, Pocock explicitly references Beck, quoting from eXtreme Programming Explained, sharing the quotation ‘Invest in the design of the system every day’. The software engineer must make decisions on the strategic level, whatever magical AI tool they are using. They must be able to understand the big picture. They are the link between the real world of people and requirements, and the changing tool chains that build the software that solves real-world problems.
Reflections
There are interesting similarities between these talks. Pocock suggests that ‘AI coding tools are overhyped and powerful at the same time. Used well, they're extraordinary. Used badly, they'll bury you in spaghetti code faster than any human team could.’ This was the exactly same point that Beck was making.
Pocock talks about creating a shared language with an AI tool, and the AI ‘thinking’. I always cringe when I hear AI tools being referred to as ‘thinking’. The notion of the ‘shared language’ comes back to the importance of requirements, and abstractions; ideas that enable us to talk about whatever it is that software does for us. All this leads onto the slipperiness of language. Words such as ‘client’ might well be customers, but they also might be other people within a system, or even bits of software that does something for us.
References
Beck, K. (2003) Test-driven development: by example. 1st edition. Addison-Wesley.
Beck, K. and Andres, C. (2005) Extreme programming explained: embrace change. 2nd edition. Addison-Wesley.
Thomas, D. and Hunt, A. (2020) The Pragmatic Programmer: Your Journey to Mastery. Second edition. Pearson Education.
Acknowledgements
Thanks to fellow TM354 module team member (and VLE blogger) Richard Walker who kindly sent me a link to the Matt Pocock talk. Really appreciated!