Jason Gorman, a software development expert and founder of Codemanship, joins host Giovanni Asproni to explore how best to use AI in software development. They start by considering how established technical practices — test-driven development, modularization, continuous integration, and continuous reviews — become more important, not less, when working with AI assistance. These practices help address several key limitations of LLMs, including keeping context windows as small as possible.
Looking at AI’s impact on team productivity, Jason offers some practical advice for teams to introduce AI tools into their workflows. The episode also explores spec-driven development, agentic programming, and the importance of writing readable, understandable code — even when it’s AI-generated. Finally, Jason and Giovanni look at emerging research into the cognitive downsides of over-reliance on AI, and what developers can do about it.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes
Related Episodes
- SE Radio 711: Scott Hanselman on AI-Assisted Development Tools
- SE Radio 710: Marc Brooker on Spec-Driven AI Dev
- SE Radio 705: Murat Erder and Eoin Woods on Continuous Architecture
- SE Radio 633: Itamar Friedman on Automated Testing with Generative AI
- SE Radio 615: Kent Beck on “Tidy First?”
Related Resources
- The AI-Ready Software Developer – Index
- CRESS Principles for Context Engineering
- Book: Process Over Magic: Beyond Vibe Coding by Uberto Barbini
- What Is Agentic Coding?
- Specification-Driven Development (SDD)
- Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl
- Ralph Loops
- Kent Beck Canon Test Driven Development
- Book: “Test-Driven Development: By Example”, Kent Beck
- Modularity
- Gas Town
- Dora Metrics
- Article: Super-intelligence or Superstition? Exploring Psychological Factors Influencing Belief in AI Predictions about Personal Behavior
- Stack Overflow
- Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task
- AI Tools in Society: Impacts on Cognitive Offloading and the Future of Critical Thinking
- How Does Naming Affect LLMs on Code Analysis Tasks?
Transcript
Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.
Giovanni Asproni 00:00:18 Welcome to Software Engineering Radio. I’m your host, Giovanni Asproni. Today I will discuss the practices that help in making the use of AI for software development more effective with Jason Gorman. Jason has over 30 years of experience in software development, leadership, and architecture. He’s a longtime advocate of foundational practices like the TDD, refactoring, continuous integration, and many others. And he has spent over 25 years teaching and mentoring teams. After three years of research and data-driven experimentation, he describes himself as an AI realist. Jason, welcome to Software Engineering Radio. Is there anything, I missed that you’d like to add?
Jason Gorman 00:00:57 Pretty much on the nose. Yeah.
Giovanni Asproni 00:00:59 Let’s start with, some context. Now, as I said, you said that you spent three years researching and experimenting with AI to understand its capabilities for software development. Can you tell us more about that?
Jason Gorman 00:01:12 Oh sure. Well, okay, let’s begin at the beginning, shall we? So, I think it was late in 2022 that ChatGPT was launched. So, we’re nearly four years ago now. And I kept one eye on it. And then the amount of press and hoopla about GPT4 when that launched — I think it was around March of the next year, 2023. And one of the things that I was hearing now that I hadn’t heard before is how good it was at generating code, so I thought, well I need to look into this. So, I started initially just doing little experiments very off the cuff: I’ll try this, I’ll try that. And then getting more serious about it and doing closed-loop experiments, particularly as we got into this, in inverted commas, ‘agentic era’ of AI code generation, where you could run the same experiment like 10 times and get a distribution and then change variables, like what happens if I make the modules bigger or smaller?
Jason Gorman 00:02:05 What happens if I include tests? What happens if I take tests out of the prompts? And so on and so forth. But at the same time, following the research, the computer science research, but also a lot of physicists have become very interested in it because it encroaches on an area of physics called statistical mechanics. You’re dealing with these enormous probabilistic unpredictable systems and having a physics background, I was able to read some of the research on that. And so over the years, without looking for theories, just trying stuff out and experimenting with stuff, some things have come into focus. And so, I feel like I’ve got a better handle on it now as to what tends to work with this technology, what tends not to work with this technology, but also a better filter on what is pure hype and what actually has some basis in reality. And I’m really interested in what’s real and what works. So, when I talk about myself being an AI realist, what I mean is I’m just focused on what’s real, what works, what’s economically viable, what’s environmentally viable, and what’s ethical, et cetera.
Giovanni Asproni 00:03:07 What kind of conclusions did you reach if you reach any so far at least?
Jason Gorman 00:03:11 Well, it’s an ongoing story, isn’t it? But I think technology itself as with all things physical, is going to have its limits. And I think we are approaching its limits. I think no matter how much you scale language models, reliability in particular is always going to be a problem. And I don’t think it’s going to get much better. I feel at the moment that they’re probably rough… They may get more powerful and more capable, but I don’t think they’re going to get much more reliable. And I think the problem that we have as software developers is how unreliable they are, how long we can leave them to get on with it before we have to check and we have to intervene. And I think that’s going to be the real speed limit.
Giovanni Asproni 00:03:51 You found some things, some practices or techniques that help in making these AI agents, AI tools a bit more reliable or let’s say more effective when used in software development.
Jason Gorman 00:04:04 I think maybe a bit less unreliable is the word that we are looking for here. So, from a purely practical point of view, there are a number of effects that people have observed with large language models that tend to make the predictions they make more accurate and more reliable. And one of the big ones is the size of the context that they’re working with. So, the amount of information that’s being fed in. Large language models are stateless. They’re like web servers. You’re having to either pass state back and forth, which is how we work with GPT-5 or Claude, Opus or whatever. They have no memory of our conversation in the same way that a web server doesn’t. That memory has to be managed and retrieved somehow. And the longer the conversation goes over, the more information we feed in, the worse they tend to perform in terms of reliability.
Jason Gorman 00:04:50 So there are all kinds of effects that kick in. One big one is what they call attention dilution. So, the way that language model works is the context. They have to calculate what’s called a tension between pretty much every token in the context, a statistical relationship between every token. Now that’s a thousand tokens, then that’s a million calculations and a million probabilities that come out the other end. If it’s a hundred thousand tokens, then that’s a massive calculation and all these probabilities ultimately have to add up to one. That’s the way the probability works. And so, the more token attentions you’re having to calculate, the smaller and smaller and smaller the probabilities get until they become insignificant, at which point nuance, detail, that kind of stuff just gets completely lost. So, they don’t perform very well with large… No matter what the vendors say is the maximum token window, the reality is — there are some very good studies that back this up, that found this — the reality is the effective maximum token limit is orders of magnitude smaller. The point at which accuracy and reliability starts dropping off a cliff is in the order of hundreds to maybe the low thousands of tokens, maybe a hundred to a thousand. When they say, oh, we can go to 400,000 tokens or even a million tokens… Yeah, but you’re not going to get a lot of extra percents out of the model at that kind of scale.
Giovanni Asproni 00:06:17 And so, I guess one of the things we need to do is to use these models in such a way that we somehow minimize the context. How do we do that? What kind of techniques do we use to do that?
Jason Gorman 00:06:30 The ways that we broke problems down in Agile software development, for example, they’re not just compatible with AI assisted and agentic software development. They’re kind of essential. You solve one problem at a time. And when it comes to managing context or what they call context engineering, the context should only contain the information needed to solve that problem. We’re doing test driven development for example, and we’ve agreed a bunch of tests about an online shopping cart. So, we’ve agreed some scenarios, some slices into the behavior of the system. And the first slice we want to tackle is adding items to the cart. We might set up a context for writing a test that fails to add one item to the car. That would be the context. And then when we’ve seen that test fail, we might flush that context and say, okay, now we want the model to write the simplest code that will pass that test.
Jason Gorman 00:07:25 That’s a brand-new task. And a brand-new context. Writing failing tests, writing code to pass tests are not the same thing. So, you’re going through these very short steps where you’re constructing the smallest, most specific context possible to execute the current task, the current step in the process, in the workflow. And then when it’s successfully completed that task, we go with a new context. We say, what do we need to know? What does the model need to know in order to write the code to pass the test? Well, it needs to see the code for the test of course, and it needs to see some existing code that is relevant if there’s classes or functions that are related to this that are going to be involved. But it doesn’t need to know any more than that. It needs to know the task. And very importantly, it needs to know the test, which is what we are aiming to achieve here?
Jason Gorman 00:08:15 And I think people are discovering, and this is something I discovered quite a long time ago, large language models for two reasons, I think perform much better when you give them tests, you say, this is all we need to do and here’s the test or the example that it needs to satisfy. And there are two good reasons for that. One is that’s how they’re trained now. They don’t just give you a code snippet from wherever it’s come from GitHub or Stack Overflow. They will tend to pair them with examples or tests of how that code will be used. So, you can get a much better match when they’re pattern matching. But also, I think more recently in the last year or so, they’re actually using test execution to train the models. So, here’s the example. You complete the example, please, let’s run the test. Let’s see if the test passed.
Jason Gorman 00:09:00 No, it fails. Let’s feed that back. So, reinforcement learning has evolved. I think for that reason. It’s not at all surprising that they work well with tests. But also, if you are working with agentic coding where it might take multiple passes at it, having a test gives it something to converge on without the test. It just goes round and round in circles. But if you give it a very clear success criteria, very clear exit criteria, the completion rates that I found with closed loop experiments are significantly higher, a lot higher, never a hundred percent, but they’re pretty good. But the main thing about context is once it’s achieved its goal, it’s written the test, you’ve seen the test fail, okay, flush the context. Now here’s a new task that needs a new context that’s only related to that task. And so, I started to break it down into these short steps, these micro steps that have every single one of which have some kind of explicit exit criteria. And once it exits, we flush the context and we construct a new context specifically to the next task.
Giovanni Asproni 00:10:07 Okay, and how do we compose these, creating all these contexts. And so, coming up with a design of the system that makes some sort of engineering sense.
Jason Gorman 00:10:16 That’s a very good question. So, I went through a journey over the last year or so where I started controlling everything with me. So, I was the agent, okay, do this, let’s look at the results. Okay, not happy, right? Let’s fix that. And gradually got more ambitious. So, have you heard of Ralph Loops or Ralph Wiggum Loops? This is an idea based on the character and the symptoms who’s always dying, always in terrible danger. And the idea is that you give the agent a goal and it throws the dice once. And if the number you want doesn’t come up, you clear the deck, you say, let’s clear the context, let’s reset the code and try again. So, you throw the dice again and you throw the dice again and you throw the dice again. Most Ralph Wiggum Loops have a sort of a maximum number of tries.
Jason Gorman 00:11:03 I’ve seen people doing 5, 10, 3, whatever. And so, I got into Ralph Wiggum Loops, which became popular and that’s a single process basically. So, the agent is just a loop that goes round and round and round. And I had some success with that, but I found that there are times when you’re asking the Ralph Loop to throw 13 and it just can’t do it. I call them doom loops. It just goes round and round and round and it can’t do it. The problem it’s trying to solve is out of its training data distribution. And sometimes you can solve that by dropping a gear and saying, okay, let’s go back into planning mode and break the problem down into if you can’t throw 13, try throwing a six and a seven. They’re more probable. But that doesn’t always work. Sometimes you have to step in and go, okay, this problem has just been out of the model’s distribution, it’s not been trained on this.
Jason Gorman 00:11:56 You can see this with diffusion models, the text to image models where you ask at things like, can you generate an image please of a wine glass full to the brim and they just can’t do it. And there are all kinds of examples because it’s not in the training data distribution that language models just can’t do no matter how many passes you give them. So, you have to be ready to intervene, you have to watch it like a hawk and go, okay, it’s thrashing here, it’s in a doom loop. So, I need to intervene. The goal, I think of what we might call long horizon, fully autonomous agentic coding that we give it a set of requirements and then we go to the beach, I think is complete fantasy. I’ve seen nobody succeeding. I’ve seen people succeeding at having agents run for hours. What I haven’t seen yet is anyone succeeds at having them do that and produce something that actually works at the end.
Giovanni Asproni 00:12:47 So it’s more context. A TDD will give a help the model, create a test, then flush the context, create the code that solves the test. So basically, trying to keep the context always small. Then we need to grow this thing. How do we work? Do we create one module at a time, even on our modular system?
Jason Gorman 00:13:03 We do it the way that we’ve always done it, which is there are two sides of this. One is the map and one is the terrain. This is a message that I found really difficult to get across because test driven development and refactoring and continuous integration, they’re very much putting one foot in front of the other. And I think maybe the message we’re not getting across is you do have to look where you’re going and you have to have at a high level some kind of root plan that there are times when you’re not sure take a step back and just maybe do a little sketch or write it down on paper or whatever. This is the general road map I think. Now,I mean Kent Beck recently published a blog post about what he’s calling Canonical Test- Driven Developments. And in Canon Test-Driven Development, there are such things as test lists, which I’ve talked about in his, I’ve got it right here just in case.
Jason Gorman 00:13:49 In his book on TDD, he talks about test lists that you’re not going into this cold, you’ve actually thought about the problem that you’re facing and you make a little list, just a high level sketch, remembering, of course the map is not the terrain and that gives you a way to keep your place. Okay, that’s the step we’re doing now, this is the step we’re doing next. Remembering of course that as we go, we’re going to learn and we’re going to adapt and that map is going to change. And so, after the fact we’ve got practices like refactoring, continuous architecture and emergent architecture, that kind of deal let’s visualize what we’ve got, let’s think about it, let’s talk about it. And surprise, surprise, when we’re doing it with AI, it’s exactly the same. But we need to remember that AI, that large language models, let’s be specific super auto complete is not capable of that kind of reasoning.
Jason Gorman 00:14:45 I mean literally not capable of it. Language models, and this is a problem with deep neural networks generally cannot be trained on long range patterns. They cannot be trained on things that are far apart from the bigger picture because those probabilities are so low, so insignificant and large language models are kind of like averaging machines. We see this with model collapse. You take a model’s output and trade another model on it and it just gets dumber. And then you take that models out, put and trade another model on it and it gets even dumber because they tend to produce the most probable response. So, all the nuance and the detail get lost.
Giovanni Asproni 00:15:21 So basically what you’re saying is that in terms of well vision, general direction on what the system shape should be is something that humans are good at and we hear we can use the AI system to actually help with implementation of these things.
Jason Gorman 00:15:37 Absolutely, yeah.
Giovanni Asproni 00:15:37 Maybe we can have the AI if we are exploring architectural ideas with the appropriate models, trained on some architectural patterns or something, we can in general high level, we can use the system to help us, but we cannot really tell the system this is the architecture going and implement it.
Jason Gorman 00:15:55 There is an informational disconnect between we could represent architecture at a higher level, and they’ll be able to match patterns in it. But then the moment you start asking to generate code, you’re in a much deeper level of representation and I don’t see how they could fix that disconnect. I guess. I mean when we talk about AI, I always talk about actual intelligence. You can’t take the actual intelligence, the ability to see the big picture and the ability to actually reason, the ability to learn from very small number of examples, which they just can’t do.
Giovanni Asproni 00:16:27 And so basically whatever we do with the techniques that we use are aimed at keeping this context constrained. Well, there are other aspects as well, but yeah, keeping the context constrained is an important one. So without
Jason Gorman 00:16:39 Absolutely constrained in scope.
Giovanni Asproni 00:16:41 In scope, yeah, this is what I mean.
Jason Gorman 00:16:42 And constrained in time as well. To be as recent as possible.
Giovanni Asproni 00:16:46 And you mentioned Agile, so here are talking about practices that we already use basically. In Agile development with these TDD, very short feedback loops, small steps. And then some things that you mention also in your writings are also continuous refactoring, continuous code review. I guess the continuous code review is important because AI is prone sometimes to generate some questionable quality in code. And so, we need to make sure that things are proper and this also means that we really need to go small because we cannot really review a thousand lines of code at that time easily.
Jason Gorman 00:17:20 Or we can just not very well. Not in a very kind of focused kind of way. This is the other side of it I think is in terms of workflow. So, nobody is questioning whether tools like core code and Codex can produce a lot of code very fast. Nobody’s questioning. That’s definitely true — much faster than humans. The downside of that is that was never the bottleneck in software development. So, if you let them run, they all produce large change sets, large batches of changes that then start hitting these downstream bottlenecks like code review and like testing and like merging as well. And so what we’re seeing, and this is — there’s a big body of evidence being built up on this by CircleCI and by Feros, who do the sort of software development telemetry people, by the DORA folks (the DevOps Research and Assessment people) that shows a very clear picture, which is those initial gains from code being generated faster are being lost downstream to this chaos of things sitting in queues waiting to be reviewed and bugs being discovered, fixes being scheduled, and all this stuff.
Jason Gorman 00:18:26 And on top of which far more problems are leaking into production than before. So, outages and production incidents are up, delays in delivery are up. This is the CircleCI data. And if I say Farro was saying the same thing, which is I think the way Farro put it in their report, starting is easy, finishing is hard and finishing was always hard. And what generative AI has done makes starting even easier and even faster. It’s a fire hose. You’re drinking from a fire hose and when you’re drinking from a fire hose, the limit isn’t the fire hose the limit you? How much could we drink at a time? So, you let the fire hose go in these very short bursts one mouth at a time, the same it always was. And that was always the real speed limit in software development and continues to be how fast could we test code. How fast could we understand code comprehension debt? We’re seeing that building up now with CircleCI’s data there. They’ve been seeing over the last two or three years that the time taken to fix problems in production has been rising. And I think, I suspect a big factor in that is that nobody understands the code anymore. And there’s this gap you have to leap to say before we fix this, we need to understand it.
Giovanni Asproni 00:19:36 That’s an interesting one because sometimes when you, there are some people that say, you know what is generated by AI, we don’t really need to understand it as long as it does the right thing. On the other hand, the problem is that if we don’t understand it, we don’t even know if the code actually does what we want.
Jason Gorman 00:19:51 Probability is a big factor in all of this, which is it’s all an interaction with a large language model is essentially the throw of the dice. And if you calculate the probabilities, maybe eight times out of 10 you get the number you want. That’s good for one interaction. You might go, okay, so if we don’t get it the first time, we throw it again and our probabilities go up. The problem is, and this is where I diverge from a lot of people who are working with this technology or enthusiast of it, the thing that makes me a realist is the chances of what they call sort of long horizon software development where I specify 20 features and go to the pub, the chances of the model getting through all of those features with all of the steps involved without falling over, without taking a wrong turn and the moment it takes a wrong term, you’re now building on top of that.
Jason Gorman 00:20:40 You’re not going in the wrong direction. And I think the chances of that completing successfully are so astronomically remote that I dismiss them out of hand. I think long horizon, fully autonomous, agentic coding is a fantasy and a myth. It’s the pot of gold at the end of the rainbow. But the reality is there is no rainbow. It’s a fools errand. I’m concerned with the reality which is okay, let’s look at the technology as it is now and what it can do now if you’re going to use this stuff, what is the smartest way to use it?
Giovanni Asproni 00:21:09 As you know now there is a lot of talking about people managing agents, maybe tens of them working at the same time and agents that work with each other to solve a problem and apparently people reviewing the code of the agents or agents reviewing each other code. So, you think that this system actually is not that viable after all.
Jason Gorman 00:21:30 I’ve seen nothing that persuades me. Some of the larger scale ones done with Cursor and done with Claude code have indeed run for days and weeks with, as they put it, little human intervention. But they have produced broken software. The web browser that was done using, I think they said like a hundred or more Cursor agents, someone I couldn’t be bothered. Someone used the APR and GitHub to go back through the commit history, the build histories, there were more than 10,000 commits and the thing broken around commit 100, it was probably broken before that and never worked again until humans stepped in and fixed it so that it would at least compile. And the problem with continuous integration and concurrency, you know this very well, is that ultimately no matter how many developers you have working in parallel or seemingly in parallel, ultimately they all have to go through the same garden gate, which is it all has to get onto the release branch.
Giovanni Asproni 00:22:26 Yeah.
Jason Gorman 00:22:27 And there are two ways you can go about this. One is the discipline way, which is to have traffic lights and you wait your turn. So, if a builds in progress, you don’t push on top of that because you might be pushing on top of a broken build or even it’s not a broken build, you might be pushing changes that will conflict. So, you have to wait and you certainly don’t pull changes. So, you can’t synchronize either way until the build succeeded. So, if the bill takes a few minutes, you’re going to end up with every one of those agents lining up in single file. Which I think is what I ended up what I experimented with Claude code with concurrent agents, I ended up quite quickly, it only took me a week to go, okay, that doesn’t work. To go back to okay, I’ll just have a single process. And I ended up going back to Ralph Loops and then from Ralph Loops back to, okay, I’ll control the process myself.
Giovanni Asproni 00:23:16 In that case basically, even if the agents were working, let’s say, the continuous integration would act as the bottleneck.
Jason Gorman 00:23:23 Yeah. It’s like it doesn’t matter how many lanes you add to the motorway that goes to the ferry port in Kent, there’s only one boat and they’re all going to go on the boat one at a time. So, it doesn’t matter how many lines you add.
Giovanni Asproni 00:23:35 And so basically I guess then from what you’re saying that even if we try using some technical practices, like you mentioned before with the TDD continuous testing still is a problem because having say hundreds of agents, they will still have the problem of the bottleneck at the CI level.
Jason Gorman 00:23:52 Yes. And also, the fact that they are individually in parallel changing the code, with their picture of that code, which is diverging from everybody else’s picture. So, you have that as with all things concurrent, the real question is to what extent do they depend on each other and therefore how often do they need to synchronize? And that’s again, it’s nothing new. We still kill the old way, which is okay then small teams and maybe it’s better if the team actually works in a single thread so that we all work together. This is I guess the value proposition of mob programming or teaming, which is maybe it’s better if we bring different expertise to bear at the same time on a single thread of execution rather than trying to have it work in parallel. And I think we’re discovering the same limitation with agentic programming, which is the synchronization problem. The mythical man month always gets us in the end.
Giovanni Asproni 00:24:44 Do you think that actually having agents working on separate modules or something if the modularization is done properly would actually help?
Jason Gorman 00:24:53 Yes. And this is something that I’ve tested and seen, and I think a lot of other people have as well. Separation of concerns, modularity, it’s always been the secret source, but when you speed the whole thing up, it becomes so important, especially when it comes to context management because the blast radius of the changes you’re making has a massive impact on how big the context is going to be. If you can change one source file and that change is contained to that source file, are you going to get a small context if you don’t have that kind of separation of concerns, if changing that file there is going to involve changing all these other files, you’ve got a big context and then you’re going to run into all these problems with big contexts. So yeah, separation of concerns, super-duper important.
Giovanni Asproni 00:25:39 Several people are saying that AI is an amplifier. If you’re good, we’ll help you be maybe a bit better or a lot better, but if you are not so good you’ll actually experience even more trouble. So, what do you think about that and also how much more productive these teams actually become?
Jason Gorman 00:25:57 That’s a very good question. So, I could only go on the data here. So, the DORA folks have found fairly consistently over the last three years that as you say, this technology is an amplifier, that there is a small percentage of teams that were already high performing who appear to experience a sort of a productivity boost. Lead times get shorter; throughput gets higher and it’s not at the expense of the stability of their releases. What we can’t rule out is whether this is a result of the technology or result of what the technology is inflicting on their processes. That it’s a kind of a load test for software development methodology for the way you do software development. That if they were, here’s the thing, if they’re a bottleneck in your process, attaching this code, generating fire hose to your plumbing is going to show up where those bottlenecks are.
Jason Gorman 00:26:50 And I can’t rule out, and I’ve watched teams do this where they’ve said, well we are taking smaller steps now and we’re doing code review more often and so on and so forth. And I feel like maybe this technology is highlighted where they were experiencing those kind of bottlenecks to some small extent and that they’ve addressed them because they’re measuring the outcomes. And I think that’s the important thing. They are measuring things like lead times and they’re seeing the dials go in the wrong direction. They go, right, okay, we need to review code more often. One thing that’s delighted me over the last couple of years is how many teams now who just ignored me on things like mutation testing have suddenly become really interested in mutation testing and really interested in static analysis and speeding up these feedback loops. So, I can’t rule that out.
Jason Gorman 00:27:35 And if that’s the effect that it’s having, if the practical effect is that it’s a stress test for your process as one person put it to me recently, then I don’t think that’s a bad thing. It’s highlighting areas where you are weak. Where it is a bad thing is when they’re not measuring those outcomes. So, they’re not measuring the use that analogy of the fire hose. They’re connecting the fire hose to their hose plumbing; they’re not measuring the pressure of the water coming out of the shower. They’re measuring the pressure of the water coming out of the hose and going, oh, there’s lots more water coming out of the hose now. So that’s greater productivity. So, I see all these teams who are measuring more lines of code, more commits, more pull requests, more features, more throughput, more stuff going into the system and they’re not measuring what’s coming out of the system and the value of it, what it’s worth. And I think those teams are probably blissfully unaware that this technology is making them worse. It’s an interesting irony if you think about it. One of the reasons that they’re probably not high performing in that sort of DORA classification is because they don’t measure those things. They don’t pay attention to those things. And because they don’t pay attention to those things, they’re blissfully unaware that AI is making them worse.
Giovanni Asproni 00:28:44 Yeah. Because they’re measuring what they can measure easily at least.
Jason Gorman 00:28:49 Yeah. I see some wonderful posts. I saw one recently where someone said, thanks to Claude code, we’ve gone from, this is a team of developers. The team has gone from, I think it was 50 commits a week to 500.
Giovanni Asproni 00:29:01 And still doesn’t tell you anything about that achievement.
Jason Gorman 00:29:03 It tells you nothing. It just tells they could be that the batch sizes are much small. I suspect that’s not what they don’t they’re actually doing. But it could just say, well, we’re just committing a few small changes at a time.
Giovanni Asproni 00:29:13 Now a question about working in teams, because when you look around, a lot of this AI advice is, seems to be at least aimed at individuals. Code is produced by teams and has to be done by teams. Because you can imagine in a company, if a company has a single person that manages a hundred agents, great, and then this person goes on holiday, what happens or there is a problem, what happens? So there has to be some redundancy there. So as always is to be a team. Now how can we integrate these AI tools in a team environment? Well, what is your take on that?
Jason Gorman 00:29:47 I’ve been using them alone. This is something that I’ve noticed many times that we saw this over this Christmas and New Year. A lot of chief technology officers and heads of engineering went away over the Christmas break and that gave them a bit of time to, well I better take a look at this Claude code thing that everyone’s talking about. And they get the proverbial car up to 200 miles an hour on a straight road with no other traffic around and they come back, I saw this, they came back into the office in January, and they went to their teams and they said, you will use this. This is the way it’s going to be. I was so productive working by yourself with no customers. No team, no other stakeholders, no regulations, no legacy code, no dependence is well done. You, you can get the car up to 200 miles per hour.
Jason Gorman 00:30:33 That’s no one’s denying that these things can generate code really fast. But most software development teams are driving through heavy traffic and living in London. I know for a fact that doesn’t matter how fast your car is, you’re going to be going out best nine miles an hour sort of average speed. A bicycle is faster than a Bugatti. Faster cars do not equal faster traffic. I think that the mistake that so many people have made is that they’ve taken what is a local optimization code generation, writing code. And it’s kind of our fault as an industry as well because we’ve so often equated software development with coding. Whereas in reality, coding is just a small part. Coding is the part where you are driving forwards in the rush hour traffic, but most of your journey is waiting, waiting for input, waiting for feedback, et cetera, et cetera.
Jason Gorman 00:31:24 And we’ve made a terrible mistake. But also remembering that there are other cars on the road that a lot of what we do when we’re driving through cities or towns is trying not to bump into each other that we’re dealing with dependencies and mergers and conflicts and competing concerns. And that’s what takes up all the time. And coding was only ever such a small part of it. I remember when the software craftsmanship movement sort of really took off in 2006, 2007, there was this sudden fascination with everyone typing faster. They were all on the Mavis Beacon typing through the course and we need to write code faster. And I remember saying apart from it being ableist, because I know some fantastic software developers who really get stuff done, but because of certain circumstances can only type for example with two fingers at a time.
Jason Gorman 00:32:12 But at the end of a session they’ve still got just as much if not more dough in real terms. So, I had a problem with it for that, but the main problem I had was typing code was never the bottleneck. It’s never been the bottleneck. Not since we were punching holes in cards. It’s never been a real problem looking things up has never been the bottleneck. Finding out how to call this API or use that library has never really been the bottleneck. The bottleneck has always been the part that does the heavy lifting, the dependencies, the communication, the feedback loops and the big one, the really big lever that that no team wants to pull, which is batch size, try as I might to persuade them, say just take a smaller step, they, but that’s, it feels so slow Jason. It’s slowing me down and get, weirdly we’ve already delivered, it’s already shipped.
Giovanni Asproni 00:32:58 And now we said that basically the teams that are getting the most out of these tools are the teams that are already working a certain way. Yeah. So, we say all the values, small batches you just mentioned. Then we say maybe using TVD, the kind of small steps. So, keeping the context small, short integrations, continuous integration loop. So basically, all the things, the technical practices that using most Agile processes, all the ones that are mostly associated to extreme programming, which for the listeners is one of the most well-known Agile processes and is the one that is probably the most technical one in terms of practices is probably the only one that is still surviving very well. But nobody really talks about it because all the practices that we do nowadays come from it. In a way or another.
Jason Gorman 00:33:43 It’s like extreme programs, modern art and beyond that now it’s become sort of postmodern. It’s part of art but we don’t mention it anymore.
Giovanni Asproni 00:33:51 And now there is a question here because okay, the teams that are doing this, they can get something out of AI. We said that is the DORA report as well. Maybe in the report we see correlation, we don’t know exactly where the causation is from what you said, you know, what is the this make this use of AI, why this AI make things better for those teams. But there is correlation, they use it and seem to be more productive somehow.
Jason Gorman 00:34:16 Yes. For whatever reason.
Giovanni Asproni 00:34:18 For whatever reason. Now the question is, we have a team, they say they’ve never used these technical practices or use them not very proficiently and they decided to use AI to be better. Now what would you suggest to this team?
Jason Gorman 00:34:31 What I would probably do now is say, look, let’s take a look at the evidence and let’s see where you fit in the distribution of teams that the evidence is telling us is likely to produce this kind of result? Is it likely to shrink lead times or make them longer? Is it likely to make your releases more stable or less stable? So, I would suggest for example, going to the DORA website, they have this sort of quick check which is like a little survey you take, which is about things like lead times and release cycles and stuff and just try and establish where you are in that distribution. If you are not very comfortably in the blue towards the high performing and elite end, you need to try and get into the blue before you connect the fire hose to your plumbing.
Jason Gorman 00:35:17 And that should be your priority, which is okay, what kind of teams, for whatever reason, whatever the causal mechanism is are seeing modest boosts in productivity and quality and et cetera. How do we position ourselves there? The bad news for those teams and for those organizations is that’s if you’re starting way further down, if you’re poorly performing or in a band that I’ve invented and I one day hope to persuade the door of folks to include it, which I call catastrophically bad, but you’re not actually delivering anything for months and months. If you’re at that kind of end of the spectrum, the good news is it’s actually quite easy to get into average performing from there. It’s usually just a small change you can make. Like okay, if you’re going to change the code, test it first. Something as simple as that.
Jason Gorman 00:36:06 But the longer journey to get into the blue, you’ll see if you go to the website, there’s like a little color spectrum that goes to red all the way up to a nice lovely blue. If you’re the sort of purple down towards red, you probably shouldn’t, maybe not touch this technology but quarantine it. Say okay, we will to use ChatGPT or we’ll use Claude code, but in a purely advisory role. We’ll use the Chat window, we’ll take a look at the inline completion suggestions, but maybe just don’t let this thing touch the code directly. What I’m not convinced about is that all the magic and all the gold is in understanding the tools. I genuinely believe that most of the value is in the processes and the practices that you use those tools in. I think that’s where the big money is.
Giovanni Asproni 00:36:51 Almost the tools are an excuse to use good practices.
Jason Gorman 00:36:55 Absolutely. I mean if I had to, don’t make me. But if I had to, I’d be quite happy getting back into doing manual refactorings. I’d rather not. I’m quite fond of my automated, I’m quite fond of IntelliJ and rider every sharp on all of those. So, I’d rather not do it, but if I had to, I would get back into that and I don’t think it would have a massive impact on my overall productivity. And I think it’s the same with these tools. I think it’s the same as learning your IDE. I don’t think learning your IDE sort of shortcuts and inside outs makes you massively more productive overall as a software developer in terms of value delivered. But I do think it helps, it removes friction and I think tools like Codex and Claude code and Cursor and Copilot can remove some friction but in return they can also add in quite a lot of friction as well.
Giovanni Asproni 00:37:43 That’s a lot of problem. Now another question about skills. So, there is a lot of talking about the skills we should be hiring for. Now you say now we have AI and so we need to change the skills we look for when we hire people say I think that if I remember correctly, I read also things around AI native developers or things like this. The question is do we really need to look for different skills, additional skills, new skills?
Jason Gorman 00:38:12 Yes and no. I think I can only speak from my personal experience. What I have found useful to understand. Obviously, you need to understand how Claude code or cursor that, how they work compared to IDEs that we’re using these days. Like VS code, IntelliJ, these tools are relatively straightforward. They don’t take a lot of time to learn and compared to all the other stuff you need to know to be an effective software developer, it’s a blink of an eye. They take no time to learn. So, I will as it is with programming languages, it’s the same argument which is okay, if you take a C-Sharp developer and you are interviewing them for a Java role and they’re a really good C-Sharp developer and then you interview, you know a pretty decent Java developer, I’ll take the C-Sharp developer first and say it’ll probably take you a few weeks to get up to speed on Java.
Jason Gorman 00:39:03 Same with any of these tools really there’s nothing there aren’t doing the job. All the other stuff you need to know, including the domain knowledge of its banking or retail or whatever it is, is a mounting compared to the molehill of the tools and the technology usually, unless you’re literally training your networks and then that’s a whole field. But IntelliJ and Visual Studio, these are not fields. You do not need to go away and spend years learning. You can get relatively productive pretty quickly with them. My experience with AI coding assistance and is that they’re in the same, probably even simpler, what can happen I think is people can become sort of deluded into thinking that there is more to these tools than they, than there really is. And that’s when you get into the whole area of prompt engineering and all those kinds of, you know like the, when you go to the junction, the busy junction and you’re pressing the button to crossroad, you know the button’s not doing anything, it has no actual effect.
Jason Gorman 00:39:59 The whole thing’s on, you know, control centrally or whatever. And I think there is an element of that to a lot of this, which is the illusion of control, that there is more to this. That these things are really thinking, they’re really planning that this prompt is going to work better than that prompt. Do you remember at the beginning of all this, you go online and people were selling prompts and selling dice throws. It’s like, what is the point of this? And that’s not to say though that there aren’t principles behind this and there isn’t stuff that is worth understanding. So, I think a grounding in how large language models work at a high level is very useful.
Giovanni Asproni 00:40:33 As you said, you know, having knowledge of the systems can be quite useful. For example, I find it useful. Sometimes technologies you don’t know you want to explore them, you want to try something out occasionally, you know, starting to do some project it gives you, helps you solve the blank page problem when you’re getting started. Yeah. So, there are quite a lot of things that can be useful for, but we need to be careful not to overestimate the capabilities.
Jason Gorman 00:40:58 I think the psychology of it is fascinating. There was a study done that showed a very strong correlation, to let me see if I can find it. I’ve got it in my bookmarks here somewhere. Super intelligence or superstition, exploring psychological factors influencing belief in AI, predictions about personal behavior. And what they discovered is, this is mostly from, the MIT lab and what they discovered is that there was quite striking correlation between confidence in AI output and belief in the paranormal, horoscopes and that all that kind of stuff. Psychology of it is fascinating the way that we anthropomorphize these models. I’ve watched people, I’ve been in pairing sessions with developers where they, I’ve watched them intervening, editing code, changing things, saying, no, that’s wrong. Do this instead and then get to the end of the session and then have them say to me in all with a totally straight face.
Jason Gorman 00:41:53 See Claude did it all, it’s what I call the Clever Hans Effect. You heard of Clever Hans? This was a horse, at the beginning of the 20th century, the horse in Germany that apparently could do arithmetic, read maps and do all sorts of stuff. And so, he told all these fares and the great and the good key (?) to see, Clever Hans and his trainer would say, what is six times nine and Clever Hans would tap it out when it’s off and so on and so forth. People were amazed but there were some skeptics and the skeptics, they organized some experiments and tests and in some of the tests the horse couldn’t see his trainer. He was blinkered and when the horse couldn’t see his trainer, he got all the answers wrong.
Giovanni Asproni 00:42:31 So there must have been something happening in the trainer.
Jason Gorman 00:42:34 The trainer to probably totally unconsciously was somehow signaling visually to the horse what to do. And I’ve seen people do that with LLMs. I’ve seen, I’ve watched them step in fix things, correct things and at the end go see it did it all.
Giovanni Asproni 00:42:49 Do you think about programmers paid and using an AI tool? How do you see that integrated in the process should just be something they use to test ideas, conversations or get the call done. How do you see that working out?
Jason Gorman 00:43:04 Depends really on how they’re doing it. I have found; I continue to find some of the frontier models useful as sort of rubber ducks. If I want to bounce an idea off something and it’s kind of like the wisdom of crowds. It is a statistical approximation of in that particular space what a majority of physicists or software developers or bakers or guitar players might respond with. And I have found it useful for that. I’m well aware of the fact that it’s holding a mirror up to me, partly because it is the wisdom of crowds, but mostly because it has been trained through reinforcement learning to do that. To say yes, you are very clever. That’s a brilliant idea. Um, so I think we are seeing now with sort of AI psychosis how dangerous that can be. I have noticed recently the ChatGPT has started disagreeing with me a little bit. So maybe open AI is starting to respond to this in the training, but it is useful I think to hold your idea up to a mirror and have it reflected back through the kind of wisdom of crowds through that kind of filter. So, I find it useful for that. But that’s not the main role of a pair in true pair programming. If it’s the navigator, I don’t trust it to see the bigger picture? If it’s the driver, I don’t necessarily trust it to write the code without me intervening.
Giovanni Asproni 00:44:22 I’m asking because I’ve used that in some pairing and teaming sessions so far. We always use the agent as a tool. So, it’s like discussing with the other person a problem how we’d approach that. And then we had doubts to say, let’s check with AI what we get.
Jason Gorman 00:44:35 Yeah, what did a billion people say on Stack Overflow?
Giovanni Asproni 00:44:39 And then have a look at the response. Yeah. And see if it is something useful for us or not. Maybe change the prompt. So, we don’t really treat the AI tool as a, let’s say a member of the team is just another tool that we try to use it to help us thinking things through, especially in parts of the code we don’t know well or maybe there are some technologies that we need to use that are not very well known by us. And so, we try to get help. I guess that sometimes it’s like Googling for something or looking at Stack Overflow, but using an AI system, basically using the system for exactly the same purpose.
Jason Gorman 00:45:14 I think it is convenient and useful in that sense. Whether it’s worth a massive cost is a separate discussion. But from a purely practical point of view, I think it is useful in that respect to have in a teaming kind of situation for example, to be able to go, it’s like if you’re familiar with who wants to be a Millionaire, you’ve got that lifeline ask the audience, it’s ask the audience. It’s, we asked a billion software developers and sometimes it comes up with a good answer because it’s got a lot of data in in its training and sometimes the data is very flat and very sparse and you get, it’s like if you were to ask the audience what’s to the capital city of France, Paris would stand out as a probability Yeah for the next token. But if you were to ask what microscopic mechanism gives rise to superconductivity in semiconductors, you would expect the audience to just guess and you get a very flat response, a very low confidence response.
Jason Gorman 00:46:05 Yeah. And in that respect they’re quite useless because if you’re talking about your field, stuff you know a lot about, the stuff that you don’t understand is more likely to be outside of its training data distribution as well. And that’s where I’ve kind of found, whether it’s with software development or with physics or whatever it is, you very easily lead it out of its own data distribution. It’s very good at stuff I don’t understand. But then everyone says that, oh it’s really good, it can’t do my job obviously, but it could totally do yours that I don’t understand.
Giovanni Asproni 00:46:38 Apparently excessive use of AI reduces the cognitive ability of the people doing that. We kind of think less, we lose some skills that used to have like, you know, if you have all the code written by the AI then at some point we try to write the code ourselves. We are unable to do this. And this I understand is also for you, a serious issue. Am I correct?
Jason Gorman 00:47:00 Yes. So, there’s a lot of emerging research that is sort of detecting that the more people rely on these kinds of tools, the more they need to rely on them. Their ability to understand, to comprehend is being eroded. But I think this is an acceleration of a trend. I train software developers and I’ve been running a company that’s been doing that exclusively for 17 years. So, I’ve had a chance, with a lot of different teams and a lot of different companies. I watched over those 17 years how particularly code comprehension but more recently just comprehension, generally comprehension of business problems of logic of other stuff has been degrading. And that has, I’m pretty sure, been accelerating in the last three or so years, especially the last year. That things that I would expect code, I would expect a developer with, you know, 2, 3, 4 years of experience to understand I’m now finding that they can’t understand it.
Jason Gorman 00:47:55 Yes, we definitely can’t say definitely, because it’s a personal experience, but I am definitely experiencing groups of people who are struggling more and more. Not just to understand maybe code or whatever I put in front of them, but to understand requirements for an exercise that maybe 10 years ago there was never a problem and now I’m having to explain, you know, to stop them and go, no, actually what it means is this. And I haven’t changed the text of the problem, it’s the same exercise, nothing has changed. But now I’m having to intervene more often and go, okay, let’s break this down more. And also, programmers who have been working in, you know, Python or C-Sharp or JavaScript or whatever for several years who are unable to do certain very basic things from scratch in the language like Java developers who don’t know how, what a constructor is or how to declare or construct it because they’ve never done it.
Jason Gorman 00:48:44 But this I think started really with Stack Overflow and AI has accelerated it that more and more people have been copying and pasting it, which is why I try to urge, although I appreciated its harder work, particularly when you’re starting out in programming and software development. Please don’t by all means read code and copy it, but it’s going to go in the eyes through the brain and out the fingers. I think to engage those centers of your brain that will actually, that makes it sink in. It’s like, it’s like everyone’s on speed dial and no one can remember anybody’s number and the moment you take that, that phone away, they can’t remember anybody’s number. And I’m seeing this more and more now and it is from personal experience, it does really appear to be accelerating. But there’s also research that is suggesting that it really is accelerating. And I really worry about that because that’s going to hit another problem, which is that regardless of their ability to comprehend any code, is the fact that more and more code is being produced that nobody’s even looked at. So, they understand code slower and there’s going to be lots more code that needs to be understood when it inevitably breaks and the language model can’t fix it.
Giovanni Asproni 00:49:51 No. Another question will be related to this, you know, to the cognitive ability in the skills. Now the most recent development for using AI is the spec driven development trend where people are supposed to write specifications in natural language and the system will create something based on that. Now if this works out, maybe we don’t need to know coding that much after all. What do you think?
Jason Gorman 00:50:16 So there are different interpretations of what people mean by spec driven development and I think probably the mainstream one that I see a lot, I say mainstream, it’s mainstream on LinkedIn, which means it’s probably not mainstream. But the one I see most often on LinkedIn is along those lines you write natural language specifications and then you feed it to Claude code or Cursor whatever or lovable and often goes and chugs away at it and produces you a working system. It kind of sort of work provided you’re not particularly attached to any particular end result it will produce. This is the problem with natural languages; they are inherently ambiguous. Yeah. And that’s an unfixable problem. So, it will produce an interpretation as long as you’re happy with the interpretation it produces, then that’s okay. Under the hood, the code it’s likely to generate is going to be problematic in terms of, so large language models are really good at generating code that they’re really bad at modifying later.
Giovanni Asproni 00:51:10 That is actually an interesting take because actually seems that also, again, some research around that. It seems that the better the quality of the code, the better the agents are able to help with modifying and refactoring that later.
Jason Gorman 00:51:24 I see people saying, for example, they claim, oh, code doesn’t need to be readable by humans anymore because of AI. But then you get these, I’ll look at my bookmarks here. I’ve got another great study here called How Does Naming Affect Language Models on Code Analysis Tasks . So, this is a study that’s relatively recent, and I’ve done this experiment. It was done, this study’s only a couple of years old, maybe a year and a half old. I’ve done this experiment myself where you take code that is pretty easy to understand or is intuitive to me. It’s, you know, fairly easy to comprehend. And then you take it through a series of iterations where you obfuscate the code more and more and measure just how you know obfuscated it is. So, you’re changing function names and class names and everything until they make no sense whatsoever.
Jason Gorman 00:52:08 And then you give the model tasks, to conduct. And then you measure, measure completion, how many of those tasks are complete. And it does indeed go off a cliff. The less intuitive the code is to a human being, the more I think the clue really is language model. That should be our first clue. They are language models. They were originally created, invented to translate human languages. And when you start using language in the code, that doesn’t match the language of the problem, the language you’re trying to quote, all kinds of things go wrong. So obviously that affects model performance. Complexity has a massive impact. Coupling and cohesion in modular design has a huge impact as we discussed in terms of the potential blast radius of changes. How much code needs to be brought into the context? Context that has to be, needs to be changed. Duplication has a similar effect. So, all the things that we’ve been saying for years make code harder to change or harder to understand and harder to change for humans, including fast running regression tests are exactly the same factors that research and experiment and experience are telling us make code harder to change for large language models.
Giovanni Asproni 00:53:20 Okay. And now maybe a couple of words about the future. So how do you envision the future of software engineering? Do you think that AI will change things in a some kind of fundamental ways?
Jason Gorman 00:53:30 If we’re talking about large language models when we say AI, then no.
Giovanni Asproni 00:53:35 Do you think maybe we can come up with some different AI technology potentially?
Jason Gorman 00:53:41 That’s not my field, but I look forward to the day. I don’t believe so. I’m, you know, 55 and I have been programming for a large part of that, and I have heard multiple times that either artificial, general intelligence is just around the corner. It’s always 30 years away and has been since I was a kid, or certainly during those 40 plus years that I’ve been programming, Crikey, 45 years that we’re not going to need programmers soon. I saw adverts for it in the eighties. I saw people claiming it in the nineties with computer-aided software engineering. I’ve seen it with no code and low code and we’re seeing it again now. I think maybe coding, maybe me typing the code will one day no longer be a thing. But I think that wider activity of specifying, designing, delivering software in feedback loops, learning with customers and other stakeholders, I think that will always be the bulk of the job.
Jason Gorman 00:54:37 I think it will always ultimately about be about that bigger picture. I think I’m kind of insulted by people who go, I can see it replacing all software engineers soon. Because what that implies is that what we do, what I do, what you do and what 50 million other people do for a living in the world does not require general intelligence. That it can be replaced by, you know, super auto complete. And I find that quite insulting and I just don’t think it’s, I’m pretty confident it’s not true. Waiting for the rest of the market to catch up with that reality is another thing entirely. But I’m really, I’m reasonably satisfied that it’s not true. It’s probably not going to happen in my lifetime. I think the future of software development is software developers.
Giovanni Asproni 00:55:18 What skills do you think will be important for professional developers in the future?
Jason Gorman 00:55:24 Okay, so skill number one, right at the top of the tree is communication and comprehension as well. The second most important skill is the ability to change software without breaking it.
Giovanni Asproni 00:55:35 So can I say that is pretty much the same skills that are necessary today if to write good software in your room?
Jason Gorman 00:55:41 Yeah, absolutely. Absolutely. I haven’t had to memorize libraries and APIs. It’s been so many years since I’ve had to memorize things. And so yes, I think language model could take some of that load off or they could, if they were more reliable, can take some of that load off us in exactly the same way that, you know, in tele sense and auto completion or code sense and all these other things have taken load off us removed friction from the process of creating source code that does what we need. But the wider job has always been the bigger job and the most important part. But because the tools are not a hundred percent reliable, you’re always going to need someone who can understand and can edit and can fix and can debug. And I think at the core of it, I don’t think those skills are going to become less important. I think it’s that kernel, that core that’s not that important, but it does have to happen, and it does have to work. People do need to understand it, and I don’t think that’s going away and I see it going away. I see it sort of wandering off into the distance, into the fog as people rely on this technology more and more.
Giovanni Asproni 00:56:43 Okay. I think we’re having quite an interesting conversation. Jason, thank you very much.
Jason Gorman 00:56:48 No, thank you.
Giovanni Asproni 00:56:49 Thank you Jason for being with us. This is Giovanni Asproni for Software Engineering Radio. Goodbye.
[End of Audio]
