AI has the potential to speed up the software development process, but is it possible that it’s adding additional time to the process when it comes to the long-term maintenance of that code?
In a recent episode of the podcast, What the Dev?, we spoke with Tanner Burson, vice president of engineering at Prismatic, to get his thoughts on the matter.
Here is an edited and abridged version of that conversation:
You had written that 2025, is going to be the year organizations grapple with maintaining and expanding their AI co-created systems, exposing the limits of their understanding and the gap between development ease and long term sustainability. The notion of AI possibly destabilizing the modern development pipeline caught my eye. Can you dive into that a little bit and explain what you mean by that and what developers should be wary of?
I don’t think it’s any secret or surprise that generative AI and LLMs have changed the way a lot of people are approaching software development and how they’re looking at opportunities to expand what they’re doing. We’ve seen everybody from Google saying recently that 25% of their code is now being written by or run through some sort of in-house AI, and I believe it was the CEO of AWS who was talking about the complete removal of engineers within a decade.
So there’s certainly a lot of people talking about the extreme ends of what AI is going to be able to do and how it’s going to be able to change the process. And I think people are adopting it very quickly, very rapidly, without necessarily putting all of the thought into the long term impact on their company and their codebase.
My expectation is that this year is the year we start to really see how companies behave when they do have a lot of code they don’t understand anymore. They have code they don’t know how to debug properly. They have code that may not be as performant as they’d expected. It may have surprising performance or security characteristics, and having to come back and really rethink a lot of their development processes, pipelines and tools to either account for that being a major part of their process, or to start to adapt their process more heavily, to limit or contain the way that they’re using those tools.
Let me just ask you, why is it an issue to have code written by AI not necessarily being able to be understood?
So the current standard of AI tooling has a relatively limited amount of context about your codebase. It can look at the current file or maybe a handful of others, and do its best to guess at what good code for that particular situation would look like. But it doesn’t have the full context of an engineer who knows the entire codebase, who understands the business systems, the underlying databases, data structures, networks, systems, security requirements. You said, ‘Write a function to do x,’ and it attempted to do that in whatever way it could. And if people are not reviewing that code properly, not altering it to fit those deeper problems, those deeper requirements, those things will catch up and start to cause issues.
Won’t that actually even cut away from the notion of moving faster and developing more quickly if all of this after-the-fact work has to be taken on?
Yeah, absolutely. I think most engineers would agree that over the lifespan of a codebase, the time you spend writing code versus fixing bugs, fixing performance issues, altering the code for new requirements, is lower. And so if we’re focused today purely on how fast we can get code into the system, we’re very much missing the long tail and often the hardest parts of software development come beyond just writing the initial code, right?
So when you talk about long term sustainability of the code, and perhaps AI not considering that, how is it that artificial intelligence will impact that long term sustainability?
I think there, in the short run, it’s going to have a negative impact. I think in the short run, we’re going to see real maintenance burdens, real challenges with the existing codebases, with codebases that have overly adopted AI-generated code. I think long term, there’s some interesting research and experiments being done, and how to fold observability data and more real time feedback about the operation of a platform back into some of these AI systems and allow them to understand the context in which the code is being run in. I haven’t seen any of these systems exist in a way that is actually operable yet, or runnable at scale in production, but I think long term there’s definitely some opportunity to broaden the view of these tools and provide more data that gives them more context. But as of today, we don’t really have most of those use cases or tools available to us.
So let’s go back to the original premise about artificial intelligence potentially destabilizing the pipeline. Where do you see that happening or the potential for it to happen, and what should people be wary of as they’re adopting AI to make sure that it doesn’t happen?
I think the biggest risk factors in the near term are performance and security issues. And I think in a more direct way, in some cases, just straight cost. I don’t expect the cost of these tools to be decreasing anytime soon. They’re all running at huge losses. The cost of AI-generated code is likely to go up. And so I think teams need to be paying a lot of attention to how much money they’re spending just to write a little bit of code, a little bit faster, but in a more in a more urgent sense, the security, the performance issues. The current solution for that is better code review, better internal tooling and testing, relying on the same techniques we were using without AI to understand our systems better. I think where it changes and where teams are going to need to adapt their processes if they’re adopting AI more heavily is to do those kinds of reviews earlier in the process. Today, a lot of teams do their code reviews after the code has been written and committed, and the initial developer has done early testing and released it to the team for broader testing. But I think with AI generated code, you’re going to need to do that as early as possible, because you can’t have the same faith that that is being done with the right context and the right believability. And so I think whatever capabilities and tools teams have for performance and security testing need to be done as the code is being written at the earliest stages of development, if they’re relying on AI to generate that code.
We hosted a panel discussion recently about using AI and testing, and one of the guys made a really funny point about it perhaps being a bridge too far that you have AI creating the code and then AI testing the code again, without having all the context of the entire codebase and everything else. So it seems like that would be a recipe for disaster. Just curious to get your take on that?
Yeah. I mean, if no one understands how the system is built, then we certainly can’t verify that it’s meeting the requirements, that it’s solving the real problems that we need. I think one of the things that gets lost when talking about AI generation for code and how AI is changing software development, is the reminder that we don’t write software for the sake of writing software. We write it to solve problems. We write it to enact something, to change something elsewhere in the world, and the code is a part of that. But if we can’t verify that we’re solving the right problem, that it’s solving the real customer need in the right way, then what are we doing? Like we’ve just spent a lot of time not really getting to the point of us having jobs, of us writing software, of us doing what we need to do. And so I think that’s where we have to continue to push, even regardless of the source of the code, ensuring we’re still solving the right problem, solving them in the right way, and meeting the customer needs.
