#264 - From Technical Debt to Triple Debt: The Hidden Cost of AI-Generated Code - Margaret-Anne Storey

[00:02:03] Introduction

Henry Suryawirawan: Hello everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I have someone who I talked to about three years ago. It’s been a while. So her name is Dr. Margaret-Anne Storey. So she’s actually one of the leading experts, publish a lot of papers related to developer productivity, developer experience. And lately she’s also coming up with a new paper about the triple debt. So yeah, we’re gonna talk a lot about this paper, definitely, and also the impact of AI in our day-to-day development, activities. So welcome to the show, Margaret. Looking forward for this conversation again.

Margaret-Anne Storey: Thanks. Good to see you again, Henry.

[00:02:42] How Has AI Transformed Software Development Over the Past Three Years?

Henry Suryawirawan: Yeah. So Margaret, maybe in the very beginning, right, so it’s been three years. I think when we spoke last time, there was no kind of like inkling of AI or so to speak, right? Like the impact on all the software development activities. So in the last maybe three years, if you can summarize what has actually happened?

Margaret-Anne Storey: Yeah. I think everybody has experienced this change in the last three years. I remember, I’m also a teacher. I do, I teach students as well as do research, and I was teaching software testing, about at the third-year level at the university when Copilot came out at the very end of the term. And I remember thinking, “Wow, everything I have just taught my students about software testing, all of the different techniques can now be pretty much automated using Copilot.” And I actually showed my students Copilot right before the end of the term to kind of give them an, you know, a little preview of what’s coming. But I also told them, “Look, it’s really important that you do know these techniques so that when you use tools like this going forward, it will help you know, you know, whether your tests are complete or not, and you understand the fundamentals.” Understanding the fundamentals of the why behind these kinds of tests is what was so important. So that was kind of the beginning, I guess, for me.

And then as a researcher working with companies, like I’ve been working with Microsoft for about 10 years now and other companies like DX, just seeing the huge impact that we’ve all experienced with generative AI, and now agentic AI is having across the entire industry. And it’s a wild ride. It’s a wild ride for all of us. We’re all trying to figure it out. And what’s kind of cool right now is that nobody really has the answer to how we should be doing things, so we’re all trying to figure this out together. It’s kind of all hands on deck, all trying different things, trying to get it under control. And the disruption is huge. I’ve studied disruptions before in software engineering, so I studied the impact of social media, on software developers and tools like Stack Overflow and GitHub and, you know, even using Twitter and how that was having an impact on how developers communicate with each other. And that was a big change too. But generative AI is the biggest disruption that I’ve seen so far. So yeah, hope that’s– that helps for a little start of our discussion.

[00:05:14] What Inspired the Research on Cognitive Debt and AI-Assisted Development?

Henry Suryawirawan: I wasn’t aware that you had this study about social media impact. But I guess, yeah, the magnitude of the AI impact is probably greater to me because it really touches on the day-to-day activities of a software developers, right?

Margaret-Anne Storey: Yeah.

Henry Suryawirawan: I think recently you delved into these topics about cognitive debt, triple debt, and about this problem that I think for every developers who have used AI lot recently, they’re having this issue, right, about understanding exactly what happened after they use AI a lot in their software development. So maybe let’s start from there because I think, you know, what brought you into this topic, right? What made you wanted to write this paper in the first place?

Margaret-Anne Storey: Yeah. I mean, I’ve– I was observing what was happening across the industry, of course, as well, and teams and developers. Some of them really jumping on to using it really quickly and adopting it, and others not. But things really came for a head for me in terms of a course that I was teaching again. So it’s a course called Startup Studio at the University of Victoria, and it’s a fourth-year senior course. It brings together senior students in software engineering as well as students from business together to build a startup over the term. And, a few… I’ve been teaching that course actually since 2014, so I’ve kind of seen it go through the evolution. We have industry founders that come in and mentor the students and talk to the students during the term. And they have to go very, very quickly. They have to build an MVP, get an idea, a novel idea, that people really want, and they have to build that tool and get the first MVP, very, very simple MVP into the hands of users really within about six or eight weeks of the course. And then have something that folks are using by the end. That was always a big challenge, to be honest. You know, it’s hard to stand up that early MVP that, you know, even with the minimal, you know, viable features that it has, getting people to use that was a struggle. But they would manage it during the 12 to 13 weeks of the term.

And then of course, you know, AI came along and, and teaching it in – let me get my years correct – 2023, the students didn’t use it as much as I thought they would, either in the to- the products that they were making or using it themselves. So 2024, I kinda leaned into saying, “Look, you know, you’re gonna be … If you’re gonna create this company,” ‘cause some of them do, they stay on and they make companies after the course, “you need to be leaning in to use AI to go as fast.” And some of them did in 2024, but not as many again as I thought, even though we did demos. Look at how quickly you can use AI to create your MVP. And it wasn’t until 2025 in the first week that myself and my wonderful TA from the year before, we just kinda walked through, you know, the idea that he had actually taken the course, and he walked through with them how he had spent an entire term building that the year before. He used AI a bit then, but not that much. Of course, things had advanced. And he showed how he could now build it in a matter of a few minutes in September of 2025.

So we really encouraged the students to lean in and use AI both for the development part, but also for the business part. So coming up with a business plan and, you know, thinking about the different features and the users and other aspects of the product that they were building. And for the software engineering students, I really did recommend to them, of course, that, you know, you’ve got to use all of the things that you learned. Remember that testing course, remember that requirements course, remember, you know, veri- the different techniques that you’ve learned for validating the tool is meeting your users’ needs. Test-driven development, do that. Write down what your requirements are. Write down what your architectural decisions are. And then I kinda let them loose ‘cause I’m not teaching them how to code necessarily. I’m more focused on the startup side. And it wasn’t until about … at first, they were going really fast. I had not seen anything like that before. Within a few weeks, they had the earliest MVP, you know, that you could imagine. I was also asking them to share their reflections week by week, and their reflections were saying things like, “Wow, I’m learning so fast. I just have an idea, and it’s creating it for me.” And the business students were also saying that. They were also learning a little bit how to write code thems- no, not write code themselves, but use the AI to help them vibe code some of the features. So that was great.

But then about eight weeks in, I started hearing things from some of the business students and some of the software students saying, “Yeah, we know we needed to make that change, but it’s really hard to do.” And I’m like, “What do you mean? That’s not a difficult change.” And at first I thought, “Okay, they have accumulated a lot of technical debt.” That’s what I assumed. And I thought, “Okay, I’ll sit down and chat with them.” And then as I’m chatting with them, I realized that not many people across the team really understood how the code worked, you know, or their architecture. When I asked them to describe the architecture, they weren’t able to do that very well either. And when I asked, “Well, who knows about this part?” They didn’t even seem to know who knew what. So I realized at that point we have a problem, and I called it tech- I called it cognitive debt back in October. And that was kind of the first kinda inkling I had that, okay, this, you know, use of AI, particularly in the startup kind of realm where they feel the pressure to go fast, is bringing other risks that is eventually gonna slow them down. Actually, it brought, you know, one of the teams, as I mentioned, to a halt. And other teams recognized this themselves. So you know, there was one team where one of the members, he had done a lot of co-ops and he said, “Okay, we gotta stop. We gotta stop. We gotta roll back. You know, we gotta, you know, start over with some of the stuff because this is gonna break. And we’re onto something good here, so we need to kinda start over and make sure we have control.” Yeah, so I hope that helps a little bit.

[00:11:28] Why Is Cognitive Debt Accelerating Even Though It Isn’t a New Problem?

Henry Suryawirawan: Yeah, very interesting story. I think many people could relate to that, right? Especially they do a lot of this AI-driven, AI-assisted development, vibe coding, right? Especially for vibe coding, I think it- the danger is really, really high. So why this understanding problem becomes an issue compared to last time, right? So I think software developers, we all are very familiar with technical debt. We always think about, okay, when we want to go faster, fix our technical debt. But now when you mention about this cognitive debt, why now, right? Why in the past we didn’t really have this problem?

Margaret-Anne Storey: We always have this problem. We always have this problem. My PhD work many years ago was in program comprehension, was in trying to help developers understand the code that either they had written or more often than not the code they hadn’t written that, you know, was legacy system code. So my PhD was about visualizing the architecture, architecture recovery, and visualizing that in a way that would help people new to a codebase understand it so that they could make, you know, improve it in some way. So this cognitive debt has always been around. And it’s just that we didn’t name it. And, you know, poor comprehension– I mean, you know, I used to write a lot of code many years ago. Even myself, you know, I’d write something and I’d write a visualization tool and then I wouldn’t touch it for three months because I was teaching a course. And then I’d go back to it, and I’d try to like, you know, start making changes, and I’m like, “Oh my God, I don’t remember how this works.”

So this is not a new problem, it’s just the speed, the scale at which we’re going. And you know, I realize even myself when I’m, you know, vibe coding, and I’m trying not to, and I’m trying to slow down, that I’m accumulating cognitive debt way faster than I had before. Because to really understand something, it takes, you know, deliberate reflection, deliberate practice, to really understand what it is that we’re either trying to learn or we’re trying to build and maintain that understanding of it. So when we generate something, and if you’re, you know, spinning up lots of agents and they’re all creating different pieces, and then you’re putting– you have another agent putting it together, you’re gonna accumulate kind of that loss of understanding a lot faster.

Henry Suryawirawan: Yeah, especially I think I feel the past one year or so, right, when the speed of these AI coding tools really accelerate a lot and people are competing, right? I mean, the Anthropic, OpenAI, and Gemini, for example, they are competing so fast. So it’s like we are kind of like being, I don’t know, like pampered with all these features. At the same time, the industry are also pushing us to actually use a lot more AI, and thus the cycle continues, right? So we are using AI a lot more. And I’m sure in some parts of the teams they might feel this potential problem, right?

[00:14:24] What Exactly Is the Triple Debt Model in Software Development?

Henry Suryawirawan: So maybe let’s dive into the paper itself because, you mentioned about this triple model. There’s this technical debt we mentioned, cognitive debt, then there’s another one. So maybe I’ll let you explain what are the three debt models.

Margaret-Anne Storey: Yeah, so technical debt, I mean, it’s well known right across the industry. And it, you know, can also refer to other kinds of debt, like security debt or, you know, architecture debt. So I won’t talk about that a lot ‘cause I think people really have a good handle on what that means. And then cognitive debt, I’ve explained pretty well, you know, this loss of kinda understanding of what you’re building. One of the things I wanna pull out about cognitive debt is that what I noticed in my teams and what I’m also hearing from practitioners as well, is that there is also this loss of transactive memory. So who it is on the team that knows how these different components work. So that is also… I mean, transactive memory in software development was also a long-term problem. It’s been studied in software engineering research. But it’s accelerating again now as well. So that’s kinda cognitive debt, and it’s a… I think of it as a property of the system health, just as technical debt is.

And then the third kind of debt that I added to this triple debt model is intent debt. And I mentioned working… I’ll go back to my students again. So when I was chatting with them, I’m like, “So why do you have this feature in the product?” And they would kind of look at each other and, and be a little blank about, because we forget. You know, we forget why this is here. So they… you know, even though we were telling them, I mean, we were guilty of it too, right? We were telling them to go fast. They weren’t necessarily writing down what the user goal was, how those goals kinda mapped to different user needs, how those needs mapped to features, how those features then in turn would lead to certain architecture decisions that you would make and then, you know, generate the code. So there wasn’t this good kind of articulation across that or a good externalization of the different things. So not only were they on the team forgetting, but the agents that they were using also didn’t have that context, right, for building. So the agent was kinda like started to hallucinate. So I mentioned I had them create these diaries, these logs of what they were doing and, and over time, they were saying things like, “Yeah, anything I ask, it’s just breaking, and it’s just hallucinating stuff like crazy.” And so we were seeing that as well. The agents were also not having that right kind of context, right, for making changes as they went forward, as their products became more complicated.

So that was the three. So technical debt is about what’s in the code. Cognitive debt refers to what’s in our minds, you know, across the team. And then intent debt is about, you know, poor externalization of what are the goals, what are the decisions that we’ve made, you know. Not only what are the decisions that we’ve made, but also what have we decided not to do. You know, writing that down as well as, you know, decisions about the architecture, technology choices, and so on.

[00:17:36] How Does Intent Debt Relate to Context Engineering and Intent Drift?

Henry Suryawirawan: Right. And like that one of the kind of like summary of all these three debt that you put in the paper. So technical debt, it lives in the code, right? Cognitive debt lives in the people, in the brain, in the mind. And the last one, intent debt lives in the artifacts, right? The context that you mentioned.

So I like the term that you mentioned transactive memory, right? Because yeah, I use AI quite a lot as well, and yeah, sometimes I really don’t remember what I actually did last time. And especially people when they spin up multiple agents in parallel? I know it’s kind of like a trend these days. You spin up a lot of agents, you know, let them work on all these three tasks at the same time, and you just review the PR at the end of the day, right? With maybe massive lines of code, and which again, it exacerbates the problem, right? And yeah, then you move on, right? Picking up new features. So definitely I think this transactive memory can become a real challenge for developers. And for intent debt especially, are we referring this a lot to context engineering, which people have been talking a lot to prevent hallucination, you know, improve the agentic workflow. So maybe is this related to that as well, yeah?

Margaret-Anne Storey: Yeah, I mean, it is. I think we’re seeing a lot of tools. I’m seeing a lot of articles coming out about harness engineering and context engineering that are really, you know, kinda putting this harness right around the agents, right? Creating not only guardrails, but also giving that context, right, for the agents to use. In terms of intent specifications as well, I think like one of the things that I put in my paper when I wrote it back in February was intent… What did I call it? Intent-first-driven development or something like that. And some people kinda disagreed with that, and I could see why, because it’s like, that sort of sounds like waterfall. You know? Like, spending all the time creating… and we should talk about that a little bit. But spending all this time kinda writing your specifications up front, you know, and then using that to guide the agents, right, about what it is that you’re intending to do. So I see intent dri- intent debt, being somewhat addressed by some of these tools. Like I’ve been playing around with Spec Kit lately myself as well. You know, using those tools to, in particular, help you write down what you’re doing, but also help the agents as well. You know, like having a claude.md or agents.md file for the agents to have that context.

So I would also say that I see, to a certain extent, some fragmentation across the industry. Different people are almost rediscovering the same kind of things. Slight differences, but we’re starting to see some patterns and some recognition that we need these kinds of tools for supporting us. But one of the things that worries me a little bit about that, and some of the tools that we’re using, is that, you know, we can go…

i’m using the analogy of a sailboat ‘cause I like to sail, and I used- I like to… I don’t race anymore, but I used to race sailboats. And it kinda reminds me of, you can have… Your boat is singing, you know, everything’s working really well on the boat, and the crew is doing everything right, and they kinda, they all have awareness of who knows what on the boat. But you’re going really fast, but you’re going in the wrong direction, right? You know? Or the direction has changed, right? Like you were supposed to go over here, and in the middle of a race course, this happens. When there’s a wind shift, the committee will pick up a marker, and they’ll move it. And if you’re not paying attention, you won’t see that, oh, the marker’s not there anymore. I mean, this doesn’t happen very often, but it has happened when I’ve been on races.

And so you’re going super, super fast, but you’re not going in the right direction. And I think intent debt is, can also accumulate, or intent drift can also accumulate if we’re not constantly kinda checking in with our end users. Is this still what they want? So deploying, not just doing A/B testing, that’s not enough. But deploying it to our users and doing user research, so listening to our users because their needs might have changed, right, in the time that we created our product.

But I’m not sure I actually answered your question. I think I drifted. Talking about drift, I might have drifted away from your question. Hopefully not.

[00:21:57] Can AI Be Used to Solve the Cognitive Debt It Created?

Henry Suryawirawan: No, I think you kinda like answered that. So one simple thought that people have, especially when they have this AI, right? So once they accumulate this cognitive debt or maybe some intent debt, they actually think they can use AI back to explain the code, explain kind of like an intent. Do you think this is also a viable solution, using AI to actually help you improve your cognitive understanding about this stuff?

Margaret-Anne Storey: To a certain extent, yes. I think that AI can both amplify your cognition, help you with understanding the code, and also erode it. So if you have good practices around making sure that you pause, right? To understand the code, that you do read the code and think about, you know, the bigger picture while you’re looking at your PRs. And you hit something in the code that you don’t understand, but you are trying to understand it, then of course you can ask, you know, Claude or whatever you’re using to explain that piece of code, right, to you, you know, and give you that understanding. So on the one hand, it can help you repair that loss of understanding. It can also help point out to you that maybe somebody else on your team hasn’t actually looked at that part of the system for a while and maybe they should. So in some ways, we can use AI absolutely to help amplify… Or sorry, repair and mitigate cognitive debt.

But on the other hand, it can also lead to cognitive debt, right? If we don’t– If we’re not mindful about it and don’t have good practices and processes set up. And that was kind of why I wrote, you know, that paper, was to say that it isn’t just about technical debt. Just, AI can also make technical debt worse, but it can also help address it. It’s not, you know, gonna be… it’s not gonna make it disappear as a problem. I think it’s always gonna be a problem. And cognitive debt will always be a challenge as well, but we can use these tools in such a way, as long as we have good practices around them to help us kinda keep on top of the three different types of debt.

And the same for intent debt as well, you know, that we can… Actually, somebody said to me when I was seeking feedback from the paper, “We don’t need to wr- we don’t need to record the intent. We can just recover it from the code.” I kinda disagree with that. I think it’s a fair comment. It is a fair comment, right? But I disagree with it a little bit because sometimes we make decisions that aren’t in the code. So maybe I have decided in my MVP not to build this feature for a particular reason. Maybe I’ve decided it’s too much, or maybe it introduces too many risks, or maybe there’s something else that I can use off the shelf for that. And that may not necessarily appear in the code, so it has to be somehow recorded. And I think having it written down as well is something useful for the agents, right? And for other people to have a quick way to kinda get up to speed on what’s going on.

Henry Suryawirawan: Yeah so I feel that this kind of thing, right, this kind of problem is not new to us. In the past, we also have this challenge with documenting stuff, you know, updating it and all that. But again, like the speed the scale that you mentioned is really kind of like a different level today. And I think when you publish this kind of like idea about cognitive debt, many people also kind of like chimed in, right? Like people like Simon Willison, Martin Fowler and all that. So people, I saw people giving you a lot of comments. So what do you feel back then when you know such a viral kind of like viral…

Margaret-Anne Storey: Yeah, within our little pond. It, it went viral in our pond. I was really surprised actually to see, You know, I kinda put it out there and I thought, “Hmm, I wonder what people are gonna say.” And probably nothing, right? That’s more likely what would happen. But, but I started hearing from a lot of people, that they were… And people that I really respect that are really, really good developers, and they were like, “Oh yeah, that’s happening to me.” And it’s… And everybody kinda knew it. It was the elephant in the room that we were all seeing, but nobody had a name. Nobody knew to call that thing the elephant. You know, that this is cognitive debt, and we have to pay attention to it. So I think that was, it was just kinda the timing. In the few months that, you know, that these tools had really accelerated in the abilities that they had and the capabilities that they provided, that we were having this problem. And so I heard from a lot of people actually that, but that these were the challenges they were having. Interestingly, I also heard from quite a few folks on, yes, we’ve known about this, and this is what we’re doing to, you know, to address this, to mitigate this kind of cognitive debt and to repair it. So it was super interesting, it- for me to, to have those conversations with the practitioners and hear not only did these things resonate for them, but also, you know, that they were coming up with ways to address it as well.

[00:26:55] Why Does Using AI Make Developers Feel Fatigued and Stressed?

Henry Suryawirawan: Yeah so I think definitely it’s something that everyone can relate. So in the beginning, I’m sure when people find these AI tools, right, they feel they feel they are much more productive, right? But obviously there’s this now side effects that people are thinking about. And I think you mentioned there’s also the cost to the human himself or herself, right? Things like feeling stress and now what we call fatigue, right? And so I think many people mention that after using AI a lot in their day-to-day work they feel much tired very fast. Maybe a few hours then they feel this kind of thing. So maybe tell us about this effect as well, because the cognitive debt, that is one thing. But what’s the aspect of human that we we can call out as well?

Margaret-Anne Storey: Yeah. Yeah, I mean, there’s many aspects to this. Many dimensions to this, just like SPACE, right? But, on the one hand, I think some… Maybe I’ll start with a thing that’s just kinda top of mind for me right now that I’m hearing a lot about. There’s a lot of angst across the community, you know, developer jobs disappearing, developers being laid off and being replaced, you know, with coding agents or whatever, you know, automating their jobs away. So there’s a lot of fear about that, and at the same time, there’s a lot of push from a lot of organizations to adopt AI and go faster without necessarily giving the right space and time to learn those tools, to talk to others, to experience what it’s like to use them, to fail with them, and then take those learnings and then put it back into how they’re using them with their team. So I think that that is part of, you know, the challenges, the negative implications on developer experience that this is having across the industry. So that’s one part.

Another part is, you know, using… You talked about spinning up these agents. You… I could see it on your face already that you were feeling this, “Oh, my God. I have all these agents and they come back, you know, they’ve finished a task at different times.” It’s like have- for me, having 10 graduate students, you know, working on a project and then coming back at different times, “I’m ready. I’m ready. Look at my cool thing, and integrate it with this other cool thing.” And you’re trying to keep track, and you’re like, “Who are you again?” Like, you know. So it’s kinda the same thing with the agents, you know, what did I ask you to do? And integrating those, that’s a lot. You know, when we think about managers… So Annie Vella talks about, you know, this shift from developer to supervisory role. I think that that’s really apt. Because when you’re a manager, when… you know, if you’re working in a company and you have 10 people, say, reporting to you, that’s pretty much all you can do, right?

I mean, okay, I know there’s often pressure to do work as well, but managing… I remember my husband saying that to me once, and I said, “I’m so busy.” And he’s like, “How many students do you have?” And I’m like, “Oh, I have 12.” And he went, in his job where he worked, that was all they did, was manage, right? And so now you’re managing all these agents and keeping track of them, and that’s a lot. That’s a lot of cognitive load, a lot of complexity. Not to mention that those agents are creating a very complex software really fast with lots of dependencies, layers of abstraction on top of that. I mean, it’s no wonder, right, people are fatigued.

And yet, at the same time, it’s kinda fun, right? You know, like it’s really fun. You wanna, you want… It’s so cool to be able to create so quickly. I find myself staying up super late again, you know, and building things ‘cause it’s just, “Oh, just one more thing. One more thing.” And so, you know, it’s also that kind of, you know, part of our human nature that we’re having fun with it, but it can also, too much of anything can be tiring.

And then the third part, I think, and my student Arty Starr has talked about this a lot in her thesis work. The first paper is out on that on a troubleshooting theory. And she did a lot of interviews with developers and found sort of related how difficulty in troubleshooting code that you don’t understand or, you know, doesn’t work the way that you expect can lead to a lot of cognitive fatigue. So when things work okay, you know, and you’re generating stuff, and it’s all working the way you expect, it’s great. But then when something breaks, it’s really hard to fix, and then you have to put a lot of energy and a lot of cognitive resources into fixing it. So I think that that’s, you know, one important part of it as well.

[00:31:33] How Are AI Agents Affecting Human Relationships in the Workplace?

Margaret-Anne Storey: And then I think there’s another part, and I just thought of this, so I’m just gonna go with it, ‘cause maybe we’ll get to it later. But, I don’t know, because I haven’t studied this, but I’d love, you know, to hear from you. Maybe you’ve heard it from other people. But certainly from, you know, some things that I’ve seen, it feels that, you know, the team members working with each other and talking to each other, human, you know, relatedness is really important, you know, those relationships.

And people are not doing that as much as asking each other. They’re asking their chatbot. They’re, you know, with their agents and not talking to other people on their team as much. They’re relying on the chatbots, bots to give them, you know, feedback on what they’re doing or on their design. And so… And that’s tiring, you know, to be by yourself, I think, all the time. You don’t have those little mental breaks maybe that you had before of saying, “Hey, how’s your day going, you know?” You know, “Oh, what are you working on?” You know, those moments. I think it’s just this, you know, churning away, and then frantically maybe integrating your stuff, you know, with other team members. But I don’t have data for that. But it’s just kind of a hypothesis that I have that that lack of connection is kinda happening because of using generative AI so much. I’m sure somebody has data on that.

Henry Suryawirawan: Yeah I think that is quite happening. At least I can see also sometimes in in my team.

Margaret-Anne Storey: Yeah.

Henry Suryawirawan: You know, when can spin up so many things on your own doing a lot of tasks on your own I think the tendency is to do it in silo, right? Why would I need to speak with others? Even when I want to know about the work that he does, right, I can just ask AI to explain me about this part, right? I think I can see this trend as well, like people are more into this solo mode and less interacting with each other. And when worse is like they interact with just PR, right? So maybe because some people still have the PR approval process. So I think one challenge is that if you give other people a lot of PR at the same time, again like that kind of like also doesn’t help in terms of relationship. That’s what I find at least.

Margaret-Anne Storey: Yeah. And you know, this happened during COVID. So we did studies together with some colleagues at, Denae Ford Robinson, and Jenna Butler, and Brian Houck, and Tom Zimmermann. A bunch of us did some studies of developers working from home during COVID, and that was one of the main findings. Courtney as well, Courtney Miller. You know, it was that there was this lack of social interaction happening. So some developers were just like hiding at home and writing all the code and, you know, not talking to others, not answering questions. And it sort of reminds me a bit of that, you know, that that lack of social interaction and social relationship is bound to have a negative impact on their wellbeing as well as, you know, perhaps also on their productivity.

Henry Suryawirawan: Right. I like that all these researches that you have done kind of like enforcing each other, right?

Margaret-Anne Storey: Yeah.

[00:34:37] What Exactly Is Cognitive Surrender and What Are Its Risks?

Henry Suryawirawan: I wanna also call out this term that I think really, really, kinda summarize what is happening, right? So I think some people have used these tools and because of the amount of cognitive thing that comes them, right? So we all come to a point where I just accept whatever AI suggests to me. So I think this term that you call out is called cognitive surrender. So I wanna also ask you to spend some time explaining about this cognitive surrender. What is exactly that, and what is the risk of doing this?

Margaret-Anne Storey: Well, I mean, I think the risk… So the difference maybe, let me start with what’s the difference between cognitive offloading and cognitive surrender. I’m not a psychologist by the way, but this is my understanding. You know, cognitive offloading is when we offload a task to some automation, you know, maybe a calculator or something. We’re We still know, right? We’re redistributing some of the mental work that we have to do to a tool. But we still have a good kind of, we’re in control. We understand what’s happening.

Cognitive surrender is a term that is being, you know, used, and it relates a bit to Kahneman’s model, you know, Thinking Fast and Slow. That, you know, with cognitive surrender, you’re also surrendering your understanding of what it is that you’re trying to do. So you’re surrendering not just your understanding of it, but also your ability to learn, right? So, you know, doing the thing but not learning. So it’s a pretty, it’s a pretty new term, I think that, or at least new to me, term that I’m seeing being used with AI. And it’s definitely something that, you know, as educators, we’re very concerned about and trying to figure this out, what, you know, what should we be surrendering and what should we be making sure that our students learn? But yeah. But I think cognitive surrender leads to cognitive debt, so as well as challenges with skill, right?

Henry Suryawirawan: Yeah. Definitely this is not just for software development, right? So we also use other parts of AI as well, right The chat AI where you ask a lot of information, right? Trying to get information in a very quick manner, right? So definitely this is also happening in that use case as well. Yeah.

Margaret-Anne Storey: You know, we’ve done that for years, right? We did that with Google, right? You know, it used to be that we remembered how to drive from A to B, and now it’s like, no, you can’t. You have to, you know, you have to use Go- if Google Maps is down, you’re done. And we’ve all found that, right? Calculator, I saw a coffee shop one time, you know, close because their cash register wasn’t working. They could access the cash, but they couldn’t do the math. And I’m like, “Just write it on a piece of paper.” And it was like, “No, no, no, no, we have to close.” And I’m, “Okay.” So I mean, we’ve, you know, we’ve done that for years with technology. That’s not, it’s not something new. Again, it’s just the pace at which we’re doing it and the pace at which we’re figuring it out. The cognitive work that we have to do is being redistributed among different tasks. You know, it’s now not as much focus on writing the code per se, but maybe now we have a bit more time to do more quality work in terms of thinking about specifying our requirements and thinking about our requirements, and also maybe a bit more time on the verification side. So it’s more a redistribution of our work and maybe a bit less work on, you know, the writing of the code part.

Henry Suryawirawan: Yeah. I mean when you mention about shop closing because of not, I mean like calculator not available, right? So I think sometimes also this happen, right? So when we all have used AI a lot and when the AI tool is down, kind of like down, right, Claude, happened sometimes, it’s not available, like we just, we don’t even feel of working.

Margaret-Anne Storey: This is also not new. I remember when Stack Overflow… So like I’m probably quite a bit older than you, and I remember Stack Overflow, the shift that it had in software development. And it really came to my notice when I brought my entire group off campus. We went to do a hackathon at a sailing club close to where I live. And we set everything up. We had a network. You know, we had all the source code on our machines. Everything was there, and the internet went down. And my students just said, “Oh, I can’t code.” And I’m like, “Yes, you can. Yes, you can. We have all of the code locally. We don’t need the network. We’ve nothing in the cloud. Everything’s here.” And they’re like, “No, no, no, Stack Overflow’s not working.” And I’m like, “You don’t need Stack Overflow.” “Oh, no, I need Stack Overflow. I literally can’t work without Stack Overflow.” So this is, again, not new, you know. And so we’re seeing it now again, right, with Chat. I mean, and actually talking about developers being tired, some of them are saying, “I love it when my tokens are used up because I actually get a break.” So, you know, there’s the flip side of that as well ‘cause they’re like, “Oh, there’s nothing I can do, right, without it working.” So, yeah.

[00:39:38] How Can Leaders Spot Growing Cognitive and Intent Debt Within Their Teams?

Henry Suryawirawan: Yeah. Speaking about token usage, right, I mean there’s this trend called tokenmaxxing. Some companies also enforce everyone, not just developers, right, everyone in the company to use AI as much as possible, right? And even put that as part of their performance, you know, KPIs, right, so which is bad. But you mentioned about, you know, for managers out there, right, who are having this kind of trend within their company, right? Is there any kind of like warning sign that they need to pick up when all this cognitive debt, maybe intent debt are actually exacerbating situations that is happening within their team? So what are the warning signals that you think people can pick up? So okay, I see this trend going there, maybe we should stop a little bit.

Margaret-Anne Storey: Yeah. I mean, I think some of the warning signs are some of the things we’ve talked about a little bit already. I think fatigue is one of them. You know, if people are really tired and being… you know, are burnt out, that’s definitely a warning sign that I think you need to look for. Not talking to each other as much. But things like, you know, they make a… somebody makes a change and it breaks, and nobody knows how to fix it. They’re not sure who knows who to fix it. They get surprises when they make a change. Their end users are, despite them going faster, the end users are not as happy. I think we’re hearing some of that.

[00:41:02] Why Is ‘Tokenmaxxing’ a Dangerous Productivity Metric?

Margaret-Anne Storey: I do think this tokenmaxxing metric, I mean, there’s so many people pushing back against that. I don’t think I need to say much about that. Just be on LinkedIn a few minutes, and you see people pushing back against it. It’s kind of ironic to me that so many companies are, you know, using that as a metric, when we spent so long trying to get them away from, you know, lines of code. It’s sort of that, but only worse. What they’re not doing though is taking enough time, giving enough time, psychological safety, right, to their teams to learn how to use those tools and to talk about their experience or even to share their experience, like from one team to the other.

We see a little bit of this in LinkedIn, right? People are sharing their knowledge. But sometimes within companies, in large companies, they don’t share knowledge that much. They don’t know what a team over here is doing. And yet one team, you know, I’ll sometimes observe that, oh, there’s this part of the org that really has it nailed, and this other part of the org does not, and yet they’re not talking to each other. And so, you know, and yet there’s this thing from on high, oh, we’re gonna use, you know, tokens as a metric. So I think that’s very, very dangerous to do that, especially when a lot of developers feel like they’re under surveillance, and they’re… basically what they’re doing is training, you know. They’re automating away their jobs, right, by being watched of what they’re doing so that a bot can, you know, some bot can take over or some agent can take over. Yeah. So anyway, tokenmaxxing, yeah. I- I… bad, in a word. Really bad. Yeah, yeah.

Henry Suryawirawan: Anyway, the token cost is increasing lately as well, so I think this trend won’t continue because it might get very costly, yeah?

Margaret-Anne Storey: Yeah, yeah.

[00:42:49] What Is the Cognitive Tours Tool and How Does It Address Cognitive and Intent Debt?

Henry Suryawirawan: So speaking about understanding about this warning sign and people now know about this danger of cognitive debt, intent debt, what is the solution, right? So what people can do in order to avoid this? And I know that you’re also working on this tool Cognitive Tour. Maybe give us a glimpse how do we solve this?

Margaret-Anne Storey: Yeah. Yeah, I mean, I think as I mentioned, I think that there’s a lot of tools and processes and practices coming out to address both of these things. They’re fragmented. Different people are trying different things. With intent debt, I see a lot of tools coming, you know. As I said, most of them are more focused on how do we help the agents rather than the humans. But still, you know, this articulation of the goals and all of the important decisions is starting to happen. But the… it’s the cognitive part that at least today, a few weeks ago I was worried more about intent debt, but today I’m more worried about cognitive debt because I don’t see a lot of tools or practices coming out to address that. I’m starting to see some. Rahul Garg who works I think at ThoughtWorks is talking about stuff, and there are other. Russell Miles is also working on, you know, improving the habitat for developers that addresses repairing cognitive debt. My student Arty Starr is contributing to that as well.

But in general, I’m not seeing a lot. And so Cognitive Tours is actually a tool or an idea for a tool that I got from sailing, from using a GPS on my boat. This is why taking time off is important because you get some cool ideas when you take time off. And on our boat we have a log book that we record everything in. You know, not just about where we’re going and why we’re going there and when we should leave, weather conditions and so on, but we also record a lot of information in that log book about our boat. So information about when we replaced… That reminds me, I have to replace a piece of equipment and I keep forgetting. Sorry, that’s an aside, but that’s the… an example of intent debt. We have intent debt on our boat right now. We don’t write down all the things that we should be doing. But your log book keeps track of these things, you know, of all of the important things that you need to know so that later on when you need to make a decision or you need to understand what happened, something didn’t go well there, what did we not do well? And so you can go through the log book and see, you know, what it is that you need to know. What is the important information?

Then the other thing that I have on the boat is the GPS, and this notion of waypoints. So waypoints are kinda like bookmarks, but they have more metadata. And I have different types of waypoints. So I have waypoints that show me safe places to anchor, and I have waypoints that might show me where to catch the salmon that I seem to keep catching every time I go to this spot, and where is a good spot for prawns and, and so on. Where’s a good place to buy propane, those kind of decisions. And so they’re these typed bookmarks, if you like. They’re called waypoints. You can add annotations to them in your GPS, and then you can share them with other people, and you can create tours. So when– So they’re, you know, they have location, and you can create a tour out of or a route out of these waypoints, and you can use that then to navigate, right, to your destination, and you can also share it with other people.

Now, the idea of course, when you’re on a sailboat, is that you always have to be constantly changing your plans, and the same with software as well. So years ago, together with some students, we wrote a plugin for, I don’t know if you remember the Eclipse tool. And we wrote a plugin that allowed us to create waypoints and routes or tours through the waypoints. And the idea of the tour is that it’s a slice, if you like, through your software system, right? So, you know, our software system is all of our code, it’s all of our requirements, maybe it’s all of our commits, it’s all of our messages. And you could create a tour, you could create a path through all of that information that would then serve a purpose.

So I’m building this tool right now myself using the tool. And so last night I added a new feature. I added, you know, I was running a local database at first ‘cause I was just trying to use it for me. And last night I created a, you know, I used Turso so I could, you know, share it with other people so it’s running in the cloud. And I wrote a tour as I was adding this feature of different waypoints to help remind me, what it is, what are the important decisions that I’m making, what are the main code components, what did I do, what things should I watch for the next time I go back? And so it’s a slice through your information so that you can give that to somebody to answer a question. So it might be how did… For me, probably a month from now, ‘cause I don’t get to code very much these days, I’ll look at it and I’ll go, “Oh yeah, right? That’s how I did that thing.” And if it breaks, hopefully I have a starting point. So tours can be useful for documenting, you know, how you did something. It can be– They may be useful for onboarding or explaining a feature. I have a tour that is all of the things that I wanna do and add to this, you know, add to this, what are, you know, and so on. So from intent, from the why, all the way through to how I verify something could be a tour, for example. I hope that is a good description.

[00:48:19] How Do You Envision the Daily Workflow of Using This New Tool?

Henry Suryawirawan: Yeah, sounds really interesting, right? The way I– When I, when you mention all this, right, so the way I kind of like have in my mind is kind of like a journal in a sense. Also at the same time also architecture decision record that some people also practice in the past, right? So maybe you, like when- since you are building the tool, how do you envision us using the tool day-to-day, right? Is it something that is built as part of the IDE or is it part of the AI agent itself? Like how do you envision this tool being used day-to-day?

Margaret-Anne Storey: Yeah, I’m actually playing with a few approaches ‘cause I’m using it myself to see like where this should live or sit. My ideas around this are more at the idea mechanism level, and then how we instantiate it in a tool will play out, right, as we use it. I just wanna go back to one thing that you said, about architecture decision records. So in my tool, I have a waypoint type of architecture decision records, so those are actually waypoints in my tour. I see– In terms of where I see it working, it could be as simple as a skill, you know, that you, it, that, you know, maybe even the AI agent could help you generate the tour. Not fully automate it. I’ll get to that in a minute. So it could sit, you know, with the agents, or it could be within the IDE. I think it’s– If you’re using the IDE, then that’s where it belongs. That’s where we had it before with Eclipse. It was, you know, we ran a browser within the IDE, and we could show the tour, and people could kind of step through it. And then from each of the waypoints, you could then– for the ones that had a link to corresponding source code, they could click on it and go to the source code. So they could literally step through different parts, of the system and different kinds of artifacts to kinda dig in and read more detail about that. I hope that answers the full question that you asked. I feel like I might have forgotten something, but…

[00:50:16] What Is Strategic Friction and How Can It Help Developers?

Henry Suryawirawan: Yeah, definitely, I mean, the way I see it also, yeah, you can have a skills, from time to time that can kind of like prompt you to do this. Which leads me to the next thing that I find also very interesting that you mentioned, right? It’s called strategic friction. We are moving so fast now with AI, right? So, why do we need to have this strategic friction, right? Maybe because of slowing down, we have to slow down, right? So what exactly the form of strategic friction that you can advise people to do?

Margaret-Anne Storey: Yeah, so I think the cognitive tours… So I’ve just realized, I just remembered what I wasn’t explaining very well. So I think of the cognitive tours as cognitive infrastructure to help navigate from the intent layer to the technical layer. I mean, if you, you know, when you just… If you were, if you had three developers working very, very closely together building a tool from scratch, they may not need to write anything down. They all know, they all understand how it works. They all know who knows what on the team. And so maybe articulating that or having, you know, a way of helping you capture it is not needed. But with moving so fast and things happening over time, having that ability to document and construct your understanding, I think, is super powerful.

So one of the things that I’m trying to do to myself and, you know, marginally it’s succeeding at but succeeding a little, is I’m using the tours at the moment. I am gonna add AI assistance to help reduce some of the unnecessary friction. But some of the necessary friction I think is going slow enough that you understand the things that you need to understand. The decisions that you’ve made, you know, the insights that you had about your user needs. Maybe, you know, even down to some of the implementation of the features that you’re building, the different features that you’re building. How those connect, what abstractions you’re using, what dependencies maybe there are, right, between your features and also across your different components.

And so, what I’m doing is I’m documenting those manually as I go through, right? I have SpecKit, you know, I have one, I have one Claude window open, just Claude Chat, you know, helping me with the spec stuff. And then I have Claude Code helping me with the code. And then I have my own tool where I’m documenting, you know, what I’m doing and why I’m doing it, creating those waypoints, creating that tour so I can come back to it later on and create that bridge, if you like, from intent to code and back again, right? So I can look at the code and be able to go back. So that’s an example of friction, is slowing down.

Another example of friction that I think teams could look at is using more retrospectives or meetings, whatever you wanna call them, or code inspection meetings to slow down and not just review the code and have a little checkbox that says, yes, a human looked at this. Did they understand? How do we know? We don’t know. So, you know, slowing down to, you know, “I built this thing. Let me come to a meeting and explain how I built it.” And that has so much value, because now you’re not only sharing your understanding with your team, but as you’re explaining it to somebody…

Actually, I was doing this yesterday. I was explaining some of the architecture of my own tool. And I’m like, “Oh, I shouldn’t have done it that way.” So by explaining it, we get that deeper insight into our design that we’re surrendering, right, to the agents. I mean, there’s arguments about whether we sh- we will ever need to look at code in the future. But right now, I feel like we still have to have somehow control, right, over the code and over the architecture.

So the… I think those are some examples of friction and going slow. Keith Mann said something in a meeting to me the other day. He said, “Cars have brakes, so that they can go faster.” And I think, you know, we need to think about how can we design brakes, you know, into our environments, our development environments, or our habitats, as Russ Miles is calling it, so that we can slow down and actually build the understanding that we need, so that we can more safely and more efficiently eventually build the software that not just we feel comfortable with, but that our end users really want as well.

Henry Suryawirawan: Yeah. I like the way that you mentioned, you know, cognitive tool help to bridge the gap between intent and the kind of like the technical implementation. I think that is super important, right? Because sometimes if you just use AI vibe coding, I don’t think we even understand the intent that we want it to do, because AI will just suggest a lot of things out of the box, whether we want it or not want it. So I think definitely that’s super important, right?

[00:55:10] What Is the Danger of Relying More on AI Agents and Less on Humans?

Henry Suryawirawan: So speaking about, you know, people being replaced by agents and all that, I’ve heard anecdotally in some meetups that I go to, some people think that we can reduce really the amount of people that we need simply by adopting a lot more agentic workflow, automation and things like that. Is there a danger, do you think, that if we rely less on humans and rely more on these agents?

Margaret-Anne Storey: Oh, I think there’s lots of danger in that, of course. I mean, this question comes up every time with automation. I think the closest period in history to what we have happening right now is the Industrial Revolution. There’s a really interesting book about that called Blood in the Machine, you know, where the workers that were being replaced, you know, would burn the factories, you know, down the automation, you know. And they would riot because they were losing their craft, right? And they were losing their jobs and their livelihood. And the machines could be run by children, you know, that were then, you know, being abused and not well looked after to do it. And, you know, it took some time, right, before that kind of worked out. But there was a shift, right, in roles. And I think we’re gonna see the same with software as well, that some roles are gonna change, right?

I think… I mean, I’m in a software engineering program and, you know, some students are worried that software engineers are not gonna have work. I think the opposite’s gonna happen actually. I think as we have, you know, more ability to create more software, we’re innovative, right? Humans are innovative, and we always want more, more, more, right? And so we’re all- we’re just gonna keep wanting more and more software. And we’re gonna need, I think, you know, sure, we can have some agents keeping track of some things, but I think it’s gonna open up new opportunities, for other develop- you know, human tasks in terms of, you know, talking to other humans or making trade-offs or evaluating solutions within that context. So I think we’re gonna see a shift. You know, are jobs overall gonna be lost? Perhaps. I don’t know. I’m not an economist. I can’t, you know, really predict that. But I think overall, there are gonna be new roles that are gonna come out and that we’re gonna have to, you know, go back to maybe building better software that is more secure, and that is, you know, more reliable, performs better, and meets our needs.

There was also a few years ago, many years ago, decades ago, when computers were being introduced into the offices and there was, you know, this vision that paper would disappear. You know, the paperless office. And to a certain extent, that happened, but it took a very, very long time. And if you go to into any office right now, I can guarantee that you will see a lot of paper in the office. A lot of things are still used by paper. So I think, you know, we can look at that and go, yeah, that’s not quite gonna happen yet, right? But I think some organizations maybe had too many developers after COVID. So, you know, some of that is a correction because of that as well.

[00:58:26] Does the SPACE Framework Still Hold Up in the Age of AI?

Henry Suryawirawan: Yeah. So I want to bring the loop back to what we discussed three years ago, right? So, when we discussed back then, we were talking a lot about developer productivity, right? What actually drives maybe developers’ happiness and things like that. So do you think with all this AI thing happening, right, and this debt model that you just came up with, right? So what actually changed in that equation of developer happiness, developer productivity? Is there something that you think there’s a new thing that needs to be introduced in that?

Margaret-Anne Storey: Yeah, I think the SPACE framework, we had a, the five of us, I think it was five of us, got together a few weeks ago actually, and we had a panel at the University of California at Irvine. And we talked about that there. And I think the five dimensions stand up pretty well to AI. I think the way that you maybe think about each of those dimensions, and the way that you, the things that you look at have shifted. So maybe you remember Satisfaction is about, you know, wellbeing and satisfaction of developers using the tools. Performance is, you know, what are outcomes from the things that we’re trying to build, the quality of those outcomes. What is Activity are the, like lines of code, you know, or the number of tokens that we use or the number of PRs that we do. And then Communication and Collaboration is about that shared understanding and coordination with others. And then finally, Efficiency and Flow is that, you know, can people make progress confidently and efficiently, and are they also experiencing flow which then leads back to satisfaction.

So I think there’s a lot of open questions right now about each of these dimensions. In terms of wellbeing, you brought up one of them yourself. You know, are developers exhausted from using these AI tools? You know, what is the impact on cognitive fatigue, happening on their learning, on their sense of, you know, to thrive? You know, the, you know, the… our competency and how, you know, how much autonomy we have affect how happy we are in work and our wellbeing. And our research that we did earlier showed that developers that are satisfied with their work will be more productive, right? Will be more creative in the things that they’re building. So we need to be looking at that. What is the impact of AI on developer wellbeing? And are they being honest when we ask them questions in surveys? Because they may be afraid to answer, you know, “I hate AI,” right? You know, or, but, you know, but more about understanding how can it help them thrive and still feel, you know, that they’re building a craft using AI, that they still have that craft, not just being replaced, is important.

Maybe I’ll just talk about flow. I’ve got some research going on with some colleagues at the moment. Our paper’s on Archive. We just put a new version together, I’m not sure it’s up yet, called Good Vibrations, where we looked at vibe coding, and we looked at the implications around, you know, on the theory of flow. And as I mentioned, my student, Arty Starr, for her PhD work is looking at the theory of flow, two sides, you know, the troubleshooting side, and building and sustaining momentum. And so looking at those as we use AI are very, very fascinating questions, as we go forward. And then the performance, you know, one I hear a lot about that, you know, that a lot of the metrics are moving, but not necessarily the outcome metrics are moving. Which is kind of, you know, are users actually happier or not? So I think, you know, paying attention to that. I talked about that boat. We’re definitely going like super fast, but are we going in the right direction? And yeah, sure, we can use AI to also continuously deploy and even do A/B testing, but maybe that A/B testing is not asking the right question. You know, maybe things have shifted, right?

And then communication and collaboration. They… You know, I looked at, over the years, the way companies use SPACE and define metrics. And one thing I was always worried about was that you can’t just pick these metrics and then change one and then see what happens to the others. You really need a theory about why you might put an intervention in place and a hypothesis about what that might have. What will it improve maybe here but, you know, bring more challenge over here? And so I think using SPACE in that way is really important as we’re trying to do a lot of sense-making about how AI is having an impact. And collaboration is one of the things that, you know, I don’t think we could study that fast enough, because it’s changing. And it’s not just… a team is now not just, you know, developers, but it’s also agents, and how do they work across, you know, different team members. I have some research going on with a couple of folks from Monash University on that topic right now as well. So yeah. So I think the five dimensions are pretty solid. We thought long and hard about them. They came from years of research, and they were pretty solid. But what we look at, the kinds of questions that we ask and our theories about how AI is impacting them, are what we have to really kinda dig into now.

Henry Suryawirawan: Yeah. Super excited to hear your new research, right, about all this flow and all that. So I’m glad that the theory also holds kind of like this SPACE framework, right? And people can still use them. and I think one, one thing that you also have called out, right, these things have happened in the past, right? But the sheer level, of how it happens, I think probably is the difference now, right? The speed actually enforce us actually to look back at all these researches that we have done, right, this past trend, and maybe we can also learn from those as well.

[01:04:22] 3 Tech Lead Wisdom

Henry Suryawirawan: So Margaret, it’s been a pleasure, again, having you talking about this. I always find myself, learning a lot, right, because I’m quite fascinated by this topic. So unfortunately, we have to wrap up. Before I let you go, I have one last question. If you still remember, I have this question called three technical leadership wisdom. So maybe if you can share something today, that would be great.

Margaret-Anne Storey: Yeah. You did give me a heads up on this and I didn’t have time to think what are the three things, but I’ll try to suggest three. I don’t know if they’re the top three for me, but I think one of them is not just rely on metrics for measuring what’s happening with AI. You know, the metrics are measuring constructs which may or may not really measure the thing that you think. And actually it won’t, by definition, right? Metrics are a proxy for the things that we’re trying to understand. And so I think, you know, they can help. They’re definitely useful signals. But I would recommend to leadership to make sure that they are staying very close in touch with developers.

When I visited Microsoft for a sabbatical some years ago, I learned the most from going to lunch with developers, than I did from doing formal interviews or surveys. It was going to lunch. It’s where you really kinda learn, you know, what’s working well, what’s not, what are the risks. they’re usually very, very smart folks. And so sitting down and having conversations with them, observing their work, and I think everybody at every level in the organization should… Maybe they’re not gonna start writing code, but they can sit down beside a developer and ask them to walk through what it is that they’re doing and really un- and not just, you know, using the tool, but they’re, you know, a half a day or something, to really gain an understanding of what’s going on in the organization and what’s working well. So that would be one.

I think the other one would be don’t just focus on thinking about the code and using tokens. That, you know, I mentioned some prior work that I think is still foundational, and in the triple dot paper I talk about Peter Naur’s work where he talks about, you know, what is a software system, you know. It isn’t just the code. It’s the people, right, that are also involved and what’s in their heads and what they know about, you know, how we map the domain to the code and, and how, you know, what decisions we’ve made and what we can change in the future and what our design is. And so, you know, really, you know, thinking about, you know, that, that prior work, thinking about the social level, right, of the system, right? The people on the team, the different roles. Roles are really shifting right now. The boundaries between what is a program manager and a software developer and a designer, those are all shifting. So really thinking about, you know, how your teams are changing shapes and how the different roles are working I think is critical. Because, you know, helping that, you know, evolve in a good way is gonna be really, really important as we go forward to really amplifying how AI is used.

And then the third one I guess is, you know, about the triple debt. Don’t just focus on the code, right, the quality of the code. But be thinking about not just technical debt, but thinking about, also, you know, cognitive debt, which I’ve talked about a lot. I don’t need to say more about that. But also about thinking about the end users, right? So at the end of the day, we’re trying to develop the best software that we can for our end users. And maybe, you know, that now that we’re able to generate some of the code and redu- you know, spend less time maybe on that, maybe we can spend more time really understanding our users, right, and what they need, and are we really building the right thing so that we can delight our end users. So yeah, those would be… I think that was three. It might have been like seven, but anyway.

Henry Suryawirawan: Yeah. That’s a great reminder to always think about the end users, right? So, don’t just focus on the code and the features that you’re building, right? So thinking back to the end users is very important. Margaret, if people love this conversation, they wanna follow up, asking you more questions, is there a place where they can find you online and your paper?

Margaret-Anne Storey: Yeah, I can share the paper with you, if you like, the link to that. It actually was just published yesterday. It appeared on ACM Queue.

Henry Suryawirawan: Congrats.

Margaret-Anne Storey: So it’s… Yeah, yeah, I was thrilled that they accepted it. And I have some slides that expand on that a little bit as well if you want that link. I’m on LinkedIn. My e-email is broken for me. I get too many. LinkedIn is still sort of okay. You can try that. Yeah, LinkedIn is probably a good place to find me, yeah.

Henry Suryawirawan: Right. Definitely we’ll put that in the show notes. Again, thank you so much for this time today. I hope people learn a lot about the importance of, you know, putting effort on avoiding cognitive debt and also the intent debt, right? Outside of the technical debt, which is I think in some software teams we are still having that.

Margaret-Anne Storey: Oh, it’s still, it’s still a challenge. Technical debt has not gone anywhere in terms of it being a challenge. Yeah.

Henry Suryawirawan: All right. Okay, goodbye for now.

Margaret-Anne Storey: Yeah, nice to see you again. Yeah, take care.

– End –