When AI Writes the Code, What Happens to Software Engineering?

Host

[00.00.16]

Hello and welcome to the enterprise Tech Talk podcast. I am your host. So now artificial intelligence is rapidly changing. Software delivery AI tools can now, uh, we'll write the code design test cases, um, review the changes and even help in, uh, debugging the software. But writing code using AI also has some important implications. For example, would would it necessarily lead

to better quality of software? Uh, what are the implications of software architecture technology, um, engineering skills and the team sizes? And how can technology leaders adapt to this change? To explore all these questions. I'm joined today by Brian Childress. Brian is technology leader with two decades of experience across startups and financial institutions. He holds multiple US patents in software design and application security. Uh, his work specializes in, uh, software architecture, simplifying complex systems and improving, uh, engineering delivery. These days. Brian also helps engineering teams to adopt AI assisted software delivery practices. Brian, welcome to the podcast. Great to have you here.

Guest

[00.01.40]

It's great to be here.

Host

[00.01.41]

All right. Let's start with a broader question on how AI is influencing software delivery. Because as you and I know, when AI was introduced in the in the world of software development, the primary use case was around, uh, reviewing codebases and and generating small snippets of code. Right. Um, but we have come a long way since then. So where do you see, um, how AI is positively influencing across the software development lifecycle these days and what are still the untapped opportunities?

Guest

[00.02.21]

Yeah, it's it's been really interesting to see, especially as the industry continues to adopt more and more AI throughout the SDLC. One of the big things that I'm seeing is we it feels like everything is changing, and then at the same time, nothing is changing. And what I really mean by that is, uh, so much of how we, uh, develop software, the ways that we think about the software that's being built and how we start to to define and structure the code. Um, a lot of that is changed. Um, you know, now, instead of me going and getting into the flow state and developing, uh, for several days, potentially on a big feature set. Um, it's very much a a quick set of planning, sending off my agents to do the work and then checking on the progress later on. And I'm doing multiple of those work streams at one time. So instead of being deep in one problem, I'm spread across multiple problems. Um, at the same time, what hasn't really changed or what really has become more and more important are the good, strong engineering practices that surround. How do we build software? Not just how do we write the code, but how do we go about thinking about building the software? How is the software structured? Um, how what technologies are we using? Uh, how are our code bases laid out and architected? Uh, what is our deployment process? What's our review process? So many of those things have been have become just so important, um, and are really revealing the, the next bottlenecks within our organizations. Uh, just because we've shifted how we generate the code. Uh, just one piece of the puzzle now has really, uh, had a cascading effect across the entire software development lifecycle.

Host

[00.04.14]

Yeah. Now I want to come back to that. Um, the points you mentioned about the importance of good engineering, engineering and software architecture practices, which is becoming more and more important. Uh, but before we go there, um, where do you see, uh, uh, the a there is a difference between, um, an AI generated small app which is completely based on a generated code and having an enterprise grade, um, uh, system in place. Right. Where do you see, um, AI is, uh, the maturity of an and how much it is, it can be used to build broader enterprise grade software today.

Guest

[00.05.00]

Yeah. So I think AI can be used for both for a very small one off bespoke application. Maybe I'm only using it. You know, that could be the the one shot prompt. Create something and I'm okay with the results. When it comes to enterprise development, I also see a lot of opportunity for leveraging AI assisted, uh, development tools and practices. Now the big difference is who is leveraging those tools and how are they being leveraged in the process. And I think that's a big piece of where we're starting to see engineers starting to diverge is who is kind of putting in a prompt and taking whatever is, uh, comes out of the machine versus who is really trying to make sure that it's guiding the process, really keeping a close eye on how things are being developed, how they're being constructed. The latter really does support a robust enterprise application. And just because AI and AGI agents are writing all that code doesn't mean that it can't be a robust, stable, secure, maintainable platform.

Host

[00.06.10]

And one thing which I'm seeing, um, at least within the organizations, which are technology saving, which are strong engineering, um, uh, teams, um, uh, when it comes to solving new business problems, new opportunities, they always have two options that these are on the table. One is, yes, go and procure the software SaaS products. Right, which are specialized in delivering that particular capability or with a uh, a are now helping in building the software. Can we build our own custom solution to, to deliver that particular business problem? And, um. There has been a notion around whether there is a future for stars. Even a year in organizations can start building their own software. Where? Where is it on that debate?

Guest

[00.07.06]

I have to give you the classic it depends answer, because I think it really does depend on what the software is, how the organization is using that software, or at least a subset of the features of that particular software platform. And then also do they have the resources to be able to design, develop and support one of those platforms? And I think that's something that, you know, we talked about the SaaS apocalypse coming, you know, maybe 8 or 9 months ago. And I don't think that that's necessarily true. Um, if I'm in, you know, if I'm building like, say, sales software, I don't necessarily want to build some of these other platforms. I would much rather pay a monthly or an annual subscription to another platform that specializes in that particular area, use their tools, use their functionality, and then I don't have to support it. I don't have to become an expert in that other area. And I think that's a big, uh, thing that gets missed in a lot of the conversations is now just because I can build a new say CRM doesn't mean that I have the expertise, the capabilities to design and support something like that. It's much better to just kind of, you know, pay the subscription. Now, counter to that, though, I do think it's important for us to really look at how are those SaaS platforms starting to really evolve? Uh, things like how do I get and access the data that's within one of those platforms? How does that platform fit within the evolution of my organization's ecosystem? We're seeing a lot of integrations with a lot of the different tools, say, a cloud desktop or a Codex, where users are largely staying more in those types of platforms, but want access to the functionality to the data that some of these SaaS platforms would be able to provide. So your

Host

[00.09.01]

point, I think when one guardrail could be is that ability really a differentiating capability for your organization? Right. If it is a differentiating one, probably you can think of building an IP around that. But if it is not, then what's the point in building that software and then maintain that, um, in-house. Right. It's better to have a subscription around that category. Right. Um, uh, the the the question I have is, uh, AI is naturally helping to expedite delivery of software. Right. And at the point you mentioned around, um, you can potentially now work on multiple problems in parallel. Right. Uh, uh, what are the implications you are seeing in terms of overall engineering productivity? One. And the second is what it means into the over how organizations looking at team sizes for engineering do you you see invariably we will start getting into a smaller engineering teams. Um but large number of engineering

Guest

[00.10.08]

teams. Yeah. I'd like to start with that last question first. I am seeing much smaller teams being very, very effective now that they're able to really leverage, uh, these AI agents and a lot of the AI assisted tooling. Uh, you're seeing, you know, what would have taken projects may have required three teams of, say, five developers might be done with just a team of five developers, maybe even smaller, depending on what the project is. Uh, full big projects that could have taken months are now taking, uh, weeks to be able to complete again with a very effective set of engineers working on the problem. Now, How is it changing and evolving is definitely an interesting thing, right? We're seeing the different bottlenecks that are coming up, not only with the understanding what is it that we should be building, not we can build anything. What should we be building then? The review and the verification of did we build something that is actually going to stand the test of time? Is it something that's going to support our user base as it continues to grow? Is it something that our team can continue to support and extend over time? And those are the challenges that I think I'm seeing many teams struggle with right now. I think all of us in the industry are trying to figure this out, like, what is this new rhythm? Because the code creation part of it took a long enough amount of time that the other parts of the the flow didn't really reveal themselves as they are now. If

Host

[00.11.42]

I had to unpack that that thought a bit further. Ryan. Um, uh, so yes, AI is definitely to write the code faster, right? And potentially automating test cases, um, etc.. Are there still any untapped opportunities or bottlenecks? I would say in the SDLC, where the end outcome about having frequent releases is still not potentially. But we would have expected.

Guest

[00.12.14]

Yeah, I think I still see a lot of opportunity for, uh, continuing to improve just the robustness of the software that we are creating. To your point about writing test cases, for example? Unfortunately. Right. Every engineer wants to have, you know, a nice set of tests that they can trust and really, uh, gives them confidence in the code base. Oftentimes, that was always the thing that was neglected because we had, you know, growing scope and tightening deadlines. And so things like tests, things like security, those were often neglected, uh, in favor of that. Now, those should be there, not only, you know, good best practices, they're almost required as part of developing the the software and, you know, effectively with good guardrails and guidance. They come for free. Right. Uh, if an agent is able to write those things and get them into place, um, so we can be much more productive, but because we can put those best practices in place that we before we had to kind of, you know, decide, is this something that's important enough for us to put in right now or not? Uh, additionally, I'm seeing a lot of opportunities for, you know, things that, again, they they might not have bubbled to the surface right away, but there are opportunities for us to leverage these new workers, right? These new things that can go and solve problems. You know, one way that I really start to leverage, uh, agents in a lot of my projects is, hey, go and look at our error logs for the last 24 hours and identify what are the the common scenarios that are happening and proposed solutions. You know, those are things that honestly, you know, a few years ago I would have had to, you know, decide, hey, is it worth it if we had 700 of these errors over the last week or not? Now I can have somebody go in and work on those, even if it's a small number of errors, just because it is so quote unquote cheap for it to be addressed. And I think there's still a lot of opportunities for us to do that. And again, that will continue to compound and increase our productivity because it does address the the quality piece or the verification piece that's really, really important in building high quality enterprise software.

Host

[00.14.37]

Um, I also want to understand the implications of our use of AI, um, in the overall software architecture and engineering planning activities. Um, because one thing is, as as we discussed, AI can help us to generate code where AI can generate a large volume of code as well. Right. And there is always this risk of, uh, what's called as a, as law. Right. Uh, where the code is generated, but not necessarily. It could be of highest quality. Right. Uh, what are the practices emerging in, in, in, in the engineering world, which ensures that, um. The quality is maintained. Second thing is, uh. Uh, there are there is a method to how you use AI to build the software. Write the code. For example, there are there are best practices emerging around software spec driven development and others. Right. And I want you to understand that, uh, picture holistically as to what are those practices and patterns emerging, which will help us engineering teams over that as, uh, in the first place.

Guest

[00.15.52]

I think it again, it comes back to good, strong engineering practices in general, the things that we should have always had, the things that we always wanted to have in every project that we've ever worked on. And for me, that's always been good foundation. Uh, good patterns that are established very early on that are enforced, that every developer kind of follows as the the project grows and evolves. And I think that's even more true now as we have agents doing the authoring of the code. Uh, if there are two ways that something is done within a code base, an agent isn't going to pick one of those. It's going to come up with a third new bespoke way of doing it. And so without having those good foundations, those good guardrails in place. Then that's where I see a lot of slop getting generated, is because we didn't set a good foundation ahead of time. We didn't give good instructions. To your point around the increase of things like spec driven development, giving good, solid instructions coupled with a nice foundation set of guardrails, uh, our, you know, a perfect combination to then get good quality software. The same is true if we had humans authoring the code or if we have agents authoring the code, the same is true. And so we have to hold ourselves to an increasingly higher standard. I think in order to really continue to maintain good quality software, the the actual creation of the software is cheap. Managing and maintaining it and just making sure we follow those guardrails is is much more important and valuable. Now,

Host

[00.17.32]

um, at this stage, I also want to get your thoughts on, uh, the implications of whole, um, adoption of AI into software engineering on, uh, the engineering skills themselves. So I came across a study, I forgot where, uh, what was the source? Uh, but it did mention that. While engineers tend to use AI to generate code, not necessarily. It means that engineers trust the code itself. And and they always would like to have an oversight of of uh, the on that code. Right. So where do you see, uh, engineers, um, needing to do, um, the code reviews more and more versus, um, uh, being confident that AI code is good enough, that they can just do the testing and roll it out

Guest

[00.18.29]

again. I think it really does come down to how was the code, what was the input that came into the code that then was being generated? So if there are a lot of good guardrails and structure and those types of things within the code base, then my assumption, right, I would want to verify, but is that the code is continuing to follow those, um, you know, that, uh, that degree of quality. Um, now, I do think that there's still, um. The trust that we have to develop. Um, now, am I reading every line of code that AI is generating? No. Probably not. But what I've really seen a lot of teams, my team's included, really starting to adopt are more tools around understanding the code that gets generated. So we might not be going down into, say, a class or a method level to review the specifics anymore. Sometimes we are, sometimes we're not. But what we are really doing or looking at more is how does this change fit holistically into the overall software architecture? What is this change impact? Does it, you know, change the way that we interact with the third party service, for example? Understanding that I think is more important. And that's where I think I see a lot of engineers struggling is we're losing that that conceptual understanding of the system because we didn't author the code. We didn't code through the hours of soil and troubleshooting to get the thing working. We don't understand it to the same degree. And so that's where, you know, I think it is really valuable to take not only the spec as in the planning stage, but also an architectural understanding, you know, diagrams and those types of things that are getting generated. Those are really helpful for also understanding, uh, the, the software that's getting created. Um, now it's, you know, the skills that are needed for engineers. I think we're still trying to figure that out, honestly. Um, I think we're still trying to figure out, you know, is it, uh, how do I prompt? Is it how do we set up our specs? Is it how do we think about verification? Like, those are a lot of new skills for us as engineers is instead of being the one doing the work, I'm now managing something that's doing the work. And those skills are continuing to evolve.

Host

[00.20.56]

When, when when considering, uh, fact is, uh, most of the engineers. Uh, they, they learn the fundamentals of software engineering. The, the, the good practices about software architecture were purely by going through the experience of building the software. Right. That's what all of us have. I have learned software engineering. Right. But now, given AI being used to build a code more and more. Right. That that opportunity of. Yeah. Doing hands on software coding and building our our skills around fundamentals. That opportunity is diminishing. Right. So I want to get your thoughts on how is it influencing the future software engineers. What how they can actually then in turn review the code from best practices perspective, if they themselves are not potentially missing opportunity of building those fundamentals.

Guest

[00.21.58]

Yeah, if I'm honest, that's one of the questions that I struggle with the most, especially as I think about new engineers entering the field. Right. Um, for many of us, seasoned, uh, engineers are either certain rites of passage that we've all gone through. Um, you know, we've all taken down production. We've all deleted a database. Um, we've all struggled days with a simple syntax error that we just could not see. Um, and those things are just much harder to do or experience as an engineer now. And I think, you know, we it's easy for us to forget some of those as seasoned engineers, those things that did happen that we did have to kind of live through. Um, and so how if we're starting to forget about them a little bit, how is it that we can mentor others on our team that are just starting in their career and are coming up? I wish I had a really good answer for it. Um, you know, I, I don't think that it's fair for, you know, me to be over here with multiple work streams and agents and creating so much code, and then to ask someone who hasn't, uh, had the experience to then go in and go through the normal writing code by hand and troubleshooting and, you know, doing all those things. Um. That's just it's not a not an equal playing field anymore. So it's really, really interesting. And I, I'm still looking for an answer myself for many folks on my teams. Yeah.

Host

[00.23.29]

Yeah. I think that that question is there across the industry, to be honest. And maybe we're not landed on a good a good way forward on that. But what what it means then in terms of recruiting new, new engineers, what kind of skills we should be looking more and more, um, in, in the area.

Guest

[00.23.49]

I mean, I think we're really seeing that how important architecture and really things like system design are becoming. Uh, those are really important skills that for many folks, they don't start to to gather those until much later into their career right there in the senior or senior plus type roles, to be able to gather those types of, uh, understanding or experiences. And I think those are shifting more towards, uh, earlier in career is going to be more important for you to, to know and understand. Um, I think there's also more of a shift to product ownership, where, again, you know, early in your career, you kind of just take a task and I'm going to create this function, and this function is going to be part of a bigger ecosystem. Now, uh, engineers at all stages, but especially early in their career, are going to need to to grow and understand. What does it mean to build a product? To understand how does a user use this product? How does this product fit within a larger ecosystem? Uh, those types of skills, I think are really going to become more and more important. Um, it's it's again, it's a very interesting time. I think a lot of us are still trying to figure a lot of these things out.

Host

[00.25.03]

And that's an interesting point. You mentioned, um, and that was, uh, that that was where I wanted to take our conversation next. Um, because one dimension to this whole, uh, picture is not only engineers need to look at the product side, which they need to completely agree, but also it, uh, AI is enabling even the non-technical product people to also do the coding. And those those lines are starting to blur a bit. Right. And we are seeing, uh, at least as seen in some organizations where, um, you have the product that there are experiments going on where you can potentially have a product owner, uh, who can actually build the product because it's such a small team with some, uh, engineers as consultants, part of their, their teams. Right. So. How do you see this, this whole new operating model or engineering operating model evolving, where engineers need to know bit more about the product side? But product team leaders can also know potentially to the engineering work.

Guest

[00.26.13]

Yeah, I mean I absolutely seen it. I've experienced it in recent projects where a non-technical product owner comes in and is able to create a fairly robust application on their own, just leveraging a lot of the tools that are available. Um, and for me, I, I fully support it because I think it's really important to have somebody with that product ownership, creative mind, being able to get that idea out into into something. Right. Um, even if the code may not be great under the covers, it's at least a really, really great way to communicate. This is what we're trying to build now. One area that I do see teams starting to experiment with, and I think there's, uh, opportunity is to build, uh, tooling around it so that a non-technical person is able to get the idea out and do it in a way that is something that an engineering team would be able to support long term. Right. It has the good best practices in place and the shared design systems. And, you know, CI, CD and all of those things are built into this, this tool that a non-technical user can use. And I think that's really, really powerful because again. It feels like everything is changed and nothing has changed. This idea has. You know, we've been dealing with it since, you know, software was created. There's somebody that within the business that understands the problem that needs to be solved, and they just don't have the tools to be able to do it right. This is if you've ever experienced organizations that were completely run by spreadsheets. Uh, it was, you know, because the the engineering team was, you know, so far behind. And so backlog that, you know, they weren't able to build a new tool. So a spreadsheet became the answer. I think, you know, the coding tools, if you will, uh, are now that answer to the same problem. And if we can put some good guardrails around it, give some good tools and support what we want as an engineering team. Uh, I think that's going to be, you know, a great path forward.

Host

[00.28.20]

What what does it mean from for engineering leaders to think of how to organize their engineering teams? Uh, for, for the, for the future. Uh, and the reason why I ask is I come across organizations where engineering leaders are still contemplating whether, um, what should be the size of their overall engineering team. Right. Um, earlier, before I there used to be some predictability based on this. The the the project demands the, the opportunities which they can see, they can plan ahead as to what should be the engineering capacity. Right now, it's not it's not become that much clear for for most of the engineering data as to how much capacity they need to really plan ahead, uh, how much, uh, uh, automation they can bring to deliver the same opportunities without necessarily onboarding new, new people. Right. What should be the roles they should be thinking of within engineering function as distinct roles. Right. We used to have developers, bas testers, uh, release engineers and so on and so forth. Some of the roles already we are seeing are diminishing. Um, but where you see this is heading one in terms of the capacity planning or engineering functions. Um, and second is kind of roles which will still stick around.

Guest

[00.29.44]

Yeah. I think overall capacity, I do expect it to shrink. I do expect that, you know, while overall headcount might not shrink the size of specific teams, uh, will shrink. And so we might just have more teams, smaller teams that are working on more projects all at once. And so if that's the case, then I think the the teams will largely be comprised of kind of more. Maybe call them full stack type engineers. They're able to do both front end and back end, very product focused. Um, we may have, you know, very heavy automation Testing engineers, but manual testing engineers. I would expect that to largely go away, which we're already seeing decreasing in the industry, and then to be able to support many, many teams that are developing much more software. I think the the SRE, the infrastructure, the developer, um, experience or developer platform type teams or roles, I would expect those to continue to hold or there's going to be an increased demand in those types of roles. And that really doesn't get into anything that's more, um, agents or AI focused on the development side. That's just more holistically, uh, more kind of broader generalist type engineers, more, uh, folks that can support more engineers and the, the infrastructure that would be required to to support the development and the deployment of just more software being created. Yeah.

Host

[00.31.19]

One question probably I missed, but I wanted to check with you was uh, uh, around, um, bringing more automation in the, in the, in the engineering flow. And what I mean by that is, uh. What I have observed is engineering functions can definitely automate the core tasks that they need to perform, like automation, like code building, test case, test automation, etc. but there are still many other, uh, activities which go around around that that cause those core activities which are required, um, uh, to deliver the outcome. And those exam examples of those are, let's say, architecture governance. Right. Um, we're checking whether we are following, uh, established, uh, uh, organizational standards that runs from architecture perspective. Sometimes it is legal, uh, assessment required for certain types of projects. Sometimes there is a data governance that is required. So there are many other functions which also contribute to the end delivery. And these these kind of interactions are most of the times are manual. You use your architecture function to get some kind of support or approvals. You reach out to legal reach out to the data governance. And most of the times that is the bottleneck. Uh, to the security teams as well. Right. To get security assessment or clearance or some of the important aspects. And while the core engineering work could be automated, these other, other, um, interactions and engagements still could result into the, the delay or the, the still long tail in terms of delivery. Um, I have seen some engineering teams now starting to see whether they can even start automating this in terms of. Automating conformance to some architecture practices, automating conformance to security policies. Um, right. So what are the best ways engineers can think of automating these, these kind of interactions so that the outcome can still be accelerated?

Guest

[00.33.36]

Yeah, I'm not seeing a ton of it, uh, personally, but I do see a ton of opportunity there having been somebody that's had to submit to an architecture board or sat on an architecture board doing reviews. Uh, you know, I think there's a lot of opportunity, especially because, uh, the, the artifacts, the things that we're communicating about are in the code, they're in the code repository. And so if I can define, hey, here's my cloud architecture that I'm proposing with, you know, all of the, the security groups and the, the VPCs and all of those things are codified in the code base, and I can easily submit those to something that can do, even if it's only an initial review of, hey, okay, this at least passes the initial review before maybe there's a, say, a human in the loop that does it, a final approval that could drastically speed up something like an architecture review or a data governance review, or something along the security review as well. Right? So many times we would have to propose our plan, go and present that to that particular team. And it may be through a system and maybe through a, you know, a meeting once a month, depending on what it is now, because we have those artifacts, we can present those to something to do a review. I see a lot of opportunity to to speed up that process and really reduce the frustration, both from an engineering team and from the team that's responsible for, you know, making sure that everyone is following the guidelines

Host

[00.35.09]

as we start wrapping up. Um, Brian, um, I wanted to get, uh, your thoughts on, um, I think I understand you, uh, advocate the philosophy of, uh, uh, uh, hands on CTOs. Um, and, uh, because most of the in most of the organizations, as organizations become large, uh, the technology leaders in general, including CTOs, they, they become hands off. They they focus more on the, the people that achieve the broader strategies and priorities, etc.. Right. It seems that you, you you argue that, uh, the senior technology leaders should also equally be hands on. Um, uh, technically. Now, I wanted to just get your thoughts on that. On that? Why do you think that matter? Yeah.

Guest

[00.35.56]

I mean, I, even in my career, have started to, had started getting away from kind of being as hands on keyboard day to day. Uh, just my responsibilities and so forth changed. But now I think it's it's really important for, uh, technology leaders to be back hands on, almost to the degree, when we were engineers early in our career and most of what we did, because not only is the the industry and the way that we built software shifting so quickly, there's so many different tools and, uh, patterns and frameworks and architectures that are starting to evolve just around how do we build, uh, in the Atlantic world? Um, I think there's just so much opportunity. And really, one of the big reasons that I think as, uh, engineering leaders, we need to be hands on is because we largely are pushing a lot of the, uh, the ideas and the agenda behind how does our organization adopt some of these tools? Right. We hear a lot about engineers, especially folks that are kind of senior, aren't really willing to adopt AI, AI development code, right, because of the slop, because of the quality that's produced, I can't trust it. So as leaders, if we can demonstrate, hey, I was able to create this, it is good because I know what it is good. And I can demonstrate that to my teams. That's a really valuable, um, way to kind of promote and push the idea that as an organization, this is where we're shifting, this is how we're shifting, and I'm doing it myself. And so, you know, I'm very much, you know, I if I'm going to walk the walk, I'm going to talk the talk. I want to make sure that if I'm asking my teams to do something, I'm doing it as well. One last question

Host

[00.37.44]

probably is to to get your advice to those CIOs as it years, who might be on the early stages of the journey for their organizations to get on to, um, AI embedding AI into software delivery. What are the key learnings that you want to share with them? What are the mistakes they should avoid, um, in embedding AI into their software practice in.

Guest

[00.38.12]

Yeah. I think it's at this stage. How early? I mean, it feels like so much has happened, but we're still very early stages. I think it's important to just be in a playful, curious experimentation mode. I think that's really important. Really valuable to allow ourselves and our teams to start to understand and to use these tools and to figure out what they're capable of and how do I like to use them, and how does this fit into my workflow? Is my workflow changing? I think it's really important to support that opportunity to experiment. Um, additionally, you know, how do we manage the tools? What tools do we give out? How many, you know, token credits or those types of things? You know, I think that's something that we still have to, you know, we're probably going to spend a little bit more than we're comfortable with, but it is something that we do have to make sure we keep a close eye on, on how much we spend. And again, you know, what we measure is what we get as a result. And so if I'm measuring your token output, then I'm going to get a lot of token output. But if I'm measuring the the results, the outcome that's created, and then we can really look at how it was created, the speed, the efficiency, the effectiveness. Then chances are I'm going to have a more effective organization overall, and not just a group that's spending a ton of money on tokens and not getting the quality that we're really looking for in the software. But I think right now it's just super important for all of us to remain curious and play with all the tools, see what capabilities they have, and then we'll figure out how they fit into our overall workflow over time.

Host

[00.39.48]

And on that note, thank you. Thanks for your time. Um, I think this was a really good, wonderful conversation. Thanks again. Thanks for your time.

Guest

[00.39.55]

Thank you for having me. It's been great.

Host

[00.39.57]

If you found this discussion valuable, please follow us. Subscribe to Enterprise Desktop and thanks for listening. I look forward to seeing you in the next episode.