Annie Vella on Why Engineers Need to Move From Writing Code to Solving Business Problems

Guest Intro

Swami (00:01.368)

Hello everyone, welcome to another edition of ContraMinds. In this episode, I’m talking to Annie Weller. Annie Weller is an engineering leader, passionate software programmer, and a researcher. She’s got over 20 years of work experience across four countries and over 12 industry verticals.

She’s today a researcher and her advisory work is at the intersection of AI’s impact on software engineering and agentic governance. She’s a thought leader and runs a very successful blog and speaks at various international conferences. Over to my conversation with Annie Weller.

EPISODE TRANSCRIPT

Q1

Having seen the various waves of how software engineering as a industry has moved, what do you think fundamentally is changing in software engineering as we speak today?

Annie Vella (05:21.762)

You’re right. It has changed a lot over the decades. What is software? At the end of the day, it’s a lot of code. Code is syntax, it’s words, it’s language. It’s a very well-defined, precise language that we use to very specifically define how something should work. So you add these two together and it’s almost a perfect match, right? You’ve got this new technology that can generate language.

And if you give it some constraints and train it on programming languages and well-written code, it can generate well-written code as well. And when we build software, we run it through a number of deterministic processes, right? We’ve got that’s what pipelines are there for these days, but you you compile it, you build it, you run some automated tests on it, you run it through static analysis, linters, and a whole host of things.

Those are our verifiable loops as well. I know the there’s a lot of conversation around how you’ll see this either in you know, social media or people like to say software engineering was never just about the code. And they’re right. It should not, it was never meant to be just about the code.

But a lot of what we did was in service of the code being produced, And and now with this technology, the writing of the code is almost entirely automatable. It’s not perfect, but we didn’t write perfect code as humans either. That’s why we had all those verifiable loops to help us catch the problems. And many engineers got into this career because they loved mentally solving the problem and then turning it into code through hard work, through effort, through a form of creativity.

And I think for them, the people who got joy from that type of work, they’re really seeing the shift 1as something that’s not pleasant. And that makes me sad because I I’ve enjoyed my career so much and I recognize it’s changing, but I kinda hope that maybe we can start to define what it may look like.

It just looks different, I think.

Q2

Swami (12:26.992)

So I want to dive in on a couple of points that you made and I’ve kind of noted them down. See, one of the points that you said was the role of the software engineer is changing. So how is the role of the software engineer changing? Can you define it by a framework? Because I really loved your framework of the middle loop, right? So how is it changing and was there no middle loop before AI and is the middle loop the new in between between the inner loop and the outer loop? So can you walk me through how it’s changing the software engineer’s role?

Annie Vella (13:15.054)

Just the the process of building software generally requires some form of solution design, writing code, reviewing code, testing it, refactoring it, debugging it. And I asked software engineers if they felt they were spending more or less time on these six core competent core tasks. So that meant I ran two questionnaires six months apart with the same participants. So I could see how their own perceptions were changing in that period of time. And so that was between the end of 2024 and beginning of 2025. And of course, with everything changing so fast, things will be different today as compared to what I captured then.

82% in of engineer of participants in my study felt that they were spending less time writing code. And the only one of those six tasks where they felt they were spending maybe a little bit more time, just slightly above neutral, was reviewing code. All of the other tasks they felt they were spending less time on, but not quite as as many as thought they were spending less time on writing code. So how is it that this technology is on the one hand, it feels like we’re spending l less time on all the things we used to spend time on, and somehow we’re filling our time with something else. So the qualitative data that I captured through some open questions, I did some thematic analysis on, and inadvertently I saw in there, I started to see some in those in those responses, I started to see evidence of people spending their time on essentially a new category of work, something that wasn’t well captured by those six sort of core tasks that I asked about more specifically.

And I felt that this was maybe representative of a something that I’ve given a name to, supervisory engineering work. Because what they were describing was spending more time directing AI through prompts and iterations and sometimes quite a bit of frustration, you know. And then evaluating its output to check for correctness and, you know, how does this fit into the existing code base? And and then correcting it when it’s not right. And I think that takes a different type of skill. And what happens to comprehension of the code, right? So previously, when you did it by hand, you spent a lot more effort doing that, and you really you might not have understood the entire code base, but you understand the changes you made. Whereas now businesses still demand that their engineers are accountable for the code that they are generating and committing. That’s becoming harder and harder, especially when we’re asking them to go faster and faster with this technology.

Where we spend our time as th they’re the skills we practice deliberately. And if we’re not practicing those skills anymore, instead we’re spending our time on something else, then those become the skills that we we will gain

Q3

Swami (19:38.597)

Interesting. So there was the other point that you talked about in the outer loop, which is deploying, reviewing, monitoring, which was something that you, once you deploy the code and the application, then you’re kind of doing that. But that also today agents are taking over and running it, which means that you are actually having a middle loop that, from what I understood where I’m neither writing the nor doing the DevOps and the monitoring, which means that what am I doing and therefore what skills as a software engineer do I need to build is really the question that you were asking. So can you explain that a little bit more?

Annie Vella (20:20.013)

Yeah.

Annie Vella (20:25.048)

Good point. Thanks for mentioning the middle loop again. So what’s quite interesting is as a professional software engineer, I I have heard the terms inner and outer loop for some time now. And the inner loop is more think of it as what happens on your local machine. So if you’re a software engineer, you’re building code, you’re in your integrated development environment, you’re writing the code, you’re building it locally, so that means compiling it.

It’s running your build locally and and testing it locally if you can run your test locally.

And then the outer loop was more about like once you’re done with your sort of individual piece of work, you you might push a PR up, a pull request for somebody else to review and then merge it into a a pipeline takes over, and then your product owner or the the person in the team that’s more responsible for getting it released, maybe putting out some some comms about it, you know, and so that that’s more of the outer loop. But like you just said, the this this type of supervisory work, it’s not really inner loop work where you are doing the work yourself and manually building it and feeling those individual little issues yourself and it’s not out-of-loop work either, because that that’s like when it’s almost l left your local machine and it’s it’s being integrated into the bigger code base.

Because I feel like it’s a new category of work, maybe it’s actually an entirely new loop that sits in between these other two loops, Maybe it’s a new middle loop. Maybe it’s that’s where supervisory work happens. And then I think maybe around the same time or a couple of weeks later, people started talking about harness engineering.

And by the time I finished the masters, nobody was even talking about prompt engineering anymore. That’s how fast this is all moving, right? It went from prompt engineering to context engineering to harness engineering. Now it’s loop engineering or graph engineering. And I guess I contributed to the problem myself by coming up with the supervisory engineering work.

And the sorts of skills that you need for that, well that all is, I think, still changing and evolving almost daily at this point because it still feels like it’s very important to have fundamental foundational software engineering skills because otherwise how do you apply that judgment to know? How do you value evaluate and verify that the code itself is correct if you don’t know what good looks like you know looks like without having done that gaining those skills in some way? And that’s a bit of a concern because a lot of the way that we gain those skills is by doing the job.

Especially in those first formative years, you know, we we learn by doing. And if now the agents are doing it for us, how do you how do we gain that experience? I have a feeling that we need to learn how to develop a and like a sixth sense on how systems are performing after they’ve been written by AI, because we are definitely moving in in that direction where we’re letting AI write more and more of the code. We’re letting AI review the code that is written by another AI. And so we need to be able to observe the system and see through like observability, right? looking at the the signals that the system gives us to get a like a sense of whether it’s doing what it’s supposed to do, you know, that’s one way of looking at it. Another way is to think about things like formal verification that might help us have a more confidence in the correctness of the code.

Perhaps not whether the code is doing what the intent of it was, because I think that’s that’s still where human judgment should should be utilized, right? If you have a problem that you are trying to solve with software, I don’t think that there’s any mathematical style formal verification that will be able to judge that for you. That’s that’s the human role now. But how do you teach that? Judgment and taste are not easy to teach. It’s almost like a trait, a human trait. So we’re in a very this is this is precisely why I felt like I need to step out of any loop at the moment and try and see observe the loops from outside of them to see, you know, and dive in every now and then to see what’s really happening here.

Swami (28:54.096)

Beautiful, beautiful. 

Q4

So if I’m a, a 20 year old or a 10 year old engineer, software engineer, I’ve already, I’ve built the knack of writing code, now that if the machine is writing it, the challenge that I have is, that’s a skill that’s atrophies, right? Because, you know, it’s just going out of me.

Annie Vella (29:21.11)

Yeah.

Swami (29:23.236)

That’s one problem. It’s great because then in a code is being generated at speed and therefore that’s great. think businesses will be very happy about it, but it’s a skill that is decaying. At the other end, if I really do not know how to review the basis, why it is writing it, then the challenge is my knowing doing gap starts to really increase. So therefore, how do I prepare? Because the challenge that I see is that if you do software testing, the nature of software testing itself is changing because you’ll have a set of use cases, you go there and you test it out and then say it’s done, now it’s ready for deployment. But now that the code has been written by an agent, the challenge is even the way you need to do verification, has to be automated and therefore the scale of verification is also reaching a velocity that probably there are going to be new, I would say, careers, new roles that are going to come up. Is that the way software engineering is changing?

Annie Vella (30:42.22)

I think so. But there are elements of the production of software that can and should be abstracted away and and centralized or standardized and done automatically for us. And that’s what platform engineers have been doing for for some time now. and I think when we talk about harness engineering and building these harnesses, the the the thing that your agents run within that keep it safe and put the right controls in place and governance and identity and I think that’s just kind of the next generation of platform engineering.

And then so then humans become more and more responsible for verifying the output of that. And as you say, like with a huge increase in the throughput of the ability to create code, there is no way we can just ask engineers to review it all by hand. So formal verification was is the the it’s part of this concept of formal methods of computer science where you can prove given a precondition and a post-condition and an invariant, something that you feel must remain true, that a certain line of code, or used maths or code, is correct for an entire class of problems. So for all natural numbers, this function will return true or will terminate or something like that.

And it’s more efficient in some ways than testing because testing is almost like sampling, right? Is if you’ve thought of all of the potential edge cases, then hopefully you’ve caught them all, but chances are you haven’t because the problem space is too wide, right? Whereas with formal verification, if you can capture entire classes of problem, then you can literally prove the correctness of some functions.

But it is becoming easier to do because there’s better tooling to do it now than when I was learning this twenty-three years ago. And AI can help with it as well. So there’s sort of two sides to it. You need to be able to formally specify your requirements in a formal specification language and then actually write the proofs that prove that this is true.

And so perhaps we don’t apply that to every piece of software that we build, But if you’re working for a financial institution or a healthcare provider where actually it really it does matter if there’s a subtle problem with the code that is now generated by an AI, that humans can’t be expected to continue to just verify by eye, by sight, by hand. Maybe in those cases formal verification has a role to play. 

COLD OPENING 01 of 02

I think it’s a mistake to expect that the software development lifecycle of the future is just going to be a subtly different version of what we’ve got today. I think it’s time to rethink it entirely because perhaps what we’re doing now is in building these harnesses, we’re building the machine that builds the machine. And so we have to look for different signals using things like formal verification in one case, but when you start to think about it like this, it starts to feel more like a control system. 

We we need sensors that tell us that the software that the agents are building is off slightly. It’s not it’s not adhering to the requirements well enough or it’s not adhering to our coding standards and best practices. So we must tweak something about the machine for it to do better on the next loop, And that’s exciting. I think that’s that’s true engineering work. Other engineering fields have used control systems and control theory for decades. Maybe it’s time that as software engineers we maybe we mature and graduate a bit to to thinking like other engineering disciplines and and think of our life cycle as more of a control system that we manage from the outside. Maybe.

Swami (38:48.944)

Mm.

Q5

Swami (39:10.394)

That’s a very, very relevant point that you’re making, Annie, because your articles made me reflect on a few of the points that you just making. And I was just going back. It’s almost like somewhere you mentioned that, know, Deming saying that, you know, you don’t do quality check on a finished product, right? So I thought it was a very, very telling statement that you had written in that article and then I went back and started saying, okay, how did this happen during the industrial era? Right. So for example, I was a tailor, I was a cobbler, you know, I was a carpenter and machines were not there. I was doing by hand. Suddenly the machines came in. So what happened to these people? Okay. 

I think there’s a lot of learning that you can pick up from that era of change where you had machines building your trousers, your apparels, and suddenly the tailor skillset was gone, right? But what it did was you basically started having apparel designers, okay? You started having merchandisers, okay? You had a whole new category of people interested to design the apparel and earlier they were actually designing it, building it, maybe selling it, servicing it, maybe everything was being done by hand. Suddenly you had a whole set of new roles that came in and to me that analogy in say, if I look back and say, okay, if I was a cobbler, what I did was it’s not that, you know, shoe making when it was being done by machines, then we had a whole category of people who are shoe designers. So you had basketball shoes, running shoes, you know, you had, you know, cricket shoes. So you had a whole host of new methods of, you know, wearing these shoes and you had designers coming in, looking at a need and solving a problem because the machine could anyway build it. 

So the definition of the problem and the designing of that need, maybe the role that software engineers have to start playing rather than actually doing the code. Maybe that’s really where probably the industry is moving and therefore this shift is something that people have to be ready for. Does that make sense to you? Does that resonate with you?

Annie Vella (42:01.099)

Yes, and I I think there’s a nuance to it. There’s a couple of nuances. I think there will be a subset of engineers who gravitate towards building that harness, right? Like that really putting in place the tool that other engineers and and maybe non-engineers use to produce software, working software. And there’s some really really interesting engineering work, like building the rigor into that. 

And then I think that there’s a whole other subset of engineers who maybe more attracted to becoming a domain engineer. But what I mean by a domain engineer is someone who understands the domain they’re working in and has an interest in it potentially even a passion in it and they talk to customers, they talk to the stakeholders, they directly as well, not through various other roles that, you know, by the time the engineer’s hearing about a problem, it’s it’s been translated fifteen times and it’s hard for the engineer to even get a sense of what the real problem is. And then they can using the tools that the harnesses and the agents and all of that, they will be so much faster and and better equipped to solve those problems for customers.

You know, somebody who works, I don’t know, they’re processing claims for an insurance company, they are claims specialists. Bring an engineer, invite an engineer, in like a more of those domain-focused engineer, into your your team to observe how you work and work out how and where software might be able to improve the efficiency, the effectiveness of the work that that team does. I also think though that there’s a subtle difference between the examples that you gave in that AI is such a this version, generative AI, is so general purpose. 

COLD OPENING 02 of 02

You can use generative AI to write code or to write the requirements or to write the tests or to write the deployment pipeline or to learn about all of these things. It’s more like electricity than say a calculator or a GPS. 

And the difference that matters there is when we introduced things like a calculator or or perhaps a specific tool to make trousers or something. That was that eroded a very sort of surface implementation skill.

 But generative AI has the potential to take some of the more core cognitive capabilities as well. The thinking, the reasoning, the critical thinking, right? The judgment. There are skills that we’re happy to delegate to technology because they save us time and they were kind of toil. But we can’t afford to be delegating all of our critical thinking and judgment as well.

Q6 — Swami (48:26.426)

Yeah. no, no, but I, but I, I just think it will evolve because the fact is just imagine if I’m building a car today, there are guys who are product designers, right? There are, you know, guys who are maybe internal combustion engine engineers, right? People who are specialists in thermodynamics. Okay. then there is this whole set of guys who are into plastic material engineering. Now, if you really go and roll back the car, actually so many engineers have contributed to the final car.

Similarly, I think we are at a stage where if you look at AI, the way I see it is if you go to a shop floor, the shaping machine is there, the lathe is there, okay? All these machines are general purpose machines. So the important thing is what do you make out of the product in that shop floor is really what I think the analogy to take. And therefore, if you’re a software engineer, the word that you use, you being a domain engineer, you can actually be a claims specialist engineer, or you can be a customer service engineer. And then you basically have to use the cognitive side and the process side and you have to bring them together. The cognitive side is what probably AI will help you enhance. The development side, which is the process, where maybe 80 % AI will help you, but your ability to coexist in this environment is the skill that probably you need to build and that’s really where I think you’ve used a word interesting word where you said review is the new bottleneck. It’s not the code which is the bottleneck. It’s really review which is the biggest bottleneck and therefore how are you going to build that skill of building and looking at these agents working at either collaboratively or at cross purposes and your ability to kind of look at it from a cockpit and then say, how do I solve it? Is really the skill that you need to have, which means that you just can’t be a, you know, a single lens software engineer that you were. You are now going to actually look at it from the cockpit and your cockpit may not be the enterprise cockpit. Your cockpit might be the, probably the two gauges that you are probably looking at, but that gauge you should know is really affecting the larger system and therefore you talked about systems thinking. So the software engineer of tomorrow will become a systems engineer. Is that the way you thinking of software engineering of tomorrow?

Annie Vella (51:31.692)

I think so. And I am still very much at the beginnings of a journey to learn about systems engineering. I think we have a lot to learn from them to help the next generation of software engineers move in a direction that is needed, that has skills that they can build in it, that will help us build reliable software that actually solves problems and and is fun to do. 

Like if you you might become a acclaimed specialist engineer and you will be able to contribute great value to that domain by having an understanding of how those people do that job, what that process looks like. We’re we’re lifting up and out of the minute detail. You know, those semicolons that used to trip us up and you know the syntax. So that we’re not great as humans. That that’s never been a huge strength for us, which is why you had to be incredibly smart to be able to get a job at somewhere like Google where to to pass the interview you had to do these elite code exercises and write a recursive function that uses the least amount of memory and and people study so hard to to get that type of thinking into their mind for those interviews because it’s almost like passing an exam.] Nowadays, well, AI can do that pretty well, right? And and that’s maybe not where a software engineer needs to be spending their cognitive effort.

Instead it should be applied sort of up and out of that to to help deliver functioning software for teams that actually need it. I think we need to find a way to make the reviewing code part simpler for us, more with more assurance using other techniques. There’s a whole bunch of different testing approaches like property-based testing and differential random testing, but perhaps we’ve got to broaden our thinking on the ways to assure that the software that’s generated by AI does what it’s supposed to do so that we free ourselves up to do more of that higher level thinking.

Swami (54:38.506)

And I totally agree with you. Let me tell you that because I just read this quote out of your blog and I think it just got me into a rabbit hole. And one quote that I read, I think, where, you know, you’d given us links, you’ve given me links to go to different people. There was one quote by Peter Drucker, Drucker says, when a worker knows more about the work than the manager, you manage by objective, not by method. Okay. So the software engineer of tomorrow, you are not going to be saying, do you know C plus? Do you know Java? but you are actually going to say that that’s the method, right?

And suddenly your ability to look at the big picture with connected systems is really what the big change in the software engineer’s mindset is really what I thought you were talking about.

Annie Vella (56:23.744)

Yeah, yeah. And and it is significantly different to the role that most software engineers have played through to now, which is why I think it’s it’s it’s being felt as such a a big significant change. And I yeah, I don’t think software engineering is dead like you see so many bold statements out there. I just think it looks so different that we might not even recognize it anymore.

But we we need to be be comfortable in the uncertainty and also be comfortable in in knowing that we need to adapt.] and I think we do it better when we share with one another what we’re seeing and learn from one another. It’s my hope.

Q7

Swami (57:39.621)

Fantastic, fantastic. On that note, I just want to digress on two points that you made and not related to software engineering, but I think I’m deeply interested in that area. Therefore, I’m going to ask you a couple of questions. So you said you were working in software engineering and you never felt it like work, right? All these years. So tell me a little bit about that and how does one reach that state because it’s a flow state that people talk about. There books which are written, but what made you say that? if you can, right, unpeel it for me saying that, you know, why did you feel that? Because that’s a very important state because that then allows you to deeply engage with your work. So can you talk to me about that in a little bit of a detail, maybe a couple of minutes?

Annie Vella (58:37.582)

Sure. well I credit that with my my interest in solving puzzles. And I think for me on a very personal level, solving well building software felt like solving puzzles just with a different tool than a jigsaw puzzle, for example. I remember once, I’ll give you a a a solid example. So when I was working for a company in the Netherlands, they were a a photo book printing company. I didn’t even know photo books were a thing. And this is the the beautiful thing about software is that we use it in every corner of our world, right? 

So if you are a software engineer, you will have such a wide variety of choices of places to work. It doesn’t have to be banking or healthcare, it could be just any vague corner of the universe. And so PhotoBooks was where I ended up. And my manager wanted he needed a new piece of software built to solve a particular problem. And rather than sort of do it top down and say, I’m gonna pull out these three people and you’re gonna work on this now, he he put it to the team as a bit of a like a competition. He said, We need this thing built put your hand up if you would like to lead that piece of work, if you have any ideas. I give you one day to do a prototype and then sell it to me. And then I will choose who I think is best placed to build this. And I thought I can do that. I understood the problem well enough and I had some thoughts on how I might build it. And I wasn’t the only one. There were at least two others I remember who set about trying to to do the same. And I built a little prototype and well, long story short, I I won the competition and I won the right to lead this piece of work. And it felt mine. It felt like I was like I owned it. 

I owned the not the problem nor the necessarily the idea to solve it, but I owned the the way in which I thought it should be solved and software has so many layers to it that you can think about the the overarching architecture as well as every component, how they will be designed down to the code architecture level, right? So that it be it’s easy to fix in the future or to modify in the future. It can be extended. It can be it’s flipped inside out because that’s often what we need to do with software. So there was always a mental challenge there for me. And that’s I enjoy doing that whether I am working or not working. I do jigsaw puzzles in my spare time. Yeah, it it just feels like I was being paid good money to do what I enjoyed doing anyway, and hopefully deliver something that actually made a significant difference to the business I was working for. 

And you know, I got so much joy from solving the problem from the journey of that problem solving process and everything I learned, you know, and at the end of it, if if I get it right and I produce something that is useful, the satisfaction the reward of knowing that that was your work that you can be proud of. Like it’s it’s this beautiful loop of, you know, challenge, effort, earning the reward and then doing it all over again. So I I just can’t imagine having done anything else with my career. I that I’m so glad that my parents bought me that Commodore 64 when I was so young because it it put me on a path. You know, if I hadn’t had that experience I wonder if I would have ended up in the same place, I don’t know.

Swami (01:02:28.816)

So therefore what you’re saying… deeply understand what you like or explore or discover what you like and then start doing more of that. Make it your work. Do more of that by challenging yourself and once you start doing that, you end up in a state where you will of course earn money, but you will not feel that it’s work. You have to go through this loop is really what you’re talking about. Am I summarizing it well?

Annie Vella (01:03:09.76)

Yes. Yes, I think so. And there’s an element of earning it as well, which which AI somewhat threatens as we were talking before because it’s just so easy to delegate all the thinking and all the doing. But if if you I was just yesterday having a conversation with someone about how, you know, I I used to do some long distance running. And to do that I I don’t at the moment because I spent too much time in front of a computer and I’m not as fit as I was before, but you put the effort in, you just you set yourself a challenge. I’m going to run a half marathon one day. And you can’t just get up tomorrow and do it with no training. So you earn the right to be able to do that and be healthy afterwards. And that hard work, it it feels like the the satisfaction of having gone through with it is I for some of us at least is what drives the next step. You know, I’ve done I’ve conquered that now. What do I conquer next? And if you can do that on a topic that you are already interested in and want to understand at a deeper level. Those two things marry up so nicely together and hopefully there’s work in that area and that then it just doesn’t feel like work. And that’s also like can’t be a there’s two sides to that, you know, there’s a little bit of a double edged sword. If it doesn’t feel like work, you’re tempted to do it twenty four seven. And sometimes you’ve got to take a break as well. But if it doesn’t feel like work it’s it’s much better than feeling like it’s a chore, right? 

Swami (01:04:40.986)

So which really means that I’m connecting where we started to where we will end. Therefore, in software engineering, more and more code gets automated, more and more code gets automated, the fact that you need to do a lot of side projects where you are still building your craft as the machine codes, let it code, but the fact that you have to keep your skill and your hands agile or your mind agile because it may still do it. But the fact is you got to build a lot of side projects and you will do side projects only if you are interested in that particular job. Otherwise you will never do your side job. So therefore the fact that you do more of those side jobs, then you build a natural capability to look at the supervisors…supervisory engineering that you’re talking about, which is supervision engineering that you were talking about. So which means that you’re building the side project, then you know what you’re supervising, therefore you’re able to understand it a lot better and therefore direct it a lot better across the systems. That’s the way probably this whole world of software engineering is going to change and that’s what software engineers need to be ready for, right?

Annie Vella (01:06:04.182)

I believe so. Yes, you’ve summarized it really nicely. Yes, and absolutely. If if it’s something you enjoy doing, it won’t feel like a chore, so you’re more likely to do it, you’ll gain more experience doing it, you’ll have that salience around just a sixth sense of it’s working as it should. It’s produced good code and it works like it should. That will happen naturally. It if you try and force that because you want to work in this domain, it will only last so long and you may never reach those levels of flow that feel good, allow you to take pride enjoying your work and produce good outcomes. And it takes time and you know to to gain that those that intuition. But now the intuition we gain has to be gained through a different filter. It’s it’s not by manually doing so much anymore, but it is still through experience of directing, evaluating, correcting the through that supervision.

Swami (01:07:08.346)

Fantastic. On that note, Annie, thanks a lot for talking to me. I could see the deep thought that has gone in, in your search for how this field of software engineering is changing. And I could pick up a lot of nuggets of how you need to look at it, how you need to transform, and nothing is still cast in stone, but the fact that you’ve got to be ready for this change is really what I think I’m taking out of this conversation. It’s set of beautiful, I would say paintings that were there. You you got to figure out what the meaning of that is. And that’s really how I found this conversation. Thanks a lot. Thanks for your time.

Annie Vella (01:07:54.968)

Thank you for the conversation and for allowing us to observe those paintings and and and extract some meaning together from them. Thank you.

Swami (01:08:05.082)

Thanks.

END